Die 10 größten SOA-Fallstricke: #Nr. 5 - Großes Design im Vorfeld

Letzte Woche haben wir über Nr. 6 gesprochen - das bedeutet, dass wir die Hälfte des SOA Pitfall Countdowns hinter uns haben! Lassen Sie uns schnell zu #5 übergehen. Wie das Not Invented Here-Syndrom, das wir bereits besprochen haben, ist auch Big Design Up Front (BDUF) etwas, das nicht nur im Bereich der SOA zu beobachten ist. Doch während das NIH-Syndrom allgemein als etwas Schlechtes angesehen wird, sind die Dinge bei BDUF nicht so einfach.

Der Begriff BDUF bezieht sich auf die Praxis, sicherzustellen, dass ein Entwurf vollständig ist, bevor eine Implementierung durchgeführt wird. BUDF wird traditionell mit dem Wasserfallmodell der Softwareentwicklung in Verbindung gebracht. Der Vorteil dieser Praxis wäre, dass die meisten Probleme in der Anforderungs- oder Designphase entdeckt und gelöst werden können, wo sie leichter zu lösen sind. Befürworter der agilen Softwareentwicklung argumentieren jedoch, dass sich die IT-Anforderungen im Laufe des Entwicklungszyklus zwangsläufig ändern werden, so dass BDUF (oder Big Modeling Up Front) die Anpassung an den Wandel nur erschwert. Dies ist nur eine kurze Zusammenfassung aller Themen rund um BDUF. Weitere Argumente dafür und dagegen finden Sie, wenn Sie den Links im vorherigen Absatz folgen. Lassen Sie uns näher darauf eingehen, was dies für eine SOA bedeutet. Zunächst das Offensichtliche: SOA-Projekte sind in der Regel große Projekte. Einer der Gründe dafür ist, dass Unternehmen hoffen, dass SOA der Königsweg ist, der all ihre Komplexitätsprobleme löst (wie im vorigen Beitrag beschrieben), und dass sie deshalb nicht nur ein SOA-Projekt, sondern ein SOA-Programm starten. Dieses SOA-Programm wird aus vielen Projekten bestehen (kommt Ihnen das bekannt vor? ;-) ), von denen jedes die Aufgabe hat, ein bestimmtes Teilproblem zu lösen, z.B. "Geschäftsanforderungen", "Prozessdesign", "organisatorische Implementierung", "technische Architektur", "Entwicklung" usw. Und hier liegt der Knackpunkt: Die Teams, die die Aufgabe haben, die Geschäftsanforderungen, das Prozessdesign und die technische Architektur zu erstellen, werden genau das tun. Sie konzentrieren sich darauf, die Anforderungen, das Design und die Architektur genau richtig hinzubekommen, während das Entwicklungsteam gerade erst anfängt. Diese Teams werden nicht dadurch behindert, dass sie das, was sie sich ausgedacht haben, auch tatsächlich umsetzen müssen, sondern sie fügen ihren Entwürfen einfach immer mehr hinzu, während das Entwicklungsteam nur schwer aufholen kann. Wenn sie den Rückstand aufholen, können diese Teams sogar fertig sein und sich auflösen! Wir haben das schon erlebt, wenn niemand das große Ganze im Auge behält :-( Abgesehen von all den offensichtlichen Nachteilen von BDUF (große Dokumente, die sich kaum an Änderungen anpassen lassen), hat BDUF in einer SOA noch einen weiteren spezifischen Effekt. Er neigt zu einem Top-Down-Designstil, der zu Diensten von falscher Granularität führen kann. Eines der Szenarien, die dazu führen können, ist, dass sich die Prozessdesigner zuerst auf den übergeordneten (unternehmensweiten) Prozess konzentrieren, dann zu den Prozessen auf Abteilungsebene übergehen und schließlich zu den Diensten am unteren Ende der Hierarchie gelangen (siehe Abbildung rechts). Das Ergebnis ist, dass Sie am Ende einen Dienst A1 mit einer Signatur wie Address getCustomerAddress(String customerName) und einen Dienst C3 mit einer Signatur wie String getCustomerStreet(int customerId) haben können. Sie wurden getrennt entwickelt und spezifiziert und es wird einige Mühe kosten, diese ähnlichen Dienste zu entdecken und durch etwas zu ersetzen, das besser wiederverwendbar ist. Eine Möglichkeit, dies zu verhindern, besteht darin, eine Service-Registrierung zu führen, mit deren Hilfe die benötigten Dienste gefunden werden können. Dabei muss es sich nicht um ein UDDI-Verzeichnis handeln, sondern nur um etwas, das die Implementierer nutzen können. Abschließend schlagen wir vor, SOA auf agile Art und Weise einzuführen, anstatt den üblichen "Big Bang"-Ansatz zu verfolgen. Agile und SOA sind eine Methodik bzw. ein Architekturstil, die eingeführt wurden, um die Reaktionsfähigkeit von Organisationen auf Veränderungen zu verbessern. Seltsamerweise neigt SOA jedoch dazu, einige dezidiert nicht-agile Praktiken wie BDUF und "funktionale" Teams zu fördern. Agile und SOA können Freunde sein, aber wenn sie falsch gemacht werden, sind sie Feinde. Es würde den Rahmen dieses Blogbeitrags sprengen, näher darauf einzugehen. Wir werden daher zu einem späteren Zeitpunkt auf Agile & SOA zurückkommen! Nächste Woche wird Gero Vermaas mit Fallstrick #4 fortfahren.