Agilität, Wiederverwendung von Softwaremodulen und geringere IT-Kosten gehören zu den potenziellen Vorteilen einer ausgereiften Service-orientierten Architektur. Doch auf dem Weg dorthin müssen Unternehmen erhebliche technische, organisatorische und politische Hürden überwinden. Gartner-Analyst Massimo Pezzini erläutert die typischen Fehler in diesem Prozess und gibt Empfehlungen, wie sie sich vermeiden lassen.

SOA im Überfluss:

Viele Unternehmen setzen SOA-Services mit technischen Funktionen gleich, wie sie etwa in Form von Corba- oder Java-Komponenten gebräuchlich sind. Daraus entsteht nicht selten eine große Menge an Services, die sich kaum mehr mit dem Business-Modell der Kernanwendungen in Einklang bringen lässt. Gekennzeichnet sind solche Umgebungen durch Repositories voller Services, umfangreiche Dokumentationen und eine breite Palette neuer Tools und Middleware. Wesentliche SOA-Ziele wie Agilität, inkrementelle Softwareversionen oder Mehrfachverwendung lassen sich in diesem Szenario nicht erreichen.

Empfehlung: Definieren Sie den Entwurf von SOA-Services als eigenständigen Schritt im Soft-waredesign-Prozess. Orientieren Sie sich beim Zuschneiden von Services an Business-Funktionen statt an technischen Modulen.

Die vergessenen Daten:

Ein Servicemodell zu entwerfen ähnelt dem Design eines Datenmodells. Wer im Service-Designprozess die Daten vergisst, riskiert nicht nur schwache Leistungswerte, sondern auch, dass Services die Integrität der betroffenen Anwendung gefährden.

Empfehlung: Berücksichtigen Sie beim Entwerfen von Services das Designmodell der zugrunde liegenden Datenbank.

SOA den Techies überlassen:

Siedeln Unternehmen SOA-Vorhaben überwiegend in der IT-Organisation an, droht die Gefahr, dass Services vor allem mit Blick auf Leistungsoptimierung und Ausfallsicherheit konzipiert werden. Anforderungen der Fachabteilungen bleiben dabei oft auf der Strecke.

Empfehlung: Begreifen Sie das Design der SOA als gemeinsame Herausforderung für Business und IT. Bringen Sie beide Seiten an einen Tisch.

Kulturelle Hürden übersehen:

Das Wiederverwenden einmal entwickelter Services zählt zu den am häufigsten genannten Vorteilen einer SOA. Doch kulturelle Hindernisse können solche Hoffnungen schnell zunichtemachen. In etlichen IT-Organisationen beobachtet Gartner das "Not-invented-here"-Syndrom: Programmierer oder Architekten weigern sich, Services zu benutzen, die andere Teams entwickelt haben. Oft bevorzugen sie es, komplette Systeme in Eigenregie zu erstellen.

Empfehlung: Belohnen Sie die Mehrfachverwendung von Software. Fördern Sie ein kulturelles und technisches Umfeld, in dem Wiederverwendung als anzustrebendes Charakteristikum exzellenter Softwareentwicklung gesehen wird.

Zu groß in die SOA einsteigen:

Viele Unternehmen neigen dazu, von einer anfänglich skeptischen Haltung gegenüber SOA zum großen strategischen Sprung anzusetzen.

Nach Erfahrung der Gartner-Analysten gilt dies besonders für Organisationen, die von sich annehmen, in Sachen SOA im Rückstand zu sein. Doch eine breit angelegte SOA-Initiative ohne gründliche Vorbereitung und Planung birgt erhebliche Risiken.

Empfehlung: Denken Sie strategisch und handeln Sie taktisch. Entwickeln Sie eine langfristige SOA-Vision, aber setzen Sie die Strategie in kleinen Schritten um. In diesem Prozess lernen Sie dazu und können Umstellungsrisiken eindämmen.

Am falschen Ort beginnen:

Für Projektverantwortliche liegt es nahe, sich beim Einstieg in die SOA an den Benutzern der ersten Services zu orientieren. Wird der Service beispielsweise von einer Endbenutzer-Applikation nachgefragt, erscheint es sinnvoll, einen Dienst zu entwickeln, der die Datenanforderungen der Benutzeroberfläche steuert. Gartner nennt dieses Vorgehen opportunistisch. Der entscheidende Nachteil liegt darin, dass am Ende so viele Services wie Benutzeroberflächen generiert werden. Dies führt zu einer großen Zahl redundanter SOA-Dienste.

Empfehlung: Entwickeln Sie keine Services übereilt aus opportunistischen Motiven. Entwerfen Sie im ersten Schritt ein geschlossenes Set aus grundlegenden Services, das sich später schnell um weitere Funktionen erweitern lässt.

Das eigene SOA-Verständnis zum Maßstab machen:

SOA ist als Architekturstil für verteilte Systeme entstanden. Inzwischen aber interessieren sich auch viele Mitarbeiter außerhalb der Entwickler-Community dafür. In Unternehmen führt dies zu einem sehr unterschiedlichen Verständnis von SOA und den damit verbundenen Erfolgskriterien:

- Für einen Programmierer ist SOA eine Form der verteilten Verarbeitung, in der die nötigen Komponenten von anderen Applikationen bereitgestellt werden können.

- Für einen Softwarearchitekten bedeutet SOA das Verschwinden von Grenzen zwischen Anwendungen.

- Der CIO sieht Service-Orientierung als eine Investition in die Zukunft. Die Wiederverwendung von Programmcode ist für ihn ein Mittel, um Kosten zu reduzieren und Entwicklungszeiten zu verkürzen.

- Der CEO dagegen erhofft sich von einer SOA, dass die IT besser auf Geschäftsanforderungen eingeht. Zudem soll sie das Unternehmen in die Lage versetzen, rasch auf Veränderungen im Markt zu reagieren.

Empfehlung: Bedenken Sie, dass die Erwartungen an eine SOA stark divergieren können. Berücksichtigen Sie diese Unterschiede bei der Erklärung der SOA-Strategie auf den jeweiligen Hierarchieebenen.

Anarchie mit Diktatur bekämpfen:

Einzelne IT-Projekte, Gruppen und Abteilungen streben häufig nach Unabhängigkeit. SOA-Verantwortliche können darin eine Form von Anarchie sehen, die es unmöglich macht, gemeinsame Ziele für die ganze Organisation zu verfolgen. Ein drastisches Mittel, Anarchie zu bekämpfen, sind diktatorische Maßnahmen: Abteilungen und Projektgruppen werden gezwungen, sich anzentrale Vorgaben zu halten. Beide Extreme eignen sich nicht dazu, eine SOA erfolgreich aufzubauen.

Empfehlung: Gründen Sie ein SOA Centre of Excellence (COE), um einzelne Projekte zu koordinieren. Stellen Sie sicher, dass verpflichtende Vorgaben den Handlungsspielraum der beteiligten Gruppen so wenig wie möglich einschränken.

Technische Probleme unterschätzen:

SOA-Verantwortliche müssen die komplexe Welt der Middleware verstehen. Trotz der wachsenden Popularität des SOA-Paradigmas und der Verfügbarkeit zahlreicher Tools ist gerade für Neueinsteiger die Gefahr groß, falsche technische Entscheidungen zu treffen.

Empfehlung: Verwenden Sie Punkt-zu-Punkt-Verbindungen mit Web-Services nur für kleine, experimentelle SOA-Projekte. Steigt die Zahl der installierten Services auf mehr als 20 oder 30, nutzen Sie eine Middleware-basierende Vermittlungsschicht: das SOA Backplane.

Services ohne Wiederverwendung zulassen:

Mehrfach verwendbare Services beschleunigen die Anwendungsentwicklung, senken Programmierkosten und erleichtern die Wartung. Faustregel: Konsumiert eine Anwendung im Durchschnitt deutlich mehr als 20 Services oder werden weniger als zehn Prozent der Services mehrfach verwendet, ist der Grad der Wiederverwendung nicht optimal.

Empfehlung: Etablieren Sie einen formalen Prozess für die Servicedefinition und -validierung. Installieren Sie eine Design-Time-Registry für Services. Schaffen Sie Anreize für die Wiederverwendung. Übertragen Sie Verantwortung für das Identifizieren neuer, mehrfach verwendbarer Services.

Übertriebene Zentralisierung:

Im Zuge von SOA-Projekten neigen Verantwortliche zu mächtigen zentralisierten Strukturen: ein unternehmensweites SOA Backplane, eine zentrale Registry und ein vorgegebenes Set aus Governance-Prozessen und Standards. Daraus können zahlreiche technische, organisatorische und politische Probleme erwachsen.

Empfehlung: Vor allem in großen Unternehmen sollten Sie statt eines zentralen einen föderierten SOA-Ansatz wählen. Dabei wird die SOA-Initiative in Domänen unterteilt wie beispielsweise Tochtergesellschaften, Business Units oder Abteilungen. Jede Domäne wird von einem Fachverantwortlichen und einem technischen Manager geleitet. Sie besitzt jeweils ein eigenes SOA-Backplane, eine Service-Registry und ein SOA Centre of Excellence.

SOA zu früh verkaufen:

Um eine SOA unternehmensweit einzuführen, bedarf es der Unterstützung aus dem Topmanagement. Wer ein solches Vorhaben zu früh von der Führungsriege absegnen lassen will, gefährdet das Projekt. Bis zum Jahr 2010 werden weniger als 25 Prozent der großen Unternehmen die nötigen technischen und organisatorischen Fähigkeiten für derart umfassende Projekte besitzen, warnen die Analysten.

Empfehlung: Vermeiden Sie unternehmensweite SOA-Initiativen, wenn Ihre Organisation sich erst seit kurzem mit dem Thema beschäftigt. Konzentrieren Sie sich auf kleinere Vorhaben, beispielsweise innerhalb einer Business Unit.