Agilität, Wiederverwendung von Softwaremodulen und geringere IT-Kosten gehören zu den potenziellen Vorteilen einer ausgereiften Service-orientierten Architektur SOA. 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 (siehe auch: Die größten SOA-Hürden).
Mehr zum Thema Service-orientierte Architekturen finden Sie im SOA-Expertenrat der COMPUTERWOCHE.
Fehler 1: 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 Software-Versionen oder Mehrfachverwendung lassen sich in diesem Szenario nicht erreichen.
Empfehlung:
Definieren Sie den Entwurf von SOA-Services als eigenständigen Schritt im Softwaredesign-Prozess. Orientieren Sie sich beim Zuschneiden von Services an Business-Funktionen statt an technischen Modulen (siehe dazu auch: Wie granular müssen SOA-Dienste sein?).
Fehler 2: Die vergessenen Daten
Ein Servicemodell zu entwerfen ähnelt dem Design eines Datenmodells. Wer im Service-Desginprozess die Daten vergisst, riskiert nicht nur schwache Leistungswerte sondern auch, dass Services die Integrität der betroffenen Anwendung gefährden (siehe auch: Stammdaten in der SOA).
Empfehlung:
Berücksichtigen Sie beim Entwerfen von Services das Designmodell der zugrundeliegenden Datenbank.
Fehler 3: 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 (siehe auch: Alignment-Probleme in SOA-Projekten).
Fehler 4: 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 zunichte machen. 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 (siehe auch: SOA-Projekt von Standard Life).
Fehler 5: 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 (siehe dazu: Einstiegspunkte in die SOA).
Fehler 6: 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 entscheide 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:
Vermeiden Sie kurzfristig entwickelte Services 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.
Fehler 7: 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 verbunden 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 Software-Architekten bedeutet SOA das Verschwinden von Grenzen zwischen Anwendungen.
-
Der CIO sieht Service-Orientierung als eine Investition in die Zukunft. Die Wiederverwendung von Programm-Code 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 Kommunikation der SOA-Strategie auf den jeweiligen Hierarchieebenen.
Fehler 8: 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 an zentrale 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 verabschiedete Vorgaben den Handlungsspielraum der beteiligten Gruppen so wenig wie möglich einschränken.
Fehler 9: 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 (siehe dazu: Die Spaghetti-Falle in der SOA).
Fehler 10: 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 (siehe auch: Wie die Post ihre SOA steuert).
Fehler 11: Ü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 (siehe dazu: So lässt sich SOA-Governance planen).
Fehler 12: 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. (Computerwoche/rw)