Content Management Interoperability Services
I’m a little late to this particular party as it all happened early PST which was a little later GMT by which time I was unfortunately otherwise occupied. And there is already a plethora of good, initial write up out there in the blogosphere from my colleagues; Craig Randall, Chuck Hollis, Cornelia Davis, Andrew Chapman. From former colleagues; John Newton. Others in the industry; Bex Huff, Laurence Hart. And of course from the analysts; CMS Watch, 451 Group, AIIM. I encourage you to check out Craig’s interview of Kyle McNabb who is the principal analyst at Forrester.
Content is were most of your organization’s high value information is kept. Just think about the thousands, if not millions of documents, slide-decks, spreadsheets, forms, PDFs, not to mentioned emails that your organization tries to manage. It is the same the world over and it is getting worse. We are generating content faster now than at any time before and this trend continues a pace. Also legal and regulatory concerns are placing more and more constraints on this content requiring it to be managed ever more intelligently, not to mentioned, requiring it to be discoverable.
But everyone knows this and has been attempting to solve the problem for a number of years. Fast forward to the present day and take a look in any typically medium to large enterprise. What you will find is a number of different types of content repository. Each of which was introduced to solve a particular piece of the content management problem; DM, RM, Web Publishing, etc. By and large they solve the problem in their domain but obviosuly each leave us with a silo of information in a repository with yet another interface. This in itself is a big problem. But with each new interface comes another skillset and therefore there is also a not an insignificant cost of ownership attached to each as well.
In short we need to start treating our content more strategically.
To date there have been quite a few efforts to standardize the ECM space but each has had its Achilles heal and none has really achieved what they set out to do, become the standard.
But I am excited about CMIS. It’s based on web services and is therefore agnostic to your client architecture. Something that JSR170 fell fowl of. It doesn’t really favour WS* or REST, it specifies both, so you can use whichever suits your needs. It is backed by us (i.e. EMC), Microsoft and Oracle as well as Alfresco, OpenText and SAP. It only exposes features already present in these vendor’s repositories. So you can have confidence that real implementations of CMIS are imminent and CMIS as a whole will have longevity.
A word of caution though. We should be realistic about the present situation. Even when adopted it’s no silver bullet in the sense that it won’t solve the silo’s problem overnight. But it could be a real enabler. Using CMIS, as the common interface for navigating content and its metadata, we can envisage solutions that allow us to index content in all of our repositories. In turn allowing us, as users, to search and retrieve that content from any repository within the organization. Or even across organizations.
It also makes the future look a lot more exciting. In the same way SQL facilitated solutions like Documentum & SAP. We are hoping CMIS will do the same for content-centric applications and solutions. This is ultimately great news for us all as knowledge workers within content-driven organizations. We will have real solutions to real problems based on the repsitories that are right for us.
Now, to help build those solutions our ISVs are going to need tools…like Composer.Explore posts in the same categories: CMIS, content management, documentum, ecm, emc, microsoft, oracle, standards