Das Enterprise SOA Consulting Team ist 2008 von Dr. Dirk Krafzig gegründet worden und liefert IT Beratungsdienstleistungen auf Basis bewährter Prinzipien der Service-orientierten Architektur (SOA).

SOA ist eine ganzheitliche Sichtweise auf IT-Unternehmensarchitekturen, die seit 2004 allgemeine Anerkennung findet. Dabei wird SOA mehr als ein kontinuierlicher Verbesserungsprozess denn als ein statisches Konzept verstanden. Dieser Prozess hat die Entwicklung eigenständiger, fachlich motivierter Komponenten zum Ziel, die als Services bezeichnet werden. Diese Services werden von verschiedenen Anwendungen gemeinsam genutzt und bilden damit das fachliche Rückrat der Unternehmens-IT, das den Anwendungen die Daten und die Funktionen bereitstellt. Mit Recht können Services daher als die Grundbausteine der Geschäftsprozesse angesehen werden.

Die Vorteile dieser Vorgehensweise liegen im Besonderen darin, dass die Anwendungslandschaften von Redundanzen befreit werden. Das hat nachhaltige Kostensenkungen zur Folge, da weniger Source Code gewartet werden muss. Ebenso steigt die Konsistenz der Daten, da immer nur eine einzige Kopie eines Datensatzes von einem Service bereit gestellt wird und nicht per Datenabgleich zwischen den Systemen übertragen wird. Letztendlich stellt die Service-orientierte Architektur einen Baukasten zur Verfügung, aus denen sich neue Projekte bedienen können. Dies führt zu weiteren Kosteneinsparungen und zur Minimierung von Entwicklungszeiten und Risiken.

Die Umsetzung einer Service-orientierten Architektur ist jedoch kein einfaches Unterfangen. Aus diesem Grund hast das Enterprise SOA Consulting Team ein Lösungs-Framework entwickelt, das die typischen Tätigkeitsfelder in vier Workstreams gliedert.

IT/Business Alignment ist ein häufig strapazierter aber selten präzise umrissener Begriff. In erster Linie geht es beim IT/Business Alignment darum, die Leistungen der IT und die Bedürfnisse des Fachbereichs möglichst eng miteinander zu verdrahten. Im Klartext: die IT soll tun, was dem Unternehmen nützt. In der SOA Praxis haben sich insbesondere zwei Punkte in der Zusammenarbeit zwischen IT und Fachbereich als unverzichtbar herausgestellt: eine gemeinsame Begriffswelt und SOA Funding-Modelle.

Eine gemeinsame Begriffswelt ist die Voraussetzung für eine nachhaltig effiziente Kommunikation zwischen IT und Fachbereich. Nach unserer Erfahrung müssen insbesondere zwei Herausforderungen gemeistert werden:

§      Entwicklung von Begrifflichkeiten für abteilungsübergreifende, fachliche Konzepte

Anwendungssysteme stellen die wichtigste Abstraktionsform dar, über die Fachbereich und IT kommunizieren. Häufig sind Anwendungen aber proprietäre Abteilungslösungen, die auf die speziellen Bedürfnisse eines einzelnen Bereichs zugeschnitten sind (z.B. Einkauf, Schadenregulierung oder Produktion). Damit fehlen die Abstraktionen, um über abteilungsübergreifende Fragestellungen zu verhandeln (z.B. die Beschreibung von Produkten oder Kundendaten). In der praktischen Umsetzung tauchen diese übergreifenden Begriffe häufig in Form von Schnittstellen auf. Da aber nur Anwendungen als werthaltige IT Komponenten gelten, werden Schnittstellen ausschließlich als Kostenfaktor und Fehlerquelle angesehen.

§      Angleichen des Zuschnitts der fachlichen und der technischen Begriffswelt

Die zweite Schwierigkeit ist wesentlich diffiziler: Ausgehend von der Abstraktion „Anwendung“ stellen – aus Sicht der IT – die Konstrukte „Plattform“ und „Anwendungsschicht“ die erste Verfeinerungsebene dar. Auf Seiten des Fachbereichs liefern Anwendungen jedoch in erster Linie die Unterstützung von Geschäftsprozessen oder Capabilities. Damit ist die Divergenz von IT und Fachbereich vorprogrammiert. SOA Services bieten eine ausgezeichnete Lösung für das Sprachproblem. Hier sind fachlicher und technischer Zuschnitt kongruent.

Nach unseren Erfahrungen ist das Thema „Funding“ in vielen Unternehmen sehr heikel. Der Grund ist eher psychologischer Natur. Die meisten IT-Fachleute sind sehr sachbezogen und befassen sich lieber mit inhaltlichen Themen. Und hier liegt eine große Gefahr. Sehr gut kann eine SOA Initiative durch die einmalige „Spende“ des CIO ein Pilotprojekt umsetzen. Ein solcher Pilot bringt aber keine SOA. Gerade wenn die Ergebnisse des Piloten in die tägliche Praxis übertragen werden sollen, können die Finanzen zu einem Hindernis werden. Traditionelle IT Budgetmodelle, die für die Entwicklung und Pflege von Anwendungssystemen optimiert sind, greifen in einer SOA nicht. Die SOA Initiative muss vielmehr Probleme lösen wie die Anschubfinanzierung für die Infrastruktur und das Team, Kostenallokation für die Entwicklung mehrfach benutzter Services oder die Verteilung von Wartungs- und Betriebskosten und Kapitalisierung. Damit die SOA Initiative nicht direkt nach dem Piloten ins Stocken gerät, müssen Antworten auf diese Fragen gefunden werden. Dies kann nur in einer partnerschaftlichen Anstrengung von IT und Fachbereich geschehen. 

Die SOA Governance legt die Regeln fest, nach denen innerhalb einer großen Organisation SOA-relevante Projekte genehmigt, geplant, und abgewickelt sowie die entstehenden IT Systeme betrieben werden.

Die klassische IT Governance befasst sich u.a. mit dem traditionellen Lebenszyklus eines Projekts. Für unsere Betrachtung ist hier bemerkenswert, dass Projekte – bis auf wenige Ausnahmen – immer unter der Kontrolle eines einzelnen Fachbereichs ablaufen. Nach dem Projektende wird der auftraggebende Fachbereich in der Regel zum Owner des entstandenen Anwendungssystems bestellt. Der Owner steuert und finanziert, die Weiterentwicklung und Pflege der Anwendung und trägt die Betriebskosten. Damit liegt die Kontrolle immer in einer Hand.

Eine SOA Governance ist eine Erweiterung der IT Governance, die die speziellen Anforderungen einer SOA adressiert. Der Kernpunkt ist die Wiederverwendung. Ein Service ist von seiner Natur her ein Stück Software, das von mehreren Fachbereichen genutzt wird. Beispielsweise kann ein Produkt-Service von einer Anwendung zur Produktionssteuerung und von einer anderen Anwendung für den Verkauf gemeinsam genutzt werden. Daher liegen die Entwicklung eines solchen gemeinsam genutzten Services und sein Betrieb nicht mehr in der Hand eines einzelnen Fachbereichs. Aus diesem Grund ist es essentiell, die Spielregeln festzulegen, nach denen Entwicklungsvorhaben für SOA Services umgesetzt werden.

Für die Organisation bedeutet eine SOA ein ganzes Bündel an Maßnahmen und Änderungen.

Als eine bewährte Best Practice hat sich die Gründung eines SOA Competence Centers etabliert. Ein SOA Competence Center hat zur Aufgabe, Projekten Mitarbeiter mit geeigneter Qualifikation zur Abwicklung von SOA-relevanten Projekten zur Verfügung zu stellen. Es koordiniert bereichsübergreifende Maßnahmen zwischen den verschiedenen Fachbereichen, den Projekten und dem Rechenzentrum. Der Leiter des Competence Centers tritt als Promoter der SOA Initiative innerhalb des Unternehmens auf und organisiert Management-Unterstützung und Funding.

Eine SOA Initiative hat auch Einfluss auf Standardisierungs- und Portfolio-Gremien. In diesen Ausschüssen sitzt in der Regel ein SOA-Delegierter.

Auf Ebene der Mitarbeiter stehen Unternehmen vor der Notwendigkeit ihre Mitarbeiter mit Schulungen für neue Aufgaben zu qualifizieren. So sind z.B. SOA Service Designer oder SOA Repository Manager neue Berufsbilder, die ihren Weg bis in die Personalabteilungen noch finden müssen. Dazu bedarf es neuer oder überarbeiteter Arbeitsplatzprofile. Intern und extern muss neues Personal für diese Aufgaben gewonnen werden. Auf Management-Ebene können Gehaltsmodelle überdacht werden, um beispielsweise zu ermöglichen, dass der individuelle Beitrag zum Fortschritt der SOA in die persönliche Bonusregelung einfließt.

SOA Service Design ist eine neue Disziplin beim Entwurf von Unternehmens-IT-Landschaften.

Während in der Vergangenheit IT-Landschaften eher zufällig gewachsen sind und in erster Linie von den rein fachlich motivierten Projekten bestimmt wurden, muss einer planvollen SOA ein Zielbebauungsplan zugrunde liegen. Der Entwurf konkreter Service-Operationen, die in einem Projekt benötigt werden, muss immer an dem zugrunde liegenden Zielbebauungsplan gemessen werden.

Grundlage dieses Design-Prozesses sind die high-level Geschäftsobjekte und die Geschäftsprozesse. Während die Geschäftsobjekte den Zuschnitt der SOA Services vorgeben, werden aus den Geschäftsprozessen die konkreten Anforderungen an SOA Service-Operationen abgeleitet.

Dabei ist die Tatsache zu berücksichtigen, dass die Einführung einer SOA einen inkrementellen unternehmensweiten Transformationsprozess impliziert, der die bestehende Unternehmensarchitektur, die in der Regel von Applikationen geprägt ist, zu einer neuen Unternehmensarchitektur vorantreibt, die von Services gekennzeichnet ist. Dieser Transformationsprozess kann sehr komplex sein und mehrere Jahre dauern. Aus diesem Grund muss eine Methodik zur Modellierung von SOA Services gerade dieser Komplexität und der langjährigen Relevanz der Modelle Rechnung tragen.

Die technische Infrastruktur liefert die Basis für die Implementierung einer Service-orientierten Architektur. Hier ist in erster Linie zwischen einer Runtime- und einer Design-Time-Infrastruktur zu unterscheiden. Es gibt unter den Produktherstellern verschiedene Philosophien für diese Infrastrukturen, jedoch liefert die eingesetzte Technologie nur einen geringen Beitrag zum Erfolg oder Misserfolg einer SOA Initiative.

Nichtsdestotrotz ist die Auswahl und Einführung von Infrastruktur eine der vielfältigen Aufgaben, die bei der Einführung einer SOA anfällt. Dabei muss am Ende nicht immer der Kauf neuer Lizenzen stehen. Häufig sind in den Unternehmen schon Middleware, Repositories und Registries vorhanden, die für den Einsatz in der SOA fit gemacht werden können.

Ein wichtiges Beispiel ist der so genannte Enterprise Service Bus (ESB). Der ESB ermöglicht es einem Service Consumer, einen Service Provider aufzurufen. Genau das ist die Aufgabe klassischer Middleware. Technologien wie Message Queues, Web Services oder CORBA haben diese Aufgabe in den letzten zwei Dekaden zunehmend besser gelöst. Häufig ist es daher sinnvoll, eine SOA auf eine bereits im Unternehmen etablierte Middleware aufzusetzen. Dadurch spart man Kosten und Management-Bandbreite, die man z.B. für Themen wie Funding oder Governance in den ersten Monaten einer SOA besser investiert.