Top-down oder Bottom-up? Die Frage ist fast so alt wie die IT selbst. Und doch gewinnt sie im Zusammenhang mit SOA eine neue Bedeutung. Service-orientierte Konzepte sollen Anwendungsstrukturen aufbrechen, flexible Geschäftsprozesse ermöglichen und die Unternehmen agiler im Wettbewerb machen. Auf den ersten Blick scheint die Antwort deshalb klar: Nur eine vom Topmanagement getriebene Initiative hat das Zeug dazu, derart ambitionierte Ziele zu erreichen.

Die Realität sieht oft anders aus. Nicht wenige Unternehmen gehen SOA-Vorhaben gerade nicht über einen Top-down-Ansatz an. Sie beginnen mit Projekten zur Legacy-Modernisierung, kapseln Mainframe-Anwendungsfunktionen als Services und achten auf eine schnelle Rentabilität. Erst nach bewiesenem Nutzen weiten sie Service-orientierte Konzepte auf andere Unternehmensbereiche aus. Für diese Klientel steht der Investitionsschutz ihrer geschäftskritischen Altanwendungen an erster Stelle. Eine komplette Neuenwicklung nach der reinen SOA-Lehre ist für sie weder finanzierbar noch organisatorisch zu bewältigen. Vor diesem Hintergrund kann es kein Patentrezept auf dem Weg zur Service-Orientierung geben, darin waren sich die Mitglieder des SOA-Expertenrats einig. Dennoch sprechen gewichtige Gründe jeweils für den einen oder den anderen Ansatz.

Plädoyers für Top-down

"Bei SOA handelt es sich ganz klar um eine strategische Ausrichtung des Unternehmens", argumentiert Karin Sondermann, Platform Business Development Manager bei Microsoft Deutschland. Betroffen davon seien wesentliche Teile der IT. Folglich bedürften SOA-Einführungsprojekte der intensiven Beteiligung und Zustimmung des Managements. Die Expertin betrachtet Service-Orientierung als einen evolutionären Prozess, der sich über einen längeren Zeitraum erstrecke, begleitet von einer nachhaltigen Anpassung der IT-Architektur. Eine Kosten-Nutzen-Analyse könne sich deshalb nicht auf ein einzelnes oder kurzfristiges Projekt beschränken: "Der Nutzen einer SOA steigt erst mit dem Durchdringungsgrad im Unternehmen."

Architektur zuerst

Beim Konkurrenten IBM sieht man die Sache ähnlich: "Es ist hoffentlich nicht mehr strittig, dass SOA kein reines IT-Thema ist, sondern ein Hilfsmittel, um Unternehmensstrategien umzusetzen", erklärt Executive IT Architect Norbert Schädler. "Strategien entstehen aus einer Vision, und Visionen entstehen äußerst selten Bottom-up." Auch Rüdiger Spies, Analyst bei der Experton Group, stößt in dieses Horn. Er empfiehlt, die Architektur von der Spitze der Unternehmensziele her zu entwickeln. Dabei sollten die Verantwortlichen zunächst eine Unternehmensarchitektur gestalten, die den Weg für den Prozess-Bauplan weise. Dieser wiederum führe zu einer Informationsarchitektur, die ihrerseits die technische Komponentenauswahl beeinflusse. Eine Architektur erfordere stets einen Top-down-Ansatz: "Man baut ein Haus ja schließlich auch nicht, indem man erst einmal anfängt zu mauern und dann am Schluss einen Plan zeichnet."

Gartner-Berater Axel Jacobs unterscheidet zwischen einem zentralen, unternehmensübergreifende Rollout-Ansatz (Top-down) und einem dezentralen, mehr opportunitätsgetriebenen Einzelprojektansatz (Bottom-up). In der Praxis beobachte er meist eine taktisch geprägte Vermischung beider Konzepte: "In einem frühen Stadium der SOA-Adaption werden Vorhaben beispielsweise zur Schaffung von Infrastruktur- und Integrationsdiensten zunächst durch Einzelprojekte adressiert, die einen Pilotcharakter besitzen und häufig unter der Schirmherrschaft der zentralen IT-Organisation stehen." Auf Basis der Ergebnisse könnten dann Projektinitiativen folgen, in denen es um die Realisierung von mehr geschäftsprozessorientierten SOA-Implementierungen gehe.

Von solchen Erfahrungen berichtet auch Rolf Schumann, Vertriebsleiter für SAPs Netweaver-Plattform in der Region Emea. Der Trend gehe eindeutig zu kleinen, überschaubaren und entkoppelten Teilprojekten: "Es ist eine Art Inkubationsansatz, bei dem zunehmend mehr Prozesse Service-orientiert implementiert werden, die besondere Flexibilität oder eine zügige Einführung erfordern." Auf diese Weise entwickelten sich immer mehr Prozesse Service-orientiert, bis schließlich eine vollständig neue Plattform entstehe. IBM-Experte Schädler spricht vom "Prinzip Keimzelle", mit dem in der Praxis die besten Erfolge erzielt würden. Er verweist zudem auf einen anderen Aspekt in der Diskussion: Die Frage, ob die richtige Granularität der Services, die eine entscheidende Rolle beim Thema Wiederverwendung spiele, mit einem reinen Top-down-Ansatz gefunden werden kann. "Die Erfahrungen aus zahlreichen objektorientierten Projekten haben gezeigt, dass dies unter praktischen Gesichtspunkten nicht möglich ist." Deshalb gelte auch hier, "dass eine Kombination aus Top-down-Analyse und einem Bottom-up-Lernprozess oder Benchmark-Prozess die zielführende Vorgehensweise ist".

Auf strategischer Ebene sollten die Grundfragen unternehmensweit geklärt und die Eckpfeiler festgelegt sein, rät Schumann. "Darunter fallen auch die notwendigen Governance-Modelle." In der konkreten Umsetzung tendiert auch er zu einem Hybrid-Ansatz. Ganz anders Martin Raab vom IT-Beratungshaus Capgemini: "Wer über eine Senkung der IT-Kosten hinaus signifikante Geschäftsvorteile erzielen will, wird um eine Top-down-Perspektive auf die Servicearchitektur nicht herumkommen." Eine integrierte und modulare IT-Landschaft erleichtere die Prozessautomatisierung, flexibilisiere die Geschäftsmodelle und erlaube einen besseren Überblick über die Performance des Unternehmens.

Bottom-up näher an der Realität

Für Rainer Berbner von der Technischen Universität Darmstadt hängt die geeignete Strategie vom Ziel der SOA-Vorhaben ab: "Geht es vorwiegend um die sukzessive Ablösung von Legacy-Systemen, deren Funktionalität modularisiert und in Form von Services gekapselt angeboten werden soll, so verspricht eine Bottom-up-Vorgehensweise durchaus Erfolg." Ist das Ziel der SOA-Einführung dagegen umfassender, das heißt im Sinne einer "Enterprise SOA" formuliert, sei eine Top-down-Vorgehensweise unumgänglich. Einen ähnlichen Standpunkt vertritt Daniel Liebhart, der beim Schweizer IT-Dienstleister Trivadis die Anwendungsentwicklung leitet: "Die Top-down-Strategie hat den Vorteil, dass die gesamte IT-Architektur auf die Bedürfnisse der Geschäftsprozesse abgestimmt werden kann." Sie ermögliche eine kohärente Umsetzung und einen maximalen Skaleneffekt mittels SOA. "Der Nachteil ist die sehr investitionsintensive Umsetzung dieser Strategie durch den Neubau sämtlicher Services und die konsequente Modellierung aller Geschäftsprozesse." Demgegenüber bewege sich die schrittweise Einführung näher an der Realität der bereits bestehenden IT-Systeme und biete so die Möglichkeit, einmal getätigte Investitionen zu schützen.

Dass sich eine Kombination beider Ansätze in der Praxis bewährt, belegen die Erfahrungen des SOA-Pioniers Deutsche Post. "Auf die richtige Gewichtung kommt es an", betont Alexander Scherdin, Senior Professional Service Design beim Bonner Unternehmen: "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 bestimme 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", erläutert der Serviceexperte.

Das schließe andererseits die Einbindung von Bottom-up-Ansätzen nicht aus - im Gegenteil: Die Entwicklung eines konsistenten Serviceportfolios beispielsweise müsse 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 einen kurzfristigen Geschäftsnutzen zu erzielen." Aus Sicht der IT-Governance hat sich bei der Deutschen Post für dieses Vorgehen der Begriff "Managed Evolution" herausgebildet. Dabei gelte es, strategische Ziele und Quick-Wins miteinander zu verbinden, so Scherdin. In diesem Sinn steuere man die SOA zwar Top-down; in der Realisierung aber würden auch Bottom-up-Ansätze genutzt, soweit dies taktisch sinnvoll sei.

"Für beide Ansätze gibt es erfolgreiche Beispiele", berichtet auch Peter Kürpick, Vorstandsmitglied der Software AG. Eine gemeinsame Herausforderung stelle sich aber in jedem Fall: "An der Schnittstelle zwischen Fachabteilung und IT, dort wo Bottom-up und Top-down zusammentreffen, muss die Kommunikation gelingen." Ermöglicht werde sie durch einfache Steuerungsregeln und ein Governance Board, das sich aus Vertretern des Managements, der Anwender, der Fachabteilungen und der IT zusammensetze.

Wolfgang Beinhauer vom Fraunhofer-Institut Arbeitswirtschaft und Organisation (IAO) hält ein angemessenes Business-IT-Alignment für ein Merkmal einer guten SOA. Er versteht darunter eine "saubere Ausrichtung der Technologie an den Erfordernissen der Geschäftsvorgänge", was für den Top-down Ansatz spreche. Andererseits sei die flexible Rekombinierbarkeit des entwickelten Serviceportfolios erklärtes Ziel Service-orientierter Architekturen. Unter diesem Aspekt erweise sich eine Bottom-up-Ausrichtung der Entwicklung als geeignet: "Die Konvergenz beider Ansätze sicherzustellen und somit einen ,Meet-in-the middle‘-Ansatz zu komplettieren ist Aufgabe der Architekten beziehungsweise der SOA Governance."

Dass die grundsätzliche Problematik alles andere als neu ist, unterstreicht die Essener IT-Beraterin Gerhild Aselmeyer. Sie vergleicht die Diskussion mit den ersten Integrationsansätzen: Schon damals wurde über Top-down (Start mit einer Zielplanung über alle zu verbindenden Systeme) oder Bottom-up (erst einmal mit einer Verbindung anfangen) diskutiert. Nach ihrer Erfahrung brachte keiner der Ansätze den gewünschten Erfolg: "Top-down führte zu umfangreichen Planungen und dann zu komplexen Großprojekten, die häufig ohne Abschluss ausliefen, Bottom-up zu weiteren unkoordinierten Inseln, die nie ein Ganzes ergaben." Ähnliches sei beim Thema SOA zu erwarten. Unterm Strich befürwortet auch Aselmeyer den goldenen Mittelweg nach dem Motto: "Think big, start small."