The official documentation is at: http://docs.alfresco.com
Back to Records Management
This sets out the concepts behind the implementation of a records management system for DoD 5015.2 certification based on the Alfresco ECM platform. The underlying implementation generalizes out records management concepts which in turn can be used to construct different records management implementations based on different guidelines, or standards, for records management which might be country or region specific for example MoReq2 for Europe and Functional Specifications for Electronic Records Management Systems Software for Australia.
Key Design Goals
In designing the Alfresco Records Management system we had some key goals we were aiming to achieve, these have been driven and informed by current records management solutions. In looking at currently available solutions they have typically been expensive to buy and implement, unfriendly and difficult to use and in many cases disjointed from organizational requirements. This has resulted in systems which become the providence of the records management department and are used only to archive records. The expense and complexity of the systems which are licensed on a per user basis means that records management rarely extends out to the organizational departments where it needs to be.
Leading on from this our key design goals were;
- simplicity: of use for occasional users;
- reach: to all users in an organization;
- cost: deliver the first open source records management solution;
- implementation: minimize the desktop footprint;
- extension: create a records management infrastructure layer which can be used to implement other records management guidelines and policies such as MoReq2;
- future proofing: provide a potential model and basis for future standards work.
Key Design Decisions
The key design goals influenced the design of the system and led to a number of design decisions, these decisions and their consequences are described here.
Two Phase Filing
The minimization of the desktop footprint means that a user can use the records management system without needing to install any additional software on their desktop. The use of a standards compatible browser and an IMAP email client such as Outlook is sufficient to interact with the records management system. The consequence of this approach, however, is that we do not always have control of the user interface when a user comes to file a record. For example using the IMAP interface for filing records it is not possible to enforce mandatory fields.
This led to our first design decision, we split record filing into a two step process; filing and declare. Filing simply requires the user to place the record into the file plan where they have filing permissions, it does not require them to fill in mandatory fields. The second part of the process is to declare the record, in order to declare the record all of the necessary mandatory metadata attributes must be completed; the system will not allow a record to be declared which is incomplete.
Advantages and Disadvantages
Using this approach has some advantages over and above the minimization of the desktop footprint. Firstly users can be made to correct their own mistakes. Using a single step filing process a user who has Filing capability will be able to file records but not edit the metadata of those records unless they have Edit Record Metadata for Records functional access, but frequently you would not want to give users this as they could then change the metadata for all their previously filed records. With the two stage declare when a user has made a mistake and needs to correct the metadata for a record the records manager can allow them to edit the metadata by simply undeclaring the record. This provides for a much better control of editing record metadata for mistakes and puts more control at the hands of the records manager.
This approach also allows for record completion by multiple people, this is especially useful in workflow situations where various team members involved in the workflow can add their own metadata elements to a filed record with the record being declared at the end of the workflow. The approach holds true even for a single individual where they may not have all the necessary mandatory metadata, but they want to file the record as a placeholder, for later declaration.
Finally this approach opens up the possibility of using other interfaces to the records management repository such as CIFS (network file system), WebDAV, FTP, etc. each of these services could see the repository and file records, but those records would be undeclared.
Whilst our two phase filing does have some considerable advantages we do have to recognize that it introduces more complexity and because filing is not a single step it will take longer. It also means that users will leave records in an undeclared state in the system and the records manager will also need to deal with this situation. To assist in this it is easy to query for undeclared records and it would be simple to provide a user dashlet for Share which shows â€œMy Undeclared Recordsâ€.
Simple User Interface
We have designed the user interface with the typical user in mind, at the sacrifice of the records manager. The records manager will have to work harder in some circumstances to get what they want because our focus has been on ensuring that the user experience for the majority of users is the best it can be. These users will want to carry out some very basic functions with respect to the records management system, such as:
- browsing the file plan;
- filing and declaring records;
- searching for records, using metadata and content.
Adopting this approach should make the system easier to use for the broad majority and hence achieve our goal to reach all users in the organization with records management.
Records Management Services and Model
In order to ensure that the system has a degree of future proofing a meta-data model has been created which supports the requirements for the DoD 5015.2 standard, but also generalizes out records management metadata, such that other models (such as MoReq2, NOARK, etc.) could be implemented on top of the existing model. Indeed the DoD 5015.2 model is layered on top of the underlying RM model. In conjunction with the RM model there are a number of records management services which will allow other systems to easily integrate into an Alfresco RM repository, for example case management systems.
The high level architecture of the Records Management System is shown here.