Mit beißender Ironie listet Gartner-Analyst Frank Kenney die häufigsten Gründe für gescheiterte SOA-Vorhaben auf. In einem Blog-Eintrag formuliert er einen fiktiven Entschuldigungsbrief, den Projektverantwortlichen nur kopieren und ihrem Management zu senden bräuchten. Mit dem Hintergrundwissen aus zahlreichen groß angelegten SOA-Projekten legt Kenney den Finger in die Wunde:
- “Ich habe es versäumt, unsere SOA-Initiativen mit unseren geschäftlichen Anforderungen in Einklang zu bringen”, steht in dem Brief. “Deshalb kann ich den vielen hundert Services, die wir entwickelt haben, keinerlei Wert zumessen.”
Weitere Kosproben:
Continue reading ‘Die perfekte Entschuldigung für geplatzte SOA-Projekte’
Prozesse, Daten und Funktionen werden in Unternehmen nicht gemeinsam genutzt. Darin liegt ein Kernproblem beim Einführen von Service-orientierten Architekturen. So zumindest sieht es Chris Howard, Vice President beim Marktforschungs- und Beratungshaus Burton Group. Im Interview mit der COMPUTERWOCHE nennt er eine Reihe von Faktoren, die SOA-Projekte behindern: “Eine neue Architektur einzuführen ist harte Arbeit und braucht viel Zeit.” In typischen Projekten könnten drei bis fünf Jahre vergehen, bis eine gewisse Reife erreicht sei. Gleichzeitig sähen sich Unternehmen mit Quartalsberichtspflichten und jährlichen Planungszyklen konfrontiert. Howard: “Das passt nicht zusammen und führt durchaus zu einer gewissen Desillusionierung.”
Continue reading ‘Für SOA fehlt die Kultur des Teilens’
Beim Aufbau einer SOA müssen Unternehmen eine ganze Reihe technischer, organisatorischer und politischer Hürden nehmen. Gartner empfiehlt dabei eine zweigleisige Strategie. Projektplaner sollten einerseits langfristig denken, andererseits aber in kleinen, pragmatischen Schritten vorgehen und sich auf zwei zentrale Ziele konzentrieren: die langfristige Agilität einer Organisation und die kurzfristig angestrebten Kostenvorteile. Entscheidend ist aus Sicht der Analysten, dass Projektverantwortliche einige typische Fehler vermeiden, die SOA-Initiativen immer wieder ins Wanken bringen. Die COMPUTERWOCHE hat die “zwölf SOA-Todsünden” zusammengefasst und beschreibt, wie sie sich vermeiden lassen.
Den Artikel finden Sie hier.
…Sie mit ihren Softwarelieferanten zusammenarbeiten, ihnen aber nicht das Ruder überlassen. Diesen und andere Tipps gibt der US-amerikanische SOA-Experte David Linthicum in seinem Blog. Einige mögen trivial erscheinen: “Wenn Sie nachts ruhig schlafen” etwa, oder: “Wenn Sie Ihr Projekt nicht als ‘Experiment’ bezeichnen.” Andere dagegen verweisen auf klassische Fehler, die auch erfahrenen Projektverantwortlichen unterlaufen. Der Hinweis auf die Zulieferer ist in jedem Fall einen Gedanken wert: Linthicum warnt vor einem Phänomen, das in jüngster Zeit die Runde in einschlägigen Blogs macht: der sogenannten Vendor Driven Architecture (VDA).
Continue reading ‘Ihr SOA-Projekt funktioniert wenn…’
Neben dem Aufbau einer viel zu hohen Erwartungshaltung und einer ungeeigneten Technologieauswahl gehören unzureichende Organisationsstrukturen und Governance zu den Hauptgründen des Scheiterns von SOA-Projekten. Die Spannbreite der Fehlentwicklungen beeinhaltet die folgenden Situationen:
- „Wild West SOA“: Wahllose Verbreitung von Services ohne formelle Rahmenbedingungen
- „Duplicated SOA“: Wildwuchs durch Duplizierung von Services (statt: „Re-Use“)
- „Shelfware SOA“: Keine durchgängige Nutzung von Services
Gartner geht davon aus, dass nur auf der Basis eines kontrollierten Governance, die SOA-Ziele – nämlich u.a. konsequente Wiederverwendung und Vermeidung unnötiger Duplizierung – auch erreicht werden können. Zu den wichtigsten Koordinationsaufgaben der SOA-Governance zählen:
- Definition und Anpassung von Geschäftsprozessen, die durch SOA-Technologien unterstützt werden sollen
- Definition, Entwicklung, Zugriff, Ausführung, Betrieb und Wartung von wiederverwendbaren Services
- Identifikation der benötigten Service-Level und entsprechender Zugriffsrechte
- Festlegung der Service-Ownership und einer angemessenen Kostenverteilung
- Bestimmung von Richtlinien und Verantwortlichkeiten für alle SOA-relevanten Tätigkeiten (siehe obige Punkte)
- Messung des Grades der Wiederverwendung und Compliance sowie die Spezifizierung von Anreizen zur permanenten Verbesserung des Richtlinieneinhaltung.
Diese Aufgaben der SOA-Governance werden in vielen Unternehmen in einem sogenannten SOA Center of Excellence (SOA CoE) zusammengefasst. Vor allem für unternehmensübergreifende und grosse Projekte empfiehlt sich ferner eine Erweiterung des Aufgabenspektrums um die Rollen und Verantwortlichkeiten, welche sowohl zentral als auch dezentral innerhalb eines übergreifenden Integration Competence Centers (ICC) wahrgenommen werden:
Abbildung 1: Rollen und Verantwortlichkeiten eines Integration Competence Centers (ICC)
Eine Zusammenarbeit zwischen Fachabteilungen und IT findet in diesem Zusammenhang vor allem innerhalb der Aktivitätenblöcke „Enterprise Architecture“ und „Business Analysts“ statt. Hier werden koordiniert durch das SOA CoE die Rahmenbedingungen für die zu implementierenden Geschäftsprozesskonzepte gemeinsam festgelegt.