Immer wieder kommt es vor, dass ein Entwicklungsvorhaben in Schieflage kommt und die Gründe analysiert werden, was alles schief gelaufen ist. Häufig ist einer der Gründe, dass der vorhandene Code “gewachsen” oder besser “gewuchert” und kein Architekturansatz erkennbar ist.
Aus diesem Grund dauern selbst die kleinsten Änderungen halbe Ewigkeiten.
Den Entwicklern ist dabei gar kein Vorwurf zu machen, denn oft fehlen schlicht die Vorgaben oder die Rolle des Architekten, der den Blick auf das Gesamtgewerk behält.
Häufig wird ein IT-Architekt erst ins Projekt geholt wenn die Situation schon völlig verfahren ist. Durch mühevolles Reverseengineering muss dieser sich ein Bild der vorhandenen Funktionalitäten machen. Doch eigentlich ist es zu diesem Zeitpunkt schon viel zu spät.
Zu Beginn eines neuen Projekts sollte ein Business Objekt Modell erstellt werden um die Zusammenhänge und damit den Objektgraph zu visualisieren. Mit dieser Diskussionsgrundlage ist es viel einfacher über Use-Cases oder Prozesse zu diskutieren. Zudem fallen Probleme in der Architektur sehr viel früher auf und können schon in viel früherem Stadium ausgemerzt werden. Schon alleine das Beschäftigen mit den benötigten Objekten hilft dem Architekten, die Probleme, die der Entwickler später bei der Implementierung haben wird zu verstehen und sich spezifische Lösungen zu überlegen.
Ein Beispiel: In einem Abrechnungssystem gibt es das Objekt Invoice. Diese Objekt hat die Properties SumNet, Handling und SumTotal. Der Entwickler wird nun fragen: Und wo ist die Mehrwertssteuer? Normalerweise würde der Entwickler nun SumTotal von SumNet abziehen um den Wert zu bekommen. Dies wird er an zig Stellen machen – überall dort, wo er die Mehrwertssteuer benötigt.
Erkennt der Architekt dies bereits in der Designphase, wird er die fehlende Property ins Modell aufnehmen und der Fall ist erledigt. Natürlich ist dieses Beispiel banal und wird so in der Praxis nicht vorkommen aber es verdeutlicht doch die Problematik. Mit steigendem Komplexitätsgrad steigen auch solche Fehler.
Nun stellen Sie sich vor zwei Entwickler arbeiten parallel und kodieren beide eine Mehrwertsteuer-Property. Das Problem ist nur, dass der Eine nach unten rundet und der Andere nach oben. Und schon haben wir den Schlamassel, denn die Rechnung wird in sich nicht mehr konsistent sein. Solche Fehler zu finden ist zeitaufwändig und teuer.
Aus diesem Grund sollte zur Designzeit sehr viel mehr Zeit in die Architektur und das Business Objekt Modell investiert werden. Mit solch einem Modell als Basis und Prozessketten und Sequenzdiagramme die darauf aufsetzen lassen sich transparente Vorgaben beschreiben und der Entwickler muss sich nichts aus den Fingern saugen.
Sobald das Modell steht beschäftigt sich der Architekt mit den Implementierungsvorgaben:
- Wo wird Lazy-Loading verwendet?
- Welche Methoden sind synchron und welche asynchron?
- Wo muss skaliert werden?
- Wo ist High-Availability notwendig?
- Welche Teile des Modells müssen serialisierbar sein?
- Was haben bestimmte Objekte für einen Lebenszyklus?
- Welche Patterns sollen zum Einsatz kommen
- Welche Codingguidelines sollen zur Anwendung kommen?
All diese Fragen sollten bereits im Vorfeld der Entwicklung beantwortet sein. Erst dann macht es Sinn gute Entwickler an die Umsetzung des Modells zu setzen. Die Entwickler werden sich in diesem Fall effektiv der Businesslogik widmen können ohne sich mit Randproblemen wie “wo bekomme ich diesen Wert her?” herumschlagen zu müssen.
Mit solch einem Vorgehen entsteht wartbarer, homogener Code der effizient entwickelt wurde, testbar und auf die Anforderungen der Zukunft vorbereitet ist. Zudem ist die Einarbeitung neuer Mitarbeiter viel einfacher weil ein verständliches Modell vorhanden ist, welches zu Demonstrationszwecken herangezogen werden kann.
Die Frage die sich mir immer wieder stellt ist: Warum wird diese Erkenntnis in vielen IT-Projekten nicht umgesetzt?
