Content Management: Auf die Architektur kommt es an

von Michael Moppert

Wir erleben es tagtäglich: Die Menge an digitalen Informationen explodiert. 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 auf 988 Exabytes. Der Erfolg von Konzernen im globalen Wettbewerb hängt immer stärker von der effizienten Bewirtschaftung dieser immateriellen Güter ab. Das Resultat: Die Frage nach dem „richtigen” System für das Management all dieser unstrukturierten Daten bekommt eine zentrale Bedeutung.

Von Michael Moppert

Inhaltsübersicht:

• CMS-Systeme: Die Qual der Wahl
• Erfolg entscheidend: Die Architektur der Software
• Kostenfalle: Proprietäre Content-Silos
• Die Lösung: Ein neuartiger API-Standard

Mit der zunehmenden Globalisierung hat die Bedeutung der industriellen Warenproduktion stark abgenommen. Wo heute eine Fabrik steht und wem sie gehört ist zweitrangig. Vielmehr zählen das Wissen über die Produktions- und Distributionsprozesse sowie die effiziente Kommunikation mit den Kunden. Damit wird die effiziente 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.

CMS-Systeme: Die Qual der Wahl

Die Evaluierung eines Content Management Systems ist 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.

Erfolg entscheidend: Die Architektur der Software

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 sind 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 ist, 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 Funktions-Vielfalt 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.

Kostenfalle: Proprietäre Content-Silos

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 Content Management Systeme 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 Schnittestelle 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 Content Management Systeme 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 häufig in einem halben Dutzend verschiedener Systeme recherchieren müssen, von zentralen CRM- oder ERP-Systemen, über traditionelle Dokument Management Systeme und Content-Anwendungen wie Lotus Notes oder Sharepoint bis hin zu einzelnen Office-Dateien auf zentralen Servern oder dezentralen PCs und Laptops.

Die Lösung: Ein neuartiger API-Standard

Die Herausforderung für ein modernes Content Management System 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 Content Management System 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 viel versprechenden alternativen 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 alle grosßen Infrastruktur-Anbieter wie IBM, Oracle, HP, BEA sowie zahlreiche Vertreter der Content Management 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  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 von Informationen aus der ganzen Welt 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: Er ermöglicht erstmals den Aufbau einer echten Informationsinfrastruktur, die auf Standards beruht. Die Integration neuer Anwendungen wird extrem vereinfacht, da Inhalte und Funktionalitäten bereits bestehender Applikationen über ein gemeinsames API zur Verfügung stehen. Ältere Anwendungen, die nicht auf dem Standard beruhen, können durch Content-Connectoren angebunden und nutzbar gemacht werden. Damit wird der Zugriff auf wesentliche Content-Assets für den Business-User markant vereinfacht.

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, Datenbanken und Applikationen zu entkoppeln und so eine echte Infrastruktur für strukturierte Daten aufzubauen. In der Welt der unstrukturierten Daten stehen wir heute am Anfang einer ähnlichen Entwicklung.