The current gap that I see in the ECM standards is in the world of SOA. I’ve tried to make a case for having such a standard in the past. However, Bex Huff said that we don’t need another ECM standard. Let’s look at the existing standards and see if one of them can fill the void.
ODMA was the first standard in this space, back when this space was just called, and justly, Document Management. In short, it made your Microsoft Office applications automatically interact (Save, Open…) with a Document Management system. When PC Docs started supporting it, I was ecstatic. My life got so much easier.
Then came the age of the Web Application, Java, and the desire to not have to manage a fat client on the users’ computer. As poorly as ODMA may fit in today’s IT world, it solved the problem that needed solving. It is remarkably like today’s problem, but instead of plugging ECM into Enterprise Systems, we were just plugging in the users’ productivity applications.
WebDAV is one that seems like a winner at first glance. It allows for the retrieval of content in a standard URL. It allows for some manipulation of properties. It even allows you to lock content in order to update it.
However, WebDAV doesn’t really cut the cake. If you want to Version content, you have to wait for a proposed extension. As for security, forget it. It has stronger security than RSS, but you can’t modify it using WebDAV. It works for people needing an easy way to get content to and from a server from their desktop or remotely, but it doesn’t give you everything you need for true ECM functionality.
Java to the Rescue?
Starting with JSR 170 and evolving into JSR 283, the Java Community tried to provide a way for developers to access ECM systems through a common API. I nice briefing of the whole Java Content Repository concept is provided on The Server Side.
Of course, it is an API and is strictly for Java people, so it fails to fit into a true SOA solution.
What Is Needed?
What we need is simple. I can sum up some key points:
- Technology Agnostic The standard should be easily implemented by people running Java, .NET, or some other technology. While many ECM vendors offer multiple options, the Content Applications that people will want to plug into them may not.
- Function, Not Feature The capabilities supported by any ECM SOA standard should support the functions that Content Applications need to have supported. The capabilities should not be driven by the features of all the products that want to jump on board.
- Vendor Agnostic The terms describing the standard, and everything else about the standard, should not use terms that are unique to any one vendor. They should use terms that are accepted in the community at large. We use the term portlets these days, not gadgets for this very reason.
- Extensible There needs to be a way to support calls outside the standard. A vendor would have a list of available Service Extensions that a Content Application could query. The CA could then make service call to the Extension Service, where the call’s parameters include the name of the vendor’s specific service function.
- Modular Some functions are RM specific. Some are WCM specific. Some apply everywhere (like Save). There needs to be an ECM SOA standard, and then maybe a WCM SOA Extension that would collect a bunch of services that are unique to the WCM world. Examining the extensions that vendors provide for the ECM standard would help define what those need to be, though not necessarily how they are implemented in the standard itself.
Speaking of AIIM, maybe the Interoperable ECM Committee (iECM)? I plan on checking them out in the next week to see if there is any hope in that effort. I currently have no set opinion on the effort, so now is the time to objectively see if they can solve the problem, and if I can help.