Consolidate, Federate, or Leave It Alone: What to Do about All of Those Disparate Repositories

By James Watson posted 03-15-2011 12:35


Many clients engage us to help them focus on a simple objective: “We need a single repository for all of our documents.” Simple enough, yet right now their content is scattered across five, ten, or fifteen different systems (and, unfortunately, for most of our larger clients, the number of content-related systems is much greater than fifteen). So what are the options?

  1. Consolidate all content into a single repository: This would be ideal, but often the migration costs can be overwhelming. In addition, it’s more than likely a number of applications will need to be re-written, which is also expensive.
  2. Leave the content in its current systems, but aggregate meta data: Also referred to as “federated” content management, this approach provides a virtual “view” of content via a single “parent” database, with pointers to the native resources spread across the enterprise in “child” repositories. This approach presents many appealing benefits – e.g. no need to move content – but accessing the applications will still require re-writing to query the new “parent” database. In addition, access controls can become tricky, as in many cases documents users shouldn’t even be able to see that a document exists, much less get access to it.
  3. Leave it alone, give up, forget about a single repository: However you want to phase this option, I’d estimate that 70% of the time, neither consolidating (Option 1) nor federating (Option 2) is economically justified. Sure, the use case exists; e.g. a banker no longer has to look in one repository for loan documents and another for trust documents. But the costs often outweigh the benefits.

In the end, we find our client is frustrated. And yes, all this could have been prevented in the first place, if the organization in question had conducted careful long-range planning. But what can the client do now?

First, recognize that it will take years to clean up the mess. With that in mind, there are a number of key trigger points for when you should re-evaluate and conduct either Option 1 or Option 2:

  • Major application re-writes
  • Expiration of licensing agreements
  • Re-platforming efforts (e.g. going from Solaris to Windows)
  • Significant vendor code-base upgrades (e.g. going from V1.0 to 2.0)

Thus, at any given point in time, a wholesale consolidation or federation is unlikely, but an organization can opportunistically “chip away” at the problem, one system at a time. Going from fifteen different repositories down to just ten would be a huge accomplishment over 3 years. Keep this in mind when setting expectations for your own long-range planning.


#ElectronicRecordsManagement #planning #consolidation #ECM #repository #federatedcontentmanagement