20070708zg dmc SOA Gefahren beim Aufbau einer SOA
|
|
|
»manage
it«
als
|
Wie Sie Gefahren beim Aufbau einer SOA vermeiden Fallstricke SOA bietet unbestreitbare Vorteile wie gesteigerte Flexibilität, geringere Aufwände und verbesserte Messbarkeit von Investitionen. Nachteile gibt es aber auch – und die werden überwiegend im Management und in der Projektleitung produziert.
icht nur als fortschrittsorientierter Profi im IT-Business ist man in den letzten 3 Jahren um den Begriff der serviceorientierten Architekturen (SOA) nicht herumgekommen. Wie kaum ein anderes Paradigma verspricht dieser neue Ansatz, zahlreiche architektonische Probleme in verteilten Systemumgebungen zu lösen. Vorteile können tatsächlich über eine erhöhte Flexibilität gegenüber sich ändernden Anforderungen, eine Verringerung von zeitlichen und personellen Aufwänden in der Umsetzung von Projekten und in der erhöhten Messbarkeit und damit Erfolgskontrolle von Investitionen abgeschöpft werden. Trotzdem tun sich viele Unternehmen in der Einführung von SOA äußerst schwer. Es wird immer deutlicher, dass dies nicht vornehmlich an Architekturproblemen oder dem Entwicklungsprozess an sich liegt. Vielmehr werden (vermeidbare) Fehler, die den Erfolg von serviceorientierten Architekturen torpedieren, vorrangig im Management und in der Projektleitung gemacht. Wir möchten aufzeigen, auf welche Gefahren Sie bei der Einführung achten müssen, um erfolgreich und nachhaltig von dem neuen Paradigma profitieren zu können. »Nicht alles auf einmal« Durch die verlockenden Prophezeiungen von Lösungsanbietern geblendet, wird viel zu häufig versucht, SOA so schnell wie möglich in allen Bereichen des Unternehmens einzuführen. Mit diesem Ziel vor Augen erstellt dann ein Gremium ein Masterplan, der definiert, wie sämtliche Wissens- und Applikationsquellen des Unternehmens miteinander über eine SOA verschaltet werden sollen. Ein solcher Big-Bang-Approach wird heutzutage allgemein als schwerwiegender Grund betrachtet, der jegliche SOA-Bemühungen zum Scheitern verurteilen kann. Dabei geht es allerdings nicht in erster Linie um die fehlende technische Machbarkeit: viele Softwarelösungen, sowohl kommerziell als auch Open Source, sind durchaus in der Lage, effizient und schnell eine Infrastruktur abzubilden, die sämtliche notwendigen Applikationen technisch integriert. Wenn aber mehrere Dienste miteinander verbunden werden, ist eine Analyse der fachlich-logischen Abhängigkeiten untereinander wichtig: wurde früher ein ausgedrucktes Formular von einer Abteilung in die nächste gereicht, dann haben sich Menschen mit dem Inhalt des Formulars beschäftigt, die das grundsätzliche Geschäftsmodell in ihrer Firma auch über die Abteilung hinaus zumindest rudimentär verstanden haben. Eine Applikation, die in einer Abteilung entwickelt wurde und explizit deren Anforderungen genügt hat, kann oftmals nicht ohne Änderungen oder Erweiterungen in eine Gesamtarchitektur eingebunden werden. In der Planung der SOA müssen deshalb die unterschiedlichen Applikationsmodelle untersucht und auf Abhängigkeiten, globale Erfordernisse und Überdeckungen überprüft werden. Häufig führt diese Analysephase zu einem normalisierten Datenmodell, das die zentralen Geschäftsobjekte im gesamten Unternehmen umfasst. Wo dies aufgrund der Größe der Firma oder der Beschaffenheit der fachlichen Logik nicht sinnvoll oder möglich ist, müssen zumindest mögliche Abhängigkeiten erkannt und deren Auswirkungen überdacht werden. Mit der allmählichen Anbindung von unterschiedlichen Diensten wachsen auch die Anforderungen an die Gesamtarchitektur, sodass man bei den einzelnen Stufen im Aufbau einer SOA durchaus von unterschiedlichen Reifegraden sprechen kann.
Abbildung 1: Die unterschiedlichen Reifegrad-Stufen (angelehnt an das Service Oriented Architecture Maturity Model von Sonic). Quelle: dmc Selbst wenn die Herangehensweise in der Analysephase korrekt ist, empfiehlt es sich nicht, über ein Wasserfallmodell die Architektur und das Design für die gesamte Unternehmens-IT zu definieren. Eine evolutionäre Herangehensweise, in der alle in Frage kommenden Applikationen an eine zentrale Infrastruktur allmählich angebunden werden, bietet eine deutlich höhere Kontrolle über die erzielten Erfolge und lässt präzisere Rückschlüsse auf Problemfälle zu. Werden Dienste zentral angeboten, können sie leicht zu Flaschenhälsen werden und die gesamte Systemumgebung in Mitleidenschaft ziehen. Es ist besser, mit einem klar erkennbaren Problem fertig werden zu müssen (oder den alten Dienst während der Problemzeit wiederzubeleben), als sich gleichzeitig mit etlichen Diensten herumschlagen zu müssen, die die an sie gestellten Anforderungen nicht erfüllen. Die Komplexität einer solchen Systemumgebung wird noch weiter erhöht, indem Dienste allein problemlos funktionieren können, im Zusammenspiel mit anderen Diensten dann aber unerwartete Nebenwirkungen erzeugen. Wie aber wird die Entscheidung darüber getroffen, welche Dienste in welcher Reihenfolge bei der Einführung einer SOA integriert werden? Das lässt sich kaum grundsätzlich entscheiden, weil jedes Unternehmen in seinen Prozessen und den Zielen, die mit einer SOA verknüpft werden, unterschiedlich ist. In jedem Fall werden aber alle Beteiligten, ob fachlicher oder technischer Herkunft, eine gemeinsame und homogene Strategie entwerfen müssen, deren Umsetzung dann aber der Verantwortung eines kleinen Kreises übergeben werden sollte. Oftmals ist auch die Empfehlung hilfreich, mit den Diensten anzufangen, die einen hohen ROI versprechen oder schon seit langer Zeit als »Problemfälle« im Sinne eines übergeordneten Geschäftsprozesses identifiziert wurden. »Rückendeckung vom Top-Management« Will man Prozesse verändern oder einführen, die in allen Bereichen des Unternehmens tiefgreifende Veränderungen nach sich ziehen, ist eine nachhaltige und effektive Unterstützung des Top-Managements eine uneingeschränkte Vorbedingung. Oft versuchen Fachabteilungen, den zusätzlichen Aufwand, der durch die Anbindung eines vormals isolierten Dienstes an die allgemeine Infrastruktur entsteht, so gering wie möglich zu halten. Der Grund ist, dass die neue Situation in erster Linie nicht der eigenen Abteilung, sondern der Allgemeinheit dient. Diese Verhaltensweise ist für eine in sich stimmige und verlässlich funktionierende Systemumgebung hinderlich. Deshalb muss bereits in der Anfangsphase einer SOA eine Verantwortungszuteilung für die zentrale Koordination aller in die SOA eingebundenen Dienste geschaffen werden. Zudem muss ein entsprechendes Budget für die Umsetzung eingeplant werden. Gemeinsame Zielbestimmungen und die Definition von Messkriterien sind dabei unersetzliche Maßnahmen. Die zentrale Koordination der Bemühungen lässt sich durch die Einführung einer sogenannten SOA Governance erreichen. Wie diese organisatorische Einheit in einem Unternehmen eingeführt wird, lässt sich aufgrund der unterschiedlichen Dienste und Organisationsstrukturen, die sich in jedem Unternehmen befinden, nicht auf generelle Weise beantworten. In jedem Fall muss die SOA Governance die Organisation des Lebenszyklus der zentral verfügbaren Dienste übernehmen und sicherstellen, dass diese Dienste gewissen Regeln und Richtlinien folgen. In vielen Fällen hat sich eine im Unternehmen öffentlich verfügbare formale Dienstgütevereinbarung bewährt. Diese Vereinbarung definiert für den jeweiligen Dienst das geforderte Laufzeitverhalten, beispielsweise in bezug auf Antwortgeschwindigkeit, Verfügbarkeit, Stabilität, Versionierung, etc.
Abbildung 2: Wichtige Eckpunkte der SOA Governance. Quelle: dmc
»Vernünftige und realistische Planung für alle Projektphasen« Bei der Planung zur Integration eines Dienstes in eine Diensteumgebung dürfen die (fachlichen) Abhängigkeiten und damit verbundenen Mehraufwände nicht ignoriert werden. Bereits die Anforderungsphase wird bezüglich ihrer Dauer durch unterschiedliche Sichtweisen und nicht identische Perspektiven aller Interessenvertreter erheblich länger dauern als bei vergleichbaren Diensten, die nicht zentral zur Verfügung stehen müssen. Denselben Zeitaufschlag kann man in der Implementierungsphase beim Change-Management-Prozess beobachten: ein Change Request muss im Gegensatz zu isolierten Projekten immer von einer Vielzahl von Interessenvertretern verstanden, diskutiert und akzeptiert werden. In der Testphase gestalten sich die Integrationstests erheblich komplexer und dauern aus diesem Grund auch deutlich länger. Wie oben bereits beschrieben, ist es äußerst sinnvoll, deshalb einen Dienst nach dem anderen an eine SOA anzubinden, um nicht mehrere sich ständig ändernde Dienste gleichzeitig testen zu müssen. Durch das zentrale Vorhalten von Diensten werden in der Regel auch neue oder zumindest drastisch strengere Richtlininien für die Dienstgüte, beispielsweise Stabilität und Hochverfügbarkeit eines Dienstes, verlangt. Dies hat Einfluss auf die Dauer aller Phasen des Softwareentwicklungsprozesses und muss deshalb in die zeitliche Planung und die Budgetierung der einzelnen Projekte einfließen. Es empfiehlt sich zudem, in einem Integrationsprojekt evolutionär vorzugehen und die Detailplanung nicht am Anfang, sondern innerhalb der Iterationen durchzuführen, um die Komplexität des Vorhabens so weit wie möglich zu entzerren. Leider ist das aufgrund der fachlichen Abhängigkeiten der Dienste untereinander nicht immer möglich. »Mitarbeiter nicht überfordern« Zuletzt muss bei der Planung eines Integrationsprojekts darauf geachtet werden, dass die Mitarbeiter der Aufgabe gewachsen sind. Viele Technologien und Lösungen im SOA-Umfeld mögen für den einen oder anderen Entwickler und Architekten neu oder zumindest unvertraut sein. Ob es sich um Transformationslogik (XSLT), die korrekte Definition und Handhabung von Web-Service-Standards (WSDL, SOAP, WS-*, etc.), zentrale Verzeichnisdienste (UDDI, Service Registry und Repository) oder andere Themenfelder handelt, Fehler werden immer dann gemacht, wenn die Technologie noch nicht vollständig beherrscht wird. Diese Fehler können nicht nur den Projekterfolg verringern, sondern im schlimmsten Fall zu Problemen führen, mit denen man sich dann noch Jahre später auseinander zu setzen hat. Unseren Erfahrungen zufolge ist es allerdings nicht notwendig, dass jeder Mitarbeiter in einem Team ein ausgewiesener SOA-Experte ist. Allerdings muss in jedem Projekt zumindest eine Fachkraft sein, die sämtliche Anforderungen klar kommunizieren kann und dafür verantwortlich ist, dass die zum Einsatz kommende Technik richtig angewendet wird, die Dienste richtig definiert werden und keine Widersprüche in fachlicher Hinsicht auftreten, insbesondere in Bezug auf die Integration in eine zentrale Architektur. Die verantwortliche Stelle in einem SOA-Projekt ist darüber hinaus dafür zuständig, die Mitarbeiter mit dem notwendigen Wissen zu versorgen, an geeigneten Stellen einzusetzen und beispielsweise über Reviews ständiges qualitatives Feedback über den anzubindenden Dienst zu erhalten. Resümee Viele augenblicklich wahrnehmbaren Probleme von SOA-Projekten sind nicht auf technische Unzulänglichkeiten oder eine falsche Auswahl von Softwarelösungen zurückzuführen, sondern entstehen durch Fehler in der Planung oder im Management. Eine vernünftige Zielformulierung, konservative Zeitplanung und nachhaltige Unterstützung des Managements sowie die zentrale Koordination aller Bemühungen sind die Garanten für die erfolgreiche Einführung einer SOA. Nur so lässt sich eine Diensteumgebung schaffen, die sämtliche Versprechungen hält, die man allerorten von diesem vielversprechenden Paradigma vernehmen kann.
Thomas Seibert ___________________________________________________________ Thomas Seibert ist im Systemhaus der dmc digital media center GmbH in Stuttgart als director IT solutions beschäftigt. Mit Java hat er 10, mit J2EE mehr als 7 Jahre Erfahrung. Seit mehreren Jahren berät er Firmen in Themen der SOA, Applikationsintegration und des Business Process Managements.
|
Folgen Sie »manage it« auf Google+
|
