For those Doculabs clients who find themselves struggling with content stored in a multitude of different repositories, many are asking, “James, what’s the best approach to consolidating our content? We’d like to simplify our environment and reduce the complexity associated with integrating applications to a multitude of different content stores.”
Let me touch on a couple common themes: 1) how these clients got into this situation in the first place, and 2) and how to resolve it (to the extent it can be resolved).
How Did We Get Here?
About 10 to 15 years ago, when many of these content repositories were created, not all content was treated or managed the same way. Images were considered large in terms of file size and required specialized storage subsystems, caching, and annotations. Print and system output were exceptionally high volume and were optimally stored without form overlays (versus the fully composed PDFs we often see today). Electronic office documents needed collaborative tools such as version control. Email correspondence required simple, inexpensive archiving.
And individual business units and departments seeking to leverage content management capabilities generally created systems to meet their specific needs, based on the type of content they were managing and the business process the system was intended to help automate. Then, based on the type of content the business units/departments intended to manage, there were different software products, each of which offered strengths in managing the various forms of content. This was the origin of “best-of-breed”: Why not buy the best software product for your purposes?
Finally, in those days, the funding was seldom available to consider larger enterprise requirements. And so you spent only enough to implement the system serving “your” business unit/department’s specific requirements.
Little did we know back then just how big these systems would become and how critical they would be to business processes. Over a period of 10 years, with content volumes growing at 30 percent annually, a system that started in 2004 with 500,000 objects is now filled with 5.3 million pieces of content.
There are some very good reasons to consolidate repositories. Here are three of them:
- Customer servicing: One of the critical benefits of consolidating content repositories is to provide a common view of the client relationship. The ability to search and view bills, forms, scanned images, etc., is important to answering client questions efficiently – and promptly.
- Records management: In many instances, the time and energy to records-enable a repository can be considerable. Doing so ten or twenty times over, for a variety of different repositories (and those repositories likely having been built on different technologies) is cost-prohibitive.
- Simplification: The last reason to consolidate (and in my opinion, the least justifiable) is the reduction of IT costs that result from a simplified hardware / software / infrastructure environment. To reduce these costs means entirely sunsetting a number of systems – in many cases a process that can take years.
So What Are Your Options?
At Doculabs, we’ve conducted a number of consulting engagements in which we analyzed the options for our clients, and the recommendations that resulted follow some common themes:
- Stop digging. The first step is to prevent the creation of any new repositories. This includes additional “instances” (new collections of documents within a repository). One of our clients has instituted a fairly significant IT expenses / chargeback associated with any business unit seeking to stand up a new repository or instance. In fact, they’ve made the cost to the business unit 15 times the actual expense in order to ensure there is a significant need and justification.
- Declare the target: In order to stop creating new variant repositories, the organization needs to declare a standard repository, and this environment needs to be operational, available, and – ideally – inexpensive for business units to adopt as their target repository. In many instances, organizations will subsidize these costs in some manner, just to encourage adoption of the standard.
- Decide which systems will (eventually) be sunset: Also declare those systems that will be sunset, and set some timeframe in which these systems will be configured as “read-only,” with no new documents to be added.
- Identify low-hanging fruit: Some systems may be out of support, extremely low volume, a pain in the butt to support, or have poor functionality. Ideally, you can migrate a subset of the historical content from these systems – say the last 5 years – but in all too many cases, there is no easy means to segregate needed and unneeded content, so you wind up having to move everything.
- Migrate opportunistically: For the remaining systems that are deemed “sunset” candidates, but are continuing to meet their users’ needs, look for “trigger” events to time the migration of content and the decommissioning of the system. For example, if a system requires a major version upgrade and the upgrade will involve the rewriting of the consuming applications, that might be the optimal time to migrate and decommission – i.e. “when the patient is open”. Additionally, the software vendors themselves often set off trigger events for their existing customers, e.g. when they impose major jumps in licensing costs upon term renewals.
Following these guidelines, an organization can take a pragmatic approach to consolidating its content repositories over time.