Wie man durch einseitige Prioritäten viel Geld verschenkt

Das Problem mit der Architekturqualität

Uwe Friedrichsen

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 Projektes, 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?

Geschrieben von
Uwe Friedrichsen
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.