Content services and archiving records: It's complicated
Content services complicate archiving. Microservices render records dynamically for many devices, while an archive should be a static rendering that outlives present data systems.
content services abstract how content is stored and managed, hiding the machinations of back-end repositories from business application end users. After all, they don't need to know if the content they are interacting with is in the cloud, on premises or both. That's the content services advantage in the here and now.
Typically, content services support a line-of-business system, such as a case management system, which manages all the key business information and processes. But what happens when the case is finished and you have to keep a long-term record? That's when content services and archiving processes get sticky.
When a company migrates to a different platform, the content might still be available through those same services that point to the new content services platform. But what about the original case data? Will the business system still be available in three, five or 10 years? Will you still be able to view everything you need to get a full view of the record?
Application archiving
A popular trend over the past decade has been decommissioning different business applications. As companies replace these applications, instead of migrating all of their data, they archive it into specially designed systems. These systems enable users to query and retrieve the original business data.
This leads to a system where the business data is available, but it no longer lives in a content services integrated application. To view content with content services, you must generate a link as part of the data archive. Alternatively, you can create a custom search screen to perform a quick search and retrieve content stored in the underlying content services tool using the same services as the original application.
This assumes that you start looking at items via the data archive. Often, someone will be looking at the records and will need to view the corresponding business information. Sometimes that is the only way to properly understand the context of the content, but content services and archiving don't necessarily provide that insight on their own.
Using a data archive for a business system makes a lot of sense on many levels. However, it is an additional cost even if it is offset by savings from shutting down an old application. It also requires work to enable people to move between the data in the archive and the content. Additionally, if an organization decommissions a system before it disposes of the content records, what happens then?
Consider a snapshot
Content is just a collection of data with added context. A business record contains the data and necessary context to understand what is involved in a transaction, process or decision. In order to create a complete business record and meet information governance requirements, why not place a copy of the business data into the content repository, which is basically a content services archive?
This is not to say that active data should be stored in a content system -- that approach is rife with issues. But when a business process comes to an end, a copy of all the related data can be stored as content and placed under the same controls as the content that was part of the process.
In the end, business data can be recorded as just another piece of content.
It could be as simple as a final snapshot of the data, with data fields paired with their values. It doesn't have to be fancy. It just needs to be clear for those that review the information years later.
Content services are already primed to receive this information. The metadata added to the rest of the content from that process applies to this final content services archive snapshot quite well. There is no reason to get fancy. It is just the addition of one final piece of content to the record.
Don't forget the history
A common occurrence when creating a snapshot is a loss of history. When working in a system, it is easy to see the history of actions taken by previous people and to gain key insights that show the why of a decision. The why is often what people want to understand when they review a record.
This is why it is important for any snapshot to include a full history of what transpired. If a business system tracked a change, it is important to add it to the snapshot.
In large systems, detailed audits are kept in external systems. Those may need to be included in the snapshot to complete the full picture. Records may not be necessary every time a person views a case, but every change or addition needs to be captured.
An approach to consider is a dual snapshot. With this approach, you take a snapshot at the beginning of a case and place it in the repository using the content services. When the process is complete, add the final snapshot with all the changes listed. This enables people to look forward and backward for a full understanding of what transpired.
In the end, business data can be recorded as just another piece of content.
Dig Deeper on Content management software and services
