Departmental vs Collaboration Repository

Developing a repository is synonym of creating a departmental document’s safekeeping. Putting aside proper taxonomy definition, organizational site structure is defined and respective department start throwing their documents inside it. It will help on promoting single source of truth by promoting multiple access by internal staffs, dealing with departmental documents.

Times goes on then suddenly there is another requirement of setting up another repository for non-departmental repository which of course not involving same department’s user. Hence a collaborative repository created and users start dumping relevant documents.

A question suddenly appears, is there any relation between departmental and collaboration’s repository?

When setting up a repository most of the architect will found issues on managing access level for user’s accessing the location. The repository created was mean for internal staffs but at the same time required to be accessible by external or cross departmental users. Granting access for specific documents is do able, but will it solve the issue or creating other issues? Let see some of the scenarios with pros and cons.

ECM Life Cycle

  1. Granting Access At File / Folder Level
    Pros: The easiest way to do without concerning for the user accessing other contents. Find the user in existing database or create a new user directly assign to the specific files/folders. The access might be temporary and required to be revoke once access no longer required.
    Cons: Once in a while still acceptable. But when dealing with multiple files and too many users it will cause issues on managing the repository. Cataloging on assignation will be massive and difficult to manage. Most of the cases repository administrator do not revoke granted access when the assignment completed. Housekeeping will occur once audit issues arose or blunders on.
  2. Copying Files at Another Repository
    Pros: Created repository designated for collaborating and assigned for certain members. Assigned user can have roles as low as reader and as extensive as the owner.
    Cons: Replication of documents caused inconsistency of creating single source of truth repository. Issues arose when trying to identify which repository holding updated version or meaningful information. Furthermore content owner were not properly defined. When it is resides in a collaborative repository it will be identified as a join venture ownership,  not any organization or department’s specific.
  3. Downloading and Distributing Required Documents
    Pros: No user access required to be created and be accessible to anybody.
    Cons: Again not referring to the designated repository will promote multiple source of truth. Furthermore releasing the document outside controlled repository definitely exposing for information leakage.
  4. Managing Content Life Cycle Through Multiple Repository
    Pros: Documents travels through out it’s content life cycle, jumping from one repository (ie: collaboration repository) to another, until ultimately it has been identified as record (ie: departmental repository). Even though it has been created as a record, it still capable to be re-initiate into another content life cycle.
    Cons: A comprehensive workflows required to be identified before it can be applies.
  5. Metadata Consumption
    Pros: Defined metadata mostly presenting to keys element that representing common usages. As example Project Name, Fraternity and many others. A collaborative repository as example Project XYZ can consume all XYZ related documents from various repository and assign access from within it’s own repository. The single source of truth still preserved with respective originated repository holding ownership of the document
    Cons: Not much content repository products in the market can handle this requirement. Heavy customization is required.

From above listed scenarios shows pretty much of relations between departmental and collaboration repository. Departmental repository were keeping record, governance, reference or consolidation related content while collaborative repository are dealing with content in-progress or enhancement. The relation can up to one departmental repository linked to multiple collaborative repository.

Content Life Cycle from Multiple Repository


Giving another example, a Project site  is a collaboration repository. Most of the implementation document will be deposit in Project site will the governing documents can be access through departmental site (ideally to be feed to the Project site). Once Project’s related have been finalized, consolidated contents going to be archived in the departmental site.

Project vs Department Repository

Leave a Reply

Your email address will not be published. Required fields are marked *