Planung einer serviceorientierten Architektur mittels Best Practices für Enterprise Architecture Management

Whitepaper | Januar 2007 Planung einer serviceorientierten Architektur mittels Best Practices für Enterprise Architecture Management 2 Januar 2007 „Die Auswirkungen der SOA spiegeln sich in der Möglichkeit für die IT wider, die Hindernisse aus dem Weg zu räumen, die bislang ihre Unterstützung des Business gehemmt haben: Steigerung der Flexi- bilität für einen Unternehmenswandel, Ermögli- chung des Mehrkanalzugriffs auf Business-Funktio- nen und Positionierung für eine engeren Kopplung zwischen den Geschäftsprozessen eines Unterneh- mens und denen seiner Kunden und Lieferanten.“ – ‘The Enterprise Architecture of SOA’, Forrester, Alex Cullen, Feb. 2006. Planung einer serviceorientierten Architektur 3 Einleitung Die serviceorientierte Architektur (SOA) kommt zur rechten Zeit auf. Der Reife- prozess der meisten IT-Organisationen ist so weit fortgeschritten, dass sie sich wirklich als Dienstleister für das Business verstehen. Ohne dieses Selbstver- ständnis hätte die SOA keine Chance, die Vorteile für das Business zu schaffen, zu denen sie das Potenzial hat. Es gibt sicherlich einige IT-Abteilungen, die die SOA nur im Zusammenhang der Konsolidierung von routinemäßigen techni- schen Verwaltungsaufgaben wie etwa der Authentifizierung, der Autorisierung, der Sicherung und Wiederherstellung, der Sicherheit, der Nachrichtenübertra- gung, der Integration etc. umsetzen. Viele andere IT-Organisationen denken, dass SOA der IT die Möglichkeit bietet, sich selbst als einen Business-Partner zu positionieren (siehe links), können aber mangels eines detaillierten Architektur- planungs- und -verwaltungsverfahrens diese Möglichkeiten nicht ausschöpfen. Sie sind überwältigt von der wahrgenommenen Notwendigkeit, ihre gesamte Ar- chitektur neu zu verdrahten, und einige scheitern bereits an der Frage: ‘Welche Architektur?’ Dennoch haben genug IT-Organisationen das wahre Potenzial ei- ner Strukturierung der Geschäftsprozesse in Service-Portfolios und der entspre- chenden Bündelung von Technologien für die Rationalisierung und flexiblere Gestaltung von Geschäftsprozessen verstanden. Diese IT-Organisationen haben eine Führungsposition hinsichtlich der SOA-Initiativen eingenommen und er- weisen sich als engagierte Service Provider, die in hohem Maß zur Effizienz des Business beitragen. Nachfolgend sind einige Beispiele aufgeführt: • BM: 77 gemeinsam nutzbare und wiederverwendbare Services in der Pro- I duktion - von der Authentifizierung bis hin zur Auftragsausführung - was die Verringerung des Inventars von 16.000 Applikationen im Jahr 1998 auf derzeit 4.000 Applikationen ermöglicht hat. •  achovia Bank: Durch die SOA ermöglichte Entwicklung einer Hochleistungs- W Modellierungsanwendung, die die Modellierungszeit für Investment Deals von mehreren Stunden auf wenige Minuten verringert hat. Die SOA hat außerdem die Entwicklung einer Kapital-Desktopanwendung innerhalb von 90 Tagen er- möglicht, für deren Planung und Entwicklung normalerweise 6 bis 12 Monate veranschlagt werden. 4 Januar 2007 •  ewlett Packard: Die Implementierung der SOA hat zu Einsparungen von bis H zu 70 Mio. US$ geführt. Diese sind auf Rückflüsse bei der Konsolidierung, auf die Verringerungen von Redundanzen und auf die Wiederverwendung ver- schiedener Services zurückzuführen. •  meriprise: Einsparungen in Höhe von mehreren Millionen Dollar bei den Ent- A wicklungskosten dank der Wiederverwendung wichtiger Business-Services.1 Enterprise Architecture Management aus Sicht der SOA: Was hat sich geändert und was nicht? In Unternehmen, die eine SOA fördern, ist die Bedeutung des Enterprise Ar- chitecture Managements (EAM) enorm gestiegen. Diese beiden Themen sind so eng miteinander verschmolzen, dass sich nur schwer sagen lässt, ob eines dem andern übergeordnet ist. ’Best Practice’ EAM berücksichtigt bereits einige An- forderungen von SOA und Produkte für die strategische Planung wie beispiels- weise planningIT unterstützen diese Konzepte: •  in einziges, zentrales Repository, das alle planungsrelevanten Informationen E über alle Architektur-Artefakte als eine umfassende Informationsbasis für eine effektive IT-Planung enthält. •  ingehende Prüfung von Architektur-Änderungsanfragen, um redundante Ar- E beiten und negative Auswirkungen auf andere Systembereiche zu vermeiden. •  trikte Einhaltung von Standards und Richtlinien, um die kontinuierliche Ent- S wicklung hin zur IT-Architekturvision zu gewährleisten. •  ransparente und messbare IT/Business-Beziehungen, um den IT-Support für T das Business bewerten zu können. •  rchitektonische Gesamtplanung, die die aufeinander aufbauenden Schritte A auf dem Weg hin zur Soll-Architektur definieren. •  ollaborativer Prozess für eine kooperative Planung und Implementierung. K Daher erfordert die SOA üblicherweise kein neues Enterprise-Architekturkon- zept. Die SOA stellt das Architektur-Team jedoch in Bezug auf die Services1 (1 Im weiteren Verlauf dieses Dokuments bezieht sich der Begriff ‘Services’ auf Business-Services im Gegensatz zu den zuvor erwähnten routinemäßigen Planung einer serviceorientierten Architektur 5 technischen Services.) vor neue Herausforderungen. Auf dem Weg hin zu einer serviceorientierten Architektur stellt die EA-Gruppe häufig fest, dass •  ie Struktur der Geschäftsarchitektur nicht für eine Wiederverwendung geeig- d net ist, •  s der Organisation an einer unternehmensweiten, einheitlichen Serviceklas- e sifizierung mangelt, • für das Unternehmen wichtige Services nicht sofort identifiziert werden können,  •  chwächen in der aktuellen Service-Landschaft nicht gleich erkannt werden S können, •  ein geregelter Prozess für die Erstellung von Services als inhärente Elemente k der EA vorhanden ist, •  ie Erstellung und Pflege von Services auf das gesamte Unternehmen ver- d streut erfolgt. Diese unbefriedigende Situation ist der Katalysator für Verbesserungen im EAM, was dazu führt, dass sich das EA-Team intensiver mit einigen Themen wie beispielsweise den nachfolgend aufgeführten beschäftigt: •  esseres Verständnis für das Geschäft und Identifizierung wirklich unterneh- B menskritischer Geschäftsprozesse •  erbesserte Ausrichtung von IT am Geschäft durch die Förderung eines SOA- V zentrierten EA-Konzepts, das das Geschäft in der IT-Landschaft verankert •  trategische IT-Planung, die einen evolutionären Prozess mit einer Vision und S entsprechenden Teilzielen umfasst und die Disziplin in einigen Bereichen wie etwa den nachfolgend aufgeführten erhöht: • mplementierung strenger Governanceprozesse und Standards, um I •  ie Wiederverwendung von Services durchzusetzen d •  oppelte Services zu vermeiden d •  ie geforderte Qualität der Services zu gewährleisten d 6 Januar 2007 •  ufrechterhaltung einer transparenten, dokumentierten Architektur trotz der A Vielzahl der zu verwaltenden EA-Elemente, um •  as Potenzial für die Wiederverwendung von Services zu erkennen, d •  ine eingehende Analyse der Auswirkungen durchführen zu können. e Abbildung 1: ’The EA group’s SOA deliverab- les’, The Enterprise Architecture of SOA, Forrester, Alex Cullen, Februar 2006 In diesem Dokument werden EAM ‚Best Practices’ im Kontext einer serviceori- entierten Architektur vorgestellt: was bringt das EAM mit sich und zu welchen neuen Entwicklungen führt es für die Unterstützung des EA-Teams bei dessen SOA-Bemühungen. Außerdem wird die Unterstützung dieser Bemühungen durch das strategische EA-Management- und Planungstool planningIT beschrieben. Strukturierung der Geschäftsarchitektur Da das Hauptziel der SOA die Steigerung der Effizienz der Geschäftsprozesse ist, stellt das Business den Ausgangspunkt für die SOA-Initiativen eines Unterneh- mens dar. Die Geschäftsarchitektur muss so strukturiert werden, das sie ver- waltbar und - was noch wichtiger ist - für die Ergreifung des Besitzes geeignet ist, um die kollaborative Basis für die SOA-Bemühungen zu schaffen, was sicher- lich keine leichte Aufgabe ist. Die ersten Strukturierungsbemühungen werden schwierig sein, weil ‘Unternehmen starten nicht auf der grünen Wiese sondern haben eine reichhaltige über Jahre und Jahrzehnte gewachsene Unternehmens- architektur. Die Funktionsfähigkeit dieser Architektur ist für das Unternehmen Planung einer serviceorientierten Architektur 7 überlebenswichtig. Andererseits ist diese Architektur in weiten Teilen redun- dant oder monolithisch, woraus sich ja gerade das Potenzial für Kostenreduktion und Steigerung der Flexibilität ergeben. Um glaubwürdig und durchführbar zu sein, muss die Einführung von Service-orientierter Architektur bei der histo- risch gewachsenen Landschaft ansetzen.