CMS oder EIP (Enterprise Information Portal) – was ist das bessere Integrationsportal? [Live Blogging]
Veröffentlicht am März 7, 2008 by Stephan Schillerwein
Hier ein kleiner Live-Post (mit gut 18 Stunden Verspätung aufgrund der Stand-Party…) von der Content Management Arena auf der Cebit. Zum Ende des heutigen Tages wird im Schwerpunktthema „CMS als Aggregationsplattform“ über das im Titel genannte Thema diskutiert. Teilnehmer der Panel-Diskussion sind:
- Lars Onasch, RedDot
- Burkhard Bieber, Logica
- David Nüscheler, Day
Moderator: Björn Negelmann, [n-sight]
Hier einige Diskussionsaspekte:
Machen die verschiedensten neuen Plattformen wie Blogs, Wikis etc. das klassische CMS zukünftig überflüssig?
Nein, meint Lars Onasch, die verschiedenen Content-Objekte und -Arten wachsen vielmehr auf Basis des CMS zusammen. Das ist auch aus dem Blickwinkel eines Vertreters des Standards JCR (Content Repository API for Java) grundsätzlich ein richtiger Ansatz, findet David Nüscheler (der „Vater“ von JSR-170 und JSR-283). Hauptsache, es existiert überhaupt ein gemeinsames, übergreifendes Repository, das integriert alle benötigten Möglichkeiten (Funktionen, Contents, …) zur Verfügung stellt.
Auch für die CMS-Hersteller steht die Zusammenführung der heutigen Vielzahl der Repositories im Vordergrund. Noch werden die eigenen, propreritären Repositories eingesetzt, die Zukunft wird aber bspw. auch von RedDot in den Standards gesehen.
Dies umso mehr, schliesst sich auch Burkhard Bieber an, weil Content Aggregation nicht mehr nur auf die eigenen Quellen im Unternehmen beschränkt ist, sondern eine Vielzahl externen Quellen beinhaltet.
Diese Drittinhalte brauchen dabei i.d.R. nicht ins eigene Repository übernommen werden, sofern nicht hohe Performance-Anfoderungen dies erzwingen oder eine persistente Vorhaltung erforderlich ist.
.
Auf welcher Schicht soll idealerweise integriert werden?
Für jede Schicht (Daten-/Content-Schicht, Applikations- und Präsentationsschicht) gibt es Vor- und Nachteile, so das dass Anwendungsszenario und dessen Anforderungen entscheidend sind. In vielen Produkten (so z.B. auch SharePoint) sind eh bereits mehrere dieser Schichten enthalten, also z.B. Portal (=Präsentationsschicht) und Repository.
Für die Präsentationsschicht spricht, dass dort die Integration einfach und günstig erfolgt. Dafür ist sie aber auch nur oberflächlich (im doppelten Sinne des Wortes).
Dies ist bspw. auch bei RSS, Atom & Co. der Fall, die ja vor allem für externen Content eine immer grössere Rolle spielen. Hier sollten entsprechende Umwandlungen nach JSR erfolgen (z.B. durch atom-to-jsr/jsr-to-atom-Umwandlung) um auch hier wieder einheitlich zu sein.
Ein standardisiertes Content Repository kann in Zukunft auch weit über die Welt der unstrukturierten Informationen heraus benutzt werden, bspw. um ERP-Daten zu speichern. Diesen Trend der Ersetzens der Datenbank durch Content Repositories erwartet David Nüscheler in den nächsten 5-10 Jahren bei kleineren ERP-Herstellern zu sehen, bei den Grossen würde es aber wohl noch Jahrzehnte dauern.
Und das obwohl dies viele Vorteile mit sich bringt (z.B. aufgrund der bereits im Repository vorhandene Versionierung, feingranularen Access Controls etc., die heute in der DB nicht drin sind).
Auch vor diesem Hintergrund sollte die Integration idealerweise auf der Content-Ebene erfolgen.
Lars Onasch wirft ein, dass aufgrund der Möglichkeiten der meisten Organisationen besser überhaupt ein personalisierter, „Topf-übergreifende“ Informationszugriff geschaffen werden sollte, bevor weiter gehenende und aufwändigere Integrationsvorhaben auf Applikations- oder Content-Schicht angegangen werden..
Die Frage, ob das CMS oder das Portalsystem in solchen Konstellationen künftig das „Master-System“ darstellt, sieht er in der Praxis nicht erstrangig an technische Überlegungen geknüpft, sondern als meist strategische Entscheidung.
.
Das Video der Diskussion (und aller anderen Vorträge und Diskussionsrunden der Content Management Arena) sind mit einer kostenlosen Registrierung online abrufbar (die Inhalte werden nach und nach aufgeschaltet).