This week's hot ECM topic appears to be something other than SharePoint for a change. The news is that the Content Management Interoperability Services (CMIS) proposal has finally made it to OASIS for ratification in to a standard. Rather than boring you with the details of what CMIS is let me give you a few links to some background reading so I can focus on asking the important questions "Why would I care?" and "How does it relate to Microsoft SharePoint and my current ECM solutions?"
Important foot note...don't start planning anything around this just yet...the proposal needs to become a standard and then the vendors need to re-engineer their repositories, services and clients before you can take advantage of this. McNabb suggests 3 to 5 years before you’ll see something to deploy.
What is it?
You have two choices –
1. You could read the official & highly unintelligible marketing spiel – good luck.
2. You might want to head over to Craig Randall's entry on the matter; he has links to other information. Most interestingly he has an easy to follow Podcast interview with Kyle McNabb from Forrester which gives a great primer to the standard.
Why would I care?
Let's go through the usual reasons that you might care...
1. Is it interesting, cool or innovative?
2. Will it increase my job security or pay?
3. Will it make my life any easier?
4. Will it keep me out of jail?
5. Desilofication…
Is it interesting, cool or innovative?
It is an ECM standard - what about that could be deemed to be in any way cool or interesting?
The real question should probably be "Does it stand a snowball in hell's chance of being successful?" Let's face it; we are not exactly short of standards - real, perceived, successful and dismal failures. I suspect that the single biggest indicator to success is not the technical aspects rather it is the fact that it is sponsored by the three biggest players in the market - Microsoft, IBM and EMC, (the “Axis of ECM” as G.W. Bush might call them).
Will it increase my job security or pay?
Given my limited knowledge of the standard I'd say that if you are smart about this then the answer is yes. That said, theoretically it creates a market with fewer solutions. This is because it reduces the number of vendor-centric requirements so it is possible to build one solution that you can implement on top of any CMIS-compliant repository.
The idea is that if each vendor's repository implements the CMIS standard then any CMIS-compliant solution can then communicate with that repository. So if you develop a CMIS compliant document imaging solution you would be able to implement it on top of any CMIS repository. This means that smart people will do exactly that (and make more money) but over time the net number of solutions is reduced.
Will it make my life any easier?
I think the answer is probably “Yes”. As a customer you should see a greater level of interoperability between systems, less complexity and a cost savings, (through purchasing less software and not paying the premium for such specialized staff). As a developer you have a well defined, less fluid, standard interface to program to. Before the SQL standard existed I was an ICL database programmer so take it from me – this is a good thing!
Will it keep me out of jail?
I think that indirectly the standard will help keep systems compliant. I can think of a few reasons but the main one is that separating the application functionality from the repository means that you can chose the best application for your needs and then just implement it on top of the most secure repository. Typically vendors tend to excel in only one or two focus areas - security, scalability, deployability, ease of use, etc. The CMIS approach lets you combine pieces from different vendors to get a true best of breed. This is similar again to SQL as a standard - you buy a system that utilizes a SQL database and then you pick the SQL-compliant database that best suits your needs and budget.
Desilofication?
As Carl Frappaolo from AIIM has noticed I have a propensity to create new words – in fact as a Brit living in the US I feel that it is an obligation. Today’s new word is “Desilofication” – as my frequent readers know, this is my passion in life, (some life huh?)
CMIS really would give you a chance to consolidate your ECM silos like never before. Let each department choose their solution of choice but IT will dictate the repository that it runs on. Now that’s progress! 50 disparate applications and one consolidated repository – it’s a win-win!
How does it relate to Microsoft SharePoint and my current ECM solutions?
I feel like everything above has been a pre-cursor to getting to this interesting question. Let me review…
· CMIS creates a break in the ECM architecture in to two layers:
1. The content-centric application at the top of the stack. i.e. An image processing system, digital asset management application, business process-centric solution, etc.
2. The repository and the library services at the bottom. i.e. The place where the objects and metadata are stored along with the processes to manage those objects (read, write, version, query, navigate, update, delete, move, etc.)
· In SharePoint land the ‘top’ half of the solution is the Web-based functionality, the Office Integrations, your custom SharePoint-based applications, etc.
· In SharePoint land the ‘bottom’ half of the solution is the repository where the content and the library service processes live.
So in theory you could swap out the SharePoint top half and make use of the native SharePoint repository in your own applications. More probably you’d swap out the SharePoint repository and replace it with another ECM vendor’s repository giving you the SharePoint look-and-feel on top of your repository of choice.
Sounds great doesn’t it? So help me out here…can you see how this could be done? I cannot. Let me tell you where I am confused and please help me to understand how this will work.
· Adding a CMIS virtualization on top of SharePoint I get. You’d create a set of Web Services that talk to the different layers of SharePoint and expose the library services in a standardized way.
The code would be pretty convoluted and would have a multitude of touch points at differing layers of the stack but in the end the library services would be rolled up in to a set of Web Services. I wouldn’t try this myself but Microsoft could do it.
· Divorcing the SharePoint ‘top’ layer from the repository I cannot get my head around. Bear in mind that SQL Server is not the repository. The content and metadata might reside there but the library services do not. In order to check out and lock a document in SharePoint you need access to the SQL Server data but you also need the SharePoint code that performs the checkout/lock operation.
From what I know of the underlying SharePoint architecture there is not a clear delineation between the SharePoint web front end and the library services/data. SharePoint simply was not architecture in such a layered fashion. Some of these issues are caused by Microsoft re-using existing fundamental windows technologies, (quite rightly), but the issue still stands.
I do not see you how would be able to install only the SharePoint application but stop all of the library services code from also being installed. The only two options I see are:
1. Re-architect SharePoint to create a clear delineation between the layers.
2. Smoke and mirrors…install the entire SharePoint stack except SQL Server, let SharePoint trigger the native library services and then override their behavior. This seems to be an architecturally indiscrete solution but I’m not an architect so maybe it is fine.
I assume that some of you avid readers will have a much better idea than I wrt whether this is even possible. If you are shy about commenting in public then email me directly and I can consolidate the responses in to a follow-up posting.
