© Ekaphon maneechot/Shutterstock.com
Wie man durch einseitige Prioritäten viel Geld verschenkt

Das Problem mit der Architekturqualität


Kosten stehen über Qualität, billig sticht gut. Aber ist die schnelle billige Lösung automatisch die beste Wahl? Projektleiter und Architekten geraten aufgrund ihrer unterschiedlichen Aufgaben und Ziele oft in ein Spannungsfeld: Investitionen sind in der IT meist projektgetrieben, die Systemqualität leidet darunter. Dieser Artikel beschreibt, wie man dieses Spannungsfeld ausbalancieren und so höhere und langfristigere Architekturqualität erreichen kann.

Vielleicht kennen Sie die Situation: Sie sind Architekt in einem Projekt und es steht eine wichtige Architekturentscheidung an. Sie empfehlen eine Lösung, die die benötigten Qualitäten sinnvoll ausbalanciert, aber der Projektleiter interessiert sich nur für die Kosten und wählt die billigste Lösung. Oder Sie sind Projektleiter eines Projekts, das Änderungen an bestehenden Systemen erfordert. Eigentlich scheint die Aufgabe einfach, aber die Entwickler stolpern von einem Problem ins nächste und bekommen die Lösung nicht stabil, während der Releasetermin unerbittlich näher rückt. Oder Sie sind IT-Manager und haben das Gefühl, dass die Kosten für die Pflege Ihrer Systeme spätestens nach der dritten Erweiterung explodieren. Wenn Ihnen eine dieser Situationen bekannt vorkommt, dann sollten Sie weiterlesen.

Die Wurzel des Übels

Letzten Endes haben die hier geschilderten Probleme häufig die gleiche Ursache. Zum besseren Verständnis beginnen wir am besten mit einem kleinen Beispiel: Das Projekt läuft auf Hochtouren, etwa zwei Drittel der geplanten Funktionalität sind bereits umgesetzt, und der Releasetermin ist in sichtbarer Nähe. Noch sieht alles ganz gut aus, aber viel Puffer ist nicht mehr vorhanden. Da stellt sich plötzlich heraus, dass das anstehende Feature aufgrund eines dringenden Change Requests doch anders umgesetzt werden muss als ursprünglich geplant. Was tun?

Der Projektarchitekt überlegt kurz und sagt dann: „Um das halbwegs sauber und verständlich hinzubekommen, müssten wir einen neuen Service implementieren und folgendermaßen einbinden …“ Er skizziert seine Idee am Whiteboard. Der Projektleiter antwortet: „Sieht schön aus. Aber wie viel Aufwand ist das?“ Der Architekt und der Chefentwickler überlegen einen Moment gemeinsam und nennen dem Projektleiter einen Aufwand. Der stöhnt auf: „Dann können wir den Termin vergessen! Geht das nicht auch einfacher?“ Der Architekt schüttelt den Kopf: „Nicht, wenn wir eine halbwegs wartbare Lösung haben wollen.“ Darauf der Projektleiter: „Nichts für ungut, aber ‚wartbar‘ interessiert mich im Augenblick nicht. Wir haben einen Termin zu halten!“. Da meldet sich ein ambitionierter Jungentwickler: „Ich hätte da eine Idee. Wir könnten doch den bestehenden Service hier nehmen, da noch ein Flag einfügen, hier und hier ein paar Verzweigungen ergänzen und das Datenbankfeld hier in dem Fall mit den anderen Daten füllen, um uns die Schemamigration zu sparen. Das könnte ich bis zum Ende der Woche fertig haben.“

Sie ahnen schon, wie die Geschichte ausgeht? Richtig: Natürlich greift der Projektleiter die Idee des Jungentwicklers auf, und es wird so umgesetzt. Die Warnung des Architekten, dass die Lösung unter Wartbarkeitsaspekten eine Katastrophe sei, die zukünftige fachliche Änderungen extrem schwer bis unmöglich machen würde, wischt der Projektleiter mit Hinweis auf den Termin und die eh schon angespannte Budgetsituation beiseite. Frustriert nehmen Architekt und Chefentwickler hin, dass „billig“ mal wieder „gut“ gestochen hat, und das Projekt nimmt weiter seinen gewohnten Gang. Es gibt noch ein paar Probleme mit der Änderung, aber der Jungentwickler bekommt diese recht fix in den Griff und der Livegang klappt termingerecht. Abblenden. Ende.

Also hatte der Projektleiter recht, als er sich für die schnelle und billige Lösung entschieden hat, oder?

Unterschiedliche Aufgabenstellungen

Bevor ich auf diese Frage zurückkomme, möchte ich kurz auf die Ursachen für diesen Konflikt eingehen. Dafür müssen wir die Aufgaben eines Projektleiters und eines Architekten etwas genauer betrachten. Beginnen wir mit den Aufgaben eines Projektleiters:

Der Projektleiter hat die Aufgabe, ein Projekt erfolgreich abzuwickeln. „Erfolgreich“ wird dabei in den Dimensionen des magischen Dreiecks für Projektleiter (Abb. 1) gemessen: Zeit, Budget, Scope und Qualität. Vereinfacht ausgedrückt versucht der Projektleiter mit einem Minimum an Zeit und Budget ein Maximum an Scope und Qualität zu erzielen, wobei sich alle Messungen ausschließlich auf das jeweilige Projekt beziehen. Häufig sind zu Projektbeginn schon eine oder mehrere Größen vorgegeben, was die Handlungsmöglichkeiten des Projektleiters entsprechend einschränkt.

friedrichsen_architekturqualitaet_1.tif_fmt1.jpgAbb. 1: Das magische Dreieck für Projektleiter

Ein Architekt hat hingegen ganz andere Aufgaben:

Der Architekt hat vereinfacht ausgedrückt die Aufgabe, ein System erfolgreich zu machen. Dazu muss er die verschiedenen Qualitätsattribute des Systems sicherstellen. Das umfasst neben dem Umsetzen der nichtfachlichen Anforderungen insbesondere das Strukturieren des Systems (Stichwort: Verständlichkeit) und das Ausrichten an den Anforderungsdomänen (Stichwort: Änderbarkeit). Als zielgebende Rahmenbe...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang