Das Problem mit der Architekturqualität

1bt | 1.2012www.bt-magazin.de© Software & Support Media GmbH

www.bt-magazin.de 1.2012 Heft 8

expertenwissen für it-Architekten, Projektleiter und berater

Qualität

Mythos Qualitätsmanagement

„Funktioniert“ ist nicht genug

Höhere Qualität, bessere Software

Sonderdruck fürwww.codecentric.de

www.bt-magazin.de

Architekturqualität

2 bt | 1.2012© Software & Support Media GmbH

Vielleicht kennen Sie die Situation: Sie sind Architekt in einem Projekt und es steht eine wichtige Architektu-rentscheidung 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 Syste-men erfordert. Eigentlich scheint die Aufgabe einfach, aber die Entwickler stolpern von einem Problem ins nächste und bekommen die Lösung nicht stabil, wäh-rend 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 ÜbelsLetzten 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 ge-planten 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 Fea-ture 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 hinzube-kommen, müssten wir einen neuen Service implemen-tieren und folgendermaßen einbinden …“ Er skizziert seine Idee am Whiteboard. Der Projektleiter antwor-tet: „Sieht schön aus. Aber wie viel Aufwand ist das?“ Der Architekt und der Chefentwickler überlegen einen Moment gemeinsam und nennen dem Projektleiter ei-nen 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‘ interes-siert mich im Augenblick nicht. Wir haben einen Termin zu halten!“. Da meldet sich ein ambitionierter Jungent-wickler: „Ich hätte da eine Idee. Wir könnten doch den bestehenden Service hier nehmen, da noch ein Flag ein-fügen, hier und hier ein paar Verzweigungen ergänzen und das Datenbankfeld hier in dem Fall mit den anderen

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 Aufga-

ben 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 aus-

balancieren und so höhere und langfristigere Architekturqualität erreichen kann.

AuTor: uWe FrIeDrIchSen


Daten füllen, um uns die Schemamigration zu sparen. Das könnte ich bis zum Ende der Wo-che fertig haben.“

Sie ahnen schon, wie die Geschichte aus-geht? Richtig: Natürlich greift der Projektlei-ter die Idee des Jungentwicklers auf, und es wird so umgesetzt. Die Warnung des Archi-tekten, dass die Lösung unter Wartbarkeits-aspekten eine Katastrophe sei, die zukünftige fachliche Änderungen extrem schwer bis un-möglich machen würde, wischt der Projekt-leiter mit Hinweis auf den Termin und die eh schon angespannte Budgetsituation beiseite. Frustriert nehmen Architekt und Chefent-wickler hin, dass „billig“ mal wieder „gut“ gestochen hat, und das Projekt nimmt wei-ter seinen gewohnten Gang. Es gibt noch ein paar Probleme mit der Änderung, aber der Jun-gentwickler 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 AufGAbenstellunGenBevor ich auf diese Frage zurückkomme, möchte ich kurz auf die Ursachen für diesen Konflikt eingehen. Da-für müssen wir die Aufgaben eines Projektleiters und ei-nes Architekten etwas genauer betrachten. Beginnen wir mit den Aufgaben eines Projektleiters:

•Der Projektleiter hat die Aufgabe, ein Projekt erfolg-reich 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 Projekt-beginn schon eine oder mehrere Größen vorgegeben, was die Handlungsmöglich-keiten des Projektleiters entsprechend ein-schränkt.

Ein Architekt hat hingegen ganz andere Auf-gaben:

•Der Architekt hat vereinfacht ausgedrückt die Aufgabe, ein System erfolgreich zu ma-chen. Dazu muss er die verschiedenen Qua-litätsattribute des Systems sicherstellen.

Das umfasst neben dem Umsetzen der nichtfachlichen Anforderungen insbesondere das Strukturieren des Systems (Stichwort: Verständlichkeit) und das Aus-richten an den Anforderungsdomänen (Stichwort: Änderbarkeit). Als zielgebende Rahmenbedingungen muss er dabei die Zufriedenheit über alle Stakehol-der-Gruppen über den Lebenszyklus eines Systems maximieren und gleichzeitig die Kosten über alle Ko-stenarten über den Lebenszyklus eines Systems mini-mieren. 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 Pro-jektleiter auf Projekte fokussiert ist, ist der Architekt auf

Abb. 1: Das magische Dreieck für Projektleiter

Abb. 2: Das magische Dreieck für Architekten

www.bt-magazin.de4 bt | 1.2012© Software & Support Media GmbH

Systeme fokussiert. Ihr jeweiliger Fokus ist also orthogo-nal zueinander (Abb. 3).

ein JAhr sPäterSind 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 wei-terentwickelt worden. Nun läuft wieder ein Projekt, in dem u. a. ein neues, sehr wichtiges Geschäftsfea-ture umgesetzt werden soll, mit dem man sich gegen einen Mitbewerber positionieren will. Der damals erfolgreiche Projektleiter ist wieder an Bord, der Ar-chitekt ist dieses Mal nicht dabei und der mittlerweile bei Projektleitern für seine pragmatischen Lösungen geschätzte Jungentwickler ist in einem anderen wich-tigen Projekt unabkömmlich. Das Projekt geht ganz gut voran. Nur dieses eine kritische Feature macht un-geahnte 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 Architekturdo-kumentation 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 Fol-ge, 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 sta-bile Lösung ist nicht in Sicht. Der Projektleiter schimpft auf seine „inkompetenten“ Entwick-ler und versucht, den pragmatischen Jungent-wickler aus dem alten Projekt per Eskalation in sein Projekt zu bekommen („Der kann das bestimmt!“), während der Releasetermin er-barmungslos näher rückt. Egal, wie das Pro-jekt jetzt weitergeht, werden wahrscheinlich die falschen Schlüsse gezogen. Schafft es der Projektleiter durch Eskalation den Jungent-wickler 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 sol-che Probleme gehäuft im Umfeld seiner „prag-matischen“ 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 unternehmenssichtHierfü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ön-nen. Dies wird organisatorisch typischerweise in Form von Projekten abgewickelt. Projekte verfolgen meistens eher kurzfristige Ziele und sind zeit- und budgetgetrie-ben. 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ön-nen die meisten Unternehmen ihren Geschäftsbetrieb nicht aufrechterhalten, auch nicht für kurze Zeit. Sie haben in der Regel einen Lebenszyklus von vielen Jah-ren, 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).

Abb. 3: Das natürliche Spannungsfeld zwischen Projektleitern und Archi-tekten


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 Mitar-beiter und ihre Ressourcen entsprechend aufstellen. Zu den Ressourcen gehören auch die langlebigen IT-Syste-me. 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 (insbe-sondere 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üns-tige 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ätsattri-bute 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 projektgetrie-ben: 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 System-qualitä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 ent-standenen, häufig unwartbaren Systemen, während das Management und die Fachbereiche, die dieses Projekt-system etabliert haben, beklagen, dass die IT „langsam und ineffizient“ sei, „die Innovation behindern“ würde. Entsprechend wird IT nur noch als Kostenfaktor wahr-genommen und man versucht weiter Budgets abzuzie-hen. 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 Ver-nachlässigung der Architekturqualität.

Die lösunG Des ProblemsAber 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 be-halten. Gerade die Qualitätsattribute Verständlichkeit und Änderbarkeit sind bei den langen Lebenszyklen der Systeme extrem wichtig, wenn man will, dass auch zu-künftige Projekte Änderungsanforderungen schnell und flexibel umsetzen können.

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

Aber wie kann man das hinbekommen? Es gilt, das natürliche Spannungsfeld zwischen Projektleiter und

Abb. 4: unternehmensnutzen abhängig vom Fokus (verein-facht)


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 Pro-jektleiter die komplette Entscheidungsgewalt hat und der Architekt gar keine. Im Zweifelsfall bestimmt der Projektleiter und der Architekt hat das Nachsehen. Bes-ser 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 Fle-xibilität und Reaktionsfähigkeit als Unternehmen: Das Schaffen einer Umgebung, in der das natürliche Span-nungsfeld zwischen Projektleiter und Architekt zum Tragen kommt und so die für das Unternehmen wich-tigen Größen Projektgeschwindigkeit (und Kosten) so-wie Systemqualität in eine sinnvolle Balance kommen können.

fein-tuninGIn einem solchen Umfeld hat der Projektleiter ein Prob-lem: 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 durch-zusetzen? 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 durchzuset-zen. 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 dar-stellen, gibt man dem Architekten analog zum Projekt-leiter ein Budget zur Sicherstellung der Systemqualität im Sinne der Erfüllung der architekturrelevanten Qua-litätsattribute, mit einem besonderen Fokus auf Ver-ständlichkeit und Änderbarkeit. Allerdings könnten immer noch Projekttermine durch für die Architek-turqualitä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 durch-zuführen. Man hätte dann die normalen Projekte und orthogonal dazu eine Systempflege. Um sicherzustel-len, dass innerhalb der Projekte keine Entscheidungen getroffen werden, die komplett gegen die Architektur-

ziele 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 kom-merzieller 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 Pro-jekts begleiten. Dort kann er dann mögliche Alternati-ven 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 Kon-sequenzen explizit zu machen. Hat der Architekt weder Budgets noch Entscheidungskompetenzen und wird mit aus Systemqualitätssicht schlechten Lösungen konfron-tiert, so kann er diese Lösungen und deren Konsequen-zen zumindest dokumentieren. Aus der agilen Welt gibt es hierfür den Begriff der „technischen Schulden“. Die-ser bezeichnet eine Lösung, die man vorläufig „quick and dirty“ umgesetzt hat und die man zu einem späte-ren Zeitpunkt noch einmal nacharbeiten muss, wenn man nicht Zins und Zinseszins in Form von steigenden Fehlerquoten, Instabilitäten und sinkender Produktivi-tät zahlen will. Damit hat man das Problem zwar noch nicht gelöst, aber man hat als Architekt Transparenz ge-schaffen, was ein erster Schritt ist.

Bei all diesen Ansätzen ist es essenziell wichtig, dass sich Architekten auf die beschriebenen Ziele fo-kussieren. Das häufig schlechte Bild von Architekten rührt unter anderem daher, dass viele Vertreter die-ser Spezies ein ausgeprägtes Bedürfnis entwickelt ha-ben, sich selbst Denkmäler zu setzen: Überkandidelte Architekturen, diktatorisches Verhalten usw. waren häufig die Folge, gepaart mit unvermeidlichem Ver-trauensverlust. 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 Vor-schlä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 Umfel-dern. Damit treten die in diesem Artikel beschriebenen Probleme und Zielkonflikte ebenso auf, auch wenn man sie nicht mehr so einfach mit bestimmten Rollen asso-ziieren 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 Prob-lem befassen.

fAzitArchitekturqualität und Projektdenken passen häufig nicht gut zueinander. Während Projekte sich nur auf das Geschehen bis zum Projektende fokussieren, müssen Ar-chitekten weit darüber hinaus denken. Letztlich braucht ein Unternehmen beide Aspekte in vernünftiger Balance, um dauerhaft den maximalen Mehrwert aus seinen In-vestitionen sicherzustellen. Heute ist es aber meistens so, dass der Fokus ausschließlich auf Projekten liegt und die Systemqualität den Projektzielen komplett untergeord-net wird. Damit verschenken Unternehmen viel Poten-zial, nachhaltige Innovationsfähigkeit und letztlich auch viel Geld. Durch eine gesunde Balance zwischen Pro-jekt- und Systemzielen und einem konstruktiven Span-nungsfeld 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.

uwe friedrichsen hat langjährige erfahrungen als Archi-tekt, Projektleiter und Berater. Aktu-ell ist er bei der codecentric AG als cTo tätig und beschäftigt sich in dem Kontext insbesondere mit agilen Ver-fahren und neuen Architekturansätzen und Technologien.

Notizen:


codecentric AG Kölner Landstraße 11 40591 Düsseldorf

Tel: +49 (0) 211.9941410 Fax: +49 (0) 211.9941444

E-Mail: [email protected] www.codecentric.de blog.codecentric.de

Documents

Das Problem mit der Architekturqualität