Gregor Wolf, Chief Operating Officer bei OPTIMAL SYSTEMS, beschreibt in einem Gastbeitrag für den Project-Consult-Newsletter, wie moderne IT-Architekturen den bisherigen Systementwürfen nach und nach den Rang ablaufen.

Ist die Architektur der großen ECM Systeme am Ende?

[… ] Gartner hat es nicht leichter gemacht, indem sie ECM den Tod erklärten und eine zu beliebiger Interpretation und wahlloser Vereinnahmung einladende Begrifflichkeit „Content Services“ propagierten. Würde dadurch Innovation in den unbeweglichen Markt und damit eine Diskussion darüber in Gang kommen, wie ein modernes ECM beschaffen sein sollte, so wäre das ein guter Effekt. Das ist aber kaum passiert. Passiert ist nur, dass sich die gleichen Systeme plötzlich als Content Services bezeichnen. […]

Wenn nun die gleichen Hersteller mit den gleichen Systemen plötzlich zu den Leadern in Content Services mutieren, dann sind Zweifel anzumelden, ob modere und nützliche Software genügend gewürdigt wird.

Gregor Wolf, COO bei OPTIMAL SYSTEMS

Von Content Services zu wirklich moderner ECM Software

Ist „modern und nützlich“ eine nach objektiven Kriterien überprüfbare Eigenschaft? Software sollte offensichtlich nützlich sein und das bedeutet, sie ist dann modern, wenn sie heutige Interessen mit modernen Konzepten besser befriedigt als es mit alten Konzepten möglich ist. Modernität ist nicht Mode.

Für wen also sollte eine moderne ECM Software nützlich sein?

  • Offensichtlich für die Endanwender, diese sollen schließlich damit ihre Arbeit erledigen können […]
  • Sie sollte für das Unternehmennützlich sein, so dass das Geschäft nach gültigen Regeln (Gesetze und Compliance) abgewickelt wird. […]
  • Unterschätzt, aber extrem wichtig: Sie soll für die DevOpsnützlich sein (die IT Abteilung, der Betreiber, der Admin, der CIO). Sie müssen für reibungslosen Betrieb sorgen, ohne den die beiden vorgenannten Nutzenkriterien niemals erfüllt werden können. […]

ESB und SOAP versus Microservices und REST

SOAP (Simple Object Access Protocol) und ESB (Enterprise Service Bus) haben sich als schwergewichtige, komplexe Technologien erwiesen. Der theoretischen Begeisterung folgte weithin praktische Desillusionierung. Vorgebliche SOA-Dienste monolithischer Application Server waren mit noch monolithischeren ESBs mit schwergewichtigem SOAP zu integrieren. Das überforderte und misslang häufig.

Zudem fügt der alles vermittelnde ESB einen „big single point of failure“ hinzu. Wenn er scheitert, so scheitert alles […]

Microservices können für die Integration SOA 2.0 sein. Es geht immer noch um Wiederverwendung und Integration von Services, aber nun auch um Dinge wie verteilte Anwendungen und Dezentralisierung. Microservices sind in Bezug auf Entkopplung der Services ein erheblicher Fortschritt, der sich real für jeden Endkunden in einfacher Betreibbarkeit, Skalierbarkeit und Ausfallsicherheit zeigt. […]

Eine moderne Microservices-Architektur stellt de facto alle Dienste mit REST zustandslos und via http(s) nach außen zur Verfügung. Deshalb ist es nicht anders vorstellbar, als dass in einer modernen Microservices-Architektur die Services eines Gesamtsystems extern wie intern mittels REST kommunizieren. […]

Statt die Anwendung in einen schwergewichtigen Application Server zu verpacken, kann sie ihre gesamte Infrastruktur mitbringen und sich in einem Netz lose gekoppelter Services entfalten. Offensichtlich wird ein solchesSystem leichtgewichtiger, übersichtlicher und gleichwohl skalierbarer und ausfallsicherer.

Den vollständigen Beitrag finden Sie im Project-Consult-Newsletterarchiv 2017  (S. 472)