Das Problem mit der Architekturqualität

Ein Jahr später

Sind die unterschiedlichen Aufgabenstellungen und Fokussierungen denn kritisch? Dafür möchte ich noch einmal das Beispiel vom Anfang aufgreifen: Seit dem Livegang des Projekts ist ein Jahr vergangen. Das System ist zwischenzeitlich in anderen Projekten weiterentwickelt worden. Nun läuft wieder ein Projekt, in dem u. a. ein neues, sehr wichtiges Geschäftsfeature umgesetzt werden soll, mit dem man sich gegen einen Mitbewerber positionieren will. Der damals erfolgreiche Projektleiter ist wieder an Bord, der Architekt ist dieses Mal nicht dabei und der mittlerweile bei Projektleitern für seine pragmatischen Lösungen geschätzte Jungentwickler ist in einem anderen wichtigen Projekt unabkömmlich. Das Projekt geht ganz gut voran. Nur dieses eine kritische Feature macht ungeahnte Probleme. Zur Umsetzung muss nämlich der Service erweitert werden, in den der Jungentwickler aus dem initialen Projekt seinen „Hack“ integriert hat. Die Entwickler des aktuellen Projekts tun sich sehr schwer damit, überhaupt zu verstehen was der Code macht. Die wenige Dokumentation und die wenigen Testfälle helfen nicht so richtig. Auch die Benennung der Methoden und Variablen scheint nicht zu dem zu passen, was der Code macht und die Architekturdokumentation hilft an der Stelle auch nicht. Manchmal glaubt ein Entwickler trotzdem verstanden zu haben, was der Code macht und integriert eine Änderung. Das hat dann jedes Mal zur Folge, dass irgendein Teil der ursprünglichen Funktionalität nicht mehr läuft.

Das „Trial and Error“-Spiel nimmt seinen Lauf, die Aufwände explodieren und eine stabile Lösung ist nicht in Sicht. Der Projektleiter schimpft auf seine „inkompetenten“ Entwickler und versucht, den pragmatischen Jungentwickler aus dem alten Projekt per Eskalation in sein Projekt zu bekommen („Der kann das bestimmt!“), während der Releasetermin erbarmungslos näher rückt. Egal, wie das Projekt jetzt weitergeht, werden wahrscheinlich die falschen Schlüsse gezogen. Schafft es der Projektleiter durch Eskalation den Jungentwickler in sein Projekt zu bekommen und der bekommt eine Lösung hin, dann wird er vom Projektleiter und dem Management als Held gefeiert und keiner stört sich daran, dass solche Probleme gehäuft im Umfeld seiner „pragmatischen“ Lösungen auftreten. Und läuft das Projekt gegen die Wand, dann wird irgendein anderer Schuldiger gesucht, wahrscheinlich die „inkompetenten“ Entwickler. Niemand käme allerdings auf die Idee, dem Projektleiter die Schuld für das Desaster zu geben, weil er vor einem Jahr nicht auf seinen Architekten gehört hatte. Wenn man es recht bedenkt, kann man ihm auch gar keinen Vorwurf machen, denn er hat damals nur die ihm gestellte Aufgabe so gut wie möglich erledigt. Seine Entscheidung war bezogen auf die ihm gestellte Aufgabe richtig. Aber wo liegt dann das Problem?

Das Problem aus Unternehmenssicht

Hierfür müssen wir Projekte und Systeme einmal aus Unternehmenssicht betrachten. Beginnen wir mit den Projekten: Es ist für Unternehmen wichtig, schnell und flexibel auf interne und externe Treiber reagieren zu können. Dies wird organisatorisch typischerweise in Form von Projekten abgewickelt. Projekte verfolgen meistens eher kurzfristige Ziele und sind zeit- und budgetgetrieben. Dauert ein Projekt zu lange, ist man vielleicht zu spät mit dem Feature am Markt, und verbraucht man zu viel Geld, dann rechnet sich das Projekt nicht mehr.

Dann gibt es die IT-Systeme: Ohne die Systeme können die meisten Unternehmen ihren Geschäftsbetrieb nicht aufrechterhalten, auch nicht für kurze Zeit. Sie haben in der Regel einen Lebenszyklus von vielen Jahren, häufig sogar Jahrzehnten. Gerade die Kernsysteme zeichnen sich durch sehr lange Lebenszyklen gepaart mit häufigen Änderungen aus (was klar ist, weil in ihnen die Kernkompetenzen des Unternehmens abgebildet sind). Im direkten Vergleich ist der Lebenszyklus eines Systems damit typischerweise um ein Vielfaches länger als die Laufzeit eines Projekts.

Jetzt stehen Unternehmen vor der Herausforderung, jederzeit schnell und flexibel auf Treiber reagieren zu können. Dafür müssen sie ihre Organisation, ihre Mitarbeiter und ihre Ressourcen entsprechend aufstellen. Zu den Ressourcen gehören auch die langlebigen IT-Systeme. Damit diese jederzeit schnell und flexibel geändert werden können, müssen sie zu jedem Zeitpunkt zwei der vielen Qualitätsattribute erfüllen, für die ein Architekt typischerweise verantwortlich ist: Verständlichkeit und Änderbarkeit.

  • Verständlichkeit bedeutet, dass ein Stakeholder (insbesondere ein Entwickler) das System möglichst schnell und einfach verstehen können muss. Verständlichkeit ist die Grundvoraussetzung für Änderbarkeit: Was man nicht versteht, kann man auch nicht ändern.
  • Änderbarkeit bedeutet, dass man (zukünftige) neue Anforderungen auf möglichst einfache, kostengünstige und risikoarme Weise in ein bestehendes System integrieren kann. Änderbarkeit entfaltet ihren Nutzen in der Regel mittel- oder langfristig.

Vernachlässigt man diese zwei essenziellen Qualitätsattribute von Systemen, dann verliert man als Unternehmen über kurz oder lang die flexible Reaktionsfähigkeit und damit meistens auch viel Geld – von Stress, Frustration und sinkender Motivation in den Reihen der Mitarbeiter ganz zu schweigen. Neben den Projekten benötigt man also auch einen Fokus auf die Architekturqualität, um seine nachhaltige Reaktions- und Innovationsfähigkeit zu bewahren.

Wie in dem Beispiel am Anfang beschrieben, sind aber nahezu alle Investitionen in der IT projektgetrieben: Die Budgets gehören den Fachbereichen, Geld gibt es nur für das kurzfristige Umsetzen von Fachfeatures, je billiger, desto besser. Budgets für die Pflege der Systemqualität gibt es kaum oder gar nicht. Die Effekte dieser Entwicklung sind hinreichend bekannt: Dadurch, dass die IT praktisch kein Geld mehr für die Systempflege bekommt, kämpfen die IT-Abteilungen mit den so entstandenen, häufig unwartbaren Systemen, während das Management und die Fachbereiche, die dieses Projektsystem etabliert haben, beklagen, dass die IT „langsam und ineffizient“ sei, „die Innovation behindern“ würde. Entsprechend wird IT nur noch als Kostenfaktor wahrgenommen und man versucht weiter Budgets abzuziehen. Die Qualität der Systeme sinkt damit weiter, und die IT wird noch langsamer. Ein Teufelskreis!

Gut, ganz so schwarz und weiß ist es in der Praxis dann häufig doch nicht, und auch die IT-Abteilungen könnten sicherlich eine Menge besser machen, als sie es heute vielfach tun, aber insgesamt verlieren alle durch die ausschließliche Fokussierung auf Projekte unter Vernachlässigung der Architekturqualität.

Kommentare

Schreibe einen Kommentar

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