Thinking on building an electronic archive?
Looking from a governmental perspective, not only more and more information is created by or sent to our governments electronically. The share of content that is corresponded between governments and citizens on paper is decreasing. Content that is created by or received by a Swedish government is a public record and hence the need for stable archive solutions is increasing as well. How do we make sure that the information stays "in shape" throughout the remaining of times then? There are many issues to take in consideration, and there are many models to follow to get the help as well.
During my participation in projects concerning electronic archives I have found though that there are few good implementations to look at for help. And as archive solutions are using and displaying their full functionality and benefits first when some time has passed and the theories have been tested in real life, we are still in the beginning of the lifecycle of these solutions. Good practice isn't really in place yet, so to speak. There are however some findings that should be considered if you are planning on starting a project for e-archiving your information. In my experience, these are the three most important findings for a project to take in consideration.
1. Run the archive project "by the book"
I mean this in every considerable way; that is documentation, modelling, requirements specification, project staffing, budgeting etc. For example, there has to be a solid design model as a foundation for the information model and data model to be defined upon. Information and data will change over time and the foundations of the business and the business rules are less often subject to change. An example of the difficulties is the entity "client". Often, different departments within the same organisation have different views on what a client is. For this to be solid, the design model should only take in consideration the relations to other entities. And skipping this in order to cut a corner will create problems further on.
2. Develop and adopt a method for how you manage new content
In order to keep the information model and the data model as solid as possible, you should develop a method for how to take new content into the archive. From the example above, how do we manage the entity "client" for this new system since it has a different view on what a client is than any of our other systems? Well, with a solid design model and a method of defining the properties of the "new" client as a part of our already developed information model, the new system should be easier to fit into your solution. The thing here however is to realize that there is no perfect model, only ways of putting cubes into round holes without using too much violence. But remember though, the design model has to be solid.
3. Implement a cross functional information process and a process owner
Since the archiving process begins when content is created by or received by an organisation, the archive function has to be a part of a function that looks on the information through its lifecycle and not through organisational constructs. The archive function has to be regarded as a key stone in the information lifecycle and the information process. Today the archives are however often regarded as the things that happen to the information when the business doesn't need it anymore. Archiving issues hence are often considered when it's too late.
During my participation in projects concerning electronic archives I have found though that there are few good implementations to look at for help. And as archive solutions are using and displaying their full functionality and benefits first when some time has passed and the theories have been tested in real life, we are still in the beginning of the lifecycle of these solutions. Good practice isn't really in place yet, so to speak. There are however some findings that should be considered if you are planning on starting a project for e-archiving your information. In my experience, these are the three most important findings for a project to take in consideration.
1. Run the archive project "by the book"
I mean this in every considerable way; that is documentation, modelling, requirements specification, project staffing, budgeting etc. For example, there has to be a solid design model as a foundation for the information model and data model to be defined upon. Information and data will change over time and the foundations of the business and the business rules are less often subject to change. An example of the difficulties is the entity "client". Often, different departments within the same organisation have different views on what a client is. For this to be solid, the design model should only take in consideration the relations to other entities. And skipping this in order to cut a corner will create problems further on.
2. Develop and adopt a method for how you manage new content
In order to keep the information model and the data model as solid as possible, you should develop a method for how to take new content into the archive. From the example above, how do we manage the entity "client" for this new system since it has a different view on what a client is than any of our other systems? Well, with a solid design model and a method of defining the properties of the "new" client as a part of our already developed information model, the new system should be easier to fit into your solution. The thing here however is to realize that there is no perfect model, only ways of putting cubes into round holes without using too much violence. But remember though, the design model has to be solid.
3. Implement a cross functional information process and a process owner
Since the archiving process begins when content is created by or received by an organisation, the archive function has to be a part of a function that looks on the information through its lifecycle and not through organisational constructs. The archive function has to be regarded as a key stone in the information lifecycle and the information process. Today the archives are however often regarded as the things that happen to the information when the business doesn't need it anymore. Archiving issues hence are often considered when it's too late.