Skip to content

Integrating CMS with recordkeeping?

Written by James Robertson, published November 18, 2009

Categorised under: Content management

I provided a CMS short-list to a client today, just one of a number of CMS selection projects that we currently have underway. What made this different, however, was the requirement for integration between the CMS and TRIM, their records management system (RMS/EDRMS).

Their needs were fairly straightforward:

  • Take documents stored in the RMS, select the desired ones via the CMS, and publish them seamlessly to the public website.
  • Locally cache copies of the documents to reduce the impact on the RMS, and automatically refresh the local copy when the RMS version is updated.
  • Allow site visitors to fill in online forms, and store this data directly in the RMS to meet recordkeeping requirements.

It’s lucky that this project has been going very slowly, as a year ago (when they last had time to consider getting a new CMS), there were almost no products in the market that could meet this need out of the box. Thankfully there are now a (small) handful of solutions that can do this, mostly Australian-developed products.

This is a common requirement, amongst government agencies, local councils, and compliance-driven firms. This would be slam-dunk during the sales process for these types of organisations. At yet, capabilities in the CMS marketplace are weak at best.

Why do more CMS products not offer simple integration with records management systems?

When they do have this capability, why don’t they market it?

Tags: , , ,

One Comment:

  1. Marcus Nyeholt commented on November 24th, 2009

    Having developed with Alfresco for ECM/RMS and Matrix and SilverStripe for WCMS, I’ve been involved in integrations from both sides of the story, and in my experience have found there’s a few things lacking on both sides that make it difficult to do things ‘properly’. It’s not just integrating a CMS with recordkeeping, but other types of integrations as well.

    Most WCMS don’t provide a defined structure for interacting with external systems in a way that can be used as a pattern for further integrations, meaning that the integration becomes a highly custom piece of functionality that works specifically against an external system. We’re trying to address this in SilverStripe by providing a base ‘External Content’ framework that provides the basis for integrations, while Matrix has always had the concept of ’shadow assets’ which offers similar capabilities in a more general kind of way. To build once off integrations for various systems without something to build on top of can be risky and difficult to maintain, and the investment involved can’t always be justified unless that cost is shared… by someone needing the functionality, leading to a chicken/egg scenario.

    On the other had, the APIs available for integrating with ECM/RMS systems haven’t always been pleasant or even that open. Various systems behave in different ways under different circumstances, and have different nuances that you can only understand by having some level of experience with the product. Spending the time and effort to learn one ECM/RMS well enough to integrate with it needs to be weighed up against the number of users of that ECM/RMS who are also looking for a WCMS. Again it comes back to the point of being able to justify that cost to do the initial work.

    It’s one area I think that CMIS is going to really help third party integrations, as it widens the number of systems that a development can target… all three of the requirements you mentioned can be developed against the CMIS API, and theoretically speaking that means a write once, connect anywhere approach when integrating to any CMIS provider. Theoretically of course ;) .