CMIS

Abschied von Content-Management-Inseln

27.10.2009
Von Martin Ortgies

Was CMIS tatsächlich leisten kann

Vergangene Standardisierungsversuche wie die WFMC (Workflow Management Coalition) oder JCR (Java Content Repository) haben sich wegen zu hoher Komplexität nicht durchgesetzt. CMIS folgt dem Prinzip der Service-Orientierung und setzt auf eine möglichst große Einfachheit. Erste CMIS-Implementierungen auf Basis des Draft, etwa von Alfresco und EMC Documentum, sollen die Machbarkeit des Konzepts nachweisen. Entgegen seinem Namen behandelt CMIS nicht Content als Ganzes, sondern bietet lediglich ein Minimal-API für das Dokumenten-Management an. CMIS regelt somit den Zugriff auf Ordner, Dokumente und deren Beziehungen untereinander. Umfangreiche Meta-Abfragen erlauben es einem Client, abzufragen, welche Funktionalität ein bestimmtes Repository durch CMIS anbietet. Aus Sicht des Anbieters bedeutet dies beispielsweise, dass ein Repository, das Versionierung nicht unterstützt, wegen CMIS nicht extra erweitert werden muss. Es wird durch die Metadaten-Abfrage einfach bekannt gegeben, dass Check-in/Check-out nicht möglich sind.

Migration oder CMIS-Client?

CMIS geht davon aus, dass im Unternehmen für die gewünschten speziellen Funktionen auch künftig verschiedene Repositories gebraucht werden. Andererseits verweist die "Banken-IT-Studie 2009" darauf, dass sich die Geschäftsprozesse leichter elektronisch abbilden und automatisieren lassen, wenn weniger Schnittstellen berücksichtigt werden müssen.

Fme-Expertin Mayer plädiert für eine systematische Entscheidungsfindung, ob eine Migration oder der Einsatz eines CMIS-Clients sachlich sinnvoll und ökonomisch vorteilhaft ist:

Definition der Anforderungen

Im ersten Schritt geht es um die Anforderungen an die künftige Nutzung von Dokumenten-Management-Systemen. Welchen Bedarf und welche Szenarien gibt es für die Repository-übergreifende Suche? Existieren beispielsweise nach einer Fusion konkurrierende Systeme mit gleichen Funktionen, wird es sinnvoll sein, die Dokumentenverwaltung auf einer Plattform zu vereinheitlichen. Geht es stattdessen darum, dem Vertrieb Zugriff auf bisher getrennte Kundendaten in der Rechtsabteilung und in der Produktion zu gewähren, bleibt der weitere Einsatz der jeweiligen Dokumenten-Management-Systeme davon unberührt.

Ist-Aufnahme

Firmen sollten für jedes Repository klären, welche Dokumente von wem wie häufig genutzt werden und wie geschäftsrelevant sie sind. Eine zu erstellende Liste aller Repositories muss auch die Frage beantworten, wie hoch die Ausgaben für Update, Wartung und Betrieb sind, ob das Repository vom Hersteller bereits CMIS-fähig gemacht wurde und mit welchen Umstellungsrisiken zu rechnen ist (Performance, Standort des Servers etc.).

Entscheidungsvorbereitung

Auf Basis der Anforderungen und der Ist-Aufnahme lassen sich Kosten und Nutzen schätzen. Wie wichtig und wertvoll sind die Repositories? Wie viel kostet eine Migration beziehungsweise die Entwicklung eines CMIS-Clients? Existiert eine Drittlösung? Denkbar wäre hier eine Übersichtstabelle, in der die wichtigsten Argumente für die Entscheidungsfindung aufgelistet sind.

Konzept/Spezifikation

Ist eine Entscheidung zugunsten des CMIS-Clients gefallen, folgt die detaillierte Untersuchung der Repositories und der darin enthaltenen Attribute. Es ist zu prüfen, wie die durch CMIS angebotenen Repository-spezifischen Funktionen an die Anforderungen des übergeordneten Systems (beispielsweise einer Business-Prozess-Lösung) angepasst werden müssen. Hier wäre zu klären, ob beispielsweise eine bisher nicht vorhandene Versionierungsfunktion im DMS durch einen CMIS-Client bereitgestellt werden kann.

Umsetzung

Im letzten Schritt erfolgt die Entwicklung des CMIS-Clients mit den Schnittstellen zu den vorhandenen Repositories. Die zentrale Aufgabe ist jetzt die Berücksichtigung der unterschiedlichen systemspezifischen Attribute. Im Ergebnis sorgt der Client für eine gemeinsame Suchabfrage, ohne dass sich der User mehrmals unter jeweils unterschiedlichen Benutzeroberflächen anmelden muss.

Gute Chancen für CMIS

Der Bedarf für einen Standard wie CMIS ist groß, weil viele Unternehmen derzeit ihre Prozesse reorganisieren und dafür alle relevanten Informationen benötigen. Da die Anpassungen der beteiligten Hersteller vorab bei Oasis getestet werden, können sich die Client-Entwickler auf die Funktionen konzentrieren. CMIS hat eine fast nicht breiter zu machende Unterstützung aus der ECM-Industrie erhalten, entsprechende CMIS-Adapter werden vermutlich bald nach Erscheinen der verabschiedeten Spezifikation erhältlich sein. (fn)

CMIS oder JCR oder WebDAV?

  • In der Diskussion um CMIS wird gelegentlich von den Alternativen JCR oder WebDAV gesprochen. Vermutlich wird es eher zu einem Miteinander kommen. Gut vorstellbar, dass sich eine Arbeitsteilung zwischen CMIS (Interoperability) und JCR (Entwicklungs-API) ergibt, denn wer ein neues CMS/DMS entwickelt, ist mit JCR gut bedient. WCMs wie Day Communique, Magnolia und Hippo sowie Portallösungungen wie das Oracle Bea Portal und IBM Websphere Portal benutzen intern die JCR-Schnittstelle als Entwicklungsgrundlage.

  • WebDAV wird schon allein wegen der großen installierten Basis (siehe Sharepoint) bleiben. Alle Betriebssystem-Anbieter (inklusive Microsoft mit "WebFolders") unterstützen WebDAV. Ein Miteinander ist wahrscheinlich. Beispielsweise bietet der CMIS-Client von SAP auch eine WebDAV-Schnittstelle an.