SOA, BPM und Enterprise Architecture

Maturity Modelle oder Reifegradmodelle werden bereits von vielen CIOs eingesetzt. Ähnlich einer Balanced Scorecard analysieren diese den aktuellen Stand im Unternehmen. Die Anwendung eines Maturity Models ist ein strategisches Ziel, aus dem sich taktische Meilensteine ableiten lassen. Das wohl bekannteste Maturity Modell heißt CMM-i und bezieht sich auf Prozesse in der Software-Implementierung. Während die initialen Level einfach fordern, dass bestimmte Dokumente, z.B. eine Projektbeschreibung, vorhanden sind, beschreiben höhere Stufen Entwicklungsprozesse und letztlich sogar die fortlaufende Verbesserung der Prozesse. Üblicherweise erreicht ein Unternehmen diese Prozess-Qualität, indem ein etabliertes Referenzmodell wie CobiT, TOGAF oder ITIL für bestimmte Prozess-Domainen eingesetzt wird. Das Maturity Modell beschreibt die Prozessqualität, ohne ein explizites Referenzmodell zu fordern.

Inzwischen bieten die ersten Software-Hersteller und Systemintegratoren ein SOA-Maturity-Modell an. Analog der Beziehung zwischen CMM-i und den Referenzmodellen, sollte das SOA Maturity-Modell die Servicelandschaft zwar qualitativ beschreiben, aber keine Referenzarchitektur oder gar eine Auswahl von Softwareprodukten explizit vorgeben. Das SOA Maturity-Modell der Software AG geht diesen Weg und lässt sich deshalb auch auf IT-Landschaften mit Softwareprodukten beliebiger Hersteller anwenden. Die SOA-Methologie, die schon in meinem Beitrag vom 29. August 2007 beschrieben wurde, stellt dann die Beziehung zwischen Maturity-Modell und SOA-Referenzarchitektur her.

Ausgehend von wenig kommunikativen Anwendungs-Silos unterscheiden wir fünf SOA Maturity Level. Level 1 ist das “SOA Enablement” und ist dann erreicht, wenn die bestehenden Systeme technisch überhaupt in der Lage sind, Dienste in einer Servicelandschaft bereit zu stellen. Oft ist es hilfreich, einen ESB einzusetzen oder bereits ein einfaches Registry zu verwenden, um den Überblick zu behalten. Der Level 2 fordert bereits die ersten Teile der “SOA Governance”. Aufbauend auf der Reife der Infrastruktur wird nun die organisatorische Reife beschrieben, die notwendig ist, um mit einer lose gekoppelten Geschäftslogik umzugehen. Metadaten-Kollaboration ist hier wichtig und sollte durch ein SOA-Repository unterstützt werden.

Level 3 des SOA Maturity-Modells bezeichnen wir als “SOA Business Services”. Damit wird nun zusätzlich die Welt der Geschäftsprozesse erfasst. Die große Herausforderung besteht darin, die Verbindung zwischen abstrakten Geschäftsprozessen und sehr fein-granularen technischen Services des Levels 2 zu vermitteln. Insbesondere ist hier die Orchestrierung von technischen Services in höherwertige Business-Services notwendig. Man kann sich vorstellen, dass Beziehungen zwischen Prozessmodellen, Service-Orchestrierungen und technischen Services ohne ein SOA-Repository/Registry kaum zu beherrschen sind.

Nachdem die ersten drei Level den Zugriff auf bestehende Anwendungen im Fokus hatten, setzt der Level 4, die “SOA Composition”, diese Logik sehr flexibel zu neuen sogenannten Composite-Applications zusammen. SOA-Governance auf diesem Reifelevel bedeutet sehr genau zu verstehen, welcher Service oder Prozess von welcher neuen Anwendung konsumiert wird. Wieder analog zur CMM-i Prozessreife konzentriert sich auch der letzte Level 5, die “SOA Optimization”, auf die Optimierung aller Veränderungen und das Laufzeitverhalten der SOA-Infrastruktur.