Autoren: Bernhard Zöller, Jobst Eckardt
In fast allen unseren DMS/ECM-Projekten ist eine technische Integration der Archiv-/ECM-Lösung mit (einer oder mehreren) IT-Anwendungen gewünscht. Die funktionalen Integrationsanforderungen sind vielfältig. Der Klassiker ist die Verknüpfung zu Business-Objekten der IT-Anwendung für ein- und ausgehende Dokumente. Zweck: die automatischer Ablage im DMS und das einfache Retrieval aus der IT-Anwendung heraus. Mit anderen Worten: Das Dokument liegt im DMS, die User arbeiten aber nur mit ihrer vertrauten IT-Anwendung und sehen gar keine DMS-Oberflächen. Das DMS ist in diesem Fall nur ein Dienst, der von der IT-Anwendung aufgerufen wird.
Ebenfalls häufig notwendig: der programmierte Aufruf einer ECM-Funktion wie beispielsweise „Neuanlage einer Akte XYZ“ durch die IT-Anwendung (nicht manuell durch Menschen). Hierbei werden in der IT-Anwendung die Stammdaten zu diesem Objekt angelegt (Beispiel: Neuanlage eines Kunden). Danach erfolgt die automatisierte Aktenanlage (hier Kundenakte) in der ECM-Lösung.
Nicht selten wird auch ein (unidirektionaler) Datenabgleich gewünscht, wenn Datenänderungen in der führenden IT-Anwendung auf Dokument- oder Aktenattribute der ECM-Lösung synchron (und nicht erst nach nächtlichem Batchlauf) vererbt werden sollen. Vorteil: Wenn User auf die ECM-Akten zugreifen, sind alle Akten- und Dokumentattribute auf dem aktuellen Stand.
In einer SAP-Umgebung gibt es für eine kleine Untermenge dieser Funktionen (eigentlich nur Ablage und Aufruf von Dokumenten) die ArchiveLink-Schnittstelle. Diese erlaubt nur die Verknüpfung von Dokumenten zu SAP Business Objekten, aber kein Setzen oder Ändern von Attributen oder Aktenstrukturen. Fast noch wichtiger: für Cloud-Lösungen und neue SAP-Anwendungen wie c4c und SuccessFactors ist ArchiveLink praktisch nicht nutzbar. So zuverlässig also die gute alte ArchiveLink Schnittstelle in Tausenden von Installationen ihren Dienst verrichtet, umso dringlicher ist die Notwendigkeit nach einer a) Cloud-fähigen und b) funktional umfangreicheren Schnittstelle.
Mit ArchiveLink stehen die SAP-Anwender aber immer noch besser da als alle anderen IT-Anwender. Außerhalb der SAP-Welt gibt es eigentlich nur die DMS-Hersteller-APIs um eine Integration zu realisieren. Was SAP mit ArchiveLink getan hat – eine für jeden Anbieter nutzbare Archivschnittstelle zu veröffentlichen, an die sich beliebige ECM-Lösungen andocken können, hat eigentlich kein anderer ERP- oder Fachsystemanbieter getan. Folglich müssen diese Anwender entweder einen Archivanbieter suchen, der für die jeweilige ERP- oder Fachanwendung eine funktional passende und hoffentlich auch dauerhaft gepflegte Schnittstelle zur Verfügung stellt. Oder man muss eine Individual-Entwicklung akzeptieren. Beides ist mit Risiken verbunden. Oftmals decken die Integrationen der ECM-Hersteller nur bestimmte Szenarien ab. Wenn diese Komponente nicht häufig genug verkauft wurde, muss der Kunde wissen, wie es um die die Release-Fähigkeit der Schnittstelle bestellt ist. Kritisch wird es, wenn nur ein paar weitere Kunden diese Komponente einsetzen und der ERP- oder Fachsystemhersteller sein Datenmodell oder Funktionsaufrufe ändert, ohne das vorher mit dem ECM-Hersteller besprochen zu haben.
Das Problem ist nicht neu. Daher gab es in der Vergangenheit immer mal wieder Initiativen, eine herstellerunabhängige Schnittstelle in der ECM-Branche für solche ECM-Fernsteuerungsmöglichkeiten zur Verfügung zu stellen. Die bekanntesten Spezifikationen waren DMA (letzte Version vom Dezember 1997) und JSR 170 bzw. 283 (Java Specification Request). Keine der Spezifikationen wurde in Produkte implementiert. Auch andere Spezifikationen, die als „ECM-Standards“ positioniert wurden, erfüllten nicht die o.a. Anforderungen: ODMA war nur eine Client-Aufruf-Schnittstelle, WebDAV ist funktional für ECM-Projekte gänzlich ungeeignet, die iECM-Initiative der AIIM kam praktisch nie aus den Startlöchern, DMA funktionierte als klassische Client-Server-Schnittstelle nicht in neueren Architekturen und JSR bediente nur das Java-Lager, womit man Unternehmen wie Microsoft praktisch ausschloss.
Da aber nach wie vor ein Bedarf für eine solche Hersteller-unabhängige Integrationsschnittstelle gesehen wurde, entstand unter Mitwirkung von IBM, Alfresco, Microsoft und anderen (Open Text. Oracle, SAP und weitere) unter dem Dach der OASIS die erste Version der CMIS-Schnittstelle (Content Management Interoperability Services). Diese wurde im Mai 2010 veröffentlicht und dann auch von einer Reihe von ECM-Anbietern unterstützt. Die Verbreitung in produktiven Projekten blieb relativ bescheiden. In Deutschland gibt es nach unserer Einschätzung ein paar Dutzend Projekte, die CMIS als Bindeglied zwischen IT-Anwendungen und ECM-Plattformen nutzen.
Im März 2017 löste die OASIS die CMIS-Arbeitsgruppen auf, woraufhin dann die Apache -Organisation das CMIS Projekt „Chemistry“ in den „Attic“ verschob, eine Art Wachkomaraum für nicht mehr aktuelle Projekte der Apache-Organisation. Das führt daher nun zur Situation, dass zwar – unserer Meinung nach – eine sehr funktionale Spezifikation für die o.a. Integrationsanforderungen verfügbar ist, es aktuell aber keine Anbieter-übergreifende Community mehr gibt, in der die Schnittstelle gepflegt wird. Daher steht die Frage im Raum, ob man eine technische Spezifikation als Baustein seiner ECM-Landschaft wählen soll, deren Zukunft unklar ist.
Andererseits spielt CMIS bei SAP eine wichtige Rolle, weil die Anbindung der Cloud-basierten Lösungen via ArchiveLink nicht mehr funktioniert. Für die Public Cloud-Anbindung kommt man zur Archivanbindung um CMIS nicht herum.
Zusammenfassende Bewertung und Empfehlung
Nach unserer Meinung kann CMIS ein ECM-Projektbeschleuniger sein, weil nun auch kleinere Fachanwendungshersteller sich mit einer Vielzahl von ECM-Lösungen verbinden könnten, ohne die DMS-Hersteller-spezifischen APIs unterstützen zu müssen. Es gibt ja bereits genügend DMS/ECM-Hersteller, die CMIS 1.1 unterstützen und die meisten müssen – solange es frei zugängliche Bibliotheken wie Apache Chemistry gibt – nicht alles selbst bauen inkl. Test-Suite.
CMIS ersetzt nicht die vollumfänglichen APIs einer modernen ECM-Lösung. Wichtige Themen wie Berechtigungssteuerung oder Workflow – mit all seinen Facetten – ist nicht per CMIS fernsteuerbar. Und wie in vielen Standards sind manche Details nicht punktgenau definiert und müssen dann im Projekt angepasst werden. Aber: wer als Software-Hersteller für ERP- oder Fachanwendungen in seiner Branche ein Dutzend verschiedener DMS-/Archivsysteme mit Einfach-Szenarien wie Dokumentablage, Aktenanlage und Dokument- oder Aktenrecherche bedienen soll, hat mit CMIS eine Alternative zur individuellen Programmierung und Pflege herstellerspezifischer Schnittstellen. So eine Art ArchiveLink für die Nicht-SAP-Anwendungen. 1 relativ stabile Schnittstelle mit einfacher Ablage- und Aufruffunktion statt Dutzende individuell entwickelter DMS-Schnittstellen mit den berechtigten Fragen zur Release-Fähigkeit. Das gilt ebenso für große Anwender, die aus verschiedenen Anwendungen auf eine heterogene ECM-Landschaft zugreifen müssen. Auch hier kann CMIS den Aufwand zur Individualentwicklung reduzieren.
Ein weiteres Argument kann sein, dass CMIS als international offengelegter Standard eine gewisse Unabhängigkeit vom Implementierungspartner der sonst individuell entwickelten Schnittstelle erlaubt. Letzte funktionieren, solange der Entwickler noch im Boot ist. Eine Pflege durch Dritte ist schwer, manchmal unmöglich. Speziell im Archivierungsmarkt könnte es sinnvoll sein, eine Exit-Möglichkeit zu haben, wenn Support nicht mehr verfügbar ist und die Migration auf ein anderes System droht. Mit CMIS hätte man zumindest eine Option mehr, auf Dokumente zuzugreifen, ohne die Hersteller-spezifischen APIs kennen zu müssen.
Wir empfehlen daher unseren Kunden bei ihrem ECM-Anbieter oder im Falle einer Ausschreibung eine CMIS-Unterstützung undogmatisch abzufragen (kein K.O.-Kriterium). Es gibt fast immer herstellerspezifische Integrations-Alternativen, die funktional über CMIS hinausgehen. Wenn man sich für einen Anbieter entschieden hat, der erfolgreich am Markt unterwegs ist (Thema Zukunftssicherheit) und der über eine moderne, von außen aufrufbare Funktionsbibliothek anbietet und vielleicht sogar für die in Frage kommende ERP- oder Fachanwendung fertige Integrationskomponenten anbietet; dann spricht nichts dagegen, CMIS außer Acht zu lassen.
Wenn CMIS aber in zahlreichen kleineren und größeren Projekten (und bei SAP) genutzt werden kann, wenn verschiedene ECM-Lösungen angebunden werden müssen, wenn das Risiko besteht, dass entweder die neue Version der ERP- oder Fachsystemanwendung oder die neue Version der ECM-Lösung dazu führt, dass die individuell entwickelte Schnittstelle nicht mehr funktioniert: in diesen Fällen sollte man CMIS als Option in die Überlegungen mit aufnehmen.
Wenn Sie – als Leser dieses Beitrages – eigene Erfahrungen in CMIS-Projekten gemacht haben, lassen Sie uns gerne via info@zoeller.de wissen. Für Zöller & Partner ist CMIS eine unter Wert gehandelte Spezifikation, der vielleicht durch den wachsenden Druck zur Digitalisierung und ERP- und Fachsystemintegration neues Leben eingehaucht wird. Wir werden es weiter beobachten und vielleicht als Fortsetzung eine Liste von Projekten veröffentlichen, die CMIS als Verknüpfungsschnittstelle nutzen.