Die potenziellen Vorzüge Service-orientierter Architekturen sind mittlerweile weithin bekannt und akzeptiert. Viele Unternehmen beschäftigt die Frage, wie sie SOA-Projekte konkret angehen sollen. Doch darüber gehen die Meinungen auseinander: Nicht wenige Experten empfehlen die große übergreifende Strategie, das alles umfassende (fachliche) Servicemodell als Ausgangspunkt. Derartige Initiativen muss das Topmanagement treiben, lautet ein oft gehörter Rat. Andernfalls ließen sich beispielsweise die nötigen Governance-Strukturen nicht durchsetzen.
Dagegen stehen die Protagonisten eines Bottom-up-Ansatzes, unter ihnen Anwender, die ihre Kernprozesse mit Altanwendungen abwickeln und diese Investitionen schützen wollen. Sie beginnen häufig mit Projekten zur Legacy-Modernisierung, kapseln Mainframe-Anwendungsfunktionen als Services und achten auf einen schnellen Return on Investment (RoI). Erst nach bewiesenem Nutzen weiten sie Service-orientierte Konzepte auf andere Unternehmensbereiche aus.
Bottom-up oder Top-down – welches ist der richtige Weg zur SOA? Die Frage mag banal klingen. Unternehmen müssen sie beantworten, bevor sie Projekte planen.
Die Frage, ob eine Service Orientierte Architektur (SOA) top-down oder bottom-up eingeführt werden sollte, kann man nur mit einem eindeutigen JA beantworten. Einerseits ist es erforderlich, die Architektur an der Spitze der Pyramide der Unternehmensziele auszurichten. Dabei sollten die Unternehmen zunächst eine Unternehmensarchitektur gestalten, die den Weg für eine Prozessarchitektur weist. Diese wiederum zeigt den Weg zu einer Informationsarchitektur auf, die wiederum die technische Komponentenauswahl beeinflusst. Insofern ist von der Architekturseite der Top-Down-Ansatz schon im Namen – Architektur – angelegt. Man baut ein Haus ja schließlich auch nicht indem man erst einmal anfängt zu mauern und dann am Schluss einen Plan zeichnet, wie denn nun alles geworden ist. Aber zugegebenermaßen gibt es leider immer noch solche so genannten Ist-Architekturen.
Anderseits ist es unbedingt erforderlich, die involvierten Mitarbeiter eines SOA-Unterfangens intensiv auszubilden und zu motivieren, damit sie die Konzepte, Notwendigkeiten und ihre Rollen im Konzert der Aktivitäten verstehen. Die ERP-Hersteller (und andere Hersteller) können ein Lied davon singen, wie schwer es manchmal ist, die Entwickler, die bisher nach traditionellen Konzepten programmiert haben, mit dieser neuen Welt vertraut zu machen. Nach eingehender Schulung entstehen bottom-up häufig exzellente Ideen, die das Gesamtkonzept der Architektur maßgeblich positiv beeinflussen können. Von Managementseite gilt es den Kommunikationsprozess zielgerichtet zu fördern, um so zu einem Gesamtverständnis der unternehmenseigenen SOA zu kommen.
Bottom Line: Bei SOA-Projekten sind sowohl Top-Down- wie auch Bottom-Up-Aktivitäten unentbehrlich. Ein Zusammenspiel der Einzelaktivitäten erfordert ein herausragendes Projektmanagement. Einzelne Phasen der Projekte weisen unterschiedliche Schwerpunkte der Top-Down- und Bottom-Up-Anteile auf.
Wer über eine Senkung der IT-Kosten hinaus signifikante Geschäftsvorteile erzielen will, wird um eine Top-down-Perspektive auf die Service-Architektur nicht herumkommen. Eine solche integrierte und modulare IT-Landschaft kann signifikante Beiträge zur weiteren Prozessautomatisierung, Flexibilisierung des Geschäftsmodells sowie eine wesentlich höhere Transparenz der Geschäftsperformance ermöglichen. Die Voraussetzung für die erfolgreiche Realisierung der Potentiale liegen nämlich nicht nur in der Veränderung der IT, sondern auch in veränderten Geschäftsprozessen bzw. organsatorischen Strukturen. So kann die Einführung eines Data-Warehouse die Voraussetzungen für eine kunden- oder auftragsbezogene Ergebnisrechnung schaffen. Ergebniswirksam wird eine solche Investition aber erst, wenn die Kundenstammdaten systemübergreifend konsistent sind, die Prozesskosten korrekt ermittelt wurden und der Vertrieb dies bei der Kundenakquise aktiv berücksichtigt. Wird eine der beispielhaft genannten Voraussetzungen nicht erfüllt, bleibt das Data-Warehouse ein Torso.
Die Schwerpunkte einer Business Transformation sollten deshalb aus den geschäftlichen Potentialen abgeleitet werden. Die Ist-IT-Architektur ist dabei lediglich eine wichtige Randbedingung.
Der SOA Lifecycle Ansatz ist vergleichbar mit dem Vorgehen bei der Enterprise Architektur, allerdings mit besonderem Augenmerk auf die Geschäftprozesse. Im Gegensatz dazu benötigt die Service-orientierte Architektur die Geschäftprozesse und IT-Transformation. Bisherige Governance- und Organisationsmodelle werden mittels einer speziellen Vorgehensweise ersetzt, um damit ein Höchstmaß an Flexibilität zu erhalten. Die beteiligten Fach- und IT-Abteilungen schauen sich die bisherigen unmittelbar betroffenen Verantwortungsbereiche an und beteiligen sich an der Definition einer gemeinsamen Strategie und Roadmap, um ihre Ziele erreichen zu können.
Die SOA ist eine operative Geschäftsstrategie, um die passenden Informationen für die Organisationsziele zur Verfügung zu stellen. Als Unternehmensziele sind meist Umsatzsteigerung, Erhöhung der Kundenzufriedenheit, Steigerung der Produktqualität und Verbesserung der unternehmerischen Handlungsfähigkeit anzumerken.
In der Praxis wird SOA von den beteiligten Personen sehr unterschiedlich wahr genommen. Für den IT Architekten bedeutet es die unternehmensweite Architekturdefinition und den IT-Prozess von der schnellen Entwicklung zur Bereitstellung der geforderten geschäftlichen Leistungsfähigkeit zu bringen. Architekten suchen typischerweise Herstellerinformationen über detaillierte Produktbeschreibungen, Kundenreferenzen, Best Practices, dann werden existierende Publikationen und Standards miteinander verglichen, beispielsweise W3C, java.net, OASIS.
Für die Verbindung von Fachbereichen und IT (LOB-IT) bedeutet SOA vordringlich Governance, Organisation, den Prozess für Projekt- und Programm-Management und die zahlreichen Building Blocks mit ihrer potentiellen Wiederverwendbarkeit, um tatsächlich Kosten zu reduzieren. In der aktuellen Analysephase sind die LOB-IT Verantwortlichen und die CIOs auf den entsprechenden Fachforen und Konferenzen vertreten, um die Hersteller- und Analysten-Informationen zu beurteilen.
Für die rechtliche Seite in den Unternehmen wird SOA hauptsächlich als Haftungsgrundlage gesehen. Vertraglich wird festgelegt wann ein bestimmter Service die gewünschten Informationen an Geschäftspartner, Kunden und Interessenten bereitstellt, und welche gesetzlichen Vorgaben und Änderungen entstehen könnten.
Für den CIO ist SOA eine IT-Strategie, um die geschäftlichen Leistungsfähigkeit bereitzustellen. Dabei stellt sich die Frage nach den zu automatisierenden Unternehmensfunktionen: Welche Services sollen verwendet werden, wie ausgereift sollen sie sein, zu welchen Kosten und welche Service Level Agreements sind dabei zu erwarten? Fazit: Ohne diese Fragen geklärt zu haben wird ein Bottom-up Ansatz nicht gelingen.
Top-Down versus Bottom-Up ist eine der Grundfragen in der IT – und das nicht erst seit Aufkommen des Themas SOA. Beide Ansätze können richtig sein, Pauschalurteile, was der bessere oder gar der Königsweg wäre, greifen hier zu kurz. Vielmehr muss ein Unternehmen der Frage des Wann und Wie nachgehen, um eine valide Antwort zu bekommen.
Auf strategischer Ebene sollten die Grundfragen unternehmensweit geklärt und entsprechend die Eckpfeiler festgelegt sein. Darunter fallen auch die notwendigen Governance-Modelle. In der konkreten Umsetzung hingegen tendiere ich jedoch zu einem Hybrid-Ansatz auf Basis der gestellten Anforderungen: Wird ein Top-Down-Ansatz verwendet, sind im speziellen die Anforderungen der Geschäftsprozessbesitzer führend. Das bedeutet: Anforderungen werden formuliert, ohne darauf Rücksicht zu nehmen, ob diese Anforderungen durch die bestehenden IT-Systeme zu realisieren sind. Ist das der Fall, dann wird der geforderte Prozess optimal unterstützt. Werden im Gegensatz dazu die Geschäftsprozessanforderungen so lange nachjustiert, bis sie die Funktionalität der bestehenden Systeme widerspiegeln, dann spricht man vom Bottom-Up-Ansatz. Fazit: In diesem Fall ist man minimal invasiv, die Implementierungskosten halten sich in Grenzen, aber die Fachabteilung muss zwangsläufig mit Kompromissen leben.
Es ist schnell zu erkennen, welche Wichtigkeit eine Enterprise SOA der SAP und vor allem die Reichhaltigkeit des Repositories bei der Lösungserstellung spielt. Je mehr standardisierte Elemente vorhanden sind, desto schneller lassen sich befriedigende Lösungen implementieren. Was die Erfahrung aus den ersten Projekten zeigt: der Trend zeigt klar in Richtung zu kleinen, überschaubaren, entkoppelten Teilprojekten. Es ist eine Art Inkubationsansatz, bei dem zunehmend mehr Prozesse service-orientert implementiert werden, die besondere Flexibilität oder eine zügige Einführung erfordern. Durch diesen Ansatz werden sukzessive mehr und mehr Prozesse service-orientiert, bis man letztlich vollständig bei der neuen Plattform angelangt ist. Interessanterweise ist dabei auch zu erkennen, welche Teile im Unternehmen sich vornehmlich der Produktivität zuschreiben und nicht vollständig service-orientiert migriert sein müssen.
Um die Frage nach der Motivation zu klären, sollte Top-Down versus Bottom-Up um einen weiteren Aspekt erweitert werden: Outside-In versus Inside-Out.
Die Ursprungsaussage enthält zwei wichtige Erkenntnisse, mit denen allein die Überschrift schon zu rechtfertigen wäre. „Ping“: Eine SOA Initiative muss im Unternehmen vom Topmanagement getrieben werden.
„Pong“: Investitionen müssen geschützt werden.
So platt das klingen mag, die Welt ist eben nicht schwarz und weiß und das ändert sich auch dann nicht, wenn wir es uns der Einfachheit halber noch so sehr wünschen.
Es ist hoffentlich nicht mehr strittig, dass SOA kein reines IT Thema ist, sondern ein Hilfsmittel um Unternehmensstrategien umzusetzen. Strategien entstehen aus einer Vision und Visionen wiederum entstehen äußerst selten Bottom-up. Womit wir dann auch u.a. beim Thema Governance wären. Governance wird am besten mit: „angemessene Unternehmensorganisation zur Optimierung der Unternehmensführung und –steuerung“ übersetzt. Dies gilt dann 1:1 übersetzt für IT Governance und als Erweiterung dieser für SOA Governance.
Die Vorgabe der Vision, die Ableitung der Strategie/Roadmap daraus und die Schaffung der organisatorischen Rahmenbedingungen sind also tatsächlich Aufgabe des Topmanagement. Allerdings ist es nicht damit getan, ein dickes Regelwerk zu schreiben, sondern jeder Beteiligte und zwar auf jeder Ebene sollte die Relevanz für sich verstehen und damit leben können.
Bei keinem Unternehmen das ich kenne, habe ich erlebt, dass ein reiner „grüne Wiese“ – Ansatz verfolgt werden konnte, denn die Durchdringung mit IT ist inzwischen soweit fortgeschritten, dass es praktisch überall existierende Funktionalität zu berücksichtigen gilt. Das bedeutet, dass Legacy-Modernisierung oder Kapselung von Mainframe Anwendungsfunktionen meist Bestandteil von SOA-Initiativen oder Projekten sind.
Dies ist allerdings aus meiner Sicht nicht der einzige Aspekt, der zum Thema Topdown oder Bottom-up relevant ist. Es wird in diesem Zusammenhang sehr häufig diskutiert – wieder mal – ob die richtige Granularität, die eine entscheidende Rolle beim Thema Wiederverwendung spielt, mit einem reinen Topdown-Ansatz gefunden werden kann. Die Erfahrungen aus zahlreichen objekt-orientierten Projekten haben gezeigt, dass dies unter praktischen Gesichtspunkten nicht möglich ist und so gilt auch hier, dass eine Kombination aus Topdown Analyse und einem Bottom-Up Lernprozess oder Benchmarkprozess die zielführende Vorgehensweise ist. Überhaupt gilt, dass nach dem Prinzip „Keimzelle“ die besten Erfolge erzielt werden. Wir haben dabei mit der Schaffung eines SOA Centers of Excellence (CoE), das nicht diktiert, sondern berät und den Lernprozess im Unternehmen moderiert, die besten Erfahrungen gemacht.
Es wird auch immer wieder gestritten, welches nun der beste Einstiegspunkt für SOA sei. Wir haben dabei die Erfahrung gemacht, dass wenn die Rahmenbedingungen wie Vision, Strategie, Roadmap und Architekturblaupause definiert und verstanden sind, praktisch von jedem Punkt aus das Ziel erreicht werden kann.
Aus den Erfahrungen von inzwischen zahlreichen Projekten weltweit haben wir sieben unterschiedliche Einstiegspunkte identifiziert, die geeignet sind, den SOA Weg zu beginnen.
Es handelt sich dabei um die Kontexte:
1. Unternehmenstransformation (noch eher selten aber gut)
2. IT-Transformation (auch noch selten und auch gut)
3. Arbeitsplatzneugestaltung oder -umgestaltung
4. Prozessneugestaltung oder –umgestaltung
5. Information (hier Information als Service, z.B. Master Data Management)
6. Verbindung/Ökosystem (die Vorgänger waren die EAI Projekte)
7. Modernisierung/Wiederverwendung
Zusammenfassend kann also aus meiner Sicht gesagt werden, dass SOA-Initiativen, die vom Topmanagement getrieben werden und mit der Möglichkeit ausgestattet sind, in jeder Phase aktiv zu lernen, die besten Chancen haben, den erwarteten Beitrag zu erbringen.
Eine der wichtigsten strukturellen Entscheidungen im Zusammenhang mit einer SOA-Umsetzung ist die Wahl des Implementierungsansatzes.
Im wesentlichen zu unterscheiden sind dabei der zentrale, unternehmensübergreifende Roll-Out-Ansatz (Top-Down) sowie der dezentrale, mehr opportunitätsgetriebene Einzelprojektansatz (Bottom-Up). In der Praxis ist allerdings meist eine taktisch geprägte Vermischung beider Grundansätze zu beobachten:
In einem frühen Stadium der SOA-Adaption werden Vorhaben z.B. zur Schaffung von Infrastruktur- und Integrationsdiensten zunächst durch Einzelprojekte, die einen Pilotcharakter besitzen und häufig unter der Schirmherrschaft der zentralen IT-Organisation stehen, adressiert. Auf der Basis der dadurch geschaffenen SOA-Infrastrukturdienste können nun Projektinitiativen nachfolgen, in denen es um die Realisierung von mehr geschäftsprozessorientierten SOA-Implementierungen geht. Auf jeden Fall gilt: Nur durch eine übergeordnete Koordination kann verhindert werden, dass sich SOA-Insellösungen mit fehlender Interoperabilität und uneffizienter Redundanz ausbreiten.
Selbstverständlich ist die Verankerung einer zentralen, unternehmensübergreifenden SOA-Governance-Instanz ein probates Mittel zur Vermeidung solcher Fehlentwicklungen, doch kann sich zu viel Kontrolle auch negativ auf die notwendige Kreativität rund um die Umsetzung von möglicherweise kritischen Geschäftsprozessanforderungen auswirken. Somit ist es nicht verwunderlich, dass die zurzeit erfolgreichen SOA-Adaptionen durch eine ausgewogenen Balance zwischen dezentraler Automomie und zentraler Standardisierung bzw. Planung charakterisiert sind. Das im Einzelfall richtige Maß an zentraler SOA-Governance muss sich an der Organisations- und Profit-Center-Struktur, der Komplexität und der Größe des Unternehmens orientieren.
Mit Top-Down und Bottom-up verhält es sich wie mit Strategie und Taktik: Das Eine kann auf das Andere nicht verzichten. Nicht nur Feldherren, sondern auch SOA-Betreiber sind daher gut beraten, beide Ansätze überlegt und ausgewogen einzusetzen. Die Zielsetzung bestimmt dabei die Wahl der Mittel.
Wer, wie die Deutsche Post, mit SOA langfristige Integrationsziele verfolgt, wird an einer stärkeren Gewichtung der strategischen Komponente nicht vorbeikommen. Dies schließt die strategiegerechte Einbindung von Bottom-up-Ansätzen jedoch nicht aus – im Gegenteil.
Die Entwicklung eines konsistenten Serviceportfolios muss zum Beispiel nicht ausschließlich Top-down auf Basis eines übergeordneten Modells von Business-Objekten erfolgen. Vielfach lassen sich Services auch direkt aus Applikationen ableiten – um etwa kurzfristigen Business-Nutzen zu erzielen.
In der IT-Governance der Deutschen Post hat sich für diese Art des Vorgehens der Begriff der ‚Managed Evolution’ ausgeprägt. Dabei gilt es, strategische Ziele und Quick-Wins miteinander zu verbinden. Analog erfolgt die Steuerung von SOA Top-down, bei der Realisierung kann indes – wo taktisch sinnvoll – auf Bottom-up-Ansätze zurückgegriffen werden.
Serviceorientierte Architekturen (SOA) sind weniger ein Technik-Thema als viel mehr ein Management-Thema. Die derzeitigen Diskussionen um SOA sind vorrangig um Technologie, dabei liegen die wesentlichsten Herausforderungen eindeutig in unternehmerischen, organisatorischen und fachlichen Aspekten. Neben Kostenaspekten spielen strategische Überlegungen eine wichtige Rolle. Die flexible Reaktion auf neue Geschäftsanforderungen sowie die Vorbereitung auf eine neue Geschäftsmodelle und Expansionsphasen sind Argumente für SOA, die sich mit den Überlegungen des Managements decken. Bei SOA handelt es sich ganz klar um eine strategische Ausrichtung des Unternehmens, die wesentliche Teile der IT betrifft und nicht um eine punktuelle Maßnahme im Unternehmen. Somit bedarf es bei der Einführung von SOA der intensiven Beteiligung und der Zustimmung des Managements.
Rückhalt vom Management ist oft nur dann geboten, wenn eine Übereinstimmung der Zielsetzungen des Managements mit den SOA-Potenzialen vorhanden ist. Hier stehen oft kurzfristige Zielsetzungen wie Kostensenkungen und Effizienzgewinne im Vordergrund. Bei SOA handelt es sich allerdings um einen evolutionären Prozess, der sich über einen längeren Zeitraum erstreckt, begleitet von einer nachhaltigen Anpassung der IT-Architektur. Eine Kosten/Nutzenanalyse kann sich deshalb nicht auf ein einzelnes oder kurzfristiges Projekt beschränken. Der Nutzen einer SOA steigt erst mit dem Durchdringungsgrad im Unternehmen. Um vorhandene, ineffiziente Ansätze zu verdrängen, müssen verbindliche Richtlinien festgelegt und konsequent durchgesetzt werden. Somit bekommt das Architekturmanagement eine wesentliche Bedeutung für SOA. Darüber hinaus sind die fachliche Strukturierung der Services, angepasste Verantwortungsregelungen sowie abgestimmte Prozesse zur Einbindung von Services notwendig, um eine SOA in komplexen Unternehmensstrukturen zu implementieren.
Problematisch ist, dass oftmals durch die vorhandene Organisation der IT derjenige, der einen Service bereitstellt nicht den unmittelbaren Nutzen erzielt. Oftmals existiert keine interne Kostenverrechnung für die Verwendung von Services. Nutzen stellt sich aber erst ein, wenn der Anbieter einen Service von einem weiteren Anbieter verwenden kann und so der Entwicklungsaufwand im Projekt reduziert wird.
Grundlegender Erfolgsfaktor für SOA ist die ganzheitliche Betrachtung, denn SOA beinhaltet mehrere Aspekte:
• Unternehmens- und IT-Strategie
• Governance und Organisation
• Fachliche und technische Architektur
Erst das nahtlose Zusammenspiel aller Aspekte macht eine produktive und effiziente Realisierung einer SOA möglich. Dabei bedarf es der Beteiligung des Managements. Weiterhin kann die Einführung nicht im Rahmen eines isolierten Großprojektes durchgeführt werden, das ein immenses Investment benötigt und große Teile der verfügbaren Ressourcen bindet. Die Komplexität eines solchen Projekts ist kaum beherrschbar. Darüber hinaus muss die Implementierung von neuen fachlichen Anforderungen vorrangig gewährleistet sein. Oftmals besitzen diese kurzfristig eine höhere Priorität als die Umstrukturierung der Infrastruktur. Deshalb ist eine systematische und integrierte Vorgehensweise ist erforderlich. IT-Projekte, die neue Anwendungsfunktionalität bereitstellen, sollten gleichzeitig ein Stück Architekturfunktionalität realisieren, denn nur so verbinden sie Geschäftsnutzen mit Architekturnutzen im Sinne einer Schrittweisen, evolutionären Migration.
Der erste Schritt besteht darin, verbindliche Richtlinien festzulegen, welche die Ziel-Architektur („Big Picture“) beschreiben. Im Rahmen des Architekturmanagements ist es dann notwendig, Metriken und Kennzahlen zur Bewertung der existierenden Systemlandschaft zu erheben. Diese Werte in Verbindung mit geschäftsstrategischen Kriterien bilden die Grundlage für die Identifizierung der Bereiche bzw. Projekte wo kurzfristig der größte Nutzen durch eine SOA zu erwarten ist (Pilotprojekte). Die evolutionäre Migration hat den Vorteil, dass es sich um eine iterative Vorgehensweise handelt. Vorgaben des Architekturmanagements, die sich bei der Umsetzung als hinderlich bzw. falsch herausstellen, können für zukünftige Projekte sofort verbessert werden. Das Risiko eines Scheiterns wird so reduziert. Mittelfristig und mit steigender Anzahl der Projekte, die einen Beitrag zur Gesamtarchitektur liefern, wird zielgerichtet eine SOA erreicht.
Eine weitere große Herausforderung, für die Realisierung einer SOA, ist das „richtige“ Design von Services. Hier bedarf es praktischer Erfahrung und einer sorgfältigen Business-Analyse der Geschäftsprozesse. Es existieren keine formalen Ansätze zur Modellierung von Services, wie es vergleichbar für die Datenmodellierung oder das objektorientierte Design der Fall ist. Die Analyse nach geschäftlichen Fähigkeiten eines Unternehmens (Business Capabilities) unter Berücksichtigung der „Key Performance Indicators“ (KPIs) sowie der Geschäftpartner hat das Ziel, die Handlungsoptionen in den Geschäftsprozessen und in der Unternehmensarchitektur aufzuzeigen. Die Ergebnisse bieten kurzfristig eine objektivere Entscheidungsgrundlage über den Mehrwert der Änderungen. Das Resultat ist eine stabilere Sicht auf das Unternehmen als Ausgangspunkt für den Entwurf einer realitätsnäheren Unternehmensarchitektur. Sobald ein derartiges Konzept steht, kann die IT dazu übergehen, die stabilen Services mit Unterstützung der geeigneten Technologie umzusetzen. Hier bilden vor allem Erfahrungswerte die Basis für das Design von Services, wodurch die Qualität stark von der Kompetenz des Enterprise/Software Architekten abhängig ist.
Das SOA-Konzept basiert auf bereits bestehenden IT-Landschaften und bei einer gezielten unternehmensweiten Einführung (Business und IT) gelingt es, die Heterogenität innerhalb der IT- und Anwendungslandschaft zu reduzieren sowie die bereits vorhandenen Investitionen in eine adaptivere und flexiblere Unternehmensarchitektur überzuführen: Eine absolute Notwendigkeit für die Entwicklung neuer Geschäftsmodelle und Märkte im Sinne der zukünftigen globalen und vernetzten Wertschöpfungskette der Unternehmen.
Die Antwort auf die Frage, ob bei SOA-Projekten top-down oder bottom-up vorgegangen werden soll, ist abhängig von der Zielsetzung solcher Projekte.
Geht es vorwiegend um die sukzessive Ablösung von Legacy-Systemen, deren Funktionalität dann modularisiert und in Form von Service gekapselt angeboten werden soll, so ist eine bottom-up Vorgehensweise durchaus Erfolg versprechend.
Ist das Ziel der SOA-Einführung jedoch umfassender, d.h. im Sinne einer Enterprise SOA, so ist eine top-down Vorgehensweise unumgänglich. In diesem Zusammenhang ist eine ganzheitliche Sicht auf das Unternehmen notwendig, die nicht nur die IT-Landschaft betrachtet, sondern auch Geschäftsstrategie, Geschäftsprozesse und Organisationsstruktur berücksichtigt. Die Herausforderung besteht hierbei, ausgehend von den Geschäftsprozessen, in der Identifikation von Services geeigneter Granularität, die möglichst in verschiedenen Kontexten und Geschäftsprozessen unternehmensweit wiederverwendet werden können. In diesem Zusammenhang ist die Umsetzung einer SOA Governance von entscheidender Bedeutung, die das Management der Services über deren gesamten Lebenszyklus hinweg regelt.
Die Fragestellung stellt – natürlich ohne Hinterfragung – SOA und nicht das System der Geschäftsprozesse ins Zentrum des Geschehens. Für IT-Spezialisten eine quasi “natürliche” Methode, denn es sichert ihnen durch die Sicht-Verdrehung weg vom Geschäftsprozess und hin zur SW-Architektur den beherrschenden Spin im SOA-Spiel.
Im Nucleus von SOA stehen – in Übertragung der Kundenorientierung – die in einer grafischen Universalsprache (BPMN) analysierten und dargestellen Geschäftsprozesse (GP). Diese praktisch m.o.w. gegebene GP-Welt gilt es als Dienst in SW zu spiegeln – und nicht umgekehrt.
Top-Down oder Bottum-Up sind dann zwei Seiten einer konzeptionellen Orgaisationsmedaille für an die GP angepasste SW-Welten. Wer ein Haus ohne Gründung bauen will, wird scheitern. Wer bei der Gründung nicht weiß, was er darauf aufbauen wird, wird sich verkalkulieren. Jeder Bauingenieur kennt den iterativen Prozess der statischen Berechnungen. Nicht anders bei SOA: Es geht um eine Gratwanderung der zwei Seiten einer Medaille. Die beschworene Ganzheitlichkeit besteht praktisch in dieser Gratwandeurung. Sie ist garantiert keine Binsenweisheit, sondern abwägende wie gängige Praxis.
Was auch immer in einem konkreten Projekt den Ausschlag geben wird, ohne diekten Folgebezug auf die Einheit von GP-Basis und deren IT-Servicestrukutur wird man sich entweder nach oben oder nach unten verlieren. Wer hier Einseitigkeiten predigt, glaubt an sein Konzept. Besser ist es, zu wissen, dass man sich den GP- und SW-Welten nähern sollte.
Und wenn dies nicht in erster Linie aus Sicht der IT-Welten, sondern der Organisationswelten (Fach-, Führungs-, Servicemanagement usw.) bzw. der GP entwickelt wird, können komplexe GP-Systeme in komplexe SW-Welten aufgefangen werden. Warum? Die hinzu kommende Komplexität der SW-Welten ist einersteits ein Teil der Lösung und andrerseits selbst ein Teil des Komplexitätsproblems. SOA ist Risiko und Chance.
Eine SOA-Verdrehung wird Risiken mit Schadensfolgen steigen und Chancen mit Nutzenfolgen sinken lassen. SOA-Risikomanagement führt zur Ausgangssicht der GP und zur Servicesicht der IT-Welten.
Eine Aussage, zwei Gegensätze – und in der Kombination das perfekte Gespann! Das trifft für viele zu: die Welt als globales Dorf, think big, start small und eben auch Bottom-up vs. Top-down.
Für beide Ansätze gibt es erfolgreiche Beispiele. Die Herausforderungen sind zum Teil unterschiedlich. Diejenigen, die von der Technologie kommen, müssen das Management überzeugen, Budget für das Projekt zur Verfügung zu stellen. Sie müssen auch sicherstellen, dass einerseits das Projekt erfolgreich verläuft, andererseits die Architektur zu der grundlegenden Strategie des Unternehmens passt. Das ist besonders unter Zeitdruck nicht immer einfach.
Wenn das Top-Management eine Entscheidung trifft, muss es die Ziele glasklar vorgeben und so schnell wie möglich „hearts and minds“ derjenigen gewinnen, die das umsetzen sollen. Ansonsten können Initiativen scheitern oder werden nur halbherzig umgesetzt.
Eine gemeinsame Herausforderung haben beide Wege aber immer: an der Schnittstelle zwischen Fachabteilung und IT, dort wo Bottom-up und Top-down zusammentreffen, muss die Kommunikation gelingen. Einfache Governance-Regeln und ein Governance Board, das sich aus Vertretern des Managements, der Anwender, der Fachabteilungen und der IT zusammensetzt, ermöglichen diese Kommunikation. Dann ist es egal, ob ich von unten oder von oben komme – die Kommunikationskette funktioniert in beide Wege.
SOA Governance Konzepte müssen allerdings vom Management getragen werden. Egal wie eine Organisation die Best Practices und die Infrastruktur für Governance entwickelt – ob Bottom-up oder Top-down: letzten Endes muss es eine Management Entscheidung sein, diesen Grundsätzen zu folgen. Das ist aber auch schon die einzige exklusive Top-Down Entscheidung!
Die Diskussion erinnert mich an die Anfänge von Dataware-Houses; auch dort wurde und wird wohl auch heute noch der beste Ansatz diskutiert: Top-Down (Planung des gesamten DWH) oder Bottom-Up (Start mit DataMarts).
Aber sowohl bei DWHs als auch bei SOA gilt wohl: Ohne eine Zielplanung wird aus Einzelteilen kein abgestimmtes Ganzes, wer aber versucht sofort in einem Schritt alles zu realisieren wird ebenso Schiffbruch erleiden.
Allerdings ist diese Diskussion entweder Top-Down (beginnen mit der Zieldefinition und einer Gesamtplanung) oder Bottom-Up (erst einmal klein anfangen und dabei auf bekanntem aufsetzen) meiner über 10jährigen Erfahrungen in der IT nach schon viel älter; bereits bei den ersten Integratinsansätzen durch Schnittstellen wurde über Top-Down (Start mit Zielplanung über alle zu verbindenden Systeme) oder Bottom-Up (ersteinmal mit einer Verbindung anfangen) diskutiert. Meiner Erfahrung nach waren dabei die reinen Ansätze meist wenig zielführend: Top-Down führte zu umfangreichen Planungen und dann zu komplexen Großprojekten, die häufig ohne Abschluß ausliefen, Bottom-Up zu weitern unkoordinierten Inseln, die nie ein Ganzes ergaben.
Nachdem ich die bisherigen Beiträge gelesen habe, ist es bei SOA wieder dasselbe. Daher kann ich mich nur Herrn Dr Kürpick anschließen: Think big, start small oder auch nicht entweder Top-Down oder Bottom-Up sondern sowohl … als auch.
Die Einführung einer SOA wird meist mittels zweier Strategien realisiert. Der Top-Down-Approach über die Formulierung der IT-Architektur als konsequente Umsetzung der Strategie eines Unternehmens oder die schrittweise Einführung. Die Top-Down-Strategie hat den Vorteil, dass die gesamte IT-Architektur auf die Bedürfnisse der Geschäftsprozesse abgestimmt werden kann. Die schrittweise Einführung ist jedoch näher an der Realität der bereits bestehenden IT-Systeme und bietet so die Möglichkeit, einmal getätigte Investitionen zu schützen. Die schrittweise Einführung wird von den meisten Unternehmen bevorzugt, da in diesem Fall die Ergebnisse besser kontrolliert werden können.
Der Top-Down-Approach zur Einführung einer SOA legt die IT-Architektur als Konsequenz aus der IT-Strategie, die wiederum aus der Geschäftsstrategie einer Organisation abgeleitet ist, fest. Die Geschäftsstrategie wird durch eine Prozess-Architektur, also durch die Festlegung der Art und Weise, wie eine Strategie „operationalisiert“ wird, umgesetzt. Die Prozess-Architektur hat direkten Einfluss auf die Strukturierung einer Ablauforganisation eines Unternehmens. Die IT-Strategie wird aus der Geschäftsstrategie abgeleitet; sie legt fest, mit welchen strategischen Mitteln der In¬formationstechnologie eine definierte Geschäftsstrategie umgesetzt werden soll. Typische Elemente einer IT-Strategie sind die technologische Plattform (Hardware, Betriebssysteme, Standardprodukte), die Sourcingstrategie (Verteilung von internem und externem Know-how), Innovationsstrategie und die Festlegung der Regeln zur Freigabe von Investitionen. Die IT-Architektur wird aus der IT-Strategie abgeleitet und definiert den Geltungsbereich, die Ziele, Standards, Richtlinien, Architekturbausteine, die Migrationsstrategie und das Architekturmanagement (Governance). SOA spielt in diesem Rahmen die Rolle des Verbindungsglieds zwischen der Architektur der Geschäftsprozesse und der IT-Architektur. Was bedeutet, dass die Geschäftsprozesse 1:1 als Prozesse auf dem Orchestration Layer abgebildet werden. Die Services sind dann die einzelnen Prozess-Schritte. Der Vorteil dieser Strategie ist die kohärente Umsetzung und der maximale Skaleneffekt durch SOA für ein Unternehmen. Der Nachteil ist die sehr investitionsintensive Umsetzung dieser Strategie durch den Neubau sämtlicher Services und die konsequente Modellierung aller Geschäftsprozesse.
Schrittweise Einführung
Die Strategie der schrittweisen Einführung von SOA berücksichtigt die betriebliche Realität einer bestehenden Systemlandschaft. Eine bestehende IT-Landschaft wird Schritt für Schritt in Richtung SOA weiterentwickelt. Kernpunkt dieser Strategie ist die Bereitstellung von attraktiven Diensten, deren Nutzung jedem neuen System große Vorteile bringt. Die Architektur wird bewusst als logisches Modell kommuniziert, und es werden möglichst wenig konkrete Restriktionen bezüglich der Anwendung formuliert. Das logische Modell wird erst in einem zweiten Schritt verbindlich umgesetzt.
Eine Checkliste für die schrittweise Einführung:
Schritt
Inhalt
Bemerkung
1
SOA Know-how
Ein Unternehmen erwirbt das notwendige Wissen zum Thema SOA
2
Eigenes SOA-Modell
Eine herstellerunabhängige SOA für das Unternehmen wird als logisches Modell entwickelt; die eigenen Ziele werden formuliert.
3
Basisdienste definieren
Wenige potenzielle Basisdienste werden isoliert und dokumentiert.
4
Einführungsprojekt auswählen
Es wird ein geschäftskritisches Projekt ausgewählt, um die Architektur umzusetzen. Ein Prototyping einer kleineren Applikation kann im Vorfeld sinnvoll sein, liefert jedoch keine signifikanten Ergebnisse.
5
Prozesse modellieren
Der vom Einführungsprojekt unterstützte Geschäftsprozess wird modelliert.
6
Dienste realisieren
Die für das Einführungsprojekt benötigten Dienste werden realisiert und mit den potenziellen Basisdiensten abgeglichen.
7
Anwendung bereitstellen
Das Einführungsprojekt wird in Betrieb genommen.
8
Zielabgleich
Nach einer längeren Betriebsdauer werden die in Schritt 3 formulierten Ziele mit den Ergebnissen abgeglichen.
9
SOA-Regeln
Formulierung der SOA-Regeln und der verbindlichen Architektur
10
Ausbreitung
Das Einführungsprojekt wird kommuniziert, und die SOA wird in weiteren Projekten umgesetzt.
Hallo,
Top Down oder Bottom up? Die Diskussion ist so alt, wie die einigermaßen industriemäßige Entwicklung von Software und vor allem auch die Einführung von Standardsoftware. Viel wichtiger, als zwingend einem der beiden Ansätze folgen zu wollen ist der Business Case. Wenn es einen vernünftigen betriebswirtschaftlichen Grund gibt, SOA zu machen dann ab dafür. Dass man gleich eine alles übergreifende Plattform schaffen will, die alle künftigen Eventualitäten berücksichtigt, ist ja ein hehres Ziel, aber mehr als eine Utopie. Die Semantik bekommt man eh nie (zugegeben sehr fatalistisch) in den Griff. Zudem fehlt auch eine Dekade nach dem Beginn der Diskussion über Geschäftprozesse deren Umsetung in den Betrieben. Auch wird für meinem Geschmack bei SOA viel zu sehr auf den Auswirkungen für die Geschäftsprozesse herumgeritten. SOA ist eine Super-Idee, die IT schlagkräftiger und wirtschaftlicher zu machen. Mit gleichem Aufwand mehr und schneller entwickeln, um die Bedürfnisse des Business zu erfüllen – darum geht es. SOA ist eine Pflichtveranstaltung der IT, um die Kosten in den Griff zu bekommen.
Viel Spaß dabei!
Gruß
Bernd Seidel
Die Frage, ob Software besser top-down entwickelt wird oder bottom-up, wird nicht erst gestellt seit SOAs in Mode gekommen sind. Während hinter fachlich getriebenen top-down Ansätzen eine strategische Ausrichtung steht, hat der technikgetriebene bottom-up Ansatz den Charme einer großen Effizienz und sauberen technischen Entwicklung. Was ist nun besser für SOAs?
Hierzu müssen wir uns zunächst fragen, wodurch sich eine gute SOA eigentlich auszeichnet. Auf der einen Seite sicherlich zunächst einmal durch ein angemessenes Business IT Alignment, d.h. einer sauberen Ausrichtung der Technologie an den Erfordernissen der Geschäftsvorgänge, was für den top-down Ansatz spricht. Andererseits aber ist die flexible Rekombinierbarkeit des entwickelten Serviceportfolios erklärtes Ziel Service-orientierter Architekturen. Dieser Aspekt spricht wiederum für eine bottom-up Ausrichtung der Entwicklung.
Die Konvergenz beider Ansätze sicherzustellen, und somit einen „meet in the middle“-Ansatz zu komplettieren, ist Aufgabe der Architekten bzw. der SOA Governance. Die Aufgabe, Zusammentreffen beider Welten zu bewerkstelligen, ist keinesfalls trivial – beinhaltet sie doch den Entwurf einer geeigneten Granularität des unterliegenden Serviceportfolios.