Back on July 12, X-Hive was acquired by EMC. At the time, I did a quick glance and was a little confused. I started wondering why they made the acquisition. This was worrisome as I hadn’t had that thought in years about any acquisition in the ECM industry. Maybe the new leadership of the Documentum unit didn’t have the same touch as those recently departed. After all, Documentum has traditionally worked with XML better than any of their major competitors. Even after a few weeks, I wasn’t the only one trying to figure this out. This acquisition seemed to be either an admission of weakness or a purely anti-competitive play. Then I learned some more.
What is X-Hive
First, what is X-Hive? It is an XML repository/publishing solution that is best categorized as Component Content Management. It basically makes the creation of technical manuals and other component documents, like those in the publishing world, easier to create and manage. X-Hive’s approach allows for lots of useful tricks, including making personalized publications and manuals for consumers.
Imagine this. I design a Documentum solution and outline which features and components that are going to be used. Custom documentation could be delivered to the client containing only those sections, and sub-sections, that apply to what the client is going to need. They can still have the complete documentation, but they don’t have to wade through it. If they are installed on Solaris, then all the Windows specific sections can be left out.
Fitting X-Hive into Documentum
It is all very interesting, but it isn’t a new story in the Documentum world. Then a couple of people revealed the acquisition out in a new light. What about Web Content Management? Like most WCM applications in an ECM system with no WCM heritage, WCM in Documentum has been adequate, but not cutting edge. Those in the WCM space seem to think that the integration of X-Hive into the Documentum platform can help place the WCM solution back into the leadership role for the technology.
There are challenges. One is getting X-Hive into the Unified Repository that EMC was finally about to achieve with its release of D6. Another is going out and getting the mind share of the WCM user community. WCM and ECM have always had different user communities. EMC needs to make WCM appear to be important and not just a checkbox. The ECM/WCM divide is where the separation between an ECM platform and a Content Management Application is most apparent.
Word of Pie 
You may have read my piece on this acquisition last week (http://thecontentwrangler.com/article/x_hive_acquisition_boosts_object_based_technology_says_xml_cms_expert/). I make the point that Documentum’s X-Hive acquisition is likely the first move in a re-design of its internal data store so that it can scale more successfully while handling highly granular XML content. The unsuitability of a relational DBMS to XML content management is the driving point behind this acquisition. For additional reading, consider Michael Stonebraker’s thoughts on the end of the one-size-fits-all thinking that pervades within certain relational DBMS circles (http://www.cs.brown.edu/~ugur/fits_all.pdf). Not that Mr. Stonebraker is above cloistered rationalization (he touts technologies that just happen to coincide with his business ventures), but his point about the relational DBMS is worth arguing. Perhaps one more place to research: http://cafe.elharo.com/xml/the-state-of-native-xml-databases/. This article gives a summary of some native-XML database toolkits.
Astoria Software, where I am director of product management, built its own native-XML database a few years before X-Hive built its system. The underpinnings are essentially the same. Both are based on an object-oriented DBMS (not relational); Astoria uses ObjectStore (from Progress Software: http://www.progress.com/objectstore/index.ssp); X-Hive uses Objectivity/DB (http://www.objectivity.com/). The only principle difference is product direction. Our technology is the backbone of Astoria On-Demand, a fully hosted solution for managing XML-based product documentation; X-Hive/DB is a toolkit for customers to build their own systems. Our systems suffers none of the performance problems that typically affect RDBMS-backed XML databases when the object count soars due to high levels of granularity.
In my analysis, Documentum’s acquisition of X-Hive goes a long way toward making the point that an ECM that hopes to scale while managing an ever increasing amount of granular XML content has to go with an object-oriented architecture for its data storage.
Thanks,
Eric Kuhnen
Astoria Software
LikeLike
Eric, I had not read your article or I would have linked to it. I’m not entirely sure I agree with your assessment of what will happen, but your insight is quite interesting. Thank you for sharing.
As for the result, time will tell. I expect some good information to be shared by the end of the year to hear exactly how they plan to integrate the products together.
LikeLike
Documentum will be tied to RDBMS for a long time, their ability to deploy on their customer’s current enterprise DB platforms (Oracle, SQL Server, DB2, Sybase) has proved a very successful strategy that won’t change any time soon.
But while the introduction of FAST into the 5.3 architecture has been a boon to most of the product suite, XML search abilities have been crippled (i.e. not able to search within attribute values) when compared to Verity as implemented in 5.2.
So, I think there is definitely room for integration of X-hive features into the core content server. I guess the question in my mind is “How would this be implemented?”. The RDBMS is not going away, so would there be a new type of file store introduced specifically for XML documents? Would the search plugin have to transparently delegate to multiple sources (FAST and X-hive)?
LikeLike
The Component Content Management link by X-hive specifically distinguishes its approach from the XML ‘shredding’ that is inherent in the current Documentum XML Application (ie. Virtual Documents). It will be interesting to see what the long-term plans are. Will we retain 2 separate XML storage strategies (X-hive and Virtual Documents) or will we see the current XML application functionality (most of which is embedded into DFC) be ported to X-hive storage?
LikeLike
Eric,
One minor correction: X-Hive/DB no longer uses Objectivity/DB. We replaced that with our own code some time ago to improve performance considerably.
LikeLike
I’ve been reading the recent announcements about the EMC/Documentum X-Hive release with a sense of deja vu. First, analysis I published in August 2007 showed that the first step by EMC/Documentum would be to integrate X-Hive into the product stack. My sources inside DCTM tell me that in this first release the XML content is already being shifted over to X-Hive; only metadata stays in the RDBMS.
Remon confirms that X-Hive got rid of the Objectivity/DB core “some time ago” to improve performance. That jives with rumors a few years ago that earlier versions of X-Hive were slow in some scenarios. However, eliminating the third-party OODBMS may also have been driven by concerns over IP ownership; X-Hive would never have been an acquisition target if its critical intellectual property was built over vendor-supplied technology.
Second, the air-cover release announcement (http://www.emc.com/about/news/press/2008/20080428-01.htm) has a vendor quote from CaseCentral’s CEO, Tom Thimot. It’s a small world; I worked for Mr. Thimot at GoRemote until we were acquired in 2006. (For the record, Mr. Thimot was a good CEO.)
Thanks,
Eric
PS: I’m now running the west coast office of Focal Partners, a market research firm specializing in competitive intelligence for sales teams. I’m having a field day with EMC/Documentum + X-Hive.
LikeLike