ObjektSpektrum 06/10

Wer braucht einen Architekten?

Autor:

Agile Methoden wie Scrum und XP kennen keinen Architekten- das Team ist der Architekt. Aber, funktioniert das auch immer so? Kann ein Entwicklungsteam immer die notwendigen Architekturarbeiten übernehmen oder braucht man unter bestimmten Voraussetzungen doch einen dedizierten Architekten? Der Artikel beschreibt die Ziele und Aufgaben der Architektur und versucht, Antworten auf diese Fragen jenseits der üblichen Argumentationspfade zu finden.

Sind Architekten obsolet?

Schon 2003 stellte Martin Fowler in „Who needs an Architect” die Notwendigkeit eines Architekten in der Softwareentwicklung in Frage (vgl. [Fow03]). Dazu passend kennen die heute dominierenden agilen Methoden Scrum und XP keine expliziten Architekten. Statt dessen wird die Architekturentwicklung auf das (Entwickler-) Team verteilt (vgl. z. B. [Lip09]) und Architekturen sind „emergent”.

Das bedeutet – vereinfacht ausgedrückt –, dass die Architektur nicht mehr vor Beginn der Entwicklung festgelegt wird, sondern sich im Laufe der Entwicklung unter Berücksichtigung einiger mehr oder minder einfacher Designprinzipien aus dem erstellten Code „herausschält”. Wir sprechen hier also eher von einer impliziten als von einer expliziten Architekturentwicklung. Folgt man dieser Argumentation, wird in einem solchen Umfeld kein dedizierter Architekt mehr benötigt.

Aber stimmt das tatsächlich? War die über viele Jahre hinweg etablierte Rolle des Architekten nur schwergewichtiger Selbstzweck ohne tieferen Nutzen oder hat diese Rolle vielleicht doch einen Sinn? Um diese Frage vernünftig beantworten zu können, möchte ich im Folgenden ein paar grundlegende Gedanken zum Thema Architektur anstellen. Die elementaren Fragen sind, wofür man Architektur eigentlich benötigt und was die Ziele von Architektur sind.

Architekturziele

Damit Architektur kein Selbstzweck ist, muss sie einen Nutzen bringen, z. B. wirtschaftlich oder durch den Abbau von Risiken. Bei der Suche nach dem Nutzen von Architektur gelangt man sehr schnell zu den so genannten Qualitätsmerkmalen von Software (vgl. z. B. [ISO]): Architektur soll die Erfüllung der Qualitätsmerkmale sicherstellen. Wenn man sich jetzt überlegt, welchen Nutzen die Erfüllung dieser Merkmale letztlich bringt, kommt man zu zwei Zielen:

  • Zum einen sollen die verschiedenen beteiligten Parteien (Stakeholder) möglichst gut zufrieden gestellt werden. Hier ist also eine möglichst effiziente (schnelle und kostengünstige) und effektive (vollständige und korrekte) Umsetzung der verschiedenen funktionalen und nicht-funktionalen Anforderungen gefragt.
  • Da Geld in allen IT-Projekten eine große Rolle spielt, ist das zweite Ziel, die entstehenden Kosten so gering wie möglich zu halten.

Hierbei ist es essenziell, dass es sich nicht um eine einmalige Aufgabe handelt, sondern dass Architektur die Aufgabe hat, die Ziele über den gesamten Lebenszyklus einer Anwendung möglichst gut zu unterstützen – und nicht nur während der Ersterstellung.

Zahlreiche Untersuchungen belegen, dass die Erstentwicklung einer Anwendung in Relation zu ihrem gesamten Lebenszyklus im Schnitt nur 10 bis 20 % bezogen auf Zeit und Aufwand beträgt – Tendenz fallend (vgl. z. B. [Kos03]). Offensichtlich muss Architektur also zur Maximierung der genannten Ziele stets den gesamten Lebenszyklus einer Anwendung im Fokus haben. Damit kann man die Ziele von Architektur als eine Art „Optimierung von Summen über die Zeit” darstellen:

  • Architektur hat die Aufgabe, die Interessen aller Stakeholder am System über den gesamten Lebenszyklus zu maximieren.
  • Architektur hat die Aufgabe, die Gesamtkosten für das System über den gesamten Lebenszyklus zu minimieren.

Wichtig ist hierbei, dass die Interessen aller beteiligten Parteien maximiert werden, also nicht nur versucht wird, eine Partei zu befriedigen, und dass der gesamte Lebenszyklus und nicht nur ein bestimmter Zeitabschnitt im Fokus ist. Analog ist zu beachten, dass die Gesamtkosten betrachtet werden, also nicht nur die reinen Entwicklungskosten, sondern auch Einführungs-, Migrations-, Betriebs- sowie Wartungs- und Weiterentwicklungskosten – und das ebenfalls wieder über den gesamten Lebenszyklus. Was nützt eine möglichst billige Entwicklung, wenn Betrieb und Wartung der Anwendung kostentechnisch ein Alptraum sind?

Das ist eine Stelle, an der viele der heute üblichen Business-Case-Kalkulationsverfahren noch zu kurz greifen, weil sie die Folgekosten für Architekturentscheidungen nicht korrekt berücksichtigen. So mag ein „schneller Hack”, also eine einfache Lösung an den bestehenden Strukturen vorbei, auf dem Papier attraktiv erscheinen, wenn man nur die Entwicklungskosten berücksichtigt. Berücksichtigt man in der Kalkulation aber, dass durch solche „Hacks” die Wartung des Systems deutlich aufwändiger wird und die Systemstabilität leidet, d. h. die Fehlerquote steigt, dann sieht der Business-Case schnell ganz anders aus.

Aufgaben von Architektur

Welche Aufgaben muss ein Architekt wahrnehmen, um diese Ziele zu erreichen? Diese Frage hat John Zachman, einer der wichtigsten Unternehmensarchitekten unserer Zeit, einmal sehr prägnant beantwortet: „In short, the reasons why you need Architecture: Complexity and change” (vgl. [Zac08]). Zachman hat dabei über Architektur im Allgemeinen gesprochen. Durch Ergänzen der im Kontext von ITSystemen sehr wichtigen Qualitätsattribute lassen sich die Aufgaben von Architektur folgendermaßen formulieren:

Architektur ist das Management von Komplexität und Änderbarkeit bei Erfüllung der geforderten Qualitätsmerkmale.

Hierzu sind noch ein paar ergänzende Erläuterungen notwendig. Zunächst einmal könnte man – berechtigterweise – anmerken, dass Änderbarkeit ein Qualitätsmerkmal ist und dass Komplexitätsmanagement eine Voraussetzung für Änderbarkeit ist. Das ist prinzipiell korrekt, nur ist das Management von Komplexität und Änderbarkeit heute ein so bedeutendes Thema in der IT-Architektur, dass es wichtig ist, diese beiden Punkte gesondert hervorzuheben.

Gerade vor dem Hintergrund der immer komplexer werdenden IT-Systeme, der immer höheren Änderungsrate bei immer kürzeren Zeitstrecken und der immer längeren Betriebs- und Weiterentwicklungsphasen kommt dem Management von Komplexität und Änderbarkeit eine Schlüsselrolle in der Architektur zu. Diese beiden Aspekte einfach nur als ein Qualitätsmerkmal unter vielen zu positionieren, wird dem nicht gerecht. Sie sind der Schlüssel zum Erreichen der zuvor beschriebenen Architekturziele und müssen entsprechend gegenüber den anderen Qualitätsmerkmalen – wie etwa Ergonomieund Portierbarkeit – deutlich hervorgehoben werden.

Ein zweiter Punkt ist die Erfüllung der geforderten Qualitätsmerkmale an sich. Hier ist nicht nur von nicht-funktionalen Anforderungen die Rede, sondern von allen Qualitätsmerkmalen, also auch den funktionalen Anforderungen. Man könnte jetzt einwerfen, dass sich Architektur auf die Erfüllung der nicht-funktionalen Anfor – derungen beschränkt. Diese verbreitete Sichtweise greift jedoch zu kurz und hat schon in vielen Projekten zu unzureichenden Architekturen geführt. Es ist korrekt, dass Architektur die eine Stelle ist, die sich um die Umsetzung der nicht-funktionalen Anforderungen kümmert. Das bedeutet aber nicht, dass sich ein Architekt darauf beschränken kann. Um die Komplexität und Änderbarkeit eines Systems über seinen Lebenszyklus beherrschen zu können, muss er insbesondere auch die funktionalen Anforderungen berücksichtigen. Mindestens 90 % aller Anforderungen im Lebenszyklus eines typischen Anwendungssystems sind fachlich motiviert. Wie soll ein Architekt eine gute Architektur erstellen, wenn er die fachlichen Anforderungen nicht verstanden und angemessen in seiner Architektur berücksichtigt hat?

Wie lassen sich diese vielfältigen Aufgaben in der Praxis umsetzen? Hier finden sich sehr viele Methoden mit vielen Varianten, wobei sich zwei Herangehenweisen unterscheiden lassen: Strukturierung und Alignment. Diese beiden Herangehensweisen müssen unterschieden werden, um die Frage beantworten zu können, ob ein agiles Team einen Architekten braucht. Abbildung 1 fasst die Ziele, Aufgaben und Herangehensweisen noch einmal zusammen.

Ziele von Architektur

Strukturierung

Warum ist Struktur so wichtig? Strukturierung ist eine Reaktion auf eine Beschränkung des menschlichen Gehirns. Unser Gehirn kann nur eine gewisse Menge nicht weiter strukturierter Informationen auf einmal erfassen und damit arbeiten. Haben wir z. B. eine größere Menge an Dokumenten, fangen wir automatisch an, diese zu sortieren, in Ordnern zu organisieren, die Ordner in Bereichen von Schränken usw. Das müssen wir tun, da wir sonst den Überblick verlieren würden. Vielleicht würden wir in einer überschaubaren Anzahl an Dokumenten (weniger als 500) auch ohne eine große Strukturierung am nächsten Tag noch so ziemlich alles wiederfinden, aber spätestens, wenn wir nach einer Unterbrechung von mehreren Monaten wieder an unserem unsortierten und unstrukturierten Dokumentenstapel weiterarbeiten, müssten wir komplett von vorne anfangen.

Genauso geht es uns bei der Softwareentwicklung, bei der wir in einem normalen Anwendungssystem mit tausenden und mehr verschiedenen Information und Details konfrontiert sind, die wir alle irgendwie im Blickfeld behalten müssen. Ohne eine Form der Strukturierung ist da selbst der genialste Entwickler irgendwann rettungslos verloren. Daher strukturiert er sich sein System – implizit oder explizit – in irgendeiner Form: etwa in Methoden, Klassen, Modulen, Komponenten, in bestimmten Verfahren, wie er auf Datenbanken zugreift, wie er Schnittstellen bedient, wie er die Benutzungsoberfläche steuert usw. Wie gut die gewählte Struktur war, kann man erkennen, wenn der Entwickler nach drei oder sechs Monaten Arbeit an einem anderen System in dem alten System eine Änderung umsetzen soll. Wenn er dann erst einmal mehrere Tage benötigt, um seinen Code zu verstehen, war die Struktur wahrscheinlich nicht so gut gewählt.

Den Fall, dass nur ein Entwickler an einem Anwendungssystem arbeitet, gibt es heutzutage nur noch selten. Meistens sind mehrere, manchmal sogar hunderte Entwickler an einem Anwendungssystem beteiligt. In diesem Fall müssen sich alle im Quelltext orientieren und darin Änderungen und Erweiterungen umsetzen können. Es muss also eine Struktur geben, an der sich alle Entwickler orientieren können, und die ihnen hilft, ihre Aufgaben effizient und effektiv umsetzen zu können. Sie müssen schnell die Stellen im Code finden können, an denen sie ihre Modifikationen vornehmen, und sie benötigen einen Rahmen, wie sie ihre Modifikationen vornehmen, damit diese die Struktur nicht verletzen und damit das resultierende System immer noch für alle beteiligten Entwickler verständlich bleibt. Architektur im Sinne von Strukturierung ist daher in jedem nicht-trivialen System immer vorhanden, egal ob sie implizit oder explizit, vor oder während der Entwicklung erstellt worden ist.

In der Praxis bedeutet Strukturierung das Bilden und Verfeinern von Strukturen, das Auflösen von Problemen, die bei der Verfeinerung eventuell sichtbar werden, sowie – im Idealfall – das regelmäßige Vereinfachen der Strukturierung z. B. durch Refaktorisierungen. Dies findet praktisch vollständig in der Lösungsdomäne statt. So sind auch die üblicherweise in diesem Kontext genannten Hilfsmittel (vgl. z. B. [Mar]) Anleitungen zur (verfeinerten oder verbesserten) Strukturierung der Lösung aus Sicht der Lösungsdomäne. Dieser Teilaspekt der Architektur wird typischerweise auch nur betrachtet, wenn Architektur und Design als die gleiche Tätigkeit auf unterschiedlichen Detailebenen dargestellt werden.

Architektur und Design

Alignment

Für viele beschränkt sich Architektur auf den Bereich „Strukturierung” – sie denken nur an den strukturellen Aspekt, manchmal noch unter expliziter Berücksichtigung einiger nicht-funktionaler Anforderungen wie Skalierbarkeit oder Portabilität. Diese Herangehensweise ist jedoch nur „notwendig, aber nicht hinreichend”. Architektur umfasst natürlich die Strukturierung von Systemen auf einer bestimmten Ebene, nur wissen wir bei der beschriebenen Herangehensweise letztlich nicht, ob die gewählte Architektur im Sinne der Architekturziele „gut” oder „schlecht” ist. Die Beantwortung dieser Frage ist nur bei einer weiter greifenden Herangehensweise an Architektur möglich, die ich als Alignment bezeichne. Alignment – also Ausrichtung, Justierung oder Einklang – bedeutet, einfach ausgedrückt, dass Architektur sicherstellen muss, dass die Lösung zur Aufgabenstellung passt. Wie geschieht das? Bei einem normalen Softwareentwicklungsprojekt gibt es eine ganze Reihe unterschiedlicher beteiligter Parteien (Stakeholder), die verschiedene Interessen und Anforderungen bezüglich der zu entwickelnden Anwendung haben:

  • Die Anwender wollen ein System, das sie optimal bei ihrem Tagesgeschäft unterstützt.
  • Die Fachbereiche möchten neue Geschäftsideen und -anforderungen möglichst schnell umsetzen können.
  • Der Sponsor möchte möglichst viel Geschäftswert für sein Geld.
  • Der Projektmanager möchte ein möglichst risikoarmes Projekt.
  • Die Systemplaner wollen möglichst keine unbekannten Infrastrukturkomponenten und klar definierte Lastprofile für die Systemplanung.
  • Die Administratoren wollen ein möglichst einfach betreibbares System.
  • Die Entwickler möchten neue Technologien einsetzen können und möglichst abwechslungsreiche Aufgaben.

Die Hauptaufgabe eines Architekten ist es, alle diese unterschiedlichen Interessen und Anforderungen gegeneinander abzuwägen und auszubalancieren sowie Widersprüche aufzulösen und geeignete Kompromisse zu finden. Das ist in erster Linie keine technische oder konzeptionelle Aufgabe, sondern hat sehr viel mit dem Verstehen der verschiedenen Anforderungsdomänen sowie mit Kommunikation, Moderation und Konfliktmanagement zu tun, also mit dem Umgang mit Menschen und ihren Bedürfnissen.

Diese abgestimmten und ausbalancierten Interessen und Anforderungen muss ein Architekt verwenden, um daraus eine Lösungsstruktur zu entwerfen, d. h. er muss die Transformation der Anforderungen in die Lösungsdomäne vornehmen. Beim Erstellen des Konzepts und dem Vermitteln an die beteiligten Entwickler können neue Probleme und Widersprüche entstehen, die den Erfordernissen der Lösungsdomäne und der Entwickler als eine wichtige beteiligte Partei geschuldet sind. Diese Probleme und Widersprüche muss der Architekt abwägen, ausbalancieren, auflösen und geeignete Kompromisse finden. Bei all diesen Tätigkeiten muss er im Auge behalten, dass die Komplexität der Lösung nicht überhandnimmt und die Änderbarkeit gewährleistet bleibt.

Alignment als Herangehensweise liefert im Unternehmenssinne einen Mehrwert, also einen Geschäftswert. Im Gegensatz zur reinen Strukturierung kann Alignment aber nicht implizit erfolgen, sondern immer explizit. „Zufälliges” Alignment gibt es nicht bzw. es ist zumindest sehr unwahrscheinlich.

Risiken und Nebenwirkungen

Der große Unterschied zwischen Alignment und Strukturierung ist, dass Alignment sich primär damit beschäftigt, die verschiedenen Problemdomänen zu verstehen und eine geeignete Transformation in die Lösungsdomäne zu finden, während Strukturierung sich primär damit befasst, die Lösungsdomäne zu organisieren.

Diese Unterscheidung wird auch an verschiedenen anderen Stellen aufgegriffen, so z. B. von Leonard Fehskens in [Feh08], der zwischen Architektur (Alignment) und Design (Strukturierung) unterscheidet. In – teressant sind die ergänzenden Merkmale, anhand derer er die beiden Tätigkeiten unterscheidet (siehe Tabelle 1).

So ist es das Ziel von Architektur, eine Lösungsklasse zu finden, die den Anforderungen gerecht wird, während Design eine spezielle Lösung innerhalb der durch die Architektur vorgegebenen Grenzen definiert. Während eine andere Architektur immer eine andere Aufgabenstellung impliziert, können verschiedene Designs die gleiche Aufgabenstellung abbilden. Diese Unterscheidung macht die – zugegebenermaßen fließenden – Grenzen zwischen Architektur und Design ziemlich gut greifbar.

Abbildung 2 zeigt die verschiedenen Herangehensweisen und die damit verbundenen Rollen im Überblick. Die eventuell an einem Projekt beteiligten Business- Analysten bzw. Requirements-Ingenieure befassen sich mit der Organisation und Konsolidierung der Anforderungen, d. h. sie bewegen sich komplett in der Anforderungsdomäne (bzw. im Fall des Business-Analysten nur in der Fach – domäne). Sie lösen in der Regel auch keine Widersprüche zwischen den verschiedenen Problemdomänen auf der Anforderungs – seite auf, sondern konsolidieren nur die Anforderungen der einzelnen Domänen. Die Strukturierung findet vollständig auf der Lösungsseite statt und hat keinen oder wenig Bezug zur Anforderungsseite. Das Alignment hat die Aufgabe, den „großen Graben” zwischen Anforderungs- und Lösungsseite zu überbrücken und die auf dem Weg auftretenden Widersprüche und Probleme aufzulösen – sollte es keinen Requirements-Inge nieur oder Business- Analysten im Projekt geben, muss ein Alignment-Architekt sich in der Regel auch noch um die Konso lidierung der Anforderungen kümmern.

Alignment und Strukturierung

Alle genannten Rollen werden für die erfolgreiche Umsetzung von Anfor – derungen in eine tragfähige und nachhaltige Lösung benötigt. In der Praxis erlebt man es allerdings häufig, dass Architektur mit Strukturierung, d. h. mit Design, gleichgesetzt wird und dass der Alignment- Aspekt vernachlässigt wird. Damit fehlt ein wichtiges Glied in der Kette von den Anforderungen zur Lösung. In der Folge führt das häufig zu einer nicht optimalen Strukturierung der Lösung im Sinne der Anforderungen, was wiederum dazu führt, dass die Architekturziele nicht erreicht werden. Das bedeutet in der Regel höhere Kosten, eine höhere Fehleranfälligkeit, schlechtere Änderbarkeit und eine geringere Zufriedenheit der Stakeholder.

Was heißt es nun, einen Architekten mit an Bord zu haben, der das Alignment im Fokus hat? Die Chance, die Architekturziele zu erreichen, ist damit deutlich höher. Die Frage ist allerdings, ob man diese Rolle mit einer dedizierten Person besetzen muss oder ob sie vom Entwicklerteam übernommen werden kann. Zur Beantwortung dieser Frage muss man einen Blick auf die für diese Rolle erforderlichen Fähigkeiten werfen: Neben sehr guten Kommunikationsfähigkeiten und einer guten Portion Finger spitzen – gefühl sollte ein Alignment-Architekt ein gutes Verständnis für die Aufgaben und inhärenten Treiber der verschiedenen Parteien haben, um zum einen die Bedürfnisse verstehen und bewerten zu können, und zum anderen auf Augenhöhe mit den Parteien kommunizieren zu können.

Optimalerweise hat ein solcher Architekt in der Praxis schon in möglichst vielen dieser Rollen gearbeitet oder zumindest eng mit diesen Rollen zusammengearbeitet. Das ist notwendig, damit er die notwendige Glaubwürdigkeit bei der Gegenseite hat und das Verständnis für die Probleme und Bedürfnisse der Ge sprächs – partner besitzt, um die erforderlichen Abstimmungen durchführen und Alter – nativen diskutieren zu können. Man kann dies auch gut anhand von Dana Brede meyers „Architect Competency Frame work” (siehe Tabelle 2) nachvollziehen. Die Grundidee hinter dem Framework ist, dass ein Architekt im Laufe seiner Entwicklung Kompetenz in einer Reihe von Disziplinen aufbauen sollte. Typischerweise beginnt er in der obersten Disziplin „Technologie”. Hat er hier eine profunde Kompetenz aufgebaut, beginnt er, zusätzlich Kompetenz in der folgenden Disziplin „Beratung” aufzubauen, gefolgt von „Strategie”, „Organisationspolitik” und „Führung”. Design bedarf der Disziplin „Technologie” und vielleicht noch ein wenig „Consulting”. Architektur im Sinne von Alignment bedarf aber zumindest der ersten vier Disziplinen, optimalerweise auch der letzten Disziplin „Führung” für eine erfolgreiche Umsetzung.

Um Kompetenz in diesen Disziplinen aufzubauen, benötigt man Zeit: Man muss das erforderliche Wissen erwerben und die notwendigen guten und schlechten Erfahrungen machen. Zusätzlich reichen für ein erfolgreiches Arbeiten als Architekt Erfahrungen in der Softwareentwicklung nicht aus – darüber hinaus benötigt man Erfahrungen in den Aufgabengebieten
möglichst vieler der anderen Stakeholder.

Das sind aber Fähigkeiten, die nicht jeder haben kann, wie man leicht nachvollziehen kann. Insbesondere sind die Fähigkeiten, die ein Architekt benötigt, sehr breit gefächert. Das sind ganz andere Fähigkeiten, als sie ein Softwareentwickler üblicherweise braucht. Ein Software ent wickler benötigt für seine Arbeit relativ fokussierte, dafür aber sehr tiefe Fähig keiten in seiner
Domäne. Dieser Unter schied in den benötigten Fähigkeiten verdeutlicht auch, dass die hier beschriebene Architektenrolle üblicherweise nicht – wie immer wieder behauptet – von einem (agilen) Entwicklerteam übernommen werden kann.

Architekt-Kompetenz-Framework

Wer braucht einen Architekten?

Einen „Strukturierungsarchitekten“ – also einen Designer – benotigt man immer. Fur ein nachhaltig wartbares und anderbares System ist es unabdingbar, ein gegebenes Losungskonzept unter Einhaltung be – stimmter Prinzipien weiter bis in den Code hinein zu verfeinern und sicherzustellen, dass sich das Design im Code wiederfindet. Allerdings muss diese Rolle nicht unbedingt von einer oder mehreren Personen dediziert wahrgenommen werden. Das Design kann haufig sehr gut von den erfahrenen Entwicklern eines Teams ubernommen werden, also den Personen, die die Erfahrung und das Wissen um gute Strukturierung haben und die nah genug am Team dran sind, um dies in das gesamte Team hereinzutragen.

Die Frage nach einem Architekten (im Sinne von Alignment) ist schwieriger zu beantworten. Grundsatzlich ist es auch immer notwendig sicherzustellen, dass die Losung (uber ihren Lebenszyklus) zur Aufgabenstellung passt. Da der Architekt in der beschriebenen Form aber ganz spezielle, in der Regel nicht so haufig vorhandene Fahigkeiten benotigt, sollte man sich uberlegen, wann man den Aufwand betreibt, diese Rolle explizit zu besetzen. Dazu muss man eine Reihe von Risikofaktoren betrachten:

  • Zeithorizont: kurzfristig (Projekt- Scope) oder langfristig (System-Scope)
  • Komplexitat des zu erstellenden Systems: niedrig oder hoch
  • Anzahl der beteiligten Parteien und Personen: klein oder gros
  • Erfahrung aller beteiligten Parteien mit der Aufgabenstellung: gering oder gros
  • Zusatzliche Risikofaktoren, z. B. Zeitund Kostendruck oder politische Sensibilitat des Themas: niedrig oder hoch

Es lassen sich sicherlich noch weitere Risikofaktoren identifizieren, aber die genannten Faktoren sind hinreichend, um die Notwendigkeit eines Architekten zu beschreiben: Je hoher das Risiko eines kurz- oder auch langfristigen Fehlschlags aufgrund der Auspragung eines der beschriebenen Faktoren wird, desto wichtiger ist es, einen Architekten einzusetzen. Anders ausgedruckt: Die Aufgabe eines Architekten ist es, das Risiko eines kurzfris – tigen Fehlschlags (Projektfehlschlag) oder eines langfristigen Fehlschlags (System – fehlschlag) aufgrund der beschriebenen Risikofaktoren zu minimieren.

Entscheidungsbaum

Hat man es beispielsweise mit einem einfachen Auskunftssystem zu tun, das eine Handvoll Entwickler erstellen, die auch schon die Thematik fachlich und technisch gut kennen, ist es wahrscheinlich nicht erforderlich, explizit einen Architekten einzusetzen. Ganz anders sieht es bei einem hoch komplexen Unterfangen mit vielen beteiligten Parteien aus, bei dem fachlich und technisch an diversen Stellen Neuland betreten wird und sich die Parteien untereinander nicht einig sind, wie die Losung aussehen soll. Hier ist der Einsatz eines Architekten unabdingbar, um uberhaupt die Chance auf einen Projekterfolg zu haben, vom langfristigen Erfolg (Stichwort .Lebenszyklus) ganz zu schweigen.

Abbildung 3 stellt das zuvor Beschrie – bene noch einmal als Entscheidungsbaum dar. Bei einer langfristigen Betrachtung des Systems uber die Grenzen eines einzelnen Projekts hinaus, wie sie die Ziele der Architektur vorgeben, ist es auser bei sehr einfachen Unterfangen immer empfehlenswert, einen Architekten hinzuzuziehen. Hierbei gibt es das Problem, dass die wenigsten Unternehmen heutzutage eine Balance aus kurz- und langerfristigen Zielen anstreben, sondern meistens nur die kurzfristigen Ziele mit schnellem ROI -oftmals im unterjahrigen Bereich – im Fokus haben. Ob diese kurzfristige Denkweise fur Systeme, die haufig 15 und mehr Jahre in Produktion bleiben, uneingeschrankt sinnvoll ist, ist eine andere Diskussion.

Bei einer kurzfristigen Betrachtung, d. h. aus Projektsicht, hangt die Notwendigkeit eines Architekten von der Komplexitat der Aufgabenstellung und der Organisation sowie der Erfahrung der Beteiligten mit der Aufgabenstellung ab. Weitere Risikofaktoren – wie hoher Zeit- und Kosten – druck oder politische Sensibilitat der Aufgabenstellung- setzen die Grenze herunter, ab der ein Architekt hinzugezogen werden sollte.

Braucht ein agiles Team einen Architekten?

Am einfachsten lasst sich diese Frage beantworten, wenn man betrachtet, welche Faktoren den Einsatz einer agilen Vorgehensweise treiben.

Abbildung 4 zeigt diese Faktoren zusammen mit den zuvor betrachteten Faktoren fur den Einsatz eines Architekten. Hier gibt es eine Reihe von Punkten auf beiden Seiten, die nur eines der beiden Themen treiben. So sind eine hohe Anzahl an Personen bzw. Parteien oder die politische Sensibilität der Aufgabenstellung keine Treiber für den Einsatz einer agilen Vorgehensweise. Auf der anderen Seite sind eine Fokussierung auf das Produzieren von Mehrwert und aktives Risikomanagement (z. B. durch verkürzte Feedback-Zyklen) zwar Treiber für Agilität, aber nicht für Architektur. Auch den aktuellen Hype um das Thema Agilität darf man nicht aus dem Auge lassen. Es gibt derzeit sicherlich eine ganze Reihe von Projekten, deren primärer Treiber ist, dass es derzeit en vogue ist, agil zu sein.

Aber schaut man sich einmal die Schnittmenge in Abbildung 4 an, gibt es eine Menge an Faktoren, die als Treiber sowohl für den Einsatz eines Architekten als auch für eine agile Vorgehensweise wirken. Am wichtigsten sind dabei die Komplexität der Aufgabenstellung und die Erfahrung der Beteiligten mit ihr. Je höher die Komplexität und je geringer die Erfahrung der Beteiligten mit der Aufgabenstellung sind, desto wichtiger ist der Einsatz entsprechender Maßnahmen zum aktiven Risikomanagement. Zwei zentrale Maßnahmen dabei sind der Einsatz agiler Vorgehensweisen und der eines Architekten. Ein weiterer gemeinsamer Treiber ist ein hoher Zeit- und Budgetdruck, die das Risiko eines Fehlschlags erhöhen.

Letztlich ist auch die langfristige Systementwicklung ein gemeinsamer Treiber. Agile Vorgehensweisen sind häufig eine gute Wahl für eine langfristige Systementwicklung. XING etwa verwendet ein agiles Vorgehen, um seine Plattform in vielen kurschwerpunkt zen Release-Zyklen langfristig weiterzuentwickeln und zu optimieren (vgl. z. B. [Rep09]). Durch die konsequente Mehrwert-Fokussierung und die schnellen Feedback-Zyklen ist Agilität für solche Unterfangen meistens eine gute Wahl. Um allerdings langfristig die Beweglichkeit der Agilität sicherzustellen, muss sich ein Architekt darum kümmern, dass Komplexität und Änderbarkeit der Lösung gewährleistet bleiben. Als grobe Empfehlung möchte ich festhalten: In Vorhaben, in denen die Aufgabenstellung relativ zur Erfahrung der Beteiligten nicht sonderlich komplex ist, in denen Zeit- und Budgetdruck handhabbar sind und bei denen die langfristige Systementwicklung nicht im Vordergrund steht, kann man in der Regel auf einen expliziten Architekten verzichten. Die Aufgabe kann meistens von einem oder mehreren Senior- Entwicklern mit guten Design- und vernünftigen Beratungskenntnissen wahrgenommen werden.

Werden die Rahmenbedingungen aber komplexer – sei es durch viele beteiligte Stakeholder, durch unklare Anforderungen oder durch den schieren Aufgabenumfang –, wird Architektur im Sinne von Alignment für eine erfolgreiche Umsetzung immer wichtiger. Da dies eine Aufgabe ist, die eine oder sogar mehrere Personen vollständig auslasten kann und die aufgrund der erforderlichen Fähigkeiten oftmals nicht sinnvoll von einem reinen Softwareent wickler wahrgenommen werden kann, sollte man hier einen oder mehrere explizite Architekten einzusetzen.

Das ist jetzt kein Ruf nach einem „Big Design Upfront” oder den berüchtigten Architektur-Elfenbeintürmen, ganz im Gegenteil! Elfenbeinturm-Architekten à la „Matrix Reloaded”, die alles im stillen Kämmerlein von A bis Z durchdenken – möglichst bevor die erste Zeile Code geschrieben wird –, sind für Alignment nicht hilfreich. Die Hauptaufgabe des Architekten ist Kommunikation und Abstimmung. Das kann man als latent autistischer Elfenbeinturm-Bewohner nicht leisten. Sinnvollerweise ist ein Architekt Teil des Teams, allein schon deshalb, weil die Entwickler die Personen sind, die die eigentliche Anwendung erstellen. Für einen Architekten bedeutet das, dass das Team für ihn ein extrem wichtiger Stakeholder ist. Eine Entscheidung, die er nicht mit dem Team abgestimmt hat, kann und wird das Team in der Regel nicht umsetzen, womit die Entscheidung ohne Nutzen ist, weil sie nie den Weg in die fertige Anwendung finden wird.

Dennoch ist es zu einfach, pauschal zu sagen, dass Architektur „vom Team” übernommen wird. Aufgrund der sehr unterschiedlichen Fähigkei ten von Architekten und Softwareentwicklern ist der Architekt in der beschriebenen Form meistens eine dedizierte Person. Wenn die Architektur – aufgaben keine Voll zeitbeschäftigung versprechen, kann er auch noch andere Aufgaben wahrnehmen, z. B. Design oder auch Imple men tierung (wie in Abb. 2 angedeutet). Nur ist es häufig so, dass die Architekturaufgaben in Umfeldern, die einen Architekten erforderlich machen, so sehr zunehmen, dass der Architekt praktisch keine Zeit mehr für andere Aufgaben hat. Das ist in der Regel aber auch nicht schlimm, da das weiterführende Design, das der Architektur folgt, häufig auch noch von anderen Team mitgliedern übernommen werden kann. Wichtig ist dabei nur, dass keine Informa tionsbruchstelle zwischen dem Architekten und dem Rest des Teams entsteht.

Zusammenfassung

Die Aussage, dass ein agiles Team keinen Architekten benötigt, lässt sich nicht pauschal halten. Diese Aussage bezieht sich in der Regel auf Architektur im Sinne von Strukturierung, d. h. auf Design. Diese in praktisch jedem Kontext wichtige Aufgabe kann tatsächlich häufig von den erfahreneren Entwicklern eines Teams wahrgenommen werden. Ganz anders sieht es mit Architektur im Sinne von Alignment aus. Ein Architekt, der diese Aufgabe wahrnimmt, benötigt ganz andere Fähigkeiten als ein Software – entwickler, weshalb diese Aufgabe nicht einfach vom Entwicklerteam übernommen werden kann, sondern in der Regel von einer dedizierten Person mit den entsprechenden Fähigkeiten. Ob man einen Architekten benötigt, hängt primär von der Komplexität der Aufgabe und der Erfahrung der beteiligten Personen – über alle Stakeholder-Gruppen hinweg – mit der Aufgabenstellung zusammen. Da agile Verfahren insbesondere für komplexe Umfelder geeignet sind, in denen die Beteiligten noch nicht ausreichend Erfahrung mit der Aufgabenstellung haben, benötigen agile Teams häufig auch einen Architekten.

Faktoren für den Einsatz eines Architekten bzw. Agilität

Literatur & Links

[Bre02] D. Bredemeyer, Architect Compe tency Framework, 2002, siehe: www.bredemeyer. com/ pdf_files/ArchitectCompetencyFramework. PDF

[Feh08] L. Fehskens, Re-Thinking Archi tecture, The Open Group Conference Munich, 2008

[Fow03] M. Fowler, Who needs an Architect?, 2003, siehe: http://martinfowler.com/ ieeeSoftware/whoNeedsArchitect.pdf

[ISO] ISO/IEC 9126, siehe z. B.: http://de.wikipedia.org/wiki/ISO_9126

[Kos03] J. Koskinen, Software Maintenance Cost, 2003, siehe: www.cs.jyu.fi/~koskinen/ smcosts.htm

[Lip09] M. Lippert, S. Roock, Entkoppelte Systeme sind änderbare Systeme, in: OBJEKT spektrum 4/2009

[Mar] R.C. Martin, The Principles of OOD, siehe: http://butunclebob.com/ArticleS.UncleBob .PrinciplesOfOod

[Pop] Poppendieck.LLC, Lean Software Development, siehe: www.poppendieck.com/

[Rep09] S. Reppin, J. Mainusch, SCRUM in der Community Realität bei XING – ein Erfahrungsbericht, in: JAX 2009

[Rep10] S. Reppin, R. Wirdemann, Kanban bei XING – Wer am Ziel ist, irrt sich, in: OBJEKTspektrum 2/2010

[Zac08] J. Zachman, Introduction to the Zachman Framework, Enterprise Architecture Conference London, 2008

Vollständiger Artikel