Service-orientierte Architekturen

Zehn Gründe, warum SOA-Projekte schiefgehen

Wolfgang Herrmann ist Deputy Editorial Director der IDG-Publikationen COMPUTERWOCHE und CIO. Zuvor war er Chefredakteur der Schwesterpublikation TecChannel und stellvertretender Chefredakteur COMPUTERWOCHE. Zu seinen thematischen Schwerpunkten gehören Cloud Computing, Data Center, Virtualisierung und Big Data.
SOA-Initiativen scheitern nur selten an technischen Hürden. Viel häufiger sind menschliches Versagen und kulturelle Probleme. Doch was machen SOA-Verantwortliche falsch?

Projekte zum Einführen einer Service-orientierten Architektur (SOA) 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.

Mehr zum Thema im CW-Experten-Blog SOA meets BPM.

1. 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 (siehe auch: SOA -wie sag ich´s meinem Chef?).

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. Danach kümmern Sie sich um technische Fragen.