Auf die Architektur kommt es an Ein Schnittstellen-Standard beflügelt Content Management Systeme

In Deutschland tummeln sich unzählige Anbieter für Content-Management-Lösungen. Der Vergleich solcher Systeme auf rein funktionaler Ebene ergibt oft keinen klaren Entscheid, denn handwerklich korrektes Content Management bieten beinahe alle Systeme, die heute am Markt verfügbar sind. Ein wesentliches Unterscheidungskriterium ist jedoch die Architektur.

Anbieter zum Thema

SCHNEIDER ELECTRIC GMBH

Heidelberg iT Management GmbH & Co. KG

Die Unterschiede zwischen Content Management Systemen (CMS) finden sich im Aufbau und der Architektur der Lösungen. Die Architektur entscheidet letztlich auch über die Wirtschaftlichkeit und Zukunftssicherheit einer CMS-Plattform. Viele der heute erhältlichen Systeme haben ihre Wurzeln in verschiedenen, zusammengekauften Software-Lösungen, die zu einem Produkt vereinigt wurden. Das Ergebnis ist häufig komplex und kann in Sachen Effizienz nicht mithalten mit einer Software, die aus einem Guss gebaut ist.

Das muss nicht heißen, dass man sich zwischen schlanker Effizienz und schwerfälliger Funktions-Vielfalt entscheiden muss. Eine Lösung mit einer guten Architektur ist aus einem Guss geschrieben und verfügt über eine modulare Struktur, die es dem Anwender ermöglicht, mit zunehmenden Anforderungen zu wachsen und das System auszubauen. So sollte es ein System erlauben, bei Bedarf mit einem Digital Asset Management die Vielfalt der verwalteten Informationsformate zu erweitern oder moderne Kooperationsformen wie Wikis oder Blogs zu bewirtschaften.

Eine weitere Grundsatzfrage ist, wie das System mit seiner Umwelt interagiert.

Beinahe sämtliche Anwendungen, die unstrukturierte Daten bewirtschaften, legen ihre Inhalte in eigenen, proprietären Speichern ab. Das hat dazu geführt, dass heute die wesentlichen Content-Assets in einem Unternehmen in einer Vielzahl proprietärer Content-Silos aufbewahrt werden. Sie kommunizieren untereinander kaum. Informationen zu einem Kunden müssen zum Beispiel in einem halben Dutzend verschiedener Systeme gesucht werden, vom CRM- oder ERP-System, über traditionelle Dokumenten-Management-Systeme und Content-Anwendungen wie Lotus Notes oder Sharepoint bis hin zu Office-Dateien auf zentralen Servern oder dezentralen PCs und Laptops. Die Herausforderung für ein modernes Content-Management-System besteht darin, sich Zugang zu diesen proprietären Content-Silos zu verschaffen.

Königsweg Standard-API

Dafür gibt es zwei Konzepte: Üblicherweise wird zwischen dem proprietären Content-Management-System und den Content-Silos der anderen Systeme eine Verbindung konzipiert – mit teils beträchtlichem Aufwand. Danach wird Content in das Repository des CMS kopiert. Es entsteht ein weiteres Silo mit redundanten Daten. Das Problem – die unterschiedlichen APIs – wird nicht an der Basis gelöst, vielmehr werden auf diese Weise nur Symptome bekämpft.

Seit kurzem gibt es einen alternativen Ansatz, der dieses Problem angeht. Ein internationales Konsortium entwickelt derzeit ein standardisiertes Content-API. Zum Konsortium gehören Infrastruktur-Anbieter wie IBM, Oracle, HP, BEA sowie Vertreter der Content-Management-Industrie.

Informations-Infrastruktur

Mit JSR 170, so der Name dieser Standard-Schnittstelle, steht ein API zu Verfügung, in dem die grundlegenden Funktionen, die ein Content Repository zur Verfügung stellt, wie Lesen, Schreiben, Suche, Versionierung, Zugangskontrolle, verbindlich geregelt sind. Als Ausgangspunkt bei der Entwicklung dieses Standards diente die Struktur des Internets. Das Web nutzt einfache, standardisierte Schnittstellen und Protokolle, um riesige Volumen von Informationen in sich zu vereinen. Zentral ist dabei das Ziel, Information zu integrieren – nicht Applikationen. JSR 170 folgt dieser Logik: Eine standardisierte Schnittstelle ermöglicht es, Informationen aus unterschiedlichsten Umgebungen konsistent zugänglich zu machen.

Die Einführung eines solchen Industriestandards ermöglicht erstmals den Aufbau einer echten Informations-Infrastruktur. Die Integration neuer Anwendungen wird extrem vereinfacht, da Inhalte und Funktionalitäten bestehender Applikationen über ein gemeinsames API zur Verfügung stehen. Ältere Anwendungen, die nicht auf dem Standard beruhen, können durch Content-Connectoren angebunden werden.

Ähnlich wie SQL und ODBC

Software-Entwickler sind in der Lage, ein standardisiertes Repository als Basis für die Entwicklung Content-naher Applikationen zu nutzen. Damit müssen nicht bei jeder neuen Anwendung Basis-Funktionen wie Access-Control, Search oder Versionierung neu geschrieben werden. Die Schnittstelle und das dahinter liegende Repository sind hervorragend gestaltet und bestens dokumentiert. So werden Aufwand und Kosten neuer Eigenentwicklungen massiv reduziert. In der Diskussion um JSR 170 wird oft die Analogie zur Standardisierung der Datenbanken gezogen – mit Recht. Es waren Standards wie SQL oder ODBC, die proprietäre Schnittstellen ablösten und es ermöglichten, dass Datenbanken und Applikationen entkoppelt wurden. Damit wurde es möglich, echte Infrastruktur für strukturierte Daten aufzubauen. In der Welt der unstrukturierten Daten stehen wir heute am Anfang einer ähnlichen Entwicklung.

(ID:2008581)