Content Management: Auf die Architektur kommt es an

Die effiziente Bewirtschaftung von E-Mails, SMS, Instant-Messages, Word-Files, PDF-Dokumenten, Bildern, Soundfiles und Videos wird im Geschäftsalltag immer wichtiger – und anspruchsvoller. Ein Ende ist nicht in Sicht, im Gegenteil: Die Analysten der International Data Corp. (IDC) etwa prognostizieren eine Zunahme der Menge an digital kreierten und abgelegten Informationen bis zum Jahr 2010 um das Sechsfache, von 161 Exabytes (230 Bytes) auf 988 Exabytes.

Der Erfolg von Konzernen im globalen Wettbewerb hängt immer stärker von der effizienten Bewirtschaftung dieser immateriellen Güter ab. Mit der zunehmenden Globalisierung hat die Bedeutung der industriellen Warenproduktion stark abgenommen. Vielmehr zählen das Wissen über die Produktions- und Distributionsprozesse sowie die effiziente Kommunikation mit den Kunden. Damit wird die Bewirtschaftung von Informationen zum strategischen Wettbewerbsvorteil. Dazu gehört heute auch die Entwicklung einer konzernweiten Strategie und Technologie zum Management der stetig wachsenden Flut unstrukturierter Daten. Das Resultat: Die Frage nach dem ‘richtigen’ System für das Management all dieser unstrukturierten Daten bekommt eine zentrale Bedeutung.

Die Evaluierung eines Content Management Systems (CMS) ist jedoch alles andere als einfach. Allein in Deutschland tummeln sich unzählige Anbieter für derartige Lösungen. Der Vergleich solcher Systeme auf rein funktionaler Ebene ergibt oft keinen klaren Entscheid. Zu ähnlich sind die Produkte, wenn es um die grundsätzlichen Funktionen geht, die eine Content-Management-Lösung bieten muss. Oft wird in solchen Situationen letztlich nach dem Preis der Software-Lizenz entschieden – eine Vorgehensweise, die langfristig teuer zu stehen kommen kann.

Handwerklich korrektes Content Management bieten beinahe alle Systeme, die heute am Markt verfügbar sind. Die wesentlichen Unterschiede zwischen Content-Management-Systemen finden sich im Aufbau und der Architektur der angebotenen Lösungen. Hier liegen die wesentlichen Faktoren, die über die langfristige Wirtschaftlichkeit und Zukunftssicherheit einer CMS-Plattform entscheiden.

Welche sind die zentralen Aspekte bezüglich der Architektur eines Systems, die es zu beachten gilt?

Zuerst stellt sich die Frage nach dem internen Aufbau und damit der Effizienz einer Lösung. Viele der heute erhältlichen Systeme wurden aus verschiedenen Software-Lösungen zusammengebaut, die im Laufe der Entwicklung des Anbieters zusammengekauft wurden. Wenn jedoch funktionale Blöcke nicht optimal aufeinander abgestimmt sind, kommt es häufig zu komplexen, ineffizienten Lösungen. Hier ist Zurückhaltung geboten: Eine Software, die zusammengetackert wurde, kann nun mal in Sachen Effizienz nicht mithalten mit einer Software die aus einem Guss gebaut wurde.

Das muss im Umkehrschluss nicht heißen, dass man sich zwischen schlanker Effizienz und schwerfälliger Funktionsvielfalt entscheiden muss. Eine Lösung mit einer guten Basis-Architektur ist aus einem Guss geschrieben. Gleichzeitig verfügt sie jedoch über eine modulare Struktur, die es dem Anwender ermöglicht, mit zunehmenden Anforderungen zu wachsen und das System weiter 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. Damit werden hohe Kosten vermieden, die entstehen, wenn separate Systeme für diese Anforderungen von einem anderen Anbieter später dazugekauft und integriert werden. Neben der internen Architektur stellt sich bei der Evaluation einer Content-Management-Lösung eine weitere Grundsatzfrage.

Wie interagiert das System mit seiner Umwelt?

Zu Beginn des Internet-Booms waren CMS als separate funktionale Blöcke konzipiert, deren Aufgabe es war, ein klar umrissenes Set von Inhalten – meistens Web Content – zu bewirtschaften. Dazu wählten die meisten Anbieter eine Architektur, bei der diese Inhalte in einem eigenen, internen Repository aufbewahrt werden. Die Schnittstelle zwischen Applikation und Repository, also das API (Application Programming Interface), war dabei vollkommen proprietär.

Dieser Ansatz bringt zwei zentrale Probleme mit sich: Zum einen gerät die Wahl für ein System zu einer Entscheidung für einen spezifischen Anbieter und dessen proprietärem API. Die Folge: Ein Wechsel zu einem anderen Anbieter ist prohibitiv teuer. Wenn die zentrale Schnittstelle eines Systems proprietär ist, gehen bei der Migration auf das System eines anderen Anbieters beinahe sämtliche Aufwände, die in den Auf- und Ausbau von Struktur, Funktionalität und Inhalt einer proprietären Content-Plattform investiert wurden, verloren. Oft betragen diese Investitionen ein Mehrfaches der Software-Lizenzkosten eines Systems.

Das zweite Problem geht über den Bereich reiner CMS hinaus: Beinahe sämtliche Anwendungen, die unstrukturierte Daten bewirtschaften, legen ihre Inhalte in eigenen, proprietäten 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, die untereinander kaum kommunizieren – und das in einer Welt, in der die effiziente Bewirtschaftung dieses Wissens ein zentraler Wettbewerbsvorteil ist. Wer heute in einem Unternehmen sämtliche Informationen zu einem Kunden sucht, wird schnell ein halbes Dutzend verschiedener Systeme absuchen müssen, von zentralen CRM oder ERP Systemen, über traditionelle Dokumentenverwaltung und Content-Anwendungen wie Lotus Notes oder Sharepoint bis hin zu einzelnen Office-Dateien auf zentralen Servern oder dezentralen PCs und Laptops.

Worin besteht die Herausforderung für ein modernes CMS?

Die Herausforderung besteht nun darin, sich Zugang zu diesen proprietären Content-Silos und den darin weggesperrten Informationen zu verschaffen.

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

Seit kurzem gibt es nun jedoch einen Ansatz, der dieses Problem angeht. Unter der Leitung von Day Software hat sich ein internationales Industrie-Konsortium zusammengetan um gemeinsam ein neues, standardisiertes Content-API zu entwickeln. Das Konsortium umfasst die großen Infrastruktur-Anbieter wie IBM, Oracle, HP, BEA sowie zahlreiche Vertreter der CMS-Industrie. Mit JSR 170, so der offizielle Name dieser Standard-Schnittstelle, steht nun ein API zu Verfügung, in dem die grundlegenden Funktionen, die ein Content Repository zur Verfügung stellt – Lesen, Schreiben, Suche, Versionierung, Zugangskontrolle und ähnliches – verbindlich geregelt sind.

Als Ausgangspunkt bei der Entwicklung dieses Industriestandards für ein Content-API diente die Struktur des World Wide Web. Es ist das am weitesten verbreitete und genutzte Softwaresystem, das jemals entwickelt wurde. Das Web nutzt einfache, standardisierte Schnittstellen und Protokolle, um riesige Volumen an 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 vollkommen unterschiedlichen Umgebungen effizient und konsistent zugängig zu machen und zu bewirtschaften.

Die Einführung eines solchen Industriestandards bietet vielfältige Vorteile für Drittanbieter und Softwareentwickler. Für den CIO bedeutet der Standard aber die Möglichkeit, sich von proprietären Lösungen einzelner Anbieter unabhängig zu machen. Mittelfristig lässt sich die Informations-Infrastruktur eines Unternehmens rund um den Standard konsolidieren, was eine deutliche Reduktion von Komplexität und Kosten zur Folge hat. Für System-Integratoren ist der Standard wiederum attraktiv, da mittelfristig die Zahl proprietärer APIs reduziert wird. Integratoren können damit ihr Fachwissen auf einige klar definierte APIs fokussieren, anstatt permanent Know-how bezüglich einer Vielfalt Anwender-spezifischer Schnittstellen aufbauen und pflegen zu müssen.

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 eine Vielzahl von proprietären Schnittstellen ablösten und es ermöglichten, dass Datenbanken und Applikationen entkoppelt wurden. Damit wurde es erst möglich, echte Infrastruktur für strukturierte Daten aufzubauen. In der Welt der unstrukturierten Daten stehen wir heute am Anfang einer ähnlichen Entwicklung.

Wer also heute ein Content-zentrisches System (etwa Content Management, Dokumenten Management oder Digital Asset Management) evaluiert, ist gut beraten, seine möglichen Anbieter nach ihrer Strategie in Sachen Repository-Standardisierung und JSR 170 zu befragen. Der Entscheid für ein System, das mit dieser wichtigen Industrie-Schnittstelle nicht kompatibel ist, kann sich in kurzer Zeit als teurer Fehlentscheid erweisen.