Content-Management-Systeme entwickeln sich zu Gemischtwarenläden für alle Art von digitalen Inhalten. Zu der Website-Verwaltung kommen Dokumentenmanagement, Multimedia-Daten oder Collaboration dazu.

Mit Hilfe von Web-Services kann jedes beliebige Frontend XML-Inhalte in ein Content-Management-System einstellen.

Als Tochtergesellschaft eines amerikanischen Unternehmens muss sich der Software-Hersteller mit den Quartalsberichten, so genannten Fast-Close, herumschlagen. Alle Vierteljahre müssen die Mitarbeiter einen Haufen an Text bearbeiten. Die Finanzzahlen holen sie aus dem Legacy-System oder verschiedenen Datenbanken und pflegen die Zahlen in den Bericht ein. Dieses Vorgehen bringt es mit sich, dass Änderungen im Zahlenwerk während der Berichtserstellung nicht mehr automatisch einfließen. Da kommt der Vorschlag, mit Hilfe des Content-Management-Systems (CMS) die E-Reports zu erstellen. Bisher pflegte das Unternehmen mit dem CMS lediglich die Websites für das Intranet und den Internetauftritt. Nach einer Evaluationsphase wurden die Inhalte oder Texte, so genannte weiche Daten, in das CMS integriert. Die harten Daten, also das Zahlenwerk, die in dem Legacy-System und verschiedenen Datenbanken liegen, bleiben weiter in diesen Systemen. Abfragen im CMS an den entsprechenden Stellen im Bericht verknüpfen diesen mit den harten Daten. Gibt nun das CMS den entsprechenden Bericht etwa als PDF für die Druckvorstufe aus, holt es sich über die Abfragen die aktuellen Zahlen aus den entsprechenden Systemen. Über die Cross-Publishing-Funktionalität eines CMS können die gleichen Daten aber auch für andere Ausgabemedien wie das Intranet/Internet veröffentlicht werden.

Ein CMS kann aber auch die technische Dokumentation für ein Produkt erleichtern. Ein anderes Unternehmen erstellt für sein Produkt sehr viele unterschiedliche technische Unterlagen wie Online-Hilfe, Benutzer- oder Administrations-Handbuch. Diese müssen

in verschiedene Sprachen übersetzt werden und unterschiedliche Rechtsbereiche berücksichtigen. Die Unterlagen waren bisher in sehr viele unterschiedliche Word-Dateien aufgeteilt, was zu Update-Problemen führte. Über ein CMS bekam dann das Unternehmen diese Probleme in den Griff.

Content-Management-Systeme müssen sich also nicht auf das Management von Websites beschränken, sondern können auch andere Aufgaben übernehmen und anderen Content verwalten. Die CMS wachsen dabei in Richtung von Enterprise-Content-Management-Systemen, wo etwa Web-Daten, Dokumente sowie multimediale Inhalte zusammenfinden. In sogenannten Smart-Enterprise-Suites (Gartner) finden sich zudem auch Collaboration- (Teamarbeit) oder Community-Funktionen wieder. Gleichzeitig wächst für Unternehmen die Notwendigkeit, Content aller Art zentral in einem CMS zu verwalten, und zwar jede Art von unstrukturierten Daten, um etwa den Überblick zu behalten oder Vorgänge lückenlos zu dokumentieren.

Dennoch setzen noch nicht alle Unternehmen ein CMS für ihren Web-Auftritt ein. Es existieren selbstgestrickte Lösungen, oder Agenturen haben die Pflege der Inhalte übernommen. Ein CMS erlaubt es einem Unternehmen dann, die Pflege wieder selbst zu übernehmen. Dies kann jedoch mit Hindernissen verbunden sein. Da besitzt beispielsweise ein Unternehmen verschiedene Websites, die Webmaster pflegen. Diese kommen ihren Aufgaben nicht so richtig nach, was zur Unzufriedenheit der Abteilungen führt. Diese schaffen eigene Lösungen, und die Websites entwickeln sich auseinander. Die gewachsenen Unterschiede bereiten dann große Schwierigkeiten bei der Zusammenführung.

Nicht immer hilft das Highend-CMS einem Unternehmen am meisten. Zum einen müssen diese in Zeiten wirtschaftlicher Schwierigkeiten auch auf die Kosten schauen. Hier kann etwa die Funktionsvielfalt eines CMS im Enterprise-Bereich auf Grund vieler Stellschrauben auch die Kosten in die Höhe treiben. Mittelständische Unternehmen verfügen jedoch nicht unbedingt über das Fachpersonal, um so große Systeme zu stemmen. Sie sind wahrscheinlich mit einem einfacheren und in der Regel preiswerterem System besser bedient.

Metagroup empfiehlt, ein CMS nicht nur anzuschaffen, um ein spezielles Problem zu lösen. Dies sollte gleichzeitig als Chance gesehen werden, die Basis für ein unternehmensweites Management von unstrukturiertem Content zu legen. Dies kann aber auch bedeuten, wenn es um ein CMS für Arbeitsgruppen geht, darauf zu achten, dass andere Arbeitsgruppen im Unternehmen die Lösung übernehmen können.

Web-Content nur ein Teil

Content-Management-Systeme teilt Forrester in drei Bereiche ein: Management von Web-Content, Dokumenten oder Digitalen Medien-Beständen (Digital-Assets). Web-CMS verwalten und erstellen Content für Intranet, Extranet oder Internet. Sie besitzen oft eine enge Anbindung an Application-Server für Personalisierung, Skalierung und Seitenabruf. Dokumentenverwaltung zielt darauf, Inhalte wie technische oder rechtliche Unterlagen zu archivieren und indizieren. Das Scannen von Dokumenten und das Steuern von Geschäftsvorgängen (Business-Process-Management), die mit den verwalteten Dokumenten zusammenhängen, stellen wichtige Aufgaben von DMS (Dokumenten-Management-Systemen) dar. Medien wie Ton, Bilder oder Video auf großen Websites verwalten Digitale Medien-Management-Systeme (Digital-Asset-Management-Systeme, DAMS). Forrester sieht diese drei Bereiche nun zusammenwachsen. Systeme, die alle drei Bereiche abdecken, gelten dann als Enterprise-Content-Management-Systeme (ECMS). Diese Systeme vermeiden doppelte Aufgaben etwa bei Pflege von Benutzerprofilen, der Verwaltung von Taxonomien oder der Aktualisierung/Verteilung von Repositories. Anwender arbeiten nur noch mit einer Oberfläche und finden so relevanten Content leichter, da sie nur noch über ein System suchen müssen.

Für den Einsatz im Enterprise-Bereich erwartet Metagroup bei Content-Management-Systemen insbesondere auch folgende Fähigkeiten: Multi-Channel-Ausgabe und Content-Auslieferung an beziehungsweise -Annahme von anderen Systemen (Syndication), Digitales Rechte-Management, Freigabe-/Bearbeitungs-Workflows, direkte Unterstützung von Autoren- und Publishingtools, Verwaltung von Content in Katalogen, E-Mail-Integration, gemeinsame Verwaltung von Code und Content, Dienste für Suche, Kategorisierung oder Content-Auswertung (Content-Intelligence-Services) oder Virtuelle Repositories. Ein CMS mit Multi-Channel-Ausgabe liefert seine Daten nicht nur in einem bestimmten Format wie HTML, sondern kann je nach Anforderung verschiedene Ausgabemedien von HTML, XML, WML bis PDF ausgeben. Metagroup geht davon aus, dass Unternehmen künftig einen Teil ihres Contents für Mitarbeiter, Partner oder Kunden für den Einsatz auf nicht auf Browser basierenden Systemen liefern. Die interne und externe Kommunikation über E-Mails nehmen zu. Außerdem können E-Mails eine gewisse rechtliche Bedeutung haben. Daher kommt deren Verwaltung in einem CMS mehr Bedeutung zu. Virtuelle Repositories erlauben es einem ECMS, Content auch aus anderen Systemen wie ERP oder CRM zu integrieren, ohne diesen physisch in das CMS zu importieren.

Unternehmen, die noch kein ECM-System einsetzen, empfiehlt Forrester, als Einstieg eine standardisierte Benutzerverwaltung und externe Suchmaschinen ein- sowie Metadaten-Standards durchzusetzen. Der Einsatz von Directories, etwa LDAP, sowie die Definition von Benutzergruppen und -Rollen erleichtert die Administration der Anwender über CMS, DMS sowie DAMS hinweg. Durch externe Suchmaschinen können die Anwender Content über die verschiedenen Systeme hinweg suchen. Eine einheitliche Metadatensprache über alle Systeme hinweg, erleichtert die Suche und Klassifizierung von Content.

Unstrukturierte Daten als Content

Metagroup sieht eine wachsende Bedeutung für Unternehmen in der Verwaltung von unstrukturierten Daten. Damit meint Metagroup alle Daten, die nicht in den Tabellen relationaler Datenbanken liegen. Solche Daten können Dokumente, E-Mails, Berichte, Produktionsdaten oder Multimedia-Daten sein. Während Unternehmen in der Finanz-, Versicherungs- oder Bankenbranche sich damit schon beschäftigen, greifen, so Metagroup, auch andere Industriezweige das Thema auf. Hierbei geht es darum, den kompletten Lebenszyklus von unstrukturierten Content zu kontrollieren. Dazu gehören die Speicherung, Verwaltung, Pflege beziehungsweise Aktualisierung der Daten sowie die Löschung des Contents, wenn dieser nicht mehr gebraucht oder aus rechtlichen Gründen nicht mehr publiziert werden soll.

Wenn bei der Arbeit an einem Dokument viele verschiedene Versionen entstehen, auch noch durch unterschiedliche Mitarbeiter, kann es diesen schwer fallen, den Überblick zu behalten, welche Dokumente aktuell sind. Tauschen die Mitarbeiter zudem die Dokumente über E-Mail aus und versehen diese dabei mit Anmerkungen und Änderungen, entstehen auch hier noch einmal weitere Versionen. Auch diese müssen bei der Verwaltung von unstrukturierten Content mit einbezogen werden. Ansonsten erfasst das CMS bestimmte Versionen nicht beziehungsweise lassen sich Änderungen eventuell nicht mehr nachvollziehen.

Die Zunahme von unstrukturiertem Content geht einher mit der wachsenden Bedeutung des Contents. Dies wiederum verstärkt die Notwendigkeit eines entsprechenden CMS, um der Datenflut Herr zu werden. Die Wandlung findet sich laut Gartner auch bei CMS-Herstellern wieder. Diese erweitern ihre, auf eine bestimmte Content-Art spezialisierten Systeme um weitere Content-Typen.

Über Content reden

Eng mit Content-Management hängen das Thema Collaboration, also Teamarbeit, sowie Community-Angebote zusammen. Gartner nennt Lösungen, die Content-Management — nicht nur von Web-Daten — mit Kommunikations-Werkzeugen verbinden, »Smart Enterprise Suites«. Bei Collaboration kann die Zusammenarbeit einmal direkt (synchron) oder indirekt (asynchron) erfolgen. Zu den synchronen Möglichkeiten gehören Chat, Instant-Messaging, Whiteboards, Application-Sharing oder Web-Präsentationen. Asynchrone Instrumente sind E-Mail, Diskussionsforen oder Kalender. Das CMS hat die Aufgabe, die Dokumente für die Teams allen Beteiligten zur Verfügung zu stellen beziehungsweise zu verwalten. Community-Angebote dienen beispielsweise dazu, Kunden eines Unternehmens eine Plattform für den gemeinsamen Austausch über die Produkte zu bieten. Hier stellt das CMS einmal dazu die Community-Umgebung bereit sowie

die zugehörigen Kommunikationsmöglichkeiten wie Foren, oder archiviert die Aktivitäten im Forum. Die Smart-Enterprise-Suites leben aber auch von der Organisation und dem Wiederfinden (Retrieval) des Contents. Dazu gehören etwa die manuelle oder automatische Taxonomisierung sowie Kategorisierung, Indexierung oder Suchfunktionen. Ein Portal bindet die Suite dann in eine größere Informationsumgebung ein. Die erlaubt es, auch weitere Systeme und Informationen gemeinsam mit der Suite bereitzustellen.

Portale als Frontend

Die Bedeutung von Portalen nimmt zu. Sie fassen verschiedenste Informationsressourcen in einem Unternehmen unter einer Oberfläche zusammen. Auch wenn ein Unternehmen über kein Portal verfügt, sollte es darauf achten, dass es sein CMS leicht integrieren kann. Dies gilt etwa dann, wenn das CMS zum einen entsprechende Portlets für das Portal mitbringt wie für die Anzeige von Content oder der Administration des CMS. Portlets sind Programme, die von Systemen Daten für das Portal entgegennehmen, diese eventuell transformieren und anschließend in einem Fenster (Portlet) anzeigen. Zum anderen sollte das Portal auf einem J2EE-Application-Server (Java-2-Enterprise-Edition) aufsetzen wie das »Application Server Portal« von Oracle, das »Enterprise Portal« von Sybase, der »Websphere« von IBM oder der »Weblogic« von Bea. Oder aber das CMS bringt sein eigenes Portal mit.

Architektur eines CMS

Herzstück eines CMS stellt sein Repository dar. In diesem liegen sämtliche Dokumente sowie Metadaten. In der Regel dienen relationale Datenbanken als Speicher. Geht es speziell um XML-Content, dann liegt auch der Gedanke an eine XML-Datenbank nahe. Der Content-Server kommuniziert einerseits mit dem Repository und anderseits mit dem Anwender. Für die Veröffentlichung von Web-Content kommen in der Regel noch ein Live-Server und eventuell auch ein Staging-Server hinzu. Das CMS exportiert hier seine Daten auf den Live-Server, der dann die öffentlichen Anfragen beantwortet. Ein Staging-Server dient zur Überprüfung von Content und Layout, bevor diese endgültig live gehen.

Falls das Web-CMS mit statischen Seiten arbeitet, kann es diese einfach als HTML-Seiten auf einen Web-Server exportieren. Bei dynamischen Inhalten kommt noch ein Application-Server ins Spiel. Das CMS exportiert seine Daten in eine Datenbank, auf die der Application-Server dann zugreift und die Seiten zur Laufzeit zusammensetzt. Ein typischer Anwendungsfall für dynamische Seiten ist Personalisierung, die wieder eine spezielle Server-Software übernimmt. Im günstigsten Fall exportiert das CMS je nach Datenart diese sowohl für eine statische als auch dynamische Ausgabe. Statischer Export empfiehlt sich bei Seiten mit geringer Änderungsfrequenz. Außerdem lassen sich statische Seiten besser in einem Cache ablegen. Bei dynamischen Seiten holt sich ein Application-Server die Daten aus der Datenbank und setzt sie zusammen. Kommen noch Daten aus Backendsystemen ins Spiel, ruft der Application-Server die Daten über entsprechende Abfragen ab. Diese können entweder in der Web-Seite eingebettet sein oder als extra Programme auf dem Server laufen. Bei Backenddaten-Integration muss aber nicht nur der Application-Server, sondern auch das CMS über entsprechende Connectoren verfügen, um auf die Daten während der Contenterstellung zugreifen zu können. Alternativ holt sich das System beim Contentexport die Daten aus dem Backendsystem und schiebt alles auf das Live-System. Interessant sind auch CMS, die sowohl Code als auch Content für eine Webseite gemeinsam verwalten können.

Die Trennung von CMS und Live-Server hat Vorteile, etwa bei der Sicherheit und der Performance. Die Belastung des Live-Systems schlägt nicht auf das Produktiv-System durch. CMS und Live-System können auf entsprechend unterschiedlicher Hardware laufen. Um zu skalieren, verteilt ein Load-Balancer die Anfragen an entsprechend viele Live-Server. Außerdem müssen CMS und Live-System nicht mit dem gleichen Betriebssystem operieren. Das CMS kann etwa auf einem Windows-System laufen, während das Live-System mit Linux, Apache und Tomcat läuft. Die Trennung hilft auch, direkte Zugriffe des Live-Systems auf Backendsysteme vermeiden, so dass der Live-Server etwa in einer DMZ (DeMilitarized-Zone) stehen kann.

CMS-Hersteller stellen vielfach, wenn sie es schon nicht getan haben, den Betrieb ihres CMS auf einen Application-Server um. Unternehmen, die bereits Application-Server, speziell mit J2EE (Java-2-Enterprise-Edition) arbeiten, profitieren davon doppelt. Zum einen können sie auf einer bereits vorhandenen Software-Infrastruktur aufsetzen, was das Management des CMS deutlich erleichtert. Zum anderen profitieren sie von Load-Balancing- und Fail-over-Fähigkeiten der J2EE-Application-Server. So lassen sich bestimmte rechenintensive Prozesse auf einen anderen Server auslagern oder auf mehrere verteilen.

XML als Contentsprache

Um Content zu beschreiben, hat sich XML mittlerweile etabliert. Denn XML erlaubt es, jegliche Art von Text mit zusätzliche Beschreibungen (Meta-Informationen) durch Markierungen im Text (Tags) mit einer Struktur zu versehen und gleichzeitig das Layout nicht festzulegen, wie es bei HTML geschieht. In der Regel gibt es zu jedem XML-Text eine Dokument-Typ-Definition (DTD) oder ein XML-Schema, das festhält, wie die Struktur des XML-Dokumentes auszusehen hat. Dies wiederum erlaubt, mittels so genannter XML-Parser zu überprüfen, ob ein XML-Dokument einmal die vorgegebene Struktur einhält (Validierung beziehungsweise) anhand der XML-Auszeichnung bestimmte Informationen auszulesen. ALs zweites wichtiges Werkzeug neben Parsern dient XSLT (Extensible-Stylesheet-Language-Transformation) dazu, XML-Dokumente zu transformieren. So können aus dem gleichen XML-Dokument mittels XSLT HTML-, WML- (Wireless-Markup-Language), PDF oder Postscript-Daten entstehen. Auch wenn ein CMS seinen Content vielleicht nicht als XML ablegt, kann es in der Regel XML im- beziehungsweise exportieren. Außerdem stellt sich noch die Frage, mit welchen XML-Text-Werkzeugen wie XMetal von Softquad, Epic von Arbortext, XML-Spy von Altova das CMS zusammenarbeitet.

Die Bedeutung von XML hat auch Microsoft erkannt und in sein Office 2003 verstärkt XML integriert. Zentrales Element bildet hierbei, so Metagroup, »InfoPath«, ein einfaches XML- und Formularautorentool. Info-Path und Office-2003-Enterprise-Anwendungen können XML-Schema und -Daten importieren, manipulieren oder einfache Daten eingeben. Die Daten können in XML gespeichert oder an andere Applikationen über Web-Services geschickt werden. Metagroup vertritt die Meinung, dass Microsoft nicht ein neues XML-Austauschformat etablieren will, sondern XML in Office integriert, um dieses für den Einsatz als XML-Frontend vorzubereiten. Denn eine verstärkte Arbeit mit XML im Backoffice-Bereich benötigt natürlich ein entsprechendes Frontend. Verschiedenste Hersteller, auch im CMS-Bereich, legen ihre Schnittstellen auch als Web-Services offen. Mittels Web-Services kann dann ein Frontend die XML-Daten, die ein Autor erstellt hat, zum CMS senden beziehungsweise abholen. Durch seine XML-Integration verschafft sich Microsoft mit Hilfe der Office-Verbreitung vermutlich eine gute Ausgangsstellung.

Web-Services-Integration

Auf der untersten Ebene betrachtet, stellen Web-Services nichts anderes als eine relativ neue Möglichkeit für die Kommunikation von Anwendungen dar, die auf unterschiedlichen Rechnern liegen können und eventuell durch das Internet getrennt sind. Der besondere Reiz liegt darin, dass ein Web-Service auf beiden Seiten weder ein bestimmtes Betriebssystem noch eine bestimmte Programmiersprache voraussetzt. Auch CMS-Systeme haben sich des Themas angenommen und bieten Web-Service-Schnittstellen. Damit kann jeder Client, der Web-Service-Aufrufe starten kann, auch mit dem CMS kommunizieren und etwa neue Daten in das CMS stellen. Dennoch muss der Anwender hinschauen, welche CMS-Funktionen der Hersteller standardmäßig als Web-Services anbietet. Außerdem sollte es Tools im CMS geben, um weitere Funktion des CMS oder eigene im CMS entwickelte als Web-Service zu exportieren. Der Vorgang könnte dann beispielsweise so aussehen: Der Administrator definiert im CMS einen Content-Management-Prozess und wählt J2EE oder Dot-Net als Ablaufumgebung aus. Das CMS erzeugt entweder ein Java-Bean, EJB (Enterprise-Java-Bean), oder ein COM/COM+-Objekt. In einer Entwicklungsumgebung muss er dann noch ein Web-Service-Interface erstellen und das Deployment (Verteilen und Installieren) durchführen.

WebDAV

Während Web-Services als allgemeine Schnittstelle für ein CMS gerade erst kommen, hat sich »WebDAV« oder »DAV« (Web-Distributed-Authering-and-Versioning) bereits als Kommunikationsprotokoll zwischen CMS und Clients etabliert. Web-DAV stellt zunächst nichts anderes dar als ein Netzwerk-Dateisystem für den Internet-Einsatz. Als ein Protokoll für den Dateiaustausch basiert es auf HTTP-1.1. Mit Hilfe des DAV-Protokolls können Anwender sowie Administratoren Content auf einem Web-Server pflegen. Durch seine Funktionalitäten bietet sich Web-DAV auch als Zugriffsprotokoll für Content-Management-Systeme an.

Für seine Aufgaben bringt Web-DAV sechs Kernfunktion mit: Verwaltung von Metadaten, Name-Space-Verwaltung, Collections, Lock-Mechanismen, Versions-Management sowie Zugangskontrolle. Die Eigenschaften eines Content-Objektes (Meta-Daten) beschreibt Web-DAV mit einer Web-Adresse sowie dem zugehörigen Wert als XML-Element. Collections arbeiten ähnlich wie Ordner. Um Dateien vor dem Überschreiben zu schützen, verwendet Web-DAV einen Locking-Mechanismus. Dieser arbeitet unabhängig davon, ob der entsprechende Client online ist oder nicht. Da Web-DAV auf HTTP beruht, kann es mit allen Web-Ressourcen wie HTML, GIF oder JPEG arbeiten. Eine Arbeitsgruppe der IETF arbeitet an der Weiterentwicklung. Unter RFC 2518 wurde Web-DAV als Standard verabschiedet.

Sicherheit

Wie überall im Backendsystemen, können auch in CMS empfindliche Daten liegen. Außerdem muss sicher sein, dass jeder im System auch nur das tun kann, was er darf. Entsprechende Authentifizierungs- und Autorisierungslösen gehören daher in jedes CMS. Falls das CMS mit einem Portal zusammenarbeiten soll, kommt die Frage, inwieweit das CMS ein Single-Sign-On (SSO) unterstützt wie über SAML (Security-Assertion-Markup-Language) oder mit SSO-Produkten wie »Netegrity« von Siteminder oder »Securant« von Cleartrust. Für ein entsprechendes Rechtemanagement sollte ein Klassen- und Rollenkonzept vorhanden sein. Klassen erlauben es, Anwender bestimmten Gruppen zuzuordnen. Rollen beschreiben, welche Rechte für die entsprechenden Aufgaben ein Anwender bekommt. Dabei muss das CMS auch sicherstellen, dass jeder Anwender nur den Content sehen kann, den er auch sehen darf. Dies muss das CMS auch bei der Suche beachten. Denn die Existenz eines Dokumentes, auch wenn der Anwender es nicht lesen kann, sagt unter Umständen schon sehr viel. [ wve ]