Business Technology 06/12

Das Problem mit der Architekturqualität

Autor:

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.

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.“

Das magische Dreieck für Projektleiter

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?

Das magische Dreieck für Architekten

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.

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 Rahmenbedingungen muss er dabei die Zufriedenheit über alle Stakeholder- Gruppen über den Lebenszyklus eines Systems maximieren und gleichzeitig die Kosten über alle Kostenarten über den Lebenszyklus eines Systems minimieren. Damit ergibt sich für den Architekten ein ganz anderes magisches Dreieck (Abb. 2).

Vergleicht man die beiden Aufgabenstellungen, dann sieht man sofort den Zielkonflikt: Während der Projektleiter auf Projekte fokussiert ist, ist der Architekt auf Systeme fokussiert. Ihr jeweiliger Fokus ist also orthogonal zueinander (Abb. 3).

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.

Spannungsfeld zwischen Entwicklern und Architekten

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 Voraussetzung 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.

Unternehmensnutzen

Die Lösung des Problems

Aber wie kann man es besser machen? Die Lösung ist bereits grundsätzlich genannt worden: Man darf nicht nur in Projekten denken und handeln, man muss auch die Systeme und deren Nachhaltigkeit im Fokus behalten. Gerade die Qualitätsattribute Verständlichkeit und Änderbarkeit sind bei den langen Lebenszyklen der Systeme extrem wichtig, wenn man will, dass auch zukünftige Projekte Änderungsanforderungen schnell und flexibel umsetzen können.

Natürlich ist es dabei auch wichtig, nicht in das andere Extrem zu verfallen: Es ist niemandem geholfen, wenn die IT sich jetzt nur noch mit der Verständlichkeit und Änderbarkeit ihrer Systeme befasst und dabei wichtige, kurzfristige Geschäftsanforderungen komplett ignoriert. Es muss eine sinnvolle Balance gefunden werden, um den maximalen Nutzen zu erzielen (Abb. 4).

Aber wie kann man das hinbekommen? Es gilt, das natürliche Spannungsfeld zwischen Projektleiter und Architekten auszubalancieren. Beide werden benötigt, also sollte man als Unternehmen das Spannungsfeld für sich nutzen. Heute sieht es meistens so aus, dass der Projektleiter die komplette Entscheidungsgewalt hat und der Architekt gar keine. Im Zweifelsfall bestimmt der Projektleiter und der Architekt hat das Nachsehen. Besser wäre es, wenn Projektleiter und Architekt sich auf Augenhöhe mit vergleichbaren Kompetenzen begegnen, um so eine konstruktive Diskussion zum Finden guter Kompromisse zwischen den beiden Zielen zu fördern. Genau dies ist die Voraussetzung für nachhaltige Flexibilität und Reaktionsfähigkeit als Unternehmen: Das Schaffen einer Umgebung, in der das natürliche Spannungsfeld zwischen Projektleiter und Architekt zum Tragen kommt und so die für das Unternehmen wichtigen Größen Projektgeschwindigkeit (und Kosten) sowie Systemqualität in eine sinnvolle Balance kommen können.

Fein-Tuning

In einem solchen Umfeld hat der Projektleiter ein Problem: Seine Aufgabe ist es doch, mit einem Minimum an Zeit und Budget ein Maximum an Scope und Qualität zu erzielen, wobei in der Praxis meistens schon viele der Größen vor Projektstart festgelegt werden. Wie soll er diese Aufgabe zielgerichtet umsetzen, wenn er jetzt nicht mehr die Möglichkeit hat, diese unumschränkt durchzusetzen? Er muss sich jetzt ja mit einem Architekten arrangieren, der die gleichen Rechte wie er hat, aber ganz andere Ziele. Was tun? Jetzt könnte man sich auf den Standpunkt stellen, dass es ihm damit immer noch besser ginge als bislang einem Architekten, der auch eine Aufgabe hatte, aber letztlich keine Mittel sie durchzusetzen. Aber es gibt natürlich auch ein paar konstruktivere Lösungsansätze:

Der Architekt bekommt ein Budget für die Systempflege: Das wäre wahrscheinlich die sauberste Lösung. Da sowohl die Projektziele als auch die nachhaltige Systemqualität einen Wert für das Unternehmen darstellen, gibt man dem Architekten analog zum Projektleiter ein Budget zur Sicherstellung der Systemqualität im Sinne der Erfüllung der architekturrelevanten Qualitätsattribute, mit einem besonderen Fokus auf Verständlichkeit und Änderbarkeit. Allerdings könnten immer noch Projekttermine durch für die Architekturqualität relevante Aktivitäten gefährdet werden. Hierfür gäbe es die Möglichkeit, eine Reihe dieser Aktivitäten außerhalb der normalen Projekte durchzuführen. Man hätte dann die normalen Projekte und orthogonal dazu eine Systempflege. Um sicherzustellen, dass innerhalb der Projekte keine Entscheidungen getroffen werden, die komplett gegen die Architekturziele sind, sollte ein Architekt die Projekte weiterhin zumindest beratend unterstützen, im Notfall auch mit Vetorecht ausgestattet.

Der Architekt begleitet bereits die Planungs- und Budgetierungsphase des Projekts: Aus Architektursicht sinnvolle Lösungen sind nicht unbedingt die billigsten Lösungen. Häufig werden in der Budgetierungsphase aber zugunsten eines Business Cases oder anderer kommerzieller Gründe die billigsten Lösungsmöglichkeiten angenommen. Um den Projektleiter danach nicht vor ein unlösbares Problem zu stellen, sollte ein Architekt bereits die Planungs- und Budgetierungsphase eines Projekts begleiten. Dort kann er dann mögliche Alternativen und deren Konsequenzen aufzeigen und so helfen, die aus Unternehmenssicht ganzheitlich beste Lösung zu finden und zu budgetieren.

Technische Schulden explizit machen: Das ist keine echte Lösung, aber zumindest ein erster Schritt, um Konsequenzen explizit zu machen. Hat der Architekt weder Budgets noch Entscheidungskompetenzen und wird mit aus Systemqualitätssicht schlechten Lösungen konfrontiert, so kann er diese Lösungen und deren Konsequenzen zumindest dokumentieren. Aus der agilen Welt gibt es hierfür den Begriff der „technischen Schulden“. Dieser bezeichnet eine Lösung, die man vorläufig „quick and dirty“ umgesetzt hat und die man zu einem späteren Zeitpunkt noch einmal nacharbeiten muss, wenn man nicht Zins und Zinseszins in Form von steigenden Fehlerquoten, Instabilitäten und sinkender Produktivität zahlen will. Damit hat man das Problem zwar noch nicht gelöst, aber man hat als Architekt Transparenz geschaffen, was ein erster Schritt ist. Bei all diesen Ansätzen ist es essenziell wichtig, dass sich Architekten auf die beschriebenen Ziele fokussieren. Das häufig schlechte Bild von Architekten rührt unter anderem daher, dass viele Vertreter dieser Spezies ein ausgeprägtes Bedürfnis entwickelt haben, sich selbst Denkmäler zu setzen: Überkandidelte Architekturen, diktatorisches Verhalten usw. waren häufig die Folge, gepaart mit unvermeidlichem Vertrauensverlust. Deshalb ist es für Architekten immens wichtig, sich als Dienstleister für die beschriebenen Ziele zu verstehen und im Zweifelsfall dem „Weniger ist mehr“-Prinzip zu folgen. Dann hat man auch eine reelle Chance, Akzeptanz für die hier skizzierten Vorschläge zu bekommen.

Kein Problem im agilen Umfeld?

Wie gut, dass wir agil sind, könnte man jetzt als agiler Zeitgenosse denken. Da gibt es keine Projektleiter und keine Architekten und deshalb betrifft mich das alles nicht. Das ist natürlich ein grober Fehlschluss. Auch wenn es in agilen Umfeldern häufig nicht die Rolle eines Projektleiters oder eines Architekten gibt, so sind deren Aufgaben und Ziele trotzdem nicht hinfällig geworden. Projektziele und Systemqualität sind in agilen Umfeldern mindestens genauso relevant wie in nicht agilen Umfeldern. Damit treten die in diesem Artikel beschriebenen Probleme und Zielkonflikte ebenso auf, auch wenn man sie nicht mehr so einfach mit bestimmten Rollen assoziieren kann. Das beschriebene Problem ist nicht in der eingesetzten Methodik begründet, sondern systemischer Natur und deshalb muss man sich in agilen Umfeldern genauso mit dem in diesem Artikel beschriebenen Problem befassen.

Fazit

Architekturqualität und Projektdenken passen häufig nicht gut zueinander. Während Projekte sich nur auf das Geschehen bis zum Projektende fokussieren, müssen Architekten weit darüber hinaus denken. Letztlich braucht ein Unternehmen beide Aspekte in vernünftiger Balance, um dauerhaft den maximalen Mehrwert aus seinen Investitionen sicherzustellen. Heute ist es aber meistens so, dass der Fokus ausschließlich auf Projekten liegt und die Systemqualität den Projektzielen komplett untergeordnet wird. Damit verschenken Unternehmen viel Potenzial, nachhaltige Innovationsfähigkeit und letztlich auch viel Geld. Durch eine gesunde Balance zwischen Projekt- und Systemzielen und einem konstruktiven Spannungsfeld zwischen Projektleitern und Architekten auf Augenhöhe kann man diese Situation verbessern und sich nachhaltig einen Wettbewerbsvorteil verschaffen. Architekturqualität ist kein nettes Feature, sondern eine handfeste wirtschaftliche Größe für jedes Unternehmen, das in signifikantem Umfang IT-Unterstützung für seine Wertschöpfung benötigt, was mittlerweile für nahezu alle Unternehmen gilt.

Vollständiger Artikel