Was ist Software-Architektur? Immer noch gibt es viele Missverständnisse in der IT was diesen Begriff angeht. An dieser Stelle möchte ich etwas Licht ins Dunkel, und Ihnen gerne diesen Begriff etwas näher bringen. Darüber hinaus ist es mein Ziel damit, andere von meiner langjährigen Erfahrung profitieren zu lassen. Meiner Meinung nach handelt es sich bei der Software Architektur um die wichtigste der Disziplinen in unserer Branche. Hier werden mir vermutlich schon manche widersprechen. Was nützt mir eine gute Architektur, wenn ein System aufgrund fehlender Usability für den Benutzer unbrauchbar ist? Das ist allerdings wahr, andererseits liefert die Software-Architektur Ansätze um mit jedem System langfristig flexibel zu bleiben. Wenn Sie immer auf gute Strukturierung achten, werden Sie immer in der Lage sein einzelne Teile auszutauschen und somit Probleme zu beheben.

Zielgruppe sind alle, die sich für das Thema interessieren. Egal ob Entwickler oder Designer, die sich weiterentwickeln wollen, Manager die ein Verständnis dafür aufbauen möchten, oder auch erfahrene Architekten um ihren Wissensstand mit meinem abzugleichen. Da es mein Ziel ist hier dieses breite Thema so gut es geht auf den Punkt zu bringen, möchte ich gleich mit meiner eigenen Definition von Software Architektur starten, welche von diversen existierenden Definitionen inspiriert worden ist.

1.1 Definition

Software Architektur definiert in erster Linie, wie sich ein System aus seinen einzelnen Komponenten aufbaut. Sie beschreibt die Schnittstellen über die diese miteinander verbunden sind, und darüber hinaus die Abläufe dieses Zusammenspiels.
Es wird auf alle Entscheidungen Einfluss genommen, welche später schwer zu ändern sind. Insbesondere auf Technologieauswahl und die Abbildung auf Laufzeitumgebungen.
Ziel ist es immer, die funktionalen, wie auch die nichtfunktionalen Anforderungen des Auftraggebers zu erfüllen.

1.1.1 Strukturierung in Komponenten

Beim Thema Struktur handelt es sich bestimmt um die wichtigste Frage, und die Hauptaufgabe der Software Architektur. Eine Komponente ist dabei als ein modularer Teil des Systems definiert. Dieser wird durch seine extern wahrnehmbaren Eigenschaften beschrieben, wie ein- und ausgehende Schnittstellen. Prinzipiell sollte eine solche Komponente jederzeit auf Basis dieser Eigenschaften, die sie quasi als Vertrag garantiert, ersetzbar sein, und zwar durch eine Komponente mit den selben Eigenschaften. Um so etwas zu beschreiben eignen sich Strukturdiagramme der UML, wie hier z.B. ein Komponentendiagramm:

Abbildung 1

Abbildung 1.1

In Abbildung 1.1 sehen Sie einen sehr einfachen Fall einer Systemstruktur. Es gibt 2 Komponenten die über eine Schnittstelle miteinander kommunizieren. Wir entscheiden uns nun dazu, auf Komponente "1" noch einen näheren Blick zu werfen:

Abbildung 2

Abbildung 1.2

Wir sehen hier in Abbildung 1.2 den inneren Aufbau der Komponente "1": Diese ist ihrerseits wiederum aus 3 anderen Komponenten, nämlich "A", "B" und "C", aufgebaut. Die Schnittstelle zur Komponente "2" wird dabei an den Sub-Bestandteil "C" delegiert. Dieses Spiel der Verschachtelung können Sie, wie bei den berühmten Matrjoschka Puppen, immer weiter spielen. Je größer das System dabei in Summe ist, desto mehr dieser Verschachtelungsebenen machen Sinn.

Eine Komponente ist bei Einhaltung des Vertrages immer austauschbar. Als Vertrag werden die extern wahrgenommenen Eigenschaften gesehen, wie z.B. Schnittstellen die erfüllt werden müssen.

Dabei unterscheidet man prinzipiell zwischen den unteren Ebenen der Architektur, und den höheren Abstraktionsebenen. Die untere wird dabei üblicherweise als "Software Design", oder "Makro-Architektur" bezeichnet, während die obere "Architektur", oder expliziter "Makro-Architektur" genannt wird.

Man darf wirklich niemals unterschätzen wie wichtig es ist, bei dem Entwurf komplexer Systeme diese in solche Komponenten zu zerlegen. Die so gebauten Strukturensollten Ihnen die Möglichkeit geben, jederzeit

  • Einzelne Komponenten möglichst ohne Seiteneffekte und Abstimmungsarbeit weiterzuentwickeln
  • Einzelne Komponenten an ihren ein- und ausgehenden Schnittstellen isoliert zu testen
  • Einzelne Komponenten auszutauschen

1.1.2 Abläufe

Abläufe beschreiben das Verhalten der einzelnen Komponenten. In der UML werden diese in Verhaltensdiagrammen beschrieben. Typische Beispiele sind Zustandsdiagramme. Ein noch bekannterer Vertreter aus der Gattung der Verhaltensdiagramme der UML ist das Sequenzdiagramm,wie hier ein Beispiel in Abbildung 1-3 für das Circuit Breaker Pattern.

Abbildung 3

Abbildung 1.3

1.1.3 Anforderungen

Eine Anforderung ist zunächst mal ein Wunsch des Auftraggebers, betreffend eines gewissen gewünschten Verhaltens einer Software Lösung. Dabei wird unterschieden zwischen den funktionalen, und den nichtfunktionalen Anforderungen. Während eine funktionale Anforderung festlegt was ein System tun soll, so definiert eine Nichtfunktionale gewisse Qualitätsaspekte der Lösung. Als Softwarearchitekt werden für Sie in erster Linie die nichtfunktionalen Anforderungen interessant sein. Ein paar Beispiele dafür wären:

  • Wartbarkeit (Änderbarkeit, Erweiterbakeit, Ersetzbarkeit)
  • Zuverlässigkeit (Stabilität, Wiederherstellbarkeit)
  • Skalierbarkeit
  • Leistung (Geschwindigkeit, Effizienz, Antwortzeiten)
  • Usability (Benutzbarkeit, Erlernbarkeit)

Es ist in erster Linie eine dieser NFAs, von denen hier die Rede sein wird, und zwar die der Wartbarkeit. Diese wird oft als selbstverständlich vom Kunden angenommen, und daher oft nicht explizit als Wunsch geäußert. Die meisten Kunden gehen einfach davon aus, dass auch in Zukunft jederzeit Änderungswünsche bei gewohnter Produktivität umgesetzt werden können. Unter dem Strich ist es wichtig zu verstehen, dass es bei jeder Architekturdefinition immer um die Erfüllung der konkreten Anforderungen des Kunden geht. Wobei damit die Funktionalen ebenso gemeint sind, wie die Nichtfunktionalen. Es sind dabei die gemeint, die der Kunde äußert, als auch jene die er einfach als selbstverständlich annimmt.

ATAM

Die Architecture Tradeoff Analisys Method ATAM ist eine Methode zur Bewertung von Softwarearchitekturen. Dabei werden von den nichtfunktionalen Anforderungen verschiedene Szenarien abgeleitet wie: „System antwortet bei mehr als 100 Benutzern bei 9 von 10 Requests in weniger als 1 Sekunde“. Die Angemessenheit der Architektur wird dann danach bewertet, ob das gebaute System auch wirklich diese definierten Szenarien erfüllt. ATAM ist weit verbreitet, und durchaus empfehlenswert als Methode zur Architekturbewertung. Allerdings werden Sie eine beginnende strukturelle Erosion eines Systems damit erst entdecken, wenn es schon zu spät ist. Darum sollte man sich nicht unbedingt auf ATAM alleine verlassen.

1.2 Was Architektur NICHT ist

Über die folgenden Irrtümer, die Software Architektur betreffend, bin ich im Laufe meiner Karriere immer wieder gestolpert. Diese Mythen möchte ich an dieser Stelle entkräften, und zur besseren Abgrenzung des Themas eben auch definieren was Architektur NICHT ist:

Pflege des Legacy Systems

Oft habe ich erlebt, dass einfach die- oder derjenige als Architekt galt, der als einziger Know-How bez. des Legacy Systems anzubieten hatte. Solche Mitarbeiter sind enorm wichtig für jedes Unternehmen, trotzdem ist ihr Wissen einfach aus der Historie begründet, und hat nicht zwingend etwas mit Architektur zu tun. Oft kommt es hier sogar zu einer gewissen Betriebsblindheit, welche den Beginn eines Verbesserungsprozesses manchmal erschwert.

Development

Zugegeben, ich habe noch keinen guten Architekten kennengelernt, welcher nicht auch gute Entwicklerskills gehabt hätte. Trotzdem gibt es einen Unterschied zwischen einem Senior-Developer und einem Architekten. Ein guter Programmierer ist nicht automatisch auch ein guter Architekt. Ich empfehle dabei immer, die guten Entwickler zu motivieren, sich um die Mikro-Architektur (bzw. das Design) ihrer Komponenten zu kümmern, und wenn sie sich dabei bewähren, sie weiter zum Architekten auszubilden.

Außerdem braucht ein Developer eher detailliertes Know-How was die einzelnen Technologien betrifft, die er auch einsetzt. Ein Architekt sollte wiederum eher über einen breiten Überblick verfügen. Heutzutage ändern sich Technologien so schnell, dass es eigentlich unmöglich ist, ein tiefes Know-How in vielen Technologien zu besitzen, welches auch aktuell ist. Falls Sie nach der am meisten anerkannten Quelle für aktuelle Technologie Trends suchen, so möchte ich Ihnen noch das Technology Radar von Thoughtworks empfehlen.

Rich Hickey[1] hat einmal ganz gut auf den Punkt gebracht, was den Entwickler vom Architekten unterscheidet:

Programmers know the benefits of everything and the tradeoffs of nothing. Architects have to understand both!

Wobei es absolut Sinn macht, wenn Architekten sich auch alle paar Jahre mal die Hände schmutzig machen, und bei der Programmierung mitmachen. So bekommen sie nämlich aus erster Hand mit, was sie mit ihren Entscheidungen verursachen, und es wird auch der allseits gefürchtete "Elfenbeinturm-Effekt" dadurch verringert.

Ich finde sogar man sollte darauf bestehen, dass die Architekten eines Systems, bei der Entwicklung dessen anfangs auch immer teilnehmen. Die beste Art und Weise sicherzustellen, dass die erdachten Konzepte sich auch im Code wiederfinden, ist nämlich selber an der Erstellung dessen mitzuwirken.

1.3 Organisation

Wir stellen also fest: Je strukturierter Ihr System ist, desto besser. Im Optimalfall haben Sie Strukturen gefunden, wo nur wenige Schnittstellen zwischen den einzelnen Komponenten notwendig sind. Wie sollten Sie nun Ihr IT Team organisieren? Vielleicht haben Sie schon einmal von Conway´s Law gehört? Es besagt im Grunde, dass sich die Organisation Ihres IT Teams fast automatisch in der Struktur des Codes wiederspiegeln wird. Um die Einhaltung Ihrer Systemstruktur also optimal zu unterstützen, sollten Sie auch Ihre Teamstruktur danach ausrichten. Wenn Sie das nicht tun, kann es zu einer Situation kommen, wie ich sie als abschreckendes Beispiel in Abbildung 1.4 dargestellt habe:

Abbildung 3

Abbildung 1.4

Stellen Sie sich nun bitte den Abstimmungsaufwand zwischen den Teams vor, um eine Änderung an einem der Systeme durchzuführen. Außerdem erhöht es automatisch das Verantwortungsgefühl eines Teams, und deren Führungskräfte, für "ihr" System, wenn eine genaue Zuordnung zu den einzelnen Gruppen möglich ist.

Dezentralisierung der Architektur

Aber wo genau wird nun der (Makro-) Architekturaspekt behandelt? Sie haben nun die Teams 1:1 den einzelnen Systembauteilen zugeteilt, und jeder ist hoch motiviert "sein" System so gut als möglich zu bauen. Aber wer definiert, dass es eben genau diese 3 Systeme gibt, welche Schnittstellen dazwischen nötig sind, und welches Feature überhaupt in welchem System abgebildet wird? Im Sinne von Agilität und Time-To-Market ist es immer gut, so viele Aufgaben wie möglich zu dezentralisieren. Ein zentrales Architektenteam bringt nämlich folgende Probleme mit sich:

  • Die Mitarbeiter verlieren auf ihrer hohen Abstraktsionsebene den Konnex zur Realität und Leben von da an im "Elfenbeinturm".
  • Das Team der Architekten muss bei jeder neuen Anforderung eingebunden werden, und wird so zum Flaschenhals und behindert Ihre Agilität.
  • Ein zentrales Team neigt nach Conway´s Law dazu, auch zentrale Strukturen zu bauen, wie einen systemübergreifenden Prozess/ESB Layer, um für sich selbst eine Daseinsberechtigung zu schaffen. Dieser hat aber keinerlei Mehrwert und würde ebenfalls Ihre Time-To-Market bremsen.
  • Niemand lässt sich gerne bevormunden. Wenn Designer von Architekten genaue Vorschriften bekommen, so führt das nicht selten zum sogenannten Not-Invented-Here-Effekt und somit unter Umständen automatisch zu einer Ablehnung auf Grund der menschlichen Psychologie.
Versuchen Sie so viel Architektur-Verantwortung wie möglich an die einzelnen Designer zu delegieren, und das Thema somit zu dezentralisieren. Je besser und ausgewogener Sie das hinbekommen, desto schneller und flexibler werden Sie mit Ihrer Systemlandschaft auf Dauer sein!

1.4 Über Enterprise Architektur

Ein Begriff der wie vieles in unserer Branche nicht genau definiert ist, ist der der Unternehmensarchitektur bzw. Enterprise Architecture. Dieser Terminus ist aus meiner Sicht schwierig von der Software-Architektur abzugrenzen, trotzdem ist es wichtig zu verstehen, dass es sich hier prinzipiell um etwas anderes handelt. In dieser Disziplin wird das Unternehmen, was Business und IT betrifft, ganzheitlich betrachtet. Wir begeben uns dabei also auf eine noch höhere Abstraktionsebene.

Abstimmungen zwischen Software Architekten und Enterprise Architekten sind potentiell mühsam, weil es die SOA Pattern der Software Architekten vom Beginn des Jahrtausends fix in das Vokabular und das Rollenverständnis der Disziplin Enterprise Architektur geschafft haben, und dort bis heute überdauern. So werden diese Pattern quasi als absolute Wahrheit auch nach wie vor auf Hochschulen so unterrichtet. Während die Software Architektur pausenlos ihr Tun hinterfragt, und dabei Pattern der Vergangenheit regelmäßig zu Antipattern werden, bilden veraltete Pattern teilweise die Grundlage der gesamten Disziplin Enterprise Architektur.

Aber verstehen Sie mich bitte nicht falsch, es gibt fantastische Enterprise Architektur Teams, welche entweder auch das nötige Software-Archiektur Know How haben, oder diese Arbeit den Leuten überlassen, welche davon auch eine Ahnung haben. Ein Enterprise Architektur Team kann sich dann auf die anderen Aufgaben konzentrieren, die auch in ihren Zuständigkeitsbereich fallen, wie die Entwicklung einer gemeinsamen Sprache mit dem Kunden, oder die Abstimmung zwischen den Teams was das eingesetzte Technologie Set in Entwicklung und Betrieb angeht. Es ist aber wichtig zu verstehen, warum es hier zu Konflikten kommen kann, und wo dann dafür die Ursache zu suchen ist.

Die Theorie zur Enterprise Architektur, und die diversen Vorgehensmodelle dazu (wie TOGAF), haben klassische SOA Muster anfangs des Jahrtausends übernommen. Es wurde einfach der aktuelle Status Quo der Software Architektur "konserviert" und überdauert dort bis heute. Egal was Sie tun, fallen Sie bitte NIEMALS mehr darauf herein, weil unter Software Architekten diese Denkweise schon lange als überholt gilt.

1.5 Evolution

Wenn Sie sich nun also entschlossen haben, mit der Strukturierung ihrer Systemlandschaft zu beginnen, stellt sich automatisch die Frage, wie man so etwas organisatorisch begleiten und enforcen kann. Bitte nehmen Sie ab einer gewissen Systemgröße unbedingt Abstand von der Idee, alles in einem großen Big-Bang umstellen zu wollen. Zunächst einmal möchte ich Indizien identifizieren, die Anzeigen ob eine Migration bei Ihnen auch wirklich nötig ist:

  • Unflexibilität bei Releases - Neue Features kommen nur noch an wenigen Terminen im Jahr heraus, dafür aber immer die gesamte Systemlandschaft gleichzeitig.
  • Tests sind schwierig - Einzelne Systemtests sind wegen der Abhängigkeiten zu anderen Systemteilen kaum oder gar nicht möglich, es muss immer das gesamte System miteinander getestet werden.
  • Teure Weiterentwicklung - Die Schnittstellen der Systeme sind wahrscheinlich nicht darauf ausgelegt auch mit anderen Komponenten zu interagieren, oder einfach nur unflexibel.
  • Einzelne Änderungen betreffen oft mehrere Systemteile - Für einzelne Anforderungen sind Änderungen an einem großen Teil der IT Landschaft nötig, anstatt dass diese nur von einem Team erledigt werden können.
  • Kaum Agilität möglich - Die einzelnen Teams können nicht unabhängig an ihren eigenen Userstories arbeiten, weil ihr System zu viele enge Koppelungen an andere Systeme hat.

Wenn Sie eines dieser Probleme haben, dann leidet Ihr Unternehmen mit ziemlicher Sicherheit an schlechten architekturellen Entscheidungen aus der Vergangenheit. Was können Sie nun also tun? Verbesserungen in der Mikro-Architektur Ebene sind schon schwierig genug durchzuführen, wie verbessert man dann ganze Systemlandschaften? Ein Big Bang ist in den wenigsten Fällen eine Option. Sie können sich für eines der folgenden Maßnahmenpakete entscheiden:

1.5.1 Managed Evolution (Credit Suisse)

Bei Managed Evolution geht es, um den Inhalt des des Buchs von Stephan Murer und Bruno Bonati[2] auf den Punkt zu bringen, um Folgendes: Die Qualität der Systemlanschaft wird mittels Kennzahlen gemessen. Vor und nach jedem Projekt werden diese erhoben, wobei von jedem Projekt verlangt wird, die so gemessene Qualität zumindest nicht zu verschlechtern. Das bedeutet unter dem Strich somit, dass es durch jedes Projekt zu einer schrittweisen Verbesserung kommen sollte. Klingt zunächst einmal nach einer guten Idee, allerdings ist sie aus meiner Sicht in der Praxis völlig unbrauchbar, und zwar aus dem folgenden Grund: Mir ist keine Kennzahl bekannt, welche es durch eine Berechnungsmethode schafft, die Qualität einer Architektur einer verteilten Systemlandschaft abzubilden. Während es für Monolithen durchaus brauchbare Alternativen gibt wie die Relative Average Component Dependency (RACD). Credit Suisse selbst hat die Anzahl der wiederverwendeten Services als Reuse Kennzahl definiert, und Projekte belohnt, die diesen Reuse förderten. Im Kapitel über Architektur erkläre ich aber, warum die Maximierung des Reuse ein typsicher Denkfehler ist. Sie würden sich mit Optimierung dieser Kennzahl nur selber ein Ei legen, da Sie damit automatisch die externen Abhängigkeiten zwischen Ihren Services erhöhen werden. Managed Evolution stellt demnach nur für monolithische Architekturen eine Alternative dar.

1.5.2 Architecture Improvement Method aim42

Wesentlich vielversprechender scheint der aim42 Ansatz[3] von Gernot Starke und Stefan Tilkov zu sein. Abbildung 1.5 gibt Ihnen dazu einen Überblick:

Abbildung 5

Abbildung 1.5

  1. Analysieren Sie das System (analyze) und sammeln Sie die Probleme (collect), die sich im und um das System und dessen Organisation finden. Daraus ergibt sich eine „Issue List“
  2. Jedes Problem wird hinsichtlich seiner einmaligen und/oder wiederholten Kosten bewertet. Das ist die wesentliche Aufgabe der Evaluate-Phase.
  3. Noch beim Sammeln der Probleme suchen Sie nach Maßnahmen und Ansätzen, welche die Probleme oder deren Ursachen lösen könnten (improve). Diese Sammlung bildet dann das „Improvement Backlog“.
  4. Auch Maßnahmen verursachen Kosten. Auch diese sind systematisch zu ermitteln oder zu schätzen.
  5. Das Gegenüberstellen der Kosten von Maßnahmen sowie der Kosten des Problems ist eine wertvolle Hilfe, um beim Priorisieren und Planen der Verbesserungen die richtigen Entscheidungen zu treffen.

1.5.3 Purer Pragmatismus

Wenn Ihre Situation noch relativ überschaubar ist, dann empfehle ich folgendes einfaches Vorgehen:

  1. Gönnen Sie Ihren Designern und Architekten mal etwas Freiraum, und lassen Sie sie ein Architekturmanifest ausarbeiten. Dieses beinhaltet nach welchen Philosophien Strukturen gebaut werden, und welche Arten von Integration es vorrangig geben soll.
  2. Danach eine grobe Vision erstellen, wie die Landschaft strukturiert sein könnte.
  3. Regelmäßig Projekte auswählen, wo es sich lohnt, bei der Entwicklung der jeweils gewünschten Features auch gleich an den betroffenen Stellen die Landschaft in Richtung Zielvision umzubauen.
  4. Mit den Lessons Learned aus den Projekten die Zielvision laufend adaptieren.
  5. Irgendwann in der Zukunft treffen dann IST Situation und Zielvision aufeinander.