Eine Suche nach SOA auf www.amazon.de in der Rubrik Buch ergibt 40 deutschsprachige und 85 englischsprachige Treffer. Literatur zum Thema ist also umfassend verfügbar. Unzählige Artikel motivieren zur Erneuerung, Optimierung, Flexibilisierung mit SOA, ITIL und Modellierung. Ein modischer Hype oder doch eine wesentliche Neuausrichtung, getrieben durch Kostendruck und Anpassungsnotwendigkeit an sich rasch wandelnde Geschäftsprozesse? Mehrfache Wiederverwendung von Services, Modularisierung mit Vernetzung neben und anstatt gewachsener Applikationen – hoffentlich leichter und kostengünstiger zu betreiben und zu warten…..
Mit einem weiteren Artikel inflationär die offensichtliche Sinnhaftigkeit und auch die bekannten Risiken der Umsetzung einer SOA zu beschreiben, SOA ein weiteres Mal vorzustellen, macht wenig Sinn. Meine Tätigkeit als Berater und Modellierungstrainer in vielen, verschiedenen Branchen, bei großen, mittleren und kleinen Unternehmen ermöglicht mir eine Einschätzung der vorgefundenen  Prozessreife, des SOA-Umsetzungsgrades und der erreichten Qualitätsstandards: SOA-Theorie und aktuelle Projekt-Realitäten klaffen, abgesehen von einigen wenigen Ausnahmen, weit auseinander. Die Gleichförmigkeit der erkennbaren Ursachen hierfür ist bemerkenswert. Sie liegen selten im technischen Bereich und viele Unternehmen sind schon aus organisatorischen Gründen nicht reif für SOA.
Vielleicht hilft Ihnen meine, zugegebenermaßen generalisierende und vereinfachende, subjektive Bestandsaufnahme, Ihre Voraussetzungen zu prüfen und den guten Einstieg oder die erfolgreiche Fortsetzung eines SOA-Vorhabens zu besichern.

1. SOA & Modellierung – ja, natürlich, was sonst?
Besteht eine Unternehmung aus automatisierten, sich dynamisch verändernden Geschäftsprozessen, wenn noch dazu – wie zum Beispiel bei Telekommunikationsprovidern, Banken, Versicherungen, Versandhäusern, etc. – ein und dieselben Geschäftsprozesse in den verschiedensten Medien – Internet, Intranet, WalkUp, Callcenter, als mobiles Service, etc. – automatisiert anzubieten sind, wird SOA langfristig die einzige, flexible und kostengünstige Möglichkeit sein, dies zu realisieren. Unterschiedliche Systeme sind zu integrieren und eine starke Abhängigkeit von einem einzelnen Systemlieferanten sollte vermieden werden. EAI – auf technischem Layer – und ein Service-Bus als nächste Schicht darüber sind dann eine architektonisch-logische Notwendigkeit. Dies alles war schon Thema, lange bevor der Begriff SOA geschaffen wurde. Damals allerdings periodisch unterbrochen durch markige Sprüche aus der IT, wie zum Beispiel: „Die Kundendienstabteilung soll Ihre Prozesse den erprobten Standardwerkzeugen (CRM, Ticketsystem) anpassen!“
Die Eigeninteressen der mächtigen Systemlieferanten und die mangelnde Transparenz der Systeme standen einer umfassenden Dokumentation der Businessprozesse im Wege. Wenn die Vorgabe lautete, Standardprodukte einzusetzen und die Prozesse zu adaptieren, war eine durchgehende Modellierung von Prozessbedürfnissen bis zu Lösungen nicht erforderlich.
Dies alles soll hier nicht weiter diskutiert werden, es ist offensichtlich, dass - generell gesprochen - die Wertschöpfung optimierter, automatisierter Prozesse in den meisten Fällen ausreichend hoch ist, um die Systemlandschaft dem Prozessbedarf – rein kommerziell motiviert - anzupassen und Services bestens dokumentiert, hochverfügbar allen beteiligten Oberflächensystemen zur Verfügung zu stellen – natürlich zukünftig kostengünstig adaptierbar …. Die Literatur hierzu liegt mehrfach redundant bereit, hier besteht keinerlei Mangel an Know- und Do-How. Wie sieht das nun in der Beratungspraxis aus?

2. Programmierst du noch oder modellierst du schon? [1]
Als Mitarbeiter von SparxSystems freut mich die aktuell deutlich zunehmende Nachfrage nach Modellierungswerkzeugen natürlich sehr, das sichert meinen Arbeitsplatz und Anwendertrainings als auch die einschlägige Beratungsdienstleistung sind sehr interessante, ja geradezu spannende Tätigkeiten. Eine sauber gegliederte, modularisierte und für die einzelnen Zielgruppen aufbereitete Iststands-, Bedarfs- und Architekturmodellierung ist zweifellos eine notwendige Voraussetzung für SOA-Vorhaben.
Der gegenwärtige Marktbedarf an Modellierungswerkzeugen zeigt aber auch, dass diese Voraussetzung in der Breite noch nicht geschaffen wurde. Vielerorts geht es bei der Einführung von Modellierungswerkzeugen nicht um den Umbruch von vorhandenen Ablaufplänen in andere Darstellungsformen und Normen (UML, BPMN, SysML, …..), sondern es findet sich neben zumeist vorhandenen Systemdokumentationen eben keine oder zumindest keine aktuellen Prozessdokumentationen und damit auch keine aufbereitete Wertschöpfungsanalyse, die ihrerseits wieder strategisches Werkzeug für den Einstieg in SOA-Konzepte sein sollte.

Der naheliegende Ansatz,
• in einem Modellierungswerkzeug die Businessprozesslandschaft des Unternehmens strukturiert, transparent und verständlich für alle Beteiligten aufbereiten zu können,
• durchgängig, ausgehend von wirtschaftlichen, wertschöpfenden Kenngrößen und Zielen bis hin zu Geschäftsprozessen zu modellieren,
• sich in einem Modellierungswerkzeug mit Qualitätsmethoden wie z.B. Six-Sigma als Team zu „treffen“ und hier abteilungsübergreifend – mit Produktions-Fachbereichen und unterstützenden Abteilungen – zusammenzuarbeiten,
erscheint in den meisten betreuten Unternehmen den Verantwortlichen als viel zu weit gegriffen.
Verbesserte Dokumentation und Nachvollziehbarkeit der Prozesse einzelner  Fachabteilungen durch Modellierung werden nachgefragt – aber eine abteilungsübergreifende BP-Gesamtmodellierung des Unternehmens scheint aus organisatorischen und aus Kompetenzgründen oft nicht realisierbar.
Dies gilt auch für über die Business-Prozesse hinausgehenden Modellierungsschichten. Während
• Qualitätssicherung, bessere Strukturierung und besicherte Wiederverwendbarkeit von Softwaremodulen als Wirkung des Einsatzes von Modellierungswerkzeugen für einzelne Projekte anerkannt scheinen und
• die Vorteile der Verwendung eines Modellierungswerkzeugs, das für das gesamte Projektteam die Arbeitsplattform von Bedarfsanalyse, Requirementsmanagement über Lösungs- und Codedokumentation bis Testing zentral zusammenfasst, wahrgenommen und geschätzt werden,
ist die umfassende Modellierung einer Unternehmung abseits von einzelnen Projekten (noch) nicht gefragt.
Hier folgt auch schon eine Hauptursache des Scheiterns: Mangelnde Unterstützung der Geschäftsleitung, des zentralen Managements. Wenn die Iststands-Modellierung dezentral den Fachabteilungen aufgetragen wird, müssen zumindest Standards, Vorgehens- und Aufbereitungsweisen vereinbart und gesteuert werden. Ohne Schulung und Coaching eines Qualitätssicherungssystems werden die Analysen zumeist viel zu dürftig - und eindimensional. Eine Prozessdokumentation ohne der Aufbereitung der Wertschöpfungsdimension, der zweckbedingten Notwendigkeiten der Prozesse und ohne einer Aufzählung der wesentlichen Einflussfaktoren der einzelnen Prozesse ist einfach nicht ausreichend, um fachübergreifend anschließend weiterarbeiten zu können. Womit schon wir beim zweiten markanten, ebenfalls kritischen Punkt angelangt sind:

3. Fachbereichsbetreuer alias Solution- & Prozessarchitekt
Denkweisen und Fachsprachen der einzelnen Fachbereiche eines Unternehmens sind unterschiedlich und inkompatibel, ganz abgesehen vom Einfluss unterschiedlicher, manchmal auch verdeckter Interessen der einzelnen Fachbereiche und deren Individuen. Auch das Rollen-Selbstverständnis der Spezialisten hat hier starken Einfluss – auf jeder Seite wird fachgerechter „Input“ erwartet, selbstverständlich verständnisgerecht und unmissverständlich aufbereitet.
Diesen Umstand kann man kaum jemanden vorwerfen – unterschiedliche Ausbildung und die große Nähe zur produktiven Arbeit im jeweiligen Fachbereich als auch die grundsätzliche Notwendigkeit der Arbeitsteilung haben diesen Umstand zwingend zur Folge. Darauf zu hoffen, dass sich alle Projektteambeteiligten während des Projektes ausreichend Kompetenzen erarbeiten können, ist ebenso unangebracht, wie zu glauben, mit einer Menge an fachlich nicht kompetenten Projektmanagern vorankommen zu können, die hier ausreichend moderieren sollen.
Eine Reorganisationsplanung – Bestandteil von SOA – bedarf daher einer „grenzgehenden“ Kompetenz. Ein Fachbereichsbetreuer aus der IT, der sich vollständig in die gelebten Prozesse der Fachabteilung einarbeitet – also die Sicht der Welt durch die Brille der Fachabteilung erlernt -, oder ein hinreichend vom Produktionsprozess freigestellter Fachbereichsmitarbeiter mit einer hohen Begabung oder Ausbildung zu businesslogischer Dokumentationsaufbereitung ist notwendig, um die „Dolmetscherfunktion“ einzubringen.
Dies ist eine selten anzutreffende Fertigkeiten-Kombination. Mitarbeiter aus bereits hinreichend lang bestehenden Qualitätszirkeln kommen eventuell in Betracht. Einarbeitung benötigt Zeit und entsprechende Begabung. Zusätzlich wird für diese Rolle ein sehr hohes Maß an sozialer Kompetenz benötigt, ist doch Kommunikation zwischen Fachbereichen zu moderieren, Motivation der beteiligten Fachbereiche für die vorhabensbedingte Mehrarbeit ist zu betreiben und „vorbereitendes Change Management“ ist zu leisten. 
Hier ist auch insbesondere darauf zu achten, dass die „Last der Verantwortlichkeit“ hinzukommt. Nur, wer auch für die Richtigkeit und Relevanz der Aufbereitung geradestehen muss und daher selbst ausreichend aggressiv der jeweiligen Fachbereichsleitung gegenüber auftritt, um Ressourcen, Information, Autorisierung und Freigaben zu erhalten, wird wirksame Inhalte gestalten und vor allem – bei weitem wichtiger - Verständnis dafür bei allen beteiligten Keyplayern herstellen können. Dementsprechend ist eine externe Besetzung dieser Rolle suboptimal, extern sollten hier bestenfalls Coaches und Trainer beitragen.

4. Ausreichende Generalisierung, Transparenz der Motive, Ziele
Die klassische Modellierungssprache ist UML. Hierzu ist anzumerken, dass UML am Modellierungs¬beginn den Anwender in den Mittelpunkt stellt, seine funktionalen Anforderungen an die Oberfläche des Systems aufnimmt – und dabei den Nutzen und die Zwecke hinterfragt. Dies steht in gewissem Widerspruch zum SOA-Ansatz, wo am Beginn der Analyse die Begriffe Process, Mission, Desired Result, usw. aus Sicht des Prozessverantwortlichen eine wesentliche Rolle spielen. Hier wird von der zumeist lösungsorientierten Betrachtungsweise des Anwenders abgegangen, der Prozess wird benannt und die Wirkung, der Nutzen und der gewünschte „Output“ des Prozesses werden definiert. Selbst wenn UseCases der UML um getrennt notierte Requirements ergänzt werden, ergeben sich hier deutliche Unterschiede im Denkmodell, in der Betrachtungsweise. Für die Prozessaufbereitung bieten sich Normierungen wie BMPN oder SysML an – und diese stellen auch die Elemente bereit, um erwünschte Ziele und Wirkungen aus mehreren Blickwinkeln zu visualisieren und zu erfassen.
Beide Annährungen haben Vor- und Nachteile. Wesentlich ist aber für beide die Anforderung: Die Generalisierung muss so weit gehen, dass die gewünschte Funktionalität (nicht: Funktionsweise!) eindeutig beschrieben wird, ohne eine spezielle Lösung- oder gar Implementationsvariante voreilig aufzuzeigen oder anzudeuten.
Nur durch strikte Einhaltung dieser Regel und durch die ausreichende Hinterfragung der Motive und Ziele hinter der geforderten Funktionalität ergibt sich ein ausreichendes Generalisierungsniveau, um wirklich innovative Einsichten und Lösungen zu ermöglichen. Dies darf ausschließlich bei einfachsten Projekten außer Acht gelassen werden, bei denen der Lösungsweg schon zwingend fest steht und nur geringfügige Adaptionen gestaltet werden müssen.
In diesem Analyseprozess ist wieder von den Beteiligten hohe soziale Kompetenz und andererseits der Mut zu fordern, zu echten Motiven vorzudringen und sich nicht mit vorgeschobenen zu begnügen, die zumeist auch noch ungeprüfte, falsche Wirkungszusammenhänge unterstellen. Und - generell gilt: Wirkungszusammenhänge, auch bloß vermutete, sind so umfangreich als nur möglich anzugeben – anschließend sind diese zu überprüfen, und zwar durch kontrolliertes Experimentieren und nicht durch Abschätzung der Richtigkeit – siehe auch Kernschritte von Six-Sigma. [2]

5. Transparenz, Mut zur Top-Down Vereinfachung
Viele Kenngrößen, die eine Hauptrolle im SOA-Design-Prozess spielen – Mengengerüste, Prozesshäufigkeiten, Aufwände, Kosten, Erträge, Abbruch- und Reklamationsraten, etc. – werden gemeinhin in einem Unternehmen als vertraulich oder sogar als „geheim zu halten“ eingestuft. Abteilungen oder Bereichsleitungen sind nicht daran interessiert, dass diese Kennwerte publik werden. Ähnliches betrifft u.U. einzelne Geschäftsziele und manche anderen Vorgaben.
Hier ist Gefahr in Verzug. Was nicht explizit mitgeteilt wird, erfordert die Anwesenheit der „Geheimnisträger“ in allen relevanten Meetings um dort gegebenenfalls Vorgaben, die nicht transparent begründet wurden, zu relativieren. Zumindest ein hinreichendes Maß an Transparenz ist zu schaffen, das die effiziente und richtig priorisierte Arbeit des Kernteams sicherstellt. Gerade in diesem Punkt konnte ich als externer Berater immer wieder teuere „Unfälle“ bei finalen Konzeptpräsentationen miterleben – die Geschäftsleitung entdeckte erst hier, dass die nicht publizierten Motive für Vorgaben inzwischen weggefallen und die Vorgaben damit überholt waren.
Moderne Modellierungswerkzeuge vereinfachen die Verwaltung und Visualisierung von Requirements, schaffen Verknüpfungsmöglichkeiten von Requirements zu Prozessen, UsesCases und Abläufen.
Einer strukturierten, sauberen und gut lesbaren Darstellung von Zusammenhängen zwischen Prozesszwecken, Randbedingungen, Zielen und Motiven steht somit nichts im Wege. Abgestimmte, geprüfte Zusammenhänge und Wechselwirkungen schaffen einerseits erhöhte Management-Aufmerksamkeit für das SOA-Vorhaben und erhöhen die Motivation des Kernteams wesentlich. Als beispielhafter Link sei http://www.goobiz.com/How_to_align_IT_using_UML_and_according_to_BMM.htm genannt.
Moderne Modellierungswerkzeuge vereinigen die Visualisierungstechniken mit umfassenden Verlinkungsmöglichkeiten. Eine Top-Down-Vorhabensdokumentation ist strukturiert möglich, ausgehend von einer vereinfachenden Übersicht hin zu immer tieferen, umfangreicheren Details. Abschnitte können für verschiedene Zielgruppen (Management bis Entwickler) passend gestaltet und verlinkt werden, sodass immer der aktuelle Gesamtinformationsumfang zur Verfügung steht. Die Praxiserfahrung zeigt, dass diesem Punkt zumeist zu wenig Aufmerksamkeit geschenkt wird.

6. Projektvorgehen
Aus dem SOA-Credo heraus, sich zuerst auf die Ebene der Businessprozesse zu konzentrieren und die Umsetzung vorerst außen vor zu lassen, ist die zeitliche Gestaltung der Einbindung der IT ins SOA-Projekt regelmäßig ein Diskussionsthema. Hier zeigt die Praxis, dass die Einbindung der IT beim Review des Istzustandes der Prozesse eine heilsamer Schritt ist, sehr oft erweisen sich die Vorstellungen der Prozessverantwortlichen über die bereits tatsächlich implementierte Geschäftslogik – zumeist mangels guter Dokumentation - als unzutreffend.

7. SOA: Technische Unterstützung durch ein Modellierungswerkzeug
Im Hinblick auf SOA sind für das Modellierungswerkzeug insbesondere die Visualisierungsmöglichkeiten von Requirements, die Verlinkungsmöglichkeit von Requirements zu Prozessen, UseCases, Abläufen und weiter zur technischen Modellierung zu nennen.
Die mehrschichtige Auflösung von Businessprozessen in verschiedene Detaillierungsgrade, die strukturierte Parametrisierungsmöglichkeit der einzelnen Prozesselemente sind ebenso wie die Verlinkung mit projektrelevanten Managementdaten (Aufwände, Ressourcen, Phasenzuordnung, Versionierung) zu fordern.
Forward- und vor allem Round Trip Engineering zur kontinuierlichen Aufrechterhaltung einer aktuellen Code-Dokumentation sind maßgeblich produktivitätssteigernde Merkmale.
Eine besonderes Merkmal eines Modellierungswerkzeugs für SOA-spezifische Verwendung ist die Möglichkeit zur Modellierung und damit zur Visualisierung von W3C WSDL Web Service Definition Language Documents,

8. Conclusio
Die Umstellung auf SOA mit dem Ziel, kosteneffiziente Flexibilität der Geschäftsprozesse zu erreichen, betrifft mittlere bis große Unternehmen, die historisch und grundsätzlich durch die Notwendigkeit der Arbeitsteilung bedingt, tiefe organisatorische Strukturen aufweisen. Eine effiziente Prozessumsetzung durch modulare Services erfordert unternehmensweite Transparenz und Zusammenarbeit. Prüfen Sie die Bereitschaft zur Transparenz, Zusammenarbeit und zur Veränderung in Ihrem Unternehmen, dies ist die große Masse des Eisbergs, der Ihren Weg kreuzen wird, wenn Sie Kurs auf SOA setzen – eine Umstellung auf SOA impliziert mit hoher Wahrscheinlichkeit unternehmensweite Reorganisation, zumindest aber eine übergreifende, verbindliche Abstimmung. Der Leuchtturm "Agile Software Development" [3]  kann als Navigationshilfe beitragen, Sie sicher zum Ziel bringen. Kommen Sie wohlbehalten an!



[1] Zitat: Prof. Hans-Jörg Haubner, BA Karlsruhe
[2] http://www.bpm-guide.de/articles/32
[3] http://www.agilealliance.org/home

Dieser Artikel wurde 5.2007 von Herrn Steinpichler erstellt

zum Shop
NEWS
News als RSS-Feed abonnieren!

Logo SparxSystems