I just read Chuck Hollis’ appraisal of the impact of the Content Management Interoperability Services. I followed a couple of links and there is so much commentary you would think Ron Paul just selected CMIS as his running mate.
Despite Chuck’s nifty acronym (that I will now use often) It strikes me that I’ve heard this before. Every few months or so Marko hits me in the back of the head with the ODMA spec and opines about the missed opportunities. Chuck says this is different because the right vendor’s are backing it. Well, if memory serves – the same players were involved then as now (at least the ones that existed way back in ’94)
It is not necessarily vendor involvement that drives the adoption of standards. Often it is the success of products that use them that causes standards to take off. ODBC and SQL as standards owe their success, in no small part, to the success of Oracle itself. Back in the day – SQL wasn’t the only game around nor was it necessarily the best. Read it from one of the guys that lived it (Dave Kellogg) in this old but interesting post on Ingres.
It’s good for developers but make no mistake that making use of standards will benefit the vendors. It is simply easier to code to a good set of universally accepted requirements. Unfortunately they could actually hobble the efforts of the also-rans that support the spec but can’t keep up with the pace of innovation. Standards at some level work against competitive advantage and force a vendor to differentiate their product lines on capabilities that are not necessarily relevant to the core function the standard was intended to support.
I’m not saying I’m against standards – I am glad our industry is now mature enough to settle down around them. They are inevitable, necessary and a critical part of the maturation of our industry. But I wonder, did JSR 168 really break any silos for portals? It is arguable that the spec didn’t improve throughput of development either yet we all checked that box when we picked portal related products – except when it came to Microsoft. Clearly MS saw no need to consider JSR anything with MOSS still they are cleaning everyone’s clock (yes – it is too a portal and I know it’s not Java but that’s not the point)
What this really means (maybe) is that so long as the spec is popular, your vendor selection will focus more on the add-ons than how well they do the basics. Clearly this favors the larger players on enterprise deals who have phone book sized product lists and relegates the newer entrants to competing on price. This is certainly how the database market played out – at least until the open source community delivered MySQL with the best price of all and became the most used RDBMS in the world. So CMIS may indeed be the best thing for standardization since the Code of Hammurabi, but be careful what you ask for.
Lee Dallas
Marko Sillanpää
ODMA had over 100 product, both EDMS platforms and platform utilities, from almost 60 vendors supporting it. What it did best was to allow small tools vendors to build integrations into several platforms at once. Of course the biggest bang around ODMA came when the Microsoft Office Suite added support for the platform. So what was it that killed ODMA, lack of adoption by the developer community. Four years later, the same issue would keep Venetica from its full potential.
At the time the idea of document management was still new to most and the idea of developing ones talents with a single vendor seemed the smart thing to do. But over time the platforms that were so very different became very similar in functionality. This is why CMIS will have a much better chance, but only if people developing solutions on top of ECMS look to use it. The opportunity becomes even larger as we look at CEVAs.
In fact CMIS could not come at a better time for those developing CEVAs. By developing your CEVAs against CMIS, solutions will be able to support multiple platforms. This will eliminate the need to put all the focus on a single vendor.
But this will only be successful if the development community jumps on board.
Too much that I want to talk about this topic. I’m trying to have controlled bursts….
ODMA’s failure wasn’t really its fault. It required a desktop component to work. The Web interface killed it. It is hard to have your productivity app work with an ECM system without some client.
CMIS is different and the ODBC comparison is a great one. As I’ve said before, it is what we need.
DAMN! I’m excited.
Valid points all, Lee. Thanks for sharing your perspective.
What do you want to see product-wise, etc. from ECM vendors where CMIS support is concerned (e.g. kinds interoperable content applications)? As you offer professional services and products into the ECM marketplace, how does CMIS fit into the picture (or how do you ideally see it fitting)?
As you’ve likely noticed, a fair bit of commentary today talked about CMIS “versus” JCR. The ‘J’ in JCR (for Java) creates a bit of a interop problem if you operate in something other than Java. But that doesn’t necessarily mean that JCR “competes” with CMIS. It depends on your interoperability requirements.
I believe that the same can be said of JSR-168, or for that matter ASP.NET Web Parts.
If you portal supports one language–this is just for sake of discussion as most support WSRP, too–then the current language-oriented standard (or de facto “standard” in the case of Web Parts) may have sufficiently broken down silos (e.g. the narrower standard accomplishes the goal of taking plumbing off top of mind for the solution developer). Are they universal? No; still silos at-large may still exist.
Thanks Craig – great discussion – PIE – think I heard you shout from here – just breath – slowly
I totally get the J vs Common argument and I agree with it completely. I’ve never been a strong proponent of 170/283 for precisely this reason – What is Day’s position on CMIS? I should look that up.
What do I want to see? Simplicity – had a meeting today with a client and discussed an SAP integration. It’s been my experience that the SAP / Documentum interfaces are some of the more stable, straight forward and simple that the catalog offers. The simplicity however did not originate with EMC- it is ultimately driven by the adherence to the ArchiveLink API. There is a weak comparison here but I definitely believe there are lessons to be learned.
Types of apps? Discovery and RM come to mind but I suspect there are more than a few well entrenched architectural positions to overcome with existing offerings. I suspect the first applications will be those that deal with immutable content (images, archived materials) because it avoids much of the potential complexity.
I will say this – If you add one more install to the basic process I’ll lose my mind. C/S, DA, FAST, ACS , Messaging Server, TNail Server, CTS, SCS,DFS, WebTop,DAM,WP, CSS, AARRGGHH!!! WhatEVER you do – put it in the core or DFS and don’t charge another license fee just to support the standard.
Lee, I did startle quite a few co-workers. 🙂
Apps, everything. Collaboration, WCM, DAM, Case Management, BPM, and just about everything under the sun.
Also, I agree with the installation. There are too many things that are “separate”. Licensing is also another issue, but that is best left for another day.
Pie, the web alone didn’t kill ODMA. Not one CMS has gone 100% web, each still has client applications. Simple case in point Office and the Corel suite could both continue to support ODMA. Tools continue to be built in the client server architecture. Here’s Pie’s post on CMIS.
Craig, what do I want to see? Whole offering. As you know, too often engineering efforts stop at the product following the “Field of Dreams” approach. But in order to make this successful you need backing. You need executives at EMC that will own this. Someone needs to make sure that it not only gets the engineering resources to develop it but the marketing and field support to make sure that clients and partners understand it’s value. If not it will be just another engineer sitting on yet another standards body.
I can’t speak for Day directly, but I can point you to http://dev.day.com/microsling/content/blogs/main/cmis.html, where a number of Day folks focused on JCR dialog. I can also point you to http://www.cmswatch.com/Trends/1361-CMIS:%C3%82%C2%A0the-new-Lingua-Franca-of-ECM, where the author (Kas) references a conversation he had with the JCR lead (David)–see my first reference–concerning JCR and CMIS (i.e. not competing technologies).
Thanks, Lee, Pie & Marko for the feedback. What about priority? CMIS was developed with use cases and target scenarios in mind. What is top of mind in this regard (e.g. e-Discovery, content aggregation, content collaboration, etc.)?