Was habe ich neulich in der Presse gelesen? Eine Umfrage der User Group eines ERP-Herstellers hätte ergeben, dass sich nur ein geringer Bruchteil dessen Kunden mit SOA beschäftigt. Sofort setzte die Diskussion ein, ob SOA real oder nur ein Hype ohne Substanz ist.
Was war passiert? Die Marketing-Abteilung dieses Herstellers hatte seine SOA Strategie erneut umbenannt und war schließlich bei dem Begriff „Enterprise SOA“ angelangt. Hätte sie den Begriff etwas präziser gefasst, etwa „Enterprise Ressource Planning SOA“, wäre die Diskussion wahrscheinlich nie aufgekommen. Dann hätte jeder gewusst, dass in diesem Fall mit SOA ein Großprojekt gemeint ist – nämlich das Re-Design einer großen und komplexen Standardsoftware. Das geht nicht von heute auf morgen und ist nicht gerade einfach – das gilt im Übrigen für alle Großprojekte, auch für die A380. Solche Projekte haben noch etwas gemeinsam: den Kunden kommt eine passive Rolle zu. Ob wir in einigen Jahren mit einer A380 fliegen oder ein SOA-basiertes ERP einsetzen, liegt nur an den Fähigkeiten der Projektteams des jeweiligen Herstellers. Wir können lediglich zuschauen und die Daumen drücken, dass alles gut geht. Von daher verstehe ich die Zurückhaltung der erwähnten User Group.
Continue reading ‘SOA – worüber reden wir eigentlich?’
Die potenziellen Vorzüge Service-orientierter Architekturen sind mittlerweile weithin bekannt und akzeptiert. Viele Unternehmen beschäftigt die Frage, wie sie SOA-Projekte konkret angehen sollen. Doch darüber gehen die Meinungen auseinander: Nicht wenige Experten empfehlen die große übergreifende Strategie, das alles umfassende (fachliche) Servicemodell als Ausgangspunkt. Derartige Initiativen muss das Topmanagement treiben, lautet ein oft gehörter Rat. Andernfalls ließen sich beispielsweise die nötigen Governance-Strukturen nicht durchsetzen.
Dagegen stehen die Protagonisten eines Bottom-up-Ansatzes, unter ihnen Anwender, die ihre Kernprozesse mit Altanwendungen abwickeln und diese Investitionen schützen wollen. Sie beginnen häufig mit Projekten zur Legacy-Modernisierung, kapseln Mainframe-Anwendungsfunktionen als Services und achten auf einen schnellen Return on Investment (RoI). Erst nach bewiesenem Nutzen weiten sie Service-orientierte Konzepte auf andere Unternehmensbereiche aus.
Bottom-up oder Top-down – welches ist der richtige Weg zur SOA? Die Frage mag banal klingen. Unternehmen müssen sie beantworten, bevor sie Projekte planen.
Einfache und simplifizierende Antworten sind in – und genau so eine Antwort scheint der Enterprise Service Bus (ESB) auf die Frage nach SOA zu sein. Verstehen Sie mich nicht falsch: ein ESB ist eine sehr wertvolle und nützliche Komponente in einer SOA-Landschaft. Wenn Sie aber meinen, gut vorbereitet an SOA heranzugehen, nur weil Sie einen ausgeklügelten Auswahlprozess für die Beschaffung eines ESB hinter sich gebracht haben – Sie können weit daneben liegen.
Andere Perspektive: Ein ESB ist nicht gleichzusetzen mit SOA, er ist aber ihr Herzstück. Klingt schon besser, trifft den Hauptgedanken von SOA aber immer noch nicht ganz. Bei SOA geht es darum, die IT Welt in kleine Häppchen zu unterteilen. Diese sind nach den Wünschen der Fachabteilungen geformt, entsprechen Industriestandards und lassen sich zu neuen Prozessen und Anwendungen zusammensetzen. Sie müssen miteinander kommunizieren, Nachrichten austauschen, diese transformieren und sicher weiterleiten. Auch besteht die Anforderung, kleine Häppchen zu größeren zusammenfügen, womit wir bei dem Thema Orchestrierung und Komposition sind. Und hierbei hilft tatsächlich der ESB.
Doch wie kommen Sie zu den Häppchen, wer sagt der IT was Business braucht und wer sagt Business was für die IT machbar ist?
Continue reading ‘ESB als Herzstück jeder SOA - ist er wirklich notwendig?’
Es klingt verlockend: Statt einen mächtigen Java-Application-Server oder eine komplette Integrationsplattform zu kaufen, wählen Kunden künftig nur noch solche Funktionen aus, die sie für ihren Anwendungsbetrieb brauchen. In einem Fall könnten das einfache Messaging-Funktionen sein, in einem anderen etwa Security-Services für bestimmte Softwarekomponenten. Das und mehr verspricht Bea Systems mit seinem Konzept SOA 360. Auf Grundlage der Microservices Architecture (MSA), die sich an SOA-Prinzipien orientieren soll, ist der Hersteller dabei, seine Infrastruktur-Produkte in modulare Services aufzubrechen. Der Masterplan gilt für das komplette Produktportfolio: Dazu gehören der Transaktionsmonitor Tuxedo ebenso wie der J2EE-Applikations-Server Weblogic und die SOA-Produkte der Aqualogic-Familie. MSA soll zudem für Partner und sogar für Mitbewerber geöffnet werden. Damit ließen sich auch Softwareservices von Drittanbietern einbinden.
Als erster Anbieter von Infrastruktur-Software geht Bea damit einen ähnlichen Weg, wie ihn die ERP-Marktführer SAP und Oracle schon länger für ihre monolithischen Pakete vorgezeichnet haben. Dass dieser Weg lang und steinig ist, haben die Branchenriesen bereits erfahren, schlimmer noch: Anwender, die zumeist noch mit älteren ERP-Releases arbeiten, goutieren die Bemühungen bisher kaum. Im Vergleich zu den ERP-Anbietern hat sich Bea einen ambitionierten Zeitplan auferlegt: Erste aus Weblogic herausgeschälte Services sollen bereits im nächsten Jahr auf den Markt kommen. Bis 2008 will der Middleware-Spezialist alle Produkte auf MSA umgestellt haben. Man darf gespannt sein, ob Bea damit erfolgreicher agiert als die ERP-Boliden.
Das große Ziel von SOA ist es, Business und IT enger zusammenzubringen. SOA Governance soll dabei helfen, die richtigen Prozesse im Unternehmen aufzusetzen, damit dieses Ziel erreicht werden kann. In der aktuell geführten Governance-Diskussion scheint sich aber alles ausschließlich um Services zu drehen. Nichts gegen Services, schließlich bilden sie die atomaren Grundbausteine einer jeden SOA-Landschaft. Wenn Sie aber ausschließlich auf Services und deren Implementierung schauen, können Sie schnell das Big Picture aus den Augen und damit die Business-Sicht verlieren. Warum also nicht größer denken? Nehmen wir also was richtig Großes – eine Business Domäne. Beispiele dafür können Zahlungsverkehr, Logistik oder das Call Center sein.
Bleiben wir bei Letzterem. In einem Call Center gibt es automatisierte Prozesse, diese basieren vielleicht auf Standards wie BPMN. Dann gibt es Anwendungen wie Composite Applications. Aus einzelnen Prozessschritten heraus werden Business Services aufgerufen, diese wiederum setzen sich aus technischen Services zusammen. Technische Services werden oft auf Basis von Standards wie BPEL orchestriert und zu größeren Einheiten komponiert. In einer Business Domäne haben wir es also mit verschiedenen Schichten und Technologien zu tun, die aber alle miteinander verbunden und voneinander abhängig sind.
Continue reading ‘SOA-Governance - der Blick auf Services reicht nicht’
Beiträge (Atom)
Letzte Kommentare
RSSMax J. Pucher - Chief Architect ISIS Papyrus
Max J. Pucher - Chief Architect ISIS Papyrus, Uwe Feddern, Falke [...]
Benjamin Hötzel
B. A. Schön, Jakob Freund