Projekte zum Einführen einer Service-orientierten Architektur sind komplex, kosten viel Geld und laufen oft über mehrere Jahre. Nach den teilweise ernüchternden Erfahrungen in der Anfangsphase sind sich Analysten und Berater weitgehend einig: Es sind weniger technische Fallstricke, die SOA-Vorhaben ins Wanken bringen. Das Problem sitzt in den Köpfen der Verantwortlichen.

Die Verantwortlichen versäumen es, den Business-Nutzen der SOA zu erklären

Zu den häufigsten Fehlern von IT-Verantwortlichen gehört es, SOA nur technisch zu betrachten. Sie verbringen viel Zeit mit Architekturfragen, Governance-Mechanismen und dem Bewerten von Herstellern. Dabei vergessen sie, dass SOA am Ende Geschäftsprobleme lösen muss. Wenn die Architektur endlich steht, zeigt sich, dass die Fachabteilungen den Nutzen nicht verstehen und an der reinen Technik kein Interesse haben.

Empfehlung: Stellen Sie fachliche Probleme an den Anfang Ihrer Überlegungen. Die Killerapplikation für SOA ist Business-Process-Management (BPM). Damit lassen sich Geschäftsprozesse optimieren und automatisieren. BPM schafft Transparenz hinsichtlich der operativen Abläufe und erlaubt es Unternehmen, ohne Beteiligung der IT auf Veränderungen zu reagieren. Neben der potenziellen Kostenersparnis bietet BPM eine Reihe weiterer Vorteile. Mit solchen Argumenten können Sie Fachverantwortlichen den geschäftlichen Nutzen einer SOA klarmachen.

Sie unterschätzen die organisatorischen Auswirkungen

Widerstände gegen Veränderungen können Projekte scheitern lassen. Eine SOA bringt besonders weitreichende Umstellungen mit sich, vor allem wenn im Unternehmen noch keine Enterprise Architecture etabliert ist. Die Angst vor dem Unbekannten lässt bei vielen Betroffenen eine ablehnende Haltung aufkommen. Die Mitarbeiter müssen verstehen, warum Anpassungen sowohl für die Organisation als auch für sie persönlich von Vorteil sind. Erschwerend hinzu kommt, dass sich Veränderungen in den diversen Unternehmensteilen und Führungsebenen unterschiedlich auswirken.

Empfehlung: Entwickeln Sie einen Plan für das organisatorische Change-Management. Prüfen Sie, wie externe Spezialisten dem SOA-Team helfen können.

Sie versäumen es, sich Unterstützung aus dem Management zu sichern

Ohne starke Rückendeckung aus dem Management ist es sehr unwahrscheinlich, dass Ihre SOA-Initiative die gesteckten Ziele erreicht. Eine SOA erstreckt sich über eine Vielzahl von Abteilungen und Systemen. Um ein solch umfassendes Vorhaben voranzubringen und Hindernisse aus dem Weg zu räumen, brauchen Sie einen Förderer mit Durchsetzungsvermögen. Doch das alleine reicht nicht. Die Person sollte auch genügend Zeit haben, um für das Projekt zu werben.

Empfehlung: Wenn Ihre SOA eng mit den Geschäftszielen verknüpft ist, sollte der Sponsor ein hochrangiger Manager sein, der letztlich selbst von der Einführung profitiert. Überlassen Sie dem Business-Management die Verantwortung für das Projektportfolio, das die SOA-Roadmap umsetzen soll. In techniklastigen Unternehmen schlüpfen oft der CEO, der CIO oder CTO in die Rolle des SOA-Sponsors.

Sie versuchen, SOA billig einzuführen

Einige Unternehmen wollen eine SOA mit einem sehr knappen Budget aufbauen. Neben Middleware-Komponenten erfordern Service-orientierte Architekturen aber erhebliche Investitionen in Governance-Tools, Schulung, Beratung, Infrastruktur und Sicherheit. Wegen der verteilten und lose gekoppelten Struktur gerät die Steuerung einer SOA im Produktivbetrieb zu einer großen Herausforderung. Wer dabei etwa auf Werkzeuge für das Lifecycle-Management verzichtet, kann im Störungsfall vor einer schier aussichtslosen Fehlersuche stehen. Um Kosten zu senken, sparen sich Firmen auch gerne die hohen Ausgaben für externe Berater. Wenn Ihr Unternehmen nicht gerade mit hochqualifizierten SOA-Spezialisten vollgepackt ist, kann dieses Vorgehen schnell im Desaster enden.

Empfehlung: Entwerfen Sie eine SOA-Roadmap mit einem Projektportfolio und den langfristigen Vorteilen, die das Unternehmen erwarten darf. Wenn Sie den Business Case, sprich den wirtschaftlichen Nutzen der SOA, überzeugend darlegen, werden auch genügend finanzielle Mittel zur Verfügung stehen. Um die Gesamtkosten zu drücken, können Sie auch auf ausgereifte Open-Source-Produkte zurückgreifen.

Sie besitzen nicht die nötigen SOA-Kenntnisse

SOA erfordert viele spezialisierte Positionen und Kenntnisprofile. Dazu gehören etwa SOA-Architekten, Prozessmodellierer, Administratoren und Spezialisten für das Daten-Management. Solche Experten sind nicht billig. Wer versucht, ohne profunde Kenntnisse eine SOA einzuführen, begeht einen schweren Fehler. Von einer SOA-Initiative sind sämtliche IT-Abteilungen betroffen, vom Testing über die Infrastruktur bis hin zum Sicherheitsteam. Deshalb genügt es nicht, einige Entwickler auf Schulungen zu schicken.

Empfehlung: Entwickeln Sie einen umfassenden Schulungs- und Ressourcenplan. Stellen Sie diesen von Anfang an als Teil des Gesamtkonzepts dar und fordern Sie entsprechende Gelder. Je öfter Sie im späteren Projektverlauf zusätzliche Qualifizierungsressourcen beantragen, desto größer werden die Widerstände auf Seiten des Managements sein.

Sie offenbaren ein schwaches Projekt-Management

Auch über den Erfolg einer SOA-Initiative entscheidet letztlich die Fähigkeit des Unternehmens, Projekte zu steuern. Projekt-Manager müssen eine ganze Reihe von Aufgaben meistern: Das große Ganze im Blick haben, Risiken dämpfen, alle Beteiligten auf dem neuesten Stand halten und sicherstellen, dass sie Termine einhalten. Nicht zu unterschätzen ist auch die vielzitierte Anforderungsanalyse, die nicht ausufern darf. Wenn Ihre Organisation schon mit normalen Projekten Probleme hat, wird sie ein SOA-Vorhaben noch vor wesentlich größere Herausforderungen stellen.

Empfehlung: Setzen Sie Ihre besten Projekt-Manager auf die SOA-Initiative an. Oder holen Sie sich ausgewiesene Experten von außen. Wie auch immer Sie sich entscheiden: Der Projekt-Manager sollte Erfahrungen mit gro ßen und weitreichenden Projekten haben und darüber hinaus das nötige technische Wissen mitbringen, um SOA aus konzeptioneller Sicht zu verstehen.

Sie betrachten SOA als Projekt statt als Architektur

Viele Unternehmen hängen der naiven Vorstellung an, das Einführen einer SOA sei nur ein weiteres Projekt auf der Agenda. Tatsächlich aber handelt es sich um eine Software-Architektur, die nur dann die gewünschten Vorteile bringt, wenn ein Unternehmen sich auf die Grundprinzipien einlässt und sicherstellt, dass Services konsistent und im Rahmen einer Strategie und einer Roadmap zur Verfügung gestellt werden. Dazu bedarf es mehrerer spezialisierter Rollen. So sind am Erstellen eines Business-Service unterschiedlichste Experten beteiligt, beispielsweise SOA-Architekten, Entwickler, Daten- und Sicherheitsspezialisten. Ebenso verschieden sind die Anforderungen in den einzelnen Ebenen des SOA-Stacks, wo etwa Oberflächen-Designer, Prozessmodellierer oder Experten für Geschäftsregeln (Business Rules) an denselben Services arbeiten. All das erfordert ein hohes Maß an Zusammenarbeit.

Empfehlung: Die hergebrachte Organisationsstruktur von IT-Abteilungen ist für SOA ungeeignet. Anzuraten ist Unternehmen stattdessen eine Matrix-Organisation und eine räumliche Aufteilung, die mehr direkte Zusammenarbeit zulässt. In einer Art Collaboration Room sollten dabei möglichst auch Mitarbeiter aus Fachabteilungen eingebunden sein. Ein weiterer Tipp aus der Praxis: Reduzieren Sie die Anzahl klassischer Meetings auf das Nötigste und nutzen Sie stattdessen mehr kollaborative Techniken.

Sie unterschätzen die Komplexität einer SOA

Als Konzept ist SOA nicht besonders schwer zu verstehen, doch das Umsetzen in die Praxis ist alles andere als einfach. Für den Endbenutzer bringen SOA und BPM ein einfacheres Arbeiten, weil mehrere Backend-Systeme so integriert werden, dass sie nach außen wie eine einzige zusammengesetzte Anwendung (Composite Application) erscheinen. Hinter den Kulissen aber steigt die Komplexität beim Erstellen und Verwalten der Softwaremodule. Viele Entwickler haben mit den veränderten Anforderungen zu kämpfen. SOA erfordert ein strenges Befolgen von Standards und Best Practices (Governance). Unternehmen brauchen dazu talentierte Mitarbeiter, die all das in die Tat umsetzen können. Ein anderes Problem in SOA-Projekten ist häufig, dass Sicherheitsaspekte zu spät berücksichtigt werden. Steht die Architektur erst einmal, lassen sich solche Anforderungen nur noch mit hohem Aufwand erfüllen.

Empfehlung: Ganz gleichgültig, wie konservativ Sie sind: Rechnen Sie mit etlichen technischen Hürden auf dem Weg zur SOA. Kalkulieren Sie beispielsweise Integrationsprobleme ein, die sowohl durch Ihre eigene Software als auch durch zugekaufte Tools entstehen können. Die einschlägigen Produkte der Softwarehersteller sind noch längst nicht ausgereift. Schüren Sie keine allzu großen Erwartungen, beginnen Sie mit kleinen Projekten und belegen Sie den konkreten Nutzen der SOA so oft wie möglich.

Sie vernachlässigen die SOA-Governance

Die potenziellen Vorteile einer SOA heißen Wiederverwendung, Flexibilität und Agilität. Um sie zu ernten, muss das zuständige Team Richtlinien für die Architektur befolgen. Dafür steht der Begriff Design-time Governance. Ohne diese Art der Governance kann schnell eine unkontrollierte Sammlung von Web-Services entstehen (JBOWS = Just a Bunch of Web-Services). Der erhoffte Return on Investment (RoI) bleibt in solchen Fällen aus, weil das Rad jedes Mal neu erfunden wird. Mit verbindlichen Vorgaben aber stellen sich allmählich Kostenvorteile ein: Unternehmen können in der Softwareentwicklung immer häufiger auf bereits bestehende Services zurückgreifen und diese wiederverwenden.

Hinzukommen muss ein zweiter Aspekt, der unter dem Namen Run-time-Governance gehandelt wird. Dabei geht es darum, den Produktivbetrieb der SOA sicherzustellen. Run-time-Governance erlaubt es den Verantwortlichen nachzuvollziehen, welche Services konsumiert werden. Unternehmen können auf diese Weise Policies und SLAs durchsetzen und Fehler beheben. Derartige Strukturen lassen sich indes nicht über Nacht einziehen. SOA-Governance ist eine langfristig angelegte Aufgabe.

Empfehlung: Behandeln Sie Governance als eine eigenständig finanzierte Initiative, die parallel zur SOA-Einführung läuft. Dazu sollte ein dediziertes Team bereitstehen, mit einer eigenen Roadmap und einem eigenen langfristigen Ziel. Um eine wirklich ausgereifte Governance zu etablieren, brauchen Unternehmen mehrere Jahre. Investieren Sie in eine Registry, ein Repository und in Service-Management-Werkzeuge.

Sie lassen Hersteller die Architektur bestimmen

Das Analystenhaus Zapthink prägte den Begriff der Vendor-Driven Architecture (VDA). Er deutet die darin liegende Gefahr schon an: Wer sich beim Aufbau einer SOA zu sehr auf Hersteller verlässt, bezahlt dafür teuer. Softwareanbieter haben ein natürliches Interesse, so viele Produkte wie möglich zu verkaufen. Ihr Ziel hingegen ist es, eine SOA einzuführen und Ihrem Unternehmen damit möglichst viel Nutzen zu niedrigen Kosten zu verschaffen.

Zudem versprechen Softwarehersteller stets eine problemlose Integration, wenn Sie nur alle Tools ihres Software-Stacks erwerben. In Wirklichkeit aber haben sie so viele Produkte von anderen Anbietern zugekauft, dass die so entstandenen Stacks keineswegs besser integriert sind, als wenn Sie sie von verschiedenen Anbietern beziehen würden.

Empfehlung: Überlegen Sie sich genau, was Sie brauchen, bevor Sie mit Softwareherstellern sprechen. Organisieren Sie einen gründlichen Auswahlprozess. Wenn Sie sich auf einige wenige Anbieter festgelegt haben, lassen Sie diese ein Proof of Concept in Ihrem Haus und nach Ihren Vorgaben präsentieren. Überzeugen Sie sich mit eigenen Augen, wie die Hersteller die Aufgabe angehen. Last, but not least machen Sie Ihre Hausaufgaben: Lesen Sie Blogs von Praktikern, sprechen Sie mit Beratern, die die Tools einsetzen, und kontaktieren Sie andere Unternehmen, die eine SOA eingeführt haben.