Basic Structures

There are 4 basic structures that handle everything in a repository.

1. Physical

2. Classification

3. Logical

4. Users/Groups/Roles

We have the folder structure where we could follow the way the organization is structured to implement it. Then we have a classification structure which provides us with a way to customize the various types of files we use. A quick example: In legal documents you handle much of the bulk using MS word format. So only classifying by the type of office file would not give us any meaningful benefit as in this case mostly all are of the same type. We need to create types based on the documents themselves, like contracts, letters, approvals, etc; each type can define the retention period and a set of rules the owner requires like for example which medium you want it stored, or how long should it be kept in active mode before sending it to archival, etc. Custom fields can be added to a type so that sorting and searching can be more powerful and flexible at the same time. The folder view should allow you to view not only its contents, but any classification type defined in the objects it contains. This provides you with a mechanism of displaying each node differently depending on its contents. Music and math files should be displayed differently.

The logical structure is targeted more to the “How do I do this” type of question. It does not reflect the groups in the organization but the most important tasks needed to be performed by teams of people. Examples: How do we buy something? What is the process of acquiring insurance? How do we close a deal legally? How do we ask for services? Who is the expert in IT and databases? All of these questions can be put together in a simple structure to help others find their way without getting into the intricacy and complexity businesses create.

The way I’ve been learning how the last structure should work follows a simple rule. Things should be guided by the role more than the name of the person. So this is what it will look like:

Groups

Roles

People

Groups should have a setting where it tells the system not to go in to big loops by looking down more than 2 levels. What that means is that we can create groups of groups, and they can fall into a deadlock, so by creating a group which is clearly marked as a group only, then the system know where to stop looking for permissions (More on this later). Then roles should define the name, any rules applicable, and especially who is your proxy or backup. The major benefit about this method is that we can have the organization chart embedded into the system nicely, so processes can be created more easily based on groups and roles.