ECM Standards Flurry

Hadn’t planned on this post today. Saw a post out there by Bex Huff that I wanted to comment upon. Bex basically rants in his post. I’m not being dismissive, he states that he is ranting. I like a good chunk of what he says, but I have two comments.

First, a Correction

In regards to universal connectors created by third parties, Bex states that they were bought up and shut down by Documentum. This is not accurate in the least. There were two major players at the time in the US market and another in the European market. Here is what really happened.

These were smart acquisitions as it allows the products to easily communicate with 3rd party repositories without having to leave the primary product. EMC was first, but everyone saw the wisdom and followed suit.

Second, a Clarification

I don’t think I missed the point of Billy’s comment. I think we are missing each other’s point. We even agree on parts. This is a drawback of communicating purely through the written word. I kept it very brief in my last standards post. Now I will be less so.

I said Standards don’t define business. Standards enable business. I may have been overly dismissive of Billy’s overall comment, but I stand by my conclusion based upon what he wrote:

In the view of this blogger, standards may be useful starting points for clients and folks looking at software (ANY software). But a standard will not define YOUR business. It tries to define the lowest common denominator across all businesses-abstracted.

See, we agree about Standards not defining business. What throws me are these lines:

Standards can help you think yourself outside of your own head and clue you into to other things that may be important to you, at some not too distant point. The assumption is that you already know what is important to you now, but you want your software investment to be useful tomorrow as well as today.
Beyond that, standards do jack for the way you do business. You may do some of your business in a standards compliant way, but never all of it.

Billy wrote this before my last post, so I hope he reads it. It talks about the why of standards. Enterprise Content Management is a PART of the ENTERPRISE. As part of the Enterprise, it must TALK to the ENTERPRISE. All the systems can do that now, if you have the time to work through the different APIs. When we take the time to do that work, we lose time that could be spent on functionality.

An ECM web application doesn’t necessarily need to abide by any standards unless you want to embed it in a portal using JSR-168. It may even hurt performance. However, if I want to surface functionality in another application and be able to send security, authentication, metadata, and content back and forth, I need standardized ways of doing it. Without those, we have a lot of work if we have to change systems or the underlying API changes for a product.

The question to answer when defining an ECM Standard is, “What functionality does an ECM system need to provide to the rest of the Enterprise?” The ECM platform is not the end-point any more than a database system is one. A WCM application built on an ECM platform is an end-point.

This could go on for a while, but I will stop here. Bex has a great line that I want to emphasis. All these niche repositories either write an interface, or go away. Classic and great. We want Enterprise Content Management Standards, nothing less. If you aren’t going to pony up, stay in your niche.