Scrum Think big

2	Architektur

Die Architektur eines Produkts ist die erste und wichtigste Voraussetzung für eine gelungene Skalierung. Es ist die Architektur, durch die sich ein Produkt vergrößern und erweitern lässt, genau so kann sie das Wachstum des Produkts oder Projekts behindern. Teams können durch die Architektur zu Bottlenecks werden oder sie kann Teams dazu bringen, unabhängig voneinander zu arbeiten. Die Skalierung eines Projekts wird also vom Rahmen bestimmt, den die Architektur vorgibt. Architektur ist immer auch Projektstruktur und beeinflusst dadurch die Kommunikation und Interaktion. Ich werde Ihnen in diesem Kapitel nicht sagen, wie eine skalierbare Architektur aussehen muss. Ich liefere Ihnen also keine Blaupausen, sondern architektonische Muster, die Sie in jedem Projekt anwenden können ‒ auch in nichtagilen Projekten.

Mein erster Job nach dem Studium führte mich zu Electronic Data System (EDS). Auf einem Mainframe entwickelten mein Entwicklungsteam und ich unter Cobol eine Applikation, mit der Gut- und Lastschriften für die Fahrzeuge eines Automobilkonzerns erstellt werden konnten. Die erfahrenen Entwickler erzählten mir vom Frontend, vom Backend und einer sogenannten „Three Tier Architecture“. Ich lernte, logische und physische Datenmodelle zu unterscheiden, und ich erfuhr, dass man auch objektorientiert statt prozedural programmieren kann. Mein damaliges Entwicklungsteam machte mich mit Business Modelling vertraut und kurz darauf begann der große Hype: Internet. Ich lernte etwas Wesentliches: Das eigene System sollte modular entwickelt werden und über Interfaces mit anderen Systemen arbeiten. Die Module mussten so geschrieben werden, dass sie vollkommen autark von allen anderen Systemen funktionieren konnten. Und das alles noch auf einem Mainframe. Später sprachen wir auf den ersten agilen Entwicklerkonferenzen von emergenten Software- und Systemarchitekturen, also von Architekturen, die erst im Laufe der Zeit entstehen. Eigentlich wächst ein System also, aber wie sollte das gehen: Ich selbst hatte noch gelernt, dass man ein Datenbankmodell nicht einfach ändern kann, es wäre ein zu großer Aufwand. Diese Annahme war auch korrekt. Zumindest in der Toollandschaft der 1990er-Jahre.

Ende 1999 war Extreme Programming noch weitgehend unbekannt und auch fünf Jahre später hatte noch immer kaum jemand verstanden, wie man das machen sollte, was sich Kent Beck da ausgedacht hatte. Doch die Ideen klangen verlockend und vor allem klangen sie logisch. Es war das Thema auf Konferenzen und einige Softwareentwickler schrieben begeistert Tests. Aber es flammten auch die ersten Glaubenskriege auf: Braucht man nun eine Architektur oder entwickelt sie sich emergent? Und dann hörten wir von Conway's Law (Conway 1968): „Organizations which design systems [. . .] are constrained to produce designs which are copies of the communication structures of these organizations.“

2.1	Architektur als Ergebnis der Kommunikationsstruktur

In den Entwürfen von Systemen spiegelt sich laut Melvin Conway also die Kommunikationsstruktur einer Organisation wider. Wenn man sich genauer damit auseinandersetzt, was Conway geschrieben hatte, wird klar, warum viele Softwaresysteme so komplex sind, wie sie es eben sind. Zunächst bauen einzelne Abteilungen jeweils ihr System, danach werden die Einzelsysteme miteinander verbunden. Allerdings passiert das oft nicht so, wie ich es in meinem ersten Team gelernt habe: über klar definierte Schnittstellen und nach genauen Absprachen zwischen den Abteilungen. Vielmehr gibt sich jede Abteilung einfach mit dem zufrieden, was sie bekommen kann und strickt ihre eigene Applikation um. Ein Beispiel: Ein Unternehmen baute ein System, das man als Middleware bezeichnen kann. Bei vielen großen Kunden ist dieses System seit mehr als einem Jahrzehnt im Einsatz. Heute hat es aber nicht alle Funktionalitäten, die von den Kunden benötigt werden, weil die Entwickler vor zehn Jahren noch gar nicht wissen konnten, was in den Systemen der Zukunft wichtig sein würde ‒ die Kunden wussten es ja selbst nicht. Als sich der Bedarf der Kunden allmählich änderte, war das Unternehmen zunächst einfach zu langsam und konnte nicht für jeden Kunden sofort die passende Lösung entwickeln. Also bauten die Kunden ihre eigenen Behelfslösungen um die existierende Applikation herum, die sogenannten „Workarounds“. Als das Softwareunternehmen sein Produkt an die Erfordernisse der Kunden anpasste und damit die eigene Architektur änderte, verursachte genau diese Anpassung ein neues Problem: Nun funktionierten die Workarounds nicht mehr. So verrückt es klingt: Der Softwareanbieter baute seine „richtige“ Architektur wieder zurück.

Ein Manager jenes österreichischen Telekommunikationsunternehmens, bei dem ich nach EDS arbeitete, bezeichnete diese Art, Softwaresysteme zu entwickeln, als „Mushroom-Architektur“. Überall schießen Systeme und Applikationen aus dem Boden. Sie sind nicht so elegant miteinander verbunden, dass man leicht weiterentwickeln kann, meistens weiß niemand mehr, wie diese Systeme miteinander verbunden sind. Konsequenterweise beginnen die verschiedenen Systeme irgendwann, völlig unkontrolliert und unerwartet aufeinander zu reagieren. Entwickelt ein Team an einer Applikation weiter, funktioniert plötzlich in einer anderen Applikation etwas nicht mehr, das bisher keine Probleme gemacht hat. Bei diesem Telekommunikationsunternehmen erlebte ich, wie man sich zunächst mit Release-Management behelfen wollte, nur um wenig später zu merken, dass man auch mit dieser Maßnahme dem Komplexitätsproblem nicht beikommen konnte. Ganz im Gegenteil: Alle Prozesse in der Entwicklung wurden noch langsamer. Viele Telekom-Unternehmen starteten daher in den frühen 2000er-Jahren kostspielige Infrastrukturprojekte und versuchten, mit Middleware die Lage wieder in den Griff zu bekommen. Als Middleware bezeichnet man in der IT-Systemlandschaft jene Systeme oder Programme, die als Datendrehscheibe für alle Applikationen dienen. Gut vergleichbar mit dem Kabelbaum eines Autos, nur viel komplizierter.

Diese Middleware sollte es also richten. Sie sollte das Chaos der Applikationen und Programme, der Datengräber und Fehlplanungen entwirren. Aber sie tat es nicht. Die Systeme wurden immer nur komplexer und die Projekte teurer und teurer. Aus meiner heutigen Sicht wurde dabei die wichtigste Voraussetzung des Aufräumens nicht erfüllt: Wer aufräumt, muss auch wegwerfen. Wer alles Alte aufhebt, kann nicht umbauen oder renovieren und schon gar nicht für die Zukunft planen. Der Ballast, den man mit sich herumschleppt, wird ständig größer, schwerer und unübersichtlicher. Genau das passiert bei vielen Softwareprogrammen in Unternehmen: Anstatt alles, was nicht mehr verstanden wird, einfach auszumisten, werden Applikationen am Leben erhalten ‒ weil man nicht mehr weiß, was sie genau tun.

Aufräumen, wegwerfen und dann: miteinander reden

Aber ich will die aufräumenden Softwareentwickler in Schutz nehmen. Niemand will für das Aufräumen bezahlen, denn Projekte sind Investitionen. Wie soll man den Aktionären klarmachen, dass ständig aufgeräumt werden muss? Das Aufräumen als eine Investition in die Zukunft zu verstehen, fällt vielen schwer. Man bekommt auf den ersten Blick ja nichts dafür, außer einem aufgeräumten System, das eigentlich schon aufgeräumt sein sollte. Aufräumen kostet Arbeit, Zeit und meist auch ein wenig Geld.

In vielen Unternehmen sind die Architekturen der Systeme und Programme so miteinander verwachsen, dass es so gut wie unmöglich scheint, sie wieder aufzulösen und zu entwirren. Sieht man sich Conway's Law noch einmal genauer an, wird deutlich, warum das passieren muss: Die Informationsstrukturen in einem Unternehmen ändern sich schneller, als man sie mit Hilfe von Software nachbilden kann. Ändert sich nun die Informationsstruktur der Realität (des Business) und werden zum Beispiel dezentrale Abteilungen und Prozesse zentralisiert, müsste sich das unterstützende Softwaresystem sofort mitändern. Genau das kostet aber sehr viel Geld, das man nicht jedes Mal ausgeben will, wenn sich innerhalb der Organisation etwas ändert.

Das gilt nicht nur für Software. Auch Hardwareprodukte werden nicht unabhängig von den Informationsstrukturen entworfen, entwickelt und gebaut ‒ in diesem Fall sind es die Lieferantenstrukturen. Aus meinen Beobachtungen ziehe ich den Schluss, dass die Abhängigkeiten im Hardwarebereich sogar noch stärker sind. Deshalb ist es so wichtig, mit den richtigen Lieferanten zu arbeiten und Schnittstellen nicht nur am Anfang der Zusammenarbeit, sondern regelmäßig abzustimmen und gegebenenfalls zu testen, um Änderungen zu erlauben. Wird etwas gemeinsam entwickelt, das beide Seiten der Lieferkette gut beherrschen, ist das meistens kein Problem. Doch wehe, wenn die Lieferkette dysfunktional aufgesetzt wurde und nicht über Dinge geredet wird (manchmal aus seltsamen Gründen auch nicht geredet werden darf), über die unbedingt miteinander geredet werden müsste. Ich habe auch schon erlebt, dass Kunden die fehlende Kommunikation zwischen den Herstellern und ihren Lieferanten ausbaden müssen.

Abgesehen davon, dass solche Setups an sich dysfunktional sind, ist vollkommen klar, warum so ein Projekt nicht erfolgreich sein kann:

• Niemand kennt die Architektur des Gesamtprodukts.

• Niemand hat ein ähnliches Produkt bereits gebaut, aber die Budgets und Deadlines stehen fest.

• Bei Fehlern kann man sich nicht gemeinsam auf die Suche nach der Ursache machen, denn das wäre eine Grenzüberschreitung. Die Folge: Verzögerungen.

• Nicht die Teammitglieder, die täglich am Produkt arbeiten, treffen die...