161526

Was SOA-Projekte erfolgreich macht

16.01.2008 | 12:05 Uhr |

Nur im Kontext einer Enterprise Architecture und eines durchgängigen Business-Process-Management entfalten Service-orientierte Architekturen (SOA) ihr volles Potenzial.

"SOA und Enteprise Architecture müssen verknüpft werden", forderte Ingo Arnold, Enterprise Systems Architect beim Schweizer Pharmakonzern Novartis, auf einer Fachkonferenz in Frankfurt am Main. Die vom amerikanischen Analystenhaus ZapThink organisierte Veranstaltung bot Besuchern eine Reihe von Fallstudien und Best Practices zum Thema SOA . Zu letzteren gehört der Aufbau eines Enterprise Architecture (EA) Council, den Novartis vor eineinhalb Jahren in Angriff genommen hat. In diesem "Board of the boards" sitzen laut Arnold Vertreter aus sämtlichen IT-Abteilungen des weit verzweigten Unternehmens. "Die Enterprise Architecture baut Brücken zwischen der Business-Strategie und der IT-Implementierung", erläuterte der Manager. Er sprach damit zugleich ein Kernproblem beim Aufbau einer Service-orientierten Architektur an: die häufig unzureichende Abstimmung von Geschäfts- und IT-Zielen ( Alignment ).

Novartis hat noch kein SOA-Großprojekt angestoßen. Gemäß dem oft gehörten Rat "Think big, start small" verfolgen die Eidgenossen stattdessen mehrere kleinere Initiativen. Dabei spielt die Verbindung zum strategischen Rahmen der Enterprise Architecture eine entscheidende Rolle. Arnold: "EA-Architekten müssen IT- und Business-Standards kombinieren." Nach seiner Einschätzung haben EA- und SOA-Konzepte vieles gemeinsam. In beiden Fällen handele es sich um Architekturen, die Unternehmen zu mehr Agilität und Flexibilität verhelfen könnten. Dahinter stehe auch die Hoffnung auf eine reduzierte Komplexität. Sowohl EA- als auch SOA-Initiativen erstreckten sich über mehrere Projekte und Funktionen in den Unternehmen und seien vom Ansatz zunächst unabhängig von bestimmten Technologien. Novartis unterhält eine komplexe und heterogene IT-Infrastruktur mit rund 3500 RZ-Servern an 350 Standorten weltweit.

Den Zusammenhang zwischen SOA und EA betonte auch Florian Mösch, Vice President Enterprise Integration & Architecture bei T-Mobile Deutschland. Die immer wieder angemahnte SOA-Governance bilde letztlich nur einen Aspekt eines ganzheitlichen EA-Management, so seine Einschätzung. In der europaweit angelegten SOA-Initiative des Mobilfunkanbieters sind wirksame Governance-Mechanismen unverzichtbar, so Mösch. Das IT-Team orientiert sich dabei an SOA-Policies und –Prinzipien, die wiederum aus der "SOA Mission" abgeleitet sind. Für T-Mobile heißen die damit verbundenen Ziele Konsolidierung, Standardisierung und Backend-Modularisierung.

Als praxistaugliches Instrument für Governance hat sich laut Mösch das "SOA Dashboard" erwiesen. Das Monitoring-System setzt auf dem zentralen Repository von T-Mobile auf und hilft dem Unternehmen dabei, den Fortschritt von Abteilungen und ganzen Standorten in Sachen SOA zu messen. Dazu nutzt die Software eine Reihe von Key Performance Indicators (KPIs), die den Verantwortlichen beispielsweise Daten zur Anzahl der installierten Services oder zum Grad der Wiederverwendung liefern.

Erfolgsentscheidend für Mösch ist zudem das Zusammenspiel der SOA-Initiativen mit einem umfassenden Business-Process-Management (BPM). Zwar ließen sich beide Ansätze auch separat betreiben. Doch nur in der Kombination könnten Unternehmen das volle Potenzial ausschöpfen. BPM biete einen Ansatz, um Geschäftsprozesse topdown zu implementieren. Dieses Vorgehen lasse sich durch SOA-Services gut unterstützen. T-Mobile arbeite mit einer geschlossenen "BPM Tool Chain", die von der Prozessmodellierung über die Entwicklung und Ausführung bis hin zum Business Activity Monitoring mittels KPIs reiche.

Welche Hürden Unternehmen auf dem Weg zu einer Service-orientierten Architektur nehmen müssen, erläuterte ZapThink-Analyst und SOA-Berater Ronald Schmelzer in seinem Vortrag. Neben unklaren betriebswirtschaftlichen Zielen im Zusammenhang mit SOA warnte er einmal mehr vor einer " Vendor Driven Architecture ". Softwarehersteller, die eine SOA beim Kunden entwerfen und aufbauen, starteten stets mit ihrem eigenen Stack. Im Vordergrund ständen dabei nicht SOA-spezifische Überlegungen sondern ganz bestimmte Produkte. Den Vorteil eines "One-stop shopping" für SOA erkauften sich etliche Kunden teuer. Best Practices ließen sich auf diese Weise kaum nutzen.

Zu schaffen mache SOA-Verantwortlichen auch das sogenannte Elfenbeinturm-Problem, so Schmelzer: "Hochqualifizierte Architekten entwerfen Konzepte und SOA-Artifakte, können deren Nutzung aber nicht durchsetzen." Von Seiten der Entwickler stießen die kreativen Köpfe meist auf wenig Gegenliebe. Business-Manager könnten sich mit Architekturen zwar grundsätzlich anfreunden. All zu oft aber verhinderten kurzfristige Erfordernisse die Nutzung von Best Practices.

Ein weiteres Problem sieht der Analyst in der Budgetierung von SOA-Vorhaben, die typischerweise an ein bestimmtes Projekt gebunden sei. Fachabteilungen vergäben in der Regel IT-Budgets, um ihre speziellen Anforderungen abzudecken. Die abteilungsübergreifende Natur einer SOA mache es schwierig, Sponsoren zu finden, die auch für die langfristigen und unternehmensweiten Vorteile einer SOA Geld ausgeben möchten. Einige Unternehmen begegneten diesem Problem mit einem veränderten Modell: Sie bauten unternehmensweit agierende Architekturgruppen mit eigenen Budgets auf, um ihre SOA-Initiativen voranzubringen.

Mehr zum Thema SOA, Enterprise Architecture und BPM finden Sie im SOA-Expertenrat der COMPUTERWOCHE. (wh)

0 Kommentare zu diesem Artikel
161526