Zerfallende Architekturen

Erster Akt: Festlegung der Architektur

In der Theorie würde man bei einem neuen Softwareprojekt zuerst einmal hingehen und die fachlichen Anforderungen sammeln. In einem nächsten Schritt würde man sich hinsetzen und die technischen Alternativen zur Umsetzung dieser Anforderungen bewerten und die geeigneste auswählen und damit die Umsetzung beginnen. Soweit die Theorie.

In der Wirklichkeit ist die zu verwendende Technik schon häufig von Beginn an festgelegt. Vielleicht hat der Kunde eine Vorgabe gemacht oder das eigene Team hat sich spezialisiert oder ein Techniker ist bei der Angebotserstellung zwischen Tür und Angel gefragt worden, was im so spontan einfallen würde.

Zweiter Akt: Beginn der Umsetzung

Wir habe eine fachliche Beschreibung, z.B. in Form eines Satzes von Anwendungsfällen (Use Cases) und wir haben eine technische Architektur. Das müßte doch reichen, mit der Umsetzung zu beginnen. Also bekommt jeder Entwickler die technische Architektur vorgesetzt und einen Anwendungsfall zur Umsetzung, jeder einen anderen.
Mit der Zeit kommen bei der Entwicklung Fragen an die Architektur auf, die in dem bisherigen Bild noch nicht enthalten waren. Also wird da ergänzt. Inkrementelle Arbeitsweise ist doch seit Jahren angesagt und nicht nur ich sage immer wieder, daß das die einzige Art ist, die realistisch ist.

Dritter Akt: Erste Risse

Irgendwann kommt dann das unvermeidliche. Jemand fordert eine Änderung an der Architektur an, jemand anderes stellt fest, daß diese Änderung entscheidende Voraussetzung seiner Implementierung untergräbt.

Dann kommen immer häufiger Argumente gegen diskutierte Änderungswünsche, die da etwa so lauten: "Wir können das nicht machen. Wir wissen nicht ob das jemand so braucht, wie es jetzt ist."

Vierter Akt: Verzweiflungstaten

Irgendwann kommt der Punkt, an dem die Rücksichtsmaßnahmen auf bestehende Arbeit als nicht mehr praktikabel angesehen wird. Dann wird ohne Rücksicht auf Verluste aufgeräumt. Das ist eine Krise, die entweder zum baldigen Ableben des Projekts führt oder aber heilsam sein kann. Teuer ist sie in jedem Fall.

Was hier fehlte

Um Zeit, Geld und Nerven zu sparen, ist ein entscheidender Schritt vor Beginn der Umsetzung notwendig. Die fachlichen Anforderungen müssen auf die Architektur abgebildet werden. Es muß genau klar sein, welche Bedürfnisse jede fachliche Anforderung an die Architektur hat.

Es sollten dann Komponenten entstehen, die konkrete Verantwortlichkeiten haben. Die Entwickler werden sich dann eher an den Verantwortlichkeiten der Komponenten orientieren als an den ursprünglichen fachlichen Anforderungen. Diese treten dann wieder bei der Integration des Gesamtsystems zutage.
Ein Vorteil hier ist, daß frühzeitig ähnliche technische Anforderungen von unterschiedlichen Anwendungsfällen identifiziert werden können. Doppelarbeit kann so vermieden werden und noch wichtiger nicht kompatible Lösungsansätze.

Desweiteren sollte ein Bild der Gesamtarchitektur existieren, etwa in der Größe einer Wandtafel. Dieses Bild sollte so aufgehängt werden, daß jeder Entwickler es immer sehen kann. Anhand dieses Bildes kann man dann den Ablauf der Implementierung eines Anwendungsfalls durchspielen und so Probleme und Lösungsmöglichkeiten erkennen.