Die Service Orientierte Architektur ist ein strategisches IT-Konzept, das hohe Flexibilität und Anpassungsfähigkeit in Aussicht stellt. Richtig eingesetzt verspricht sie handfeste geschäftliche Vorteile. Ob und wann sich jedoch die Einführung einer derartigen SOA-Strategie lohnt, hängt von verschiedenen Faktoren ab.
Der individuelle Nutzen einer SOA für ein Unternehmen kann auf verschiedenen Ebenen realisiert werden – von Effizienzsteigerungen über Flexibilisierung bis hin zu neuen Geschäftsmodellen.
Zur nachhaltig erfolgreichen Einführung einer Service Orientierten Architektur sind jedoch Anpassungen an den Prozessen des IT-Managements sowie, in der Regel, Investitionen in unterstützender IT-Infrastruktur notwendig.
Diese Anschubfinanzierung muss sich, wie alle Investitionen in IT, rechnen. Viele Unternehmen konzentrieren sich bei der Bewertung einer SOA für ihre spezifische Situation auf die Analyse und die Auswahl der unterstützenden IT-Infrastruktur, z.B. die Auswahl eines passenden Enterprise Service Bus, ESB.
Einen überzeugenden Business Case auf rein technischen Untersuchungen aufzubauen, ist sehr schwer wenn nicht unmöglich. Besser ist es, auf Basis geschäftlicher Anforderungen die Stellen oder Projekte im Unternehmen zu identifizieren, an denen der Einsatz von SOA bewertbare Vorteile für das Unternehmen bringt und dann die Investition in Infrastruktur gegenzuhalten.
Detecon empfiehlt daher jedem Unternehmen die Entwicklung einer individuellen SOA-Strategie mit individuell passender Umsetzungsstrategie. Die hierfür anfallenden – in Relation eher geringen – Kosten rechnen sich durch eine gezieltere, schnellere Erschließung von Nutzenpotentialen, einer höheren Qualität der Umsetzungsprojekte sowie durch die Sicherung der Nachhaltigkeit.
Wann lohnt sich eine Service Orientierte Architektur?
SOA Strategie
Für jede Investition in IT muss mindestens eine der drei Fragen positiv beantwortet werden:
– Verbessert der Einsatz die Geschäftsmöglichkeiten des Unternehmens?
– Erhöht sich die Qualität der Geschäftsunterstützung?
– Verbessert sich die Wirtschaftlichkeit des IT-Einsatzes?
Dies gilt auch für die Einführung eines neuen Architekturkonzepts, wie das der Service Orientierten Architektur (im Folgenden kurz SOA genannt).
SOA ist keine Technologie. Als vollständiges Architekturkonzept können durch die Anwendung von SOA-Prinzipien, Methoden und passender Technologie Vorteile auf allen Ebenen einer Unternehmensarchitektur realisiert werden.
Auf Ebene der Geschäftsarchitektur können beispielsweise leichter und flexibler neue IT-basierte Produkte angeboten werden, die sich aus firmeneigenen Modulen und denen von Geschäftspartnern zusammensetzen und auch tarifiert werden oder beispielsweise in der Wiederverwendung standardisierter Prozessbausteine (Templates).
In der Informationsarchitektur kann durch den SOA-Einsatz zum Beispiel einfacher und schneller eine Geschäftsfeldübergreifende
Berichtsfähigkeit hergestellt werden, um etwa rechtlichen oder regulatorischen Anforderungen zu genügen oder um mehr Transparenz an sich herzustellen, zum Beispiel bei Mergers & Aquisitions.
Für die Applikationsarchitektur bietet sich die Chance eines effizienteren Betriebs beispielsweise durch die erleichterte Wiederverwendung von Anwendungsbausteinen, vor allem wenn dadurch hohe Kosten durch die Umsetzung nichtfunktionaler
Anforderungen wie hohe Verfügbarkeit oder erweiterte Sicherheitsanforderungen reduziert werden können.
In der Technischern Architektur kann durch die logische Entkopplung von Diensten und ihrer technischen Bereitstellung
in Infrastruktur ein höherer Standardisierungsgrad und damit wiederum ein effizienterer Betrieb realisiert werden.
Um den möglichen Nutzen einer SOA für ein Unternehmen zu realisieren, sind grundlegende Arbeiten und auch Investitionen in Infrastruktur notwendig. Welche Schritte das sind und welcher Aufwand damit verbunden ist, hängt von der Situation des jeweiligen Unternehmens ab. Beispielsweise hängen Umfang und Stellenwert bisheriger Architekturarbeit im Unternehmen direkt mit dem Aufwand für die Einführung einer SOA zusammen. Dies wird später an Hand eines Projektbeispiels verdeutlicht.
Die identifizierten Ziele für die Einführung der SOA, definierte Aktivitäten zum Aufbau des unternehmensweiten SOA-Rahmenkonzepts und die konkrete zeitliche Abfolge zur Einführung, inklusive der Pilotprojekte, werden in der SOA-Strategie festgelegt. Die konsequente Verkettung von Zielen, Initiativen und Umsetzung von geplantem Nutzen ermöglicht damit die übergreifende Bewertung des Nutzens, welcher durch die Einführung und den Betrieb von SOA entsteht und definiert die Roadmap für Investitionen in die IT-Architektur.
Einführung einer Service-orientierten Architektur
Unternehmen brauchen eine verabschiedete SOA-Strategie als Grundlage für ihre Initiativen, um den Nutzen einer SOA nachhaltig realisieren zu können.
Wenn Sie jetzt denken, das ist doch keine „Rocket Science“, was hier beschrieben wird, dann haben Sie sicher Recht. Allerdings ist die IT in vielen Unternehmen in der Vergangenheit sehr schnell und rein technisch getrieben gewachsen. Pragmatisch entwickelte Lösungen zur Befriedigung des aktuellen Bedarfs ersetzten eine geplante, effiziente Weiterentwicklung der Unternehmens-IT. Die notwendige Transparenz, um Handlungsfelder und Einsatzbereiche der SOA im Unternehmen zu untersuchen, ist in vielen Unternehmen heute dadurch nicht vorhanden. Es fehlt ein modernes IT-Architekturmanagement.
Doch keine Angst. Unternehmen können sich die Vorteile einer SOA erschließen, ohne erst langwierige Konzeptionsphasen zu durchlaufen und aufwendige administrative Strukturen aufzubauen.
Geschickterweise lassen sich die Entwicklung einer SOA-Strategie und der Aufbau eines modernen IT-Architekturmanagement verbinden, orientiert am aktuellen Bedarf und ohne Investitionen auf Vorrat. Ein Beispiel hierfür wird im folgenden Kapitel beschrieben.
Projektbeispiel: Optimierung der Prozessunterstützung in einem unternehmenskritischen Bereich
In einem ersten Schritt beauftragte der Kunde Detecon mit der Entwicklung einer IT-Architekturstrategie. Ziel des Projekts war es, die IT-Architektur mittelfristig an den Zielen und dem Bedarf der Fachbereiche auszurichten. Schwachstellen und bekannte Probleme der heutigen IT-Landschaft sollten bei der Konzeption der Soll-Architektur genauso mit einfließen wie externe Einflüsse, zum Beispiel die Abkündigung technischer Services von Dritten zu einem bestimmten Zeitpunkt. Als wichtiges Ergebnis des Projekts wurde eine Roadmap zur Implementierung der Soll-Architektur für den Kunden entwickelt.
Die am höchsten priorisierte Maßnahme war die Ablösung verschiedener Alt-Systeme in einem der wichtigsten Kernbereiche des Unternehmens. Die durch die abzulösenden Systeme bereitgestellte Funktionalität reichte nicht mehr aus, die erhöhten Qualitätsanforderungen in der Product Delievery sicher zu stellen. Im Zusammenspiel dieser Systeme mit einer Fülle angrenzender Systeme traten verstärkt Probleme mit der Datenqualität auf. Verschiedene Initiativen dies zu lösen waren bis dato nicht erfolgreich. Als Kommunikationsdienst war Datex-P fest in den Anwendungen verwoben. Dieser Dienst war vom Anbieter abgekündigt und hätte nur mit immensen Mehrkosten weiter genutzt werden können.
Die Entwicklung einer zukunftsfähigen IT-Architektur wurde zusätzlich noch dadurch komplizierter, dass das neue Anwendungssystem von verschiedenen Legaleinheiten im Konzernverbund genutzt werden sollte. Versuche der Prozess-Standardisierung über die Legalgrenzen hatten bis zu diesem Zeitpunkt keinen Erfolg.
Obwohl zu dem Zeitpunkt, als das Projekt mit einer Vorstudie gestartet wurde, das Konzept der Service Orientierten Architektur noch nicht sehr bekannt war, empfahl Detecon den Einsatz von Methoden und Modellen der SOA, um die Komplexität der Aufgabenstellung zu reduzieren und Arbeitspakete für alle Beteiligten aus IT und Fachbereichen überschaubarer und leichter Verständlich gestalten zu können.
Der Erfolg belohnte das Vertrauen des Kunden. Ähnlich dem Zachman Framework für Enterprise Architecture wurde die Zielarchitektur durch Analyse der verschiedenen Architekturebenen und deren Zusammenhänge analysiert – von der Geschäftsarchitektur bis zur technischen Implementierung. Mit Hilfe eines datengetriebenen Ansatzes konnte dann die IT-Architektur in Domänen und erste grobe Services strukturiert werden. So wurden in einem ersten Analyseschritt sechsunddreißig funktionale Bausteine identifiziert werden, wovon bereits auf dieser hohen Analyse-Ebene sechs als in allen Einheiten wieder verwendbar erkannt wurden. Durch den datengetriebenen Ansatz wurde beispielsweise auch das Konzept der Data-Ownership umgesetzt, welches bei der Bereinigung der bisherigen Konsistenzprobleme half.
Auch beim Einführungsszenario konnte durch den SOA-Einsatz dem Wunsch des Kunden nach einer sanften und schrittweisen Ablösung mit schneller und sukzessiv ergänzter Bereitstellung neuer Funktionalität entsprochen werden.
Enterprise Architecture Management
Die Erstellung des Architektur-Modells ist ein fortlaufender, iterativer Prozess. Reichweite und Detaillierungsgrad richten sich nach der Zielsetzung aktueller Projekte.
Rückblickend kann gesagt werden, dass durch die Anwendung von SOA-Konzepten und Methoden die Komplexität der gestellten Aufgabe gemeistert werden konnte. Selbst Problemstellungen, die vor dem Projekt schon bekannt waren, aber nicht gelöst werden konnten, wurden erfolgreich in der neuen Zielarchitektur umgesetzt.
Bei der Entwicklung der Zielarchitektur wurde viel grundlegende Arbeit für ein modernes IT-Architekturmanagement geleistet. Diese musste bereits während des Projekts anderen zur Verfügung gestellt werden, um den Erfolg der insgesamt über drei Jahre laufenden Ablösung zu sichern. Hierzu war ein nur bedingt dem Projekt zuzurechnender Aufwand notwendig. Andere Projekte profitierten hiervon und sparten manche Arbeitsschritte ein. Dies war dem hohen Handlungsdruck, der allen Beteiligten bewusst war, und der eisernen Disziplin beim parallelen Aufbau von Governance-Strukturen zu verdanken. Vieles wäre für die Projekte und die Beteiligten leichter gewesen, wenn vorab die Grundstrukturen aufgebaut worden wären.
Enterprise Architecture Management und SOA
Die Komplexität bei der Planung und Einführung des neuen Anwendungssystems im obigen Beispiel, sowie die geschäftskritischen Anforderungen an das neue System, die zügig umzusetzen waren, rechtfertigten eine umfangreichere Vorstudie zu architekturellen Planung des Systems und der Einführung. Bei Projekten mit geringerem Realisierungsvolumen aber mit nicht geringerer Wichtigkeit, kann eine notwendige Vorstudie den Business Case für das Gesamtprojekt schnell negativ werden lassen. Ohne Architekturplanung erhöht sich aber das Risiko für das Scheitern des Projekts, gerade mit Blick auf die Integration in die Gesamt-IT-Landschaft. Die Effizienz der IT insgesamt leidet ebenfalls.
Abhilfe schafft die Etablierung eines modernen Enterprise Architecture Management (EAM). EAM sorgt für die Optimierung der IT-Landschaft im Spannungsfeld unterschiedlicher Zielsetzungen im Unternehmen und hilft die Umsetzung der geplanten Maßnahmen transparenter und erfolgsorientierter zu steuern. Die Einführung von EAM kann sowohl projektorientiert, wie im obigen Beispiel, oder zentral erfolgen. Im ersten Fall werden die erarbeiteten Ergebnisse gesichert und können für weitere Architekturarbeiten, zum Beispiel bei Planungsänderungen oder im Zusammenspiel mit anderen Projekten genutzt werden. Im zweiten Fall kann beispielsweise das Ziel sein, die übergreifende Planung von IT-Budgets mit einem architekturellen Kontext zu ergänzen um damit die Komplexität der Entscheidung für die Mittelverwendung aus Sicht des Managements zu reduzieren.
Gerade wenn in der SOA-Strategie geschäftsbereichs-übergreifende oder Konzern-Ziele identifiziert wurden, ist die Etablierung eines übergreifenden Modells sowie eines übergreifenden Architektur-Planungs- und Steuerungsprozesses Voraussetzung für den Erfolg. Dabei soll selbstverständlich kein unnötiger Überbau an Modellbildung und Prozessarbeit empfohlen werden, die Granularität der erhobenen
und gepflegten Informationen entspricht in jedem Fall den Anforderungen und Notwendigkeiten der zu lösenden Aufgaben.
Enterprise Architecture
Das Konzept der Enterprise Architecture (EA) beinhaltet mindestens zwei grundlegende Änderungen zu den meisten heute in den Unternehmen verwendeten Architekturmodellen.
Zum einen wird die Unternehmensarchitektur in mehre Ebenen entkoppelt, von denen mindestens eine die Ebene der Geschäftsarchitektur darstellt. Diese Ebenen werden getrennt, aber auch übergreifend nach ihren Beziehungen zueinander beplant. Die Ebenenarchitektur wird für jede Geschäftseinheit und die Zentrale in gleicher Weise erstellt, so dass tatsächlich übergreifende Analysen und Planungen möglich sind. Wichtig für den Erfolg einer EA sind zum einen ihre Skalierbarkeit, um den notwendigen Aufwand der gestellten Aufgabe entsprechend im richtigen Maß zu halten. Zum anderen einige wenige Ankerpunkte, auf die man sich unternehmensweit einigen muss, um eine Vergleichbarkeit herstellen zu können.
Zum großen Teil frei am Markt verfügbare Frameworks vereinfachen die Konzeption und den Aufbau eines unternehmensspezifischen Frameworks. Das Framework für das strategische IT-Architekturmanagement von Detecon basiert auf TOGAF 8.1 EE, dem Architekturframework der Open Group sowie dem Zachman Framework. Auf beide Frameworks soll hier nicht weiter eingegangen werden.
Enterprise Architecture
Bei der Planung von Lösungen zur Umsetzung strategischer Entscheidungen ist sowohl die Entkopplung der Ebenen als auch ihre integrierte Betrachtung notwendig.
Für das übergreifende Management von Unternehmensarchitekturen sind also ein Modell des Unternehmens und ein übergreifender Planungs-und Steuerungsprozess notwendig. Das Modell sorgt für Transparenz und Vergleichbarkeit, der Prozess stellt die redundanzfreie Planung unter Berücksichtigung von Abhängigkeiten und selbstverständlich die Nutzung und Weiterentwicklung vorhandener Services im Rahmen der SOA sicher.
Enterprise Architecture Management und SOA
Die Enterprise Architecture erweitert die Planung der IT-Architektur von einer Silo-Optimierung zu einem unternehmensweiten Wertschöpfungsprozess.
Die Schaffung von Transparenz und einer übergreifenden Planung und Steuerung sind die ersten Schritte für die erfolgreiche Migration und einem ebensolchen späteren Betrieb einer Service Orientierten Architektur. Ein genaues Verständnis des Bedarfs der Geschäftsseite wie auch des Anpassungs- und Veränderungsbedarfs aus der IT-Seite (Anforderungsmanagement), passender Strukturen und Regeln für die Zusammenarbeit sowie klar geregelter Rechte und Pflichten (Governance) wie auch die Transparenz bezüglich der Kosten- und der Ertragsseite (Kosten-und Preismodelle) sind weitere Bestandteile für ein erfolgreiches Managementkonzept im Rahmen der SOA. Auf Grund der zunehmenden Granularität der Architekturbausteine in der SOA und den unterschiedlichen Quellen, die auch außerhalb des Unternehmens und somit der eigenen Governance liegen können, sind hierfür optimierte Konzepte gefordert.
Basis für diese optimierten Konzepte bildet ein skalierbares Klassifikationssystem für die IT. Durch die Skalierbarkeit können Unternehmen schrittweise in verfeinerte Strukturen der IT-Planung hineinwachsen, aber auch schon auf früher, grober Planungsebene Nutzen für sich erzeugen. Kleinstes Element dieses Systems ist der Baustein, der als logisch geplanter Baustein oder als konkret verfügbares System, entweder implementiert oder am Markt verfügbar, vorliegt. Services einer SOA sind spezielle Ausprägungen dieser Architektur- oder Lösungsbausteine (AB oder LB). Durch den Vergleich der in den AB abgebildeten Anforderungen mit den in LB’s realisierbaren Lösungen, kann dann eine optimale Entscheidung getroffen werden wie der Bedarf befriedigt werden kann (Make, Buy oder Reuse).
Enterprise Architecture Management und SOA
Um die unternehmensweite IT-Landschaft mess-und steuerbar zu machen, wird sie in nicht-überlappende Domänen, detailliertere Systeme und Bausteine strukturiert.
Auf Basis diese Klassifikationssystems können dann die unten beschriebenen drei Management-Dimensionen des Life-Cycle-Managements in der SOA umgesetzt werden.
Enterprise Architecture Management und SOA
Die drei notwendigen Konzepte zur Steuerung einer Enterprise Architecture können mit dem Bausteinansatz umgesetzt werden.
