De belangrijkste spelers op de ecm-markt hebben onlangs een nieuwe ecm-standaard bekendgemaakt: CMIS.
De nieuwe ecm-standaard CMIS is door IBM ,EMC, Microsoft ,OpenText , SAP en Alfresco vrijgegeven en zal bij OASIS worden aangeboden om tot officiële standaard verheven te worden. CMIS (content management interoperability services ) wordt ook wel de SQL voor ecm genoemd. CMIS is een open interface waarbij een duidelijke scheiding tussen de content-repository (contentservice) en de contentapplicatie gemaakt is.
Contentsilo’s
Vooruitlopend op de CMIS-bekendmaking heb ik in een eerdere blog-post "Meer CaaS uit het vuistje" op deze site het probleem van contentsilo's en gesloten ecm-systemen aan de orde gesteld. Het acroniem CaaS (content-as-a-service) werd gebruikt. Met CMIS wordt dit mogelijk. De silo's kunnen op een uniforme wijze ontsloten worden.
Meerdere CMIS-repositories (van verschillende leveranciers) kunnen op dezelfde gestandaardiseerde wijze benaderd worden door een enkele applicatie. Een voorbeeld hiervan is hier te zien op www.emc.com/images/about/news/cmis/cmis-screen.jpg. Andersom, verschillende applicaties (Java, .NET) kunnen op een gestandaardiseerde wijze dezelfde content benaderen. Zie bijvoorbeeld de figuur op www.emc.com/images/about/news/cmis/cmis-slide4.jpg.
De huidige concept-CMIS-standaard biedt initieel de belangrijkste 'basic' contentservices als een SOAP- of REST-service. Uit eerdere artikelen en reacties die in het Computable-topic ECM zijn geplaatst, verwacht ik dat het een zeer welkome standaard is.
Mijn vraag/verzoek/uitdaging is om na te gaan wat CMIS in jouw organisatie, product of project kan gaan betekenen. Wie roept?
Hi Paul,
CMIS is inderdaad een zeer welkome aanvulling. Met JCR is het nooit gelukt (had ook een andere insteek en werd door te weinig leveranciers omarmd), CMIS lijkt een goede zet. Simpel van opzet (gelijk SQL), voldoende functionaliteit voor bevragen en uitvragen van repositories, en nu dus al ruime support van de grote leveranciers.
Ook zij lijken te onderkennen dat de praktijk nu eenmaal leert dat organisaties verschillende systemen in huis hebben, en dat het voor die organisaties waardevol is dat er tussen die systemen wel gecommuniceerd kan worden.
Kortom, vooralsnog waardevolle aanvulling, moeten nog een paar leveranciers over de streep. Ziet er inderdaad veelbelovend uit.
In tegenstelling tot de JCR standaard is de CMIS standaard onafhankelijk van de ontwikkeltaal, wat de adoptie kans zal vergroten.
Ik verwacht niet dat er op korte termijn veel zal veranderen. Wel zullen bedrijven het gaan meenemen in hun architectuur overwegingen. Het goede voor de klant is dat de afhankelijkheid afneemt en het zal hopelijk innovatie stimuleren.
ISIS Papyrus juicht CMIS toe en zal deze ook gaan ondersteunen. We zien een grote opportunity in het ontsluiten van andere CMS`en met onze zojuist geannonceerde revolutionaire Papyrus EYE User Interface (zie http://www.isis-papyrus.com/e/pages/pressreleases/2/PR20080922.htm).
De CMIS (content management interoperability services) aankondiging is een welkome en door Inter Access ook wel (lang) verwacht vervolg op de behoefte van vooral grote organisaties om meerdere applicaties te laten werken met content afkomstig uit verschillende repositories.
Eind jaren ’90 werd deze behoefte aan “Content Integration” onderkend door een aantal ISV’s – zoals het Amerikaanse Venetica – van de grote ECM leveranciers. Enkele jaren later ontstond bij de ECM leveranciers de behoefte om zelf dit deel van de klantvraag te kunnen invullen. Acquisities, zoals die van Venetica door IBM, waren het gevolg. De opkomst van Federated Search – waarbij een ECM-zoekvraag kan worden gesteld aan verschillende informatie silo’s – was een ander gevolg.
Nu zijn we aanbeland bij de volgende stap, de ECM leveranciers gaan zelf samenwerken en komen met de CMIS interoperability standaard.
Voorlopig gaat het om de samenwerking van een aantal grote wereldwijde leveranciers. Interessant is de samenstelling van de participanten in CMIS. Een deel van die leveranciers levert volledige high-end ECM oplossingen, terwijl een ander deel juist actief is op het gebied van Basic Content Services. Dat maakt dit CMIS initiatief op korte termijn vooral interessant voor een beperkte groep grote organisaties, enerzijds organisaties die beschikken over meerdere high-end ECM systemen en anderzijds organisaties die een BCS-systeem (gaan) gebruiken naast – of als gebruikersvriendelijk front-end – voor een high-end ECM-systeem.
Belangrijke vraag voor de Nederlandse markt is of – en zo ja, wanneer – de lokale spelers gaan aanhaken op CIMS. Ik ben met name benieuwd welke impact dit gaat hebben op de rol van de lokale spelers binnen de totale ECM markt. Het CMIS-initiatief lijkt voor deze lokale spelers een langzaam veranderende rol van ECM-leverancier naar die van applicatieleverancier mogelijk te maken.
Nu steeds meer mensen ook voor hun werk gebruik gaan maken van Web 2.0 services, ontstaan meer informatiesilo’s. Foto’s worden opgeslagen in Flickr, video’s op YouTube, presentaties op SlideShare etc. Naast silo’s op bestandsformaat, zullen er naast interne en nu ook externe silo’s ontstaan. De integratie van die silo’s gaat daarmee steeds belangrijker worden. Integratie in de user interface wordt vaak geboden via een zoekmachine. Integratie in de repositories kan naast de presentatie echter ook voordelen bieden voor de informatie- en documentmanagement functie. Ik ben benieuwd of de Flickr’s van deze wereld deze extra toegevoegde waarde ook zien en met CMIS hun repositories gaan ontsluiten.
Een goede evolutie, webservices is al enige tijd de manier om tussen systemen te communiceren. CMIS zet daar een laag, een protocol bovenop. Dat er grote en gevarieerde namen achter staan geeft goede hoop.
JCR, JSR 170&268 content repository API, is te beperkt en specifiek om breed toegepast te worden. Slim maar niet sterk is dat de standaard voortkomt uit een vendor, Day. Tel daarbij op dat het java georienteerd is en zich daardoor beperkt. CMIS is niet echt een revolutie, het zal het uitwisselen van informatie zeker vergemakkelijken, maar zal geen echte veranderingen met zich meebrengen.
Voor mij als adviseur bij de aanbesteding van een ECM pakket komt de nieuwe standaard CMIS als een stukje ?CAAS? voor een hongerige muis. De discussie voor het vaststellen van de standaardisatie eisen is al menig keer gevoerd. Het doel is immers is altijd maximale interoperability.
Maar hoe laat je dat terugkomen in je plan van eisen? Het afdwingen van standaarden zoals JCR (Java Content Repository) is te beperkt en te specifiek en het opnemen van eisen voor een ?alles-in-een? ECM webservice te breed.
CMIS biedt daarom een goede basis om mee te nemen als ?standaard? eis in een ECM pakketselectie. De vraag die hier echter nog niet beantwoord is: ?Hoe verhoudt deze nieuwe standaard zich tot het gehanteerde informatiebeveiligingsbeleid??.
CMIS… een evolutie binnen de SOA revolutie.
Voor de volledigheid: Het 7e lid van de CMIS werkgroep is natuurlijk Oracle.
In bovenstaande reacties wordt een aantal keren JSR170 (aka JCR) genoemd. Dit is een Java-only standaard die nu inderdaad vaak met CMIS wordt vergeleken. JSR170 heeft het nooit gemaakt met als belangrijkste redenen: Java-only, niet geaccepteerd door grote softwareleveranciers, te complex. CMIS is op die punten precies het tegenovergestelde: programmeertaal-onafhankelijk, door de grote ECM spelers gedefinieerd (tijdens een ‘plugfest’ is compatibiliteit tussen de diverse CMIS-implementaties getest) en betrekkelijk eenvoudig door de heldere functies en een zoektaal die vergelijkbaar is met SQL.
De bedoeling van CMIS is om basic-content-services te bieden die via alle repositories (van de werkgroep-leden) geboden kan worden. Deze standaard zal dus niet alle toeters en bellen van een leverancier bevatten. Wat ik zelf verwacht is dat er nieuwe ECM-applicaties zullen komen die repository onafhankelijk zijn, net zoals er nu veel applicaties zijn die een database op de achtergrond gebruiken, maar deze niet “embedded” hebben.
De commoditization van ECM zet dus door: een ECM repository wordt net zo’n commodity en standaard onderdeel van de IT-infrastructuur als een RDBMS. De toegevoegde waarde zit ‘m in de applicaties en ontwikkelgereedschappen.
CMIS betekent dat bedrijven
– veel meer per content type (editorials, media, product informatie, documenten) in 1 systeem zullen gaan beheren (de zogenaamde “single source”). Dit bespaart enorm aan management tijd en zorgt voor een veel hogere kwaliteit (correct, compleet en up to date). Tevens zal de time to market van content wederom flink verkort kunnen worden.
– Voor leveranciers zal dit betekenen dat ze meer gaan richten op specifieke applicatie toepassingen. Dit zal de snelheid van nieuwe applicaties en niche marktontwikkelingen alleen maar ten goede komen.
Sterktes:
– Een meta-standaard die ECM databases in 1 richting duwt
– Eindelijk iets van een standaard uberhaupt
Zwaktes:
– Vergt nog steeds zeer intensief en uitgebreid documenteren (en dus bestuderen) van de mogelijkeden interface van het ontvangende systeem. Je kunt met CMIS de gekste objectstructuren verzinnen, maar dat wil niet zeggen dat het ontvangende ECM systeem ze kan ontvangen, opslaan en gebruiken.
– Je moet dus als koppelend developer nog steeds erg veel kennis hebben van hoe het remote ECM systeem in elkaar zit, wat het kan, hoe het werkt, wat wel en niet de bedoeling is.
– Web content management maakt uitdrukkelijk geen deel uit van de standaard. Erg jammer, want web content zit in vrijwel elke ECM toepassing wel ergens. Standaard met een gapend gat.
kwam net nog een aardige tegen:
http://www.fiercecontentmanagement.com/story/day-ceo-david-nuescheler-discusses-cmis/2008-10-07
Niet zo vreemd dat hij sceptisch is, dat wordt Dag jsr repository standaard.