Geschäftsprozesse in monolithischen, fest verdrahteten Applikationen war gestern. Heute reden wir über Service-orientierte Architekturen (SOA). Und damit steigt in einer SOA die Notwendigkeit an fundierten Kenntnissen über die Modellierung von Enterprise Services, deren Zusammenstellung zu neuen Geschäftsprozessen und vor allem deren Verwaltung.
Um die Vorteile einer SOA zu nutzen, ist es zunächst einmal sehr wichtig, einen Governance-Prozess im Unternehmen zu etablieren. Dieser steuert den gesamten Lebenszyklus service-basierter Anwendungen. Er beginnt mit der Analyse der entsprechenden Geschäftsanforderungen, erstreckt sich über die Modellierung, das Design und die Implementierung von Services in dem Enterprise Services Repository, und endet mit der Einführung und der Optimierung der neuen, service-basierten Anwendungen (den sogenannten “Composite Applications”).
In diesem Umfeld kristallisieren sich bei SAP drei neue Rollen besonders heraus: die Rolle eines Business Process Experts (BPX), die eines Enterprise-Architekts sowie die eines Service-Entwicklers. Ein BPX besitzt tief greifendes Verständnis für Geschäftsprozesse und versteht es, die Anforderungen an neue Prozesse, in einer Definition von existierenden und fehlenden Funktionalitäten auszudrücken. Dabei muss ein BPX weit mehr Kenntnisse über den gesamten End-to-End-Prozess besitzen als ein klassischer Prozessberater. Er ist daran interessiert, Prozess-Innovation durch die Möglichkeiten von SOA-Architekturen voll auszuschöpfen.
Ein Enterprise-Architekt hat, neben der Entwicklung der Gesamtarchitektur, einen Fokus auf die logische Sicht der einzelnen Domänen bzw. Prozess-Komponenten. Die Anforderungen wandeln sich von einer klassischen IT-Infrastruktur und Architektur-Konzeption zu einem funktionalen Domänen bzw. Prozesskomponenten-Management. Weiterhin spielt das Service-Portfolio-Management eine zentrale Rolle. Welcher Semantik sollen die Services folgen, damit eine globale Architektur effizient und effektiv realisiert werden kann? Deshalb sind technische Kenntnisse nur die Grundlage, um die Architektur zu verstehen. Erfolgreiche SOA-Plattformen setzen eines voraus: Semantische Standards müssen aus dem Eff-Eff beherrscht und beachtet werden.
Der Service-Entwickler implementiert im Anschluss den sogenannten “Glue Code”. Mit anderen Worten: Er implementiert den Zugriff auf bestehende Funktionalität im Backend-System. Stehen nun alle benötigten Enterprise Services zur Verfügung, kann der Business Process Expert den fertigen Prozess modellieren, ausführen und dem Geschäftsbereich die neue Lösung zur Verfügung stellen.
Die Erstellung service-basierter Applikationen erfordert Kenntnisse und Fertigkeiten im Umgang mit neuen Methoden und modellbasierten Tools. Es hat sich gezeigt, dass der Umfang von Schulungsmaßnahmen in Unternehmen häufig in direktem Verhältnis zu dem Ausmaß die jeweiligen SOA-Initiative steht. Unabhängig davon, wie schließlich ein Entwicklungsplan für eine Organisation aussehen mag, ist es wichtig, dass Mitarbeiter in einem SOA-Projekt sowohl die technischen Standards verstehen und anwenden als auch eine einheitliche betriebswirtschaftliche Semantik zur Beschreibung der Enterprise Services nutzen.
SOA-Plattformen werden nur dann erfolgreich sein, wenn das Bewusstsein der oben genannten Voraussetzungen in den Köpfen der Mitarbeiter etabliert ist und die Verantwortlichen über die notwendigen Fähigkeiten verfügen.
Rolf Schumann, CTO SAP EMEA
Sehr geehrter Herr Schumann,
mir wird mulmig bei Ihrer Darstellung. Zitat: ‘[..] gesamten Lebenszyklus service-basierter Anwendungen. [..]endet mit der Einführung und der Optimierung der neuen, service-basierten Anwendungen (den sogenannten “Composite Applications”).’ Die Lebenszyklus Ihrer Anwendungen endet mit der Einführung? So schlimm wird es doch nicht immer sein?
Hallo Herr Steunenberg,
…der Governance-Prozess endet dort.
Darauf bezieht sich das “Er” am Satzanfang…
mit freundlichen Grüßen
J.Urbschat
Hallo Herr Urbschat,
es mag sein, dass sie Recht haben. Ich lese es so, dass ‘er’ sich auf den Lebenszyklus bezieht. Aber auch wenn ‘er’ sich auf den Governance-Prozess bezieht, verstehe ich nicht, warum ‘er”endet mit der Einführung und der Optimierung der neuen, service-basierten Anwendungen’.
Ich gestehe, dass ich mein Anliegen eher flapsig angesprochen habe. Ich komm noch mal rein:
wie ich den Beitrag des Herrn Schumanns lese, hört der Prozess auf bei der Einführung. Das lese ich bei ‘endet mit der Einführung und der Optimierung der neuen, service-basierten Anwendungen’, aber auch bei den 3 neuen Rollen, die er beschreibt. Es gibt kein Verantwortlicher für Wartung, Orchestrierung, oder wie ich mich aus Anwendersicht einen Lebenszyklus in ein sich änderndes Unternehmen sehe.
Ich muss dabei gestehen, dass ich keinerlei Erfahrungen mit SOA habe. Ich habe in den letzten Jahren etwas ganz anders gemacht. Ich habe viel in bestehenden Quelltexten und Konfigurationen geforscht, IT-Archeologie betrieben, und ich weiss, dass jeder neuen Medienbruch ein neues Problemfeld in der Wartung ist.
Ich habe gerade aus dieser Perspektive ein Misstrauen gegenüber SOA, und sehe mein Misstrauen bestätigt, wenn dieser Abschnitt des Lebenszyklus nicht erwähnt wird.
Der letzten Abschnitt steht dann noch vol mit Erwartungen an empfangenden Organisationen, die ich nicht ganz realistisch finde. In der Perspektive der vielleicht 2-Jährige Entwicklung eines Systems kann ich mitschwingen, in der Perspektive einer 10- bis 20-Jähriger Pflege und Wartung einer Unternehmenssoftware wird mir immer noch mulmig.
“Erfolgreiche SOA-Plattformen setzen eines voraus: Semantische Standards müssen aus dem Eff-Eff beherrscht und beachtet werden.”
Semantik ist für mich ein Kernpunkt Herr Schumann.
Könnten Sie hierzu bitte ein paar Zeilen schreiben?
Wie kommen Unternehmen zu einer unternehmensweiten Daten Semantik?
Was passiert wenn Unternehmen dies nicht erreichen? Dann gibt es keine Wiederverwendung in meinen Soll Prozessen! Status Quo in 90% der Unternehmen.
Hat J2EE vielleicht sogar die Semantik hinterrücks erstochen?
Hallo Herr Gössel,
Daten Semantik hat erst mal gar nichts mit J2EE zu tun und überhaupt mit der eigentlichen Implementierung. Es ist wichtig , daß Unternehmensbereiche für unternehmensweite begrifflickeiten das selbe Verständnis haben ( zB Definition von Kunde ) und dass es dafür ein Repository gibt, in dem man die begrifflichkeiten nachschlagen kann .
MfG,
Iris Peters
Hallo Frau Peters,
stimme Ihnen voll zu, dass Unternehmen ein einheitliches Verständnis ihrer Identität (Business Capabilities) sowie der verwendeten Begrifflichkeiten haben müssen.
J2EE hat in diesem Zusammenhang meiner Meinung nach die IT wieder weiter weg von der natürlichen OO gelockt und dazu geführt, dass die IT sich mehr mit sich selbst beschäftigt hat, als mit dem Business ihres Unternehmens.
Dadurch wurden in vielen Unternehmen gut 5 Jahre “verschenkt”. Einige Unternehmen haben diese Herausforderung damals angenommen und werden heute als SOA Vorreiter gefeiert. Hier können die meisten Unternehmen noch sehr viel lernen.
Beste Grüße,
Stefan Gössel, EXXETA
Hallo Herr Gössel,
es kommt für mich immer auf die Implemtentierung an und wie grob- der kleingranular Objekt ausgefasst worden sind . Es gibt genug J2EE Implemtierungen, die sich bzgl einer reinen OO Implementierung nicht schwar getan haben.
IT Abteilungen haben sich genauso viel mit allen Legacyimplementierungen befasst und denen nur reine technische Interfaces gegeben ohne ein richtiges Business Reengineering durchzuführen.
Gruß,
Iris