Federated repository management--making CM play well with others
There's a lot of buzz about evolving the ability to access and manipulate, through a single interface, content in repositories of disparate content management (CM) systems made by different vendors residing anywhere in an extended enterprise. Most consultants agree that addressing this issue will be one of the most important developments in the CM industry in the next year or so. A bit of history will help put this phenomenon--known as federated repository management (FRM)--into perspective.
The fact is that vendors making applications other than CM have been doing that for about 15 years, according to Ted Friedman, research VP of data management and integration at Gartner. Information Builders offered a data federation and distributed query product first for business intelligence apps to aggregate structured data from relational databases from different vendors, he says. Others followed suit, but structured data was the only content in their field of vision.
FRM products from major CM vendors are expanding that content context; they focus on federating unstructured data. Friedman says that technology advances like XML have made it easier to perform FRM because it provides a common language to represent data in different formats from disparate sources--but with a caveat: FRM for structured data is light years ahead of FRM for unstructured data, and Friedman just doesn't believe it's for real yet in CM.
Other consultants disagree, but not very forcefully. Richard Medina, principal analyst at Doculabs, says that FRM "involves the integration of multiple moving parts, none of which are mature, so it's going to be complex and expensive for the customer." Despite what vendors might claim, you can't just simply layer FRM software on disparate CM apps, turn the key and go. Medina, who's seen many demos, says it's incredibly complicated; for instance, it requires copious integration using what are known as "adaptors" or "connectors," focused functionality for specifically accessing content from a FileNet or Documentum (now part of EMC) repository via a Hummingbird one, for example.
Probably more importantly, the "coopetition" (competition on one level and cooperation on another) necessary to make FRM work--CM vendors sharing proprietary code with other CM vendors to accelerate the development of adaptors--is rife with conflict. IBM and FileNet, for instance, want to dominate CM for finance and insurance and, along with Open Text, purport to have formed an alliance to more easily access content in each other's systems. But what if the Bank of America (bankofamerica.com) wants to standardize on one CM system through which to access multiple CM repositories throughout its global enterprise? It wants an anchor CM system that allows for federation of the functionality and data in its legacy CM systems--which is mission-critical and which will be a multimillion-dollar windfall for the provider. Which of those hypertrophied CM pit bulls is going to hold open the sales door for the other and say, "Oh, no, I insist, you first?"
Cooperation is, according to Priscilla Emery, president of e-Nterprise Advisors, unnatural for these guys, and they're still feeling their way. Emery also says that FRM is a capability customers have been screaming for at least since the Document Management Alliance was formed at AIIM in the late 1990s to better serve the customer. But vendors, despite their public hosannas to openness, in fact, viewed the development as a threat to their installed bases, thinking that FRM would make it easier for one vendor to poach another's customers. The result is the situation customers have now: Multiple CM systems were bought for their different strengths in an ad hoc manner by different departments, and they contain data that are needed enterprisewide, but which are locked in proprietary application silos. For this reason, despite marketing claims that the dominant CM vendors are ECM renaissance men, there is no such thing as enterprisewide content management.