Softwarearchitektur für Dummies

Von Holger Gast

Tragfähige Literatur für Ihre Softwarearchitekturen

Besuchen Sie eine Veranstaltung zu Softwarearchitektur oder stehen Sie in einem Projekt vor Architekturentscheidungen und wollen daher die aktuellen Architekturansätze verstehen? Dann hilft Ihnen dieses Buch. Holger Gast erläutert zunächst die grundlegenden Elemente von Architekturen und führt die technischen Hintergründe aus. Er erklärt Ihnen danach die klassischen Stile und Patterns und geht schließlich auf Cloud-Architekturen ein. Durchgängig legt er den Fokus auf konkrete Softwarestrukturen statt auf Theorie und ermöglicht Ihnen so einen verständlichen und zügigen Einstieg in das Thema.

Sie erfahren

• Wie Sie Entscheidungen zum Aufbau einer Anwendung treffen
• Wann bestimmte Architekturen oder Frameworks für Ihr Projekt geeignet sind
• Welche Herausforderungen Sie bei der Erstellung oder Weiterentwicklung einer Anwendung lösen müssen

• Sprache: Deutsch
• Herausgeber: Wiley
• Erscheinungsdatum: 30. Nov. 2023
• ISBN: 9783527839797

Buchvorschau

Einleitung

Eine Anwendung ohne eine durchdachte Software-Architektur zu entwickeln, ist keine gute Idee. Wenn man ein Gebäude für einen bestimmten Zweck haben will, sagen wir, eine neue Schule, dann geht man ja auch zu einen Architekten, der schon Schulen realisiert hat. Er weiß, wie Schulen genutzt werden und woran man deshalb gleich zu Beginn denken muss, damit am Ende Schüler und Lehrer gern dort sind und mit Freude und Erfolg gelernt wird. Man würde nicht zum lokalen Bauunternehmer gehen, der zufällig die Schule in der Nachbarstadt gebaut hat und sagen: »Du kannst doch Schulen, bau uns auch eine.«

Der Software-Architekt oder die Software-Architektin¹ hat eine genauso spannende Aufgabe wie der Schul-Architekt: Er muss ein guter Techniker sein, damit seine Planungen effektiv implementiert werden können. Er muss für möglichst viele Aufgaben, Probleme und Herausforderungen passende Strategien und Software-Strukturen parat haben. Er muss für das einzelne Projekt strategisch und oft kreativ eine Auswahl treffen und einen Gesamtplan entwickeln. Und schließlich muss er auch noch ausführlich mit den beteiligten Menschen sprechen und ihnen genau zuhören: mit Benutzern, Entwicklern, Projektleitern, Teamleitern, Budgetverantwortlichen und vielen weiteren – denn sie alle haben Erwartungen und Ziele, die in Architektur, Design und Implementierung einfließen.

Klingt ein bisschen kompliziert? Kein Problem, denn Sie haben das richtige Buch in der Hand. Die Rückmeldungen von Studierenden in meinen Vorlesungen und Seminaren haben mich motiviert, immer sehr konkret, mit der Implementierung im Blick, vorzugehen. Vor allem ist es mir wichtig, Technik, Patterns und Strategien nebeneinander zu stellen und ihre Querbeziehungen aufzuzeigen. Denn dann wird es richtig spannend, weil man Alternativen abwägen und Entscheidungen treffen kann, um zu guten Designs und tragfähigen Architekturen zu kommen. Und aus meinen eigenen Software-Projekten in vielen verschiedenen Anwendungsbereichen bin ich sicher: Nichts davon ist »Theorie«, alles wird früher oder später in Ihre eigenen Architekturen einfließen.

Über dieses Buch

Software-Architektur versteht man erfahrungsgemäß am besten anhand von konkreten Aufgabenstellungen und den passenden Lösungen. Deshalb enthält dieses Buch:

Software-Patterns für häufig auftauchende Aufgaben und Herausforderungen

Ziele, Argumente und Strategien zur Auswahl von Patterns und zur Entscheidung zwischen alternativen Lösungen

technische Hintergründe zu Architekturen und Entscheidungen

Sie brauchen das Buch nicht von vorn nach hinten durchzulesen. Jedes Kapitel behandelt diese Punkte abgeschlossen für einen bestimmten Aufgabenbereich. Je mehr Kapitel Sie lesen, desto mehr gewinnen Sie einen Rundumblick und desto mehr Werkzeuge haben Sie zur Verfügung. Aber Sie können natürlich dort beginnen, wo im aktuellen Projekt Fragen auftauchen, oder einfach bei dem Ansatz, der Sie gerade am meisten interessiert.

Konventionen in diesem Buch

Englische Fachbegriffe habe ich beibehalten, wenn es nicht gerade sehr gängige deutsche Entsprechungen gibt. Allerdings habe ich die Rechtschreibung angepasst, um das Lesen zu erleichtern: Nomen sind groß geschrieben und zusammengesetzte Begriffe stehen wie im Deutschen mit Bindestrich statt wie im Englischen in getrennten Wörtern. Beim ersten Auftreten ist ein Fachbegriff kursiv gesetzt, später nicht mehr.

Die meisten Konzepte lassen sich gut mit Beschreibungen und Illustrationen erläutern. Dort, wo es um technische Details geht und Quelltext notwendig wird, ist er in Typewriter-Font gesetzt.

Mit Ausnahme von Implementierungsbeispielen habe ich darauf verzichtet, einzelne Produkte oder Frameworks vorzustellen, weil das leicht wie eine Empfehlung oder Standardlösung wirkt und außerdem schnell veraltet. Die Produktauswahl ist ein wichtiger Teil der Architektur und speziell für jedes Projekt. Mit den Konzepten und Begriffen aus dem Text finden Sie aber leicht immer mehrere Kandidaten und können dann die besprochenen Auswahlkriterien anwenden. Die im Umfang größte Ausnahme hiervon ist Java: Die Plattform und das Ökosystem bieten viele kleine Beispiele unter einem Dach, und weil Sie wahrscheinlich Java schon begegnet sind, finden Sie sich leicht zurecht. Alle gezeigten Mechanismen gibt es analog aber auch in vielen anderen Plattformen.

Was Sie nicht lesen müssen

Die Kapitel sind so geschrieben, dass Sie sie unabhängig voneinander lesen können. Weitgehend können Sie auch bei einzelnen Abschnitten innerhalb des Kapitels einsteigen, wenn Ihnen eine Überschrift mit einem interessanten Begriff ins Auge springt. Allerdings enthält der Text keine Rückwärtsverweise. Damit Sie wissen, was Sie verpasst haben, sollten Sie wenigstens die vorherigen Überschriften im Kapitel kurz überfliegen. Die Stichworte »weiter oben« und »weiter unten« beziehen sich immer auf Abschnitte innerhalb desselben Kapitels. Wenn es zu einem Thema ausführlichere Erklärungen anderswo im Buch gibt, verweise ich auf das jeweilige Kapitel.

Außerdem habe ich zwei Formen von »Abkürzungen zum Ziel« eingebaut, wo die Vorstellung von Patterns oder Argumenten einmal ausführlicher sein muss, damit sie verständlich wird.

Ein separater Abschnitt »Folgerungen für die Architektur« fasst rückblickend über mehrere Abschnitte zusammen, welche Punkte relevant sind, wenn Sie sich fragen, ob der vorgestellte Ansatz für Ihr Projekt sinnvoll sein kann.

Am Ende eines längeren Abschnitts mit eher detaillierten Inhalten fasst ein »Bindfaden«-Symbol, das weiter unten noch gezeigt wird, die Haupteinsicht zusammen.

Törichte Annahmen über die Leser

Weil Sie gerade ein Buch über Software-Architektur anschauen, nehme ich einmal an, dass Sie auf irgendeine Weise mit der Entwicklung von Anwendungen zu tun haben, sei es als Entwickler, Designer, Projektleiter oder Architekt. Wahrscheinlich interessiert Sie mindestens einer der folgenden Punkte:

Sie wollen Entscheidungen zum Aufbau einer Anwendung treffen.

Sie wollen verstehen, ob eine bestimmte Architektur oder bestimmtes Framework für Ihr Projekt geeignet ist.

Sie wollen Hypes und Marketing-Erzählungen rund um Software-Architekturen endlich durchschauen.

Sie wollen als Entwickler so designen und implementieren, dass Sie bestimmte langfristige Ziele erreichen.

Sie wollen als Entwickler eine vorgegebene Architektur verstehen, um sie richtig umzusetzen.

Sie interessieren sich allgemein dafür, welche Herausforderungen man bei der Erstellung oder Weiterentwicklung einer Anwendung lösen muss.

An vielen Stellen versteht man Architektur, vor allem die Entscheidungen, nur, wenn man die Implementierung kurz durchdenkt. Und das tut der Text dann auch. Deshalb nehme ich auch an, dass Sie schon ein wenig Programmiererfahrung mitbringen. Praktische Anwendungen müssen es nicht sein, Praktika oder Übungen in fortgeschrittenen Vorlesungen an der Hochschule oder Universität reichen sicher aus.

Wie dieses Buch aufgebaut ist

Dieses Buch gliedert sich in fünf Teile, die allerdings nicht aufeinander aufbauen, sondern jeweils eigenständige Aspekte von Software-Architektur behandeln.

Teil I: Überblick

Zuerst geht es um einen kurzen Überblick über die Aufgaben von Software-Architektur und die Rolle des Software-Architekten. Die nicht-technischen Überlegungen hinter Architektur-Entscheidungen in Kapitel 2 führen in Seminaren immer zu den spannendsten Diskussionen: Wie entscheiden wir uns zwischen alternativen Lösungen, wenn keine eindeutig besser geeignet ist?

Teil II: Elemente von Architekturen

Der zweite Teil bringt Inhalte, die grundlegend für die später vorgestellten Software-Architekturen sind, aber eigentlich nicht zur Software-Architektur selbst gehören. Sie kommen deshalb normalerweise in separaten Vorlesungen oder Büchern vor. Damit Sie sich das sparen können, habe ich die relevanten Aspekte hier kurz zusammengefasst.

Einigen Raum nehmen technische Grundlagen ein, die bei vielen Architektur-Überlegungen unverzichtbar sind. Hier folge ich der Idee der Mechanical Sympathy, die ursprünglich von einem Rennfahrer formuliert wurde: Man fährt besser Auto, wenn man genau weiß, warum das Auto wie reagiert.

Teil III: Klassische Patterns und Stile

Der dritte Teil stellt klassische Software-Patterns für klassische Aufgabenstellungen vor. Eigentlich ein Muss für jeden Software-Architekten. Ein besonderer Fokus liegt auf der Motivation und Erläuterung der Herausforderungen und auf der Abwägung zwischen alternativen Lösungsmöglichkeiten.

Teil IV: Architekturen für die Cloud

Die Cloud bietet, vor allem durch die Virtualisierung von Servern, ganz neue Möglichkeiten für die Verteilung von Anwendungen auf verschiedene physische Rechner. Verteilte Systeme werden quasi zum Normalfall. Entsprechend brauchen Anwendungen aber auch Strukturen und Mechanismen, um zuverlässig mit den Unwägbarkeiten von verteilten Anwendungen umzugehen. Dazu gibt es verschiedene Architektur-Ansätze.

Teil V: Top-Ten

Die Informatik und die Software-Technik sind sehr schnelllebige Gebiete. Das birgt die Gefahr, dass sich Geschichte wiederholt: im Guten, wenn dieselben Aufgaben mehrmals und vielleicht immer besser gelöst werden. Aber auch im Schlechten, wenn dieselben Sackgassen immer wieder ausgelotet werden, in der Hoffnung, mit neuen Technologien endlich eine Lösung zu finden. Deshalb ist es auch für uns Software-Ingenieure wichtig zu wissen, wo wir herkommen: Was sind die grundlegenden Ideen und Meilensteine? Was war letztlich ein Hype, aber können wir daraus lernen?

Symbole, die in diesem Buch verwendet werden

Einige Absätze sind aus dem Textfluss hervorgehoben, damit sie gleich ins Auge springen.

Hinter dem Bindfaden-Symbol stehen Dinge, die Sie sich merken sollten. Das können Details sein, aber auch zusammenfassende Einsichten, die als Take-Home-Message noch mal eigenständig formuliert sind.

Hier stehen Hinweise, die das Verständnis erleichtern oder Querbeziehungen zu anderen Inhalten zeigen.

Das Warnschild zeigt Fallen an, in die man gedanklich leicht tappt, wenn man einen bestimmten Aspekt übersieht. Oft betrifft das scheinbare Abkürzungen, von denen man erst hinterher sieht, dass es eigentlich Sackgassen sind.

Hier geht es um technische Details, die für das konzeptuelle Verständnis nicht unbedingt notwendig sind.

Die gerade ausgeführten Konzepte brauchen dringend eine Erläuterung. Sie werden daher anhand eines längeren Beispiels nochmals ausführlicher beleuchtet.

Wie es weitergeht

Jetzt sind wir startklar! Sie wissen, was Sie im Buch erwartet und wo Sie was finden.

Sie müssen nur noch entscheiden, wo Sie anfangen wollen zu lesen: Wollen Sie den neuesten Hypes folgen? Dann empfehle ich eines der Kapitel aus Teil IV. Oder wollen Sie erst einmal schauen, was eigentlich wirklich hinter den »normalen« und scheinbar offensichtlichen Patterns wie Layers steckt? Dann fangen Sie mit Kapitel 7 an. Persönlich möchte ich Ihnen ans Herz legen, Kapitel 6 nicht zu lange zu verschieben, denn die Daten sind in vielen Fällen der eigentlich wertvolle Kern der Anwendung und bestimmen den langfristigen Erfolg stark mit.

Wie auch immer Sie sich entscheiden: Ich wünsche Ihnen viel Spaß und gute Erkenntnisse für Ihre nächsten Projekte!

Notiz

1  Der Einfachheit halber benutze ich ab jetzt immer männliche Bezeichnungen. In meinen Seminaren merke ich aber aufgrund der durchdachten Beiträge: Es sollte viel mehr Software-Architektinnen geben!

Teil I

Überblick

IN DIESEM TEIL…

In dieses Buch dreht sich alles um die technische Seite von Software-Architektur – aus dem einfachen Grund, dass meine Studierenden mir später zurückgemeldet haben, dass sie dieser Teil meiner Vorlesungen und Seminare im Beruf am meisten weitergebracht hat. Außerdem ist die Technik einfach unglaublich spannend.

Aber Software-Patterns und -Stile kann man nicht als Kochbuch lesen nach dem Motto: »Wenn Sie einen saftigen Schweinsbraten essen möchten, kochen Sie wie auf Seite 147 beschrieben. Für den aktuell angesagten Grünkernburger nutzen Sie dagegen das Rezept auf Seite 220.« Software-Architekturen werden getrieben vom Projektkontext, in dem sie entwickelt werden, und von den Zielen ganz unterschiedlicher Interessensgruppen. Außerdem müssen Software-Architekten andauernd Entscheidungen treffen, von denen es häufig abhängt, ob diese Ziele erreicht werden – und damit auch, ob das Projekt am Ende erfolgreich ist.

Daher beschäftigt sich der erste Teil mit den – verglichen mit der Technik – scheinbar »weicheren« Faktoren von Software-Architektur, von den verschiedenen Bereichen des Gebiets über die Rolle des Architekten bis hin zu einem geeigneten Mindset, um die notwendigen Entscheidungen zielsicher anzugehen.

Kapitel 1

Wie wir Software-Systeme bauen

IN DIESEM KAPITEL

Die Leistungen von Software-Architektur

Die Rolle des Software-Architekten

Software wird schnell sehr komplex. Sogar wenn die Aufgabe am Anfang einfach aussieht, wird sie später schnell größer, weil im Produktivbetrieb Sonderfälle auftauchen oder die Benutzer von der laufenden Anwendung inspiriert werden, weitere Arbeitsschritte zu digitalisieren. In vielen Fällen ist die Aufgabenstellung aber schon zu Beginn komplex. So oder so brauchen wir einen strategischen Plan für die Entwicklung.

Software-Architektur beschäftigt sich damit, solche strategischen Pläne bereitzustellen und über die Lebensdauer der Software weiterzuentwickeln. In diesem ersten Kapitel schauen wir darauf, was sie dazu alles leisten muss.

Allerdings soll es dabei in den Beispielen nicht schon zu technisch zugehen, sonst müssten Sie ja dauernd vorausblättern in die späteren Kapitel. Stattdessen nehmen wir Beispiele aus einer Metapher: Die Entwicklung einer Software-Anwendung ist in vielen Aspekten ähnlich dem Bau einer Schule. So wie die meiste Software ist eine Schule vor allem ein Funktionsbau. Das, was dort geleistet werden muss, um eine brauchbare Schule zu erhalten, muss in analoger Form auch für Software geleistet werden. Diese Analogie ist tatsächlich nicht ganz neu: Die Patterns-Community sieht sich bekanntlich in der Tradition des Architekten Christopher Alexander und seiner Ideen, wie man zu guten Gebäuden kommt [7].

Aufgaben und Ziele von Architektur

Wir wollen also eine Schule bauen und dafür einen großen Gesamtplan entwerfen. Dieser Plan muss natürlich viele ganz verschiedene Dinge festlegen, von der Anzahl und Größe der Klassenräume über die Lage und Größe des Lehrerzimmers bis zur Einhaltung von Vorgaben zur Beleuchtung. Auch Details wie die Lage und Anzahl von Steckdosen muss der Architekt schon mitbedenken, denn die hängen oft eng mit der geplanten Raumnutzung zusammen. Es wird also ein sehr vielschichtiger Plan.

So wollen wir arbeiten – funktionale Anforderungen

Im Zentrum der Planung stehen natürlich die funktionalen Anforderungen (engl. functional requirements): In der Schule soll vor allem effektiv unterrichtet und gelernt werden. Alles, was dazu notwendig ist, muss in der Schule vorhanden sein. Alle Anforderungen aufzulisten, ist allerdings gar nicht so einfach: Zunächst braucht man Klassenräume mit genug Platz je Schüler, klar. Dann braucht man Flure, die die Klassenräume verbinden, klar. Dann sanitäre Einrichtungen, Lehrerzimmer, einen Raum für Kopierer, klar. Und natürlich auch einen Server-Raum und überall Schächte für Netzwerkkabel. Vielleicht Freiarbeitsflächen für spezielle pädagogische Konzepte. Eine Cafeteria für Nachmittagsunterricht und Ganztagsangebote. Labore für Physik und Chemie. Und und und.

In der Software-Architektur ist eine möglichst vollständige Übersicht über die funktionalen Anforderungen deshalb wichtig, weil sie ja darüber bestimmten, welche Aufgaben die Software technisch lösen muss. Und diese Aufgaben werden auf verschiedene Komponenten oder Module der Software verteilt, sodass indirekt auch die Struktur mitgeprägt wird.

Der Teilbereich des Requirement Engineering kümmert sich um solche Fragen. Es kommt darauf an, zu Beginn des Projekts wirklich gründlich nach Anforderungen zu suchen und in den einzelnen Iterationen während des Projekts schnell auf neue und geänderte Anforderungen aufmerksam zu werden. Einige mögliche Quellen für funktionale Anforderungen sind:

Use-Cases: In welchen Situationen und mit welchem Zweck wollen Benutzer mit dem System interagieren? Was geben sie ein? Welche Reaktionen erwarten sie?

Anwendungsgebiet (Application-Domain): Welche Aufgaben müssen typischerweise von Fachleuten in dem Bereich gelöst werden, in dem die Software eingesetzt werden soll?

Unternehmerische Ziele (Business-Drivers): Warum schreiben wir die Software überhaupt? Welche wirtschaftlichen Vorteile soll sie bringen?

Im Fall der Schule wären die entsprechenden Fragen: Wie wird unterrichtet? Welche Aufgaben haben Lehrer und Schüler im Schulbetrieb? Wie gehen wir mit den steigenden Schülerzahlen nach dem Zuzug vieler Familien um?

Richtig rechnen reicht nicht – nicht-funktionale Anforderungen

Wenn man ein Gebäude einen »funktionaler Zweckbau« nennt, ist damit gemeint: Ist schon okay, aber keiner geht gern hin, und hässlich ist es obendrein. Es reicht nicht, eine Schule zu bauen, in der unterrichtet werden kann, wenn die Randbedingungen nicht stimmen: lange Wege zwischen Räumen, hässliche Betonwände, zugige Fenster, häufiger Ausfall der Heizungsanlage, hohe Betriebskosten …Mit so einer Schule kann niemand etwas anfangen.

Mit der Software ist es genauso: Über die funktionalen Anforderungen hinaus gibt es nicht-funktionale Anforderungen (engl. Non-functional Requirements), die die Software erreichen muss. Weil ihre Bezeichnungen im Englischen fast immer auf »-ility« enden, heißen sie salopp auch »die -ilities«. Wenn es mehr darauf ankommt, die Software selbst zu beschreiben, nutzt man den Begriff nicht-funktionale Eigenschaften (Non-functional Properties). Teilweise kann man die nicht-funktionalen Anforderungen auch als Qualitätsmerkmale (engl. quality attributes) sehen, weil sie etwas darüber aussagen, wie gut die Software die funktionalen Anforderungen umsetzt. Ein alternativer Begriff ist Architectural Characteristics, denn sie werden hauptsächlich durch die gewählte Software-Architektur bestimmt. Damit ist auch klar: Ein Software-Architekt sollte die »ilities« immer genau im Blick behalten.

Eine auch nur halbwegs vollständige Liste anzugeben, dafür reicht der Platz nicht, und es wäre außerdem recht leserunfreundlich, weil trocken. In der späteren Beschreibung der Architektur-Ansätze werden die jeweils relevanten nicht-funktionalen Eigenschaften besprochen. Deshalb hier nur eine grobe Gruppierung mit einigen Beispielen:

Laufzeit-Anforderungen: Availability: Welchen Anteil der Zeit ist das System verfügbar? Können Updates ohne Unterbrechung eingespielt werden? Responsiveness: Wie lange muss ein Benutzer auf eine Reaktion warten? Robustness: Wie gut geht das System mit speziellen Ereignissen wie unerwarteten Eingaben oder Netzwerkausfällen um? Scalability: Wie leicht kann die Anwendung für sehr viel mehr Zugriffe ausgelegt werden?

Strukturelle Anforderungen: Maintainability: Wie leicht können im Nachhinein Anpassungen vorgenommen werden? Extensibility: Wie leicht können neue Funktionen ergänzt werden? Testability: Wie einfach können einzelne Module oder Komponenten oder das Gesamtsystem getestet werden? Reusabilty: Können Teile des Systems in anderen Projekten wiederverwendet werden?

Querschnitts-Anforderungen: Usability: Wie einfach ist das Erlernen und wie sicher und gern arbeiten die Benutzer mit dem System? Privacy: Wie weitgehend können Vorgänge und Daten verborgen werden? Legal Requirements: Beachtet die Software alle relevanten rechtlichen Regelungen? Traceability: Findet man die funktionalen Anforderungen in der Software-Struktur wieder?

Nicht-funktionale Eigenschaften sind deshalb besonders wichtig, weil sie häufig missionskritisch sind und über den Projekterfolg entscheiden: Eine konzernweite Anwendung, die in Tests perfekt funktioniert, aber nicht für die 20.000 weltweit verteilten Benutzer skalierbar ist, ist wertlos. Gleichzeitig bestimmen sie stark die Architektur und Struktur mit, sodass man sie genauso sorgfältig sammeln muss wie die funktionalen Anforderungen. Weil jede Anforderung aber einen gewissen Mehraufwand mit sich bringt und sich die verschiedenen Anforderungen manchmal auch widersprechen, muss der Architekt außerdem sinnvoll priorisieren.

Viele Köche …– Stakeholder

Bei einer Schule wollen alle mitreden: der Kreis wegen der Baukosten, die Stadt wegen der Bebauungspläne, der Bürgermeister wegen des Prestiges, die Schulleitung und Lehrer wegen der Pädagogik, der Hausmeister wegen des Pausenverkaufs …Die Liste ist endlos. Am Ende muss es aber eine einzige Schule für alle geben.

Bei der Software-Erstellung ist es nicht anders: Viele verschiedene Interessengruppen (engl. stakeholder) wollen Einfluss nehmen und die Architektur muss die unterschiedlichen Anforderungen und Wünsche priorisieren und gegeneinander abwägen. Wie findet man aber die relevanten Stakeholder und ihre Anforderungen? Hier sind einige Ansätze:

Verschiedene Benutzergruppen (engl. user groups) haben jeweils eigene Use-Cases und Anforderungen an das System. Mit einer Liste der Benutzergruppen zu starten, ist sicher keine schlechte Idee.

Weil Beschreibungen von Benutzergruppen oft abstrakt bleiben, übersieht man leicht einige ihrer Anforderungen. Eine Persona dagegen ist ein prototypischer (engl. archetypical) Benutzer, den man sehr detailliert und individualisiert beschreibt. Damit werden implizite Erwartungen besser vorstellbar. Verschiedene Personas, die klassisch zu einer Benutzergruppe gehören würden, werden unterscheidbar.

Eine andere Möglichkeit der Konkretisierung sind Key Users. Man wählt pro Benutzergruppe einige Mitarbeiter aus, die etwa besondere Fachkompetenzen haben oder gern strategisch denken und handeln.

Ein Blick lohnt auch auf die mit der Umsetzung des Projekts beschäftigen Personen: Die Entwicklungsteams und das Projektmanagement haben selbst auch Anforderungen, zum Beispiel zuverlässige und motivierende Fortschritte, interessante Aufgaben oder eine verträgliche Arbeitslast.

Die Kunden des Unternehmens, auch wenn sie das System nicht selbst bedienen, sind von seiner Leistung oft indirekt abhängig, zum Beispiel wenn Bestellprozesse mit der Software anders ablaufen oder neue Funktionen bieten.

Das allgemeine Management und die Unternehmensführung haben die wirtschaftliche Seite des Projekts im Blick, also Budget, Kosteneinsparungen oder Gewinn durch die Software. Auch Besitzer und Anteilseigner des Unternehmens, die ja letztlich das Kapital für die Entwicklung bereitstellen, haben Interessen.

Kooperationspartner in anderen Abteilungen oder anderen Unternehmen sind vielleicht auf Schnittstellen oder bestimmte Zugriffswege angewiesen.

Bei einigen Projekten sind Behörden und andere Regulierungsorganisationen beteiligt. Beispielsweise stellt das Finanzamt ziemlich viele Anforderungen an die elektronische Buchhaltung und das Dokumentenmanagement.

Mit einer Empathy Map kann man schließlich die impliziten und emotionalen Erwartungen von identifizierten Stakeholdern herausarbeiten, zum Beispiel um Usability-Faktoren zu identifizieren.

Sie sehen schon: Es ist nicht einfach, schon allein alle Stakeholder eines Projekts zu identifizieren. Am Ende ist es immer eine Person oder Personengruppe, die direkt oder indirekt vom Fortgang und Erfolg des Projekts und der Einführung der Software betroffen ist. Weil das potenziell sehr viele sind, ist das Stakeholder Management oder die Stakeholder Analysis eine ganz eigene und wichtige Aufgabe der Software-Architektur. Ein Projekt kann nicht nur an Technik oder Budget scheitern, sondern auch daran, dass man einen wichtigen Stakeholder oder eines seiner fundamentalen Bedürfnisse übersehen hat.

Wer macht was wann wo? – Software-Strukturen

Wenn wir wissen, welche Aufgaben die Schule übernehmen soll und wer daran welches Interesse hat, geht es an die Gebäudeplanung: Welche Räume sehen wir vor? Wo wird kopiert? Wo werden Chemie-Versuche vorbereitet? Wo läuft der Pausenverkauf? Dabei geht es auch um dynamische Abläufe: Schaffen es die Lehrer in der 5-Minuten-Pause zum Lehrerzimmer und dann in die nächste Klasse? Wie kommen die Schüler trocken zum separaten naturwissenschaftlichen Trakt? Sind die Schulbusse sicher zu erreichen?

Auf der Software-Seite verteilen wir Teilaufgaben auf verschiedene Software-Elemente, wie etwa Komponenten, Module, Services, Klassen oder Methoden. Die gewählte Struktur drückt also ein bestimmtes Problem- und Lösungsverständnis aus, und schon in der Architektur muss man immer mitdenken, wie die Implementierung später aussieht.

Fast noch wichtiger ist aber, dass die Struktur mitbestimmt, welche nicht-funktionalen Anforderungen erfüllt werden. Beispielsweise erhöht sich die Maintainability – also die spätere Änderbarkeit der Software –, wenn wir inhaltlich eng zusammengehörige Funktionselemente in einem Modul zusammenfassen, während unabhängige Elemente auf verschiedene Module aufgeteilt werden. Weil Änderungen häufig nur die Details einzelner Anwendungsfunktionen betreffen, bleiben sie dann auf ein Modul beschränkt. Unter dem Slogan Low Coupling, High Cohesion ist diese Idee weit verbreitet.

Architektur-Patterns und Architektur-Stile fassen Erfahrungen mit bestimmten Aufteilungen von funktionalen Aspekten zusammen. Besonders heben sie hervor, in welcher Situation und unter welchen Voraussetzungen ein Pattern oder ein Stil sinnvoll angewendet werden kann und welche nicht-funktionalen Eigenschaften man dann erwarten darf. Der größte Teil dieses Buchs beschäftigt sich mit Patterns und Stilen, ihrem Aufbau und ihren Konsequenzen.

Wenn wir bei der Schule bleiben, wäre ein Pattern: Sieh auf jedem Stockwerk am Ende eines Ganges Toiletten-Räume vor. Eine Aufteilung von Funktionen wäre: Der Kopierraum ist neben dem Lehrerzimmer, aber wegen der Geräuschentwicklung mit einer Tür abgetrennt.

Die Software-Struktur hat aber nicht nur technische, sondern auch organisatorische Konsequenzen: Jedes Software-Element wird im Normalfall von einem einzelnen Team betreut. Damit gibt die Software-Struktur gleichzeitig die Arbeitsverteilung vor (engl. work breakdown structure). Ein umgekehrtes Phänomen, das Architekten kennen und beachten sollten, ist Conway's Law: Organisationen neigen dazu, die technische Funktionsverteilung entlang ihrer vorhandenen Organisationsstrukturen festzulegen. Teams werden also nicht für ein Projekt neu zusammengestellt, sondern die Software muss so strukturiert werden, dass die bestehenden Teams Teile übernehmen können. Diese politische Entscheidung nimmt natürlich keine Rücksicht auf die funktionalen und nicht-funktionalen Anforderungen, was zum Problem werden kann.

Von Silberkugeln und Sonnenseiten – Forces und Trade-offs

Wenn es die eine, ideale Schule gäbe, wären plötzlich viele Architekten arbeitslos. Dann würde man vielleicht 10–20 Typen für unterschiedliche Schülerzahlen einmal ausarbeiten und immer wieder genau so bauen. Aber weil die lokalen Gegebenheiten, vom Bauplatz bis zum pädagogischen Konzept, jeweils variieren, ist das einfach nicht möglich.

In der Software-Architektur gibt es genauso nie die eine richtige Lösung. Jede Entscheidung für eine bestimmte Struktur zieht beispielsweise unterschiedliche nicht-funktionale Eigenschaften nach sich, und je nach Priorisierung im konkreten Projekt kann die eine oder andere Entscheidung sinnvoller sein. Der Begriff Forces erfasst die verschiedenen Einflüsse, die die Entscheidung in die eine oder andere Richtung bewegen. Die Trade-offs sind die Abwägungen zwischen Einflüssen und Ergebnissen. Manchmal sind die Vorteile einer Lösung besonders stark, dann hat man Glück gehabt und braucht die anderen nur kurz anzudenken – aber das sollte man dann auch tun.

Zwei Schlagworte haben sich für diese Herausforderung eingebürgert:

No Silver Bullet: Man kann nicht erwarten, dass durch irgendeinen Ansatz oder irgendeine Technologie plötzlich wirklich harte Probleme gelöst werden.

No-Free-Lunch-Theorem: Wenn man auf einer Seite Gewinne macht, dann muss man auf der anderen Seite irgendetwas dafür bezahlen.

Ich habe für mich einen dritten Ausdruck gefunden, der mir mehr den Hintergrund ins Gedächtnis ruft:

Komplexität kann man nicht wegzaubern: Wenn ein komplexes Problem gelöst werden muss, dann muss die Software so oder so Mechanismen enthalten, um es zu lösen. Für diese Mechanismen muss dann eben auf die eine oder andere Art bezahlen, egal für welche Lösung man sich am Ende entscheidet.

Für den Architekten ist es wichtig, die Komplexität und die Herausforderungen im Projekt aktiv zu suchen und früh zu identifizieren. Sonst kann er die Forces nicht in seine Überlegungen einbeziehen. Es funktioniert also langfristig nicht, mit zu viel Optimismus nur auf die Sonnenseiten, die offensichtlichen Aufgaben und die »Low-hanging Fruits« zu schauen.

Luftschlösser sind nutzlos – Architektur, Design und Implementierung

Eine Schule mit modernen Glasfronten, großzügigen Räumen, geschwungenen Treppen und einladender Aula sieht natürlich in den computer-gerenderten Ansichten einfach repräsentativ und attraktiv aus. Wenn auch noch die pädogischen Konzepte in flexiblen und die Kreativität anregenden Lernlandschaften umgesetzt sind und nebenbei die neueste Wärmedämmung niedrige Betriebskosten verspricht, dann steht dem Gewinn der Ausschreibung nichts mehr im Wege. Umso ärgerlicher, wenn nachher bei der Ausführung an allen Ecken und Enden auf Kosten der Qualität gespart werden muss und es bei Regen durch das undichte Deckenlicht ins Atrium nicht tröpfelt, sondern gießt.

Eine Software-Architektur bildet die Grundlage für Design und Implementierung. Sie gibt die großen Strukturen vor, innerhalb derer die Entwickler dann Schnittstellen und Klassen ausarbeiten. Wenn diese Strukturen aber gar nicht technisch umgesetzt werden können, weil der Architekt entscheidende Details übersehen hat, führt das zu Mehraufwand für Umarbeitungen. Außerdem ist der Code langfristig weniger wartbar, weil er nur lokal durchdachte Ad-hoc-Strukturen nutzt, die nicht zur dokumentierten Architektur passen. Es ist also die Aufgabe von Architektur, das Design und an missionskritischen Stellen, wenn beispielsweise viele Nutzer einen hohen Durchsatz an Anfragen erfordern, auch die Implementierung bis hin zur Mechanical Sympathy vorauszudenken und zu evaluieren.

Die Rolle des Architekten

Es gibt Architekturbüros, die bauen häufiger Schulen und werden immer angefragt, wenn irgendwo in der Gegend eine neue Schule zu bauen ist. Dann sprechen sie mit allen Beteiligen, bringen ihre eigene Erfahrung ein und legen nacheinander Konzepte, Entwürfe und Werkpläne vor. Auf dieser Grundlage werden dann die einzelnen Gewerke ausgeschrieben und am Ende die Schule gebaut.

Ein Software-Architekt muss natürlich dafür sorgen, dass die Architektur die vorher beschriebenen Aufgaben im Projekt erfüllen kann. Aber wie arbeitet er im Projekt?

Ich bin dann mal weg – die traditionelle Rolle

Im klassischen Wasserfallmodell ist die Rolle des Architekten ganz ähnlich wie beim Schulbau: Er ist dafür verantwortlich, …

die Stakeholder zu identifizieren

deren Anforderungen und Wünsche aufzunehmen und zu analysieren

die umzusetzenden Anforderungen zu definieren und zu priorisieren

eine Gesamtstruktur aus Komponenten und Modulen zu schaffen

die Verbindungen zwischen den Komponenten vorzugeben

die Erreichung der nicht-funktionalen Eigenschaften zu analysieren

die Aufteilung der Arbeit auf Teams zu planen

das Ergebnis dieser Überlegungen präzise festzuhalten und an die Entwickler für die weitere Arbeit zu übergeben.

In diesem Modell läuft also der Informationsfluss nur in eine Richtung: Vom Architekten zu den Entwicklern. Bestenfalls hat er bei seiner Tätigkeit schon zukünftige Änderungen oder Erweiterungen vorausgedacht. In jedem Fall ist aber die Arbeit des Architekten im Wesentlichen getan, sobald das Architektur-Dokument abgenommen ist.

Ich begleite euch bis zum Ziel – die moderne Rolle

Tatsächlich stimmt es nicht, dass der Schularchitekt so vorgeht wie im vorherigen Abschnitt angedeutet. Von einer befreundeten Architektin, die öfter Schulen baut, weiß ich, wie oft sie auf den Baustellen unterwegs ist und dort mit den Handwerkern die Details der Ausführung durchspricht und mit den Plänen abgleicht. Falls möglich führt sie auch noch Änderungen an den Plänen durch, wenn der Bauherr es sich in letzter Minute anders überlegt.

Auch der Software-Architekt bleibt heute im Projekt und hat bis zum Ende eine aktive Rolle.

Er coacht die Teams und überwacht die Umsetzung der Architektur, besonders die Verbindung mit dem Design.

Er nimmt Feedback der Entwickler in die Architektur auf, vor allem, wenn sich durch Design-Entscheidungen der Entwickler Änderungen an der Architektur ergeben.

Er überarbeitet und erweitert die Architektur in agilen Projekten von Iteration zu Iteration und passt sie den neuen Zielen und Priorisierungen an.

Er behält immer ein Gefühl für die Implementierung, um die Auswirkungen seiner Entscheidungen und möglicher Trade-offs zu verstehen.

Der letzte Punkt ist besonders wichtig, weil eine Architektur natürlich auch effektiv umsetzbar sein muss, um Laufzeit und Budget des Projekts einzuhalten. Am einfachsten ist es natürlich, wenn der Architekt Teile des Codes selbst schreibt. Wenn er allerdings zu sehr Mit-Entwickler wird, kann das problematisch sein, denn seine eigentliche Aufgabe, für die er auch den Großteil seiner Zeit aufwendet, ist ja die Architektur und die Kommunikation mit allen Stakeholdern in vielen Meetings. Um eine Balance zu finden, helfen folgende Strategien:

Der Architekt schreibt keinen Code im kritischen Pfad des Projekts. Dieser Code gehört dem Team, damit er weiterentwickelt werden kann, auch wenn der Architekt gerade nicht greifbar ist. Besonders betrifft das zentrale Frameworks, bei denen allerdings die Versuchung besonders groß ist, weil der Architekt sie ja erdacht hat und zu Beginn am besten versteht. Da hilft nur Coaching.

Der Architekt schreibt Proof-of-Concept-Prototypen, mit denen er Architektur- und Design-Entscheidungen validiert. Auch wenn der Code selbst nicht produktiv verwendet wird, sollte er trotzdem eine hohe Qualität haben, weil Entwickler ihn wahrscheinlich als Blaupause nutzen.

Der Architekt schreibt Teile der Business-Logik. Sie ist das tägliche Brot der Entwickler und bestimmt damit den Aufwand und den Projekterfolg maßgeblich mit. Der Architekt sollte daher ein gutes Gefühl dafür haben, wie effektiv sie geschrieben werden kann.

Der Architekt geht in Code-Reviews zusammen mit den Entwicklern größere Teile der Implementierung durch und hört aufmerksam auf ihr Feedback. So bekommt er wenigstens passiv einen Eindruck von der täglichen Arbeit.

Am Ende geht es darum, dass der Architekt Teil des Teams bleibt und einen starken Eindruck davon gewinnt, wie sich Architektur-Entscheidungen auf die Entwicklung tatsächlich auswirken und wie Änderungen der Architektur gefühlte Schmerzpunkte beheben können. Und natürlich ist konkreter Code auch eine sehr direkte Art des Coachings, das zu verbessertem Design und einer klareren Implementierung führt.

Wo Sie mehr lesen können

Einen sehr vollständigen Überblick über die Konzepte, Begriffe und Methoden der Software-Architektur finden Sie in [10]. Das Buch war in den 1990ern eines der Ersten zum Thema und wird seitdem fortlaufend aktualisiert. Einen Hands-on- Überblick aus Sicht eines erfahrenen Architekten gibt [89], sowohl über Konzepte als auch über aktuelle Stile und Patterns. Eine moderne Sicht auf Strategien für Architektur und Design finden Sie in [73]; weil weniger konkrete Software-Strukturen besprochen werden, braucht man ein wenig eigene Entwicklungserfahrung.

Kapitel 2

Das Mindset des Architekten

IN DIESEM KAPITEL

Wie innere Einstellungen Architektur-Entscheidungen beeinflussen

Welche inneren Einstellungen dabei hilfreich sind

Software-Architekten müssen andauernd Entscheidungen treffen, denn es gibt eigentlich nie nur eine Lösung für eine Aufgabenstellung. Die Entscheidungen ziehen sich von den großen Strukturen über die Auswahl von Produkten und Frameworks bis zu Schnittstellen zwischen Komponenten und oft auch in das Design der Komponenten hinein.

Wie wir Entscheidungen treffen, hängt aber oft ganz wesentlich von grundsätzlichen Einstellungen ab, die gar nichts mit der konkreten Fragestellung zu tun haben: Sind wir eher konservativ oder sind wir neugierig und probieren gern neue Wege aus? Wie viel Risiko ist uns ein möglicher Gewinn wert? Tolerieren wir eine längere Durststrecke, wenn wir am Ende eine große Belohnung erwarten? Suchen wir perfektionistisch nach der besten Lösung oder halten wir es eher mit dem Pareto-Prinzip? Lassen wir uns schnell von Ideen begeistern oder sind wir eher skeptisch und warten erst einmal ab, ob sich die Idee bewährt?

Die Einstellungen, mit denen wir Aufgaben angehen, werden gern unter dem Begriff Mindset zusammengefasst. Genauso wenig, wie es in der Software-Architektur die eine »richtige« Lösung gibt, gibt es das eine »richtige« Mindset. Deshalb ist es gut und wichtig, dass in Teams ganz unterschiedliche Charaktere zusammenkommen, um gemeinsam strategische Entscheidungen abzuwägen. Diversity hat auch in der Entwicklung Einzug gehalten. Als Architekt sollte man sich sein eigenes Mindset bewusst machen, um seine eigenen Architektur-Entscheidungen zu hinterfragen und zu bewerten.

Dieses Kapitel sammelt Elemente eines sinnvollen Mindsets für Software-Architekten, die üblicherweise in der Literatur eher zwischen den Zeilen oder in Nebenbemerkungen behandelt werden. Einige der Punkte widersprechen sich. Besser sollte man sagen: Sie balancieren sich so aus, dass sie zusammen eine Lenkung hinbekommen. Neben der eigenen Reflexion helfen die Elemente auch bei der Einschätzung von Informationen, die man zu Architekturen findet: Wenn man sie im Hinterkopf hat, sieht man schneller, welche Punkte eines Autors man wie hinterfragen sollte, um eine ausgewogene Gesamtsicht zu bekommen.

In diesem Kapitel nenne ich Konzepte und Technologien, die später im Buch noch behandelt werden, ausnahmsweise ohne Vorwärtsverweise, damit der Text nicht unleserlich wird. Für den Überblick reicht ein ungefähres Verständnis der Begriffe aus. Wenn es Sie an einer Stelle dringend interessiert, lesen Sie aber gern einmal die Einleitung zum jeweiligen Kapitel oder Abschnitt voraus.

Software im Unternehmen

Software wird eigentlich immer mit einem einzigen Ziel geschrieben: um damit Geld zu verdienen. Das kann direkt durch Lizenzverkäufe oder im Open-Source-Bereich indirekt durch Support-Dienstleistungen passieren. Sehr häufig passiert es aber auch implizit, wenn unternehmensinterne Anwendungen den Umsatz steigern, indem sie Kernprozesse skalierbar machen, oder indem sie Arbeitsabläufe vereinfachen und dadurch die Kosten reduzieren. Wie sich die IT-Spezialisten innerhalb eines Unternehmens wahrnehmen, hat entscheidenden Einfluss darauf, ob das am Ende gelingt. Und das gilt natürlich besonders für Software-Architekten, die durch strategische Entscheidungen wesentlich zum unternehmerischen Erfolg von Software beitragen oder eben nicht.

IT/Business-Alignment

Wenn man mit Software am Ende Geld verdienen möchte, dann muss die Entwicklung von Anfang an den unternehmerischen Wert (engl. business value) der Software im Blick behalten. Und dieser Wert bemisst sich natürlich stark daran, wie das Unternehmen selbst Gewinne erwirtschaftet, oder moderner gesagt: was sein Geschäftsmodell (engl. business model) ist.

Ein Architekt sollte sich deshalb aktiv um diese Fragen Gedanken machen und entsprechend mit der Führungsebene des Unternehmens sprechen. Es reicht nicht aus, die Anforderungen der Fachanwender präzise aufzunehmen und umzusetzen, denn die orientieren sich häufig mehr am aktuellen Zustand und einer bequemen Handhabung als an der Frage, wie das Unternehmen in 3 bis 5 Jahren Geld verdienen wird. Speziell kann es etwa um folgende Fragen gehen:

Welche Funktionalitäten werden priorisiert, um den Markteintritt innerhalb eines bestimmten Zeitfensters zu schaffen?

Welche Teile der Software müssen flexibel gehalten werden, um Wünsche bestimmter Kundengruppen später genau abbilden zu können?

Wie viel sind potenzielle Kunden bereit, für eine bestimmte Leistung zu zahlen, die nur mit Software-Unterstützung angeboten werden kann?

Wie schnell rechnet sich eine bestimmte Investition? Wenn man beispielsweise Teile einer monolithischen Anwendung in Microservices überführt, dann ist das im ersten Schritt sehr aufwendig. Die Auswahl der Teile orientiert sich am unternehmerischen Wert, den der Gewinn an Flexibilität durch separate Services mit sich bringt.

Wie können wir die in Prozessen anfallenden Daten so sammeln und aufbereiten, dass sie unternehmerische Entscheidungen unterstützen?

Es gibt also viel zu bedenken, das über die reine Funktionalität und auch über nicht-funktionale Eigenschaften hinausgeht.

IT als Profit-Center

Lange Zeit waren IT-Abteilungen vor allem Kostenstellen (engl. cost centers): PCs und Großrechner, Netzwerke und Anwendungen waren halt notwendig, um zu arbeiten. Und das muss das Unternehmen dann halt zahlen, so wie es vielleicht die Straßen und Gebäude auf dem Werksgelände instand hält.

Mit der fortschreitendenden Digitalisierung sind IT-Abteilungen mehr und mehr Profit-Center, erwirtschaften also selbst zumindest indirekt Gewinne: Datensammlungen verbessern unternehmerische Entscheidungen, helfen bei der Kundenansprache oder sind vielleicht sogar selbst ein Produkt. Und mit Software skalieren die Kernprozesse des Unternehmens und das treibt den Umsatz. Oder die Unterstützungsprozesse werden effizienter und die Kosten sinken.

Der Software-Architekt sollte sich entsprechend fragen: Mit welchen Funktionen kann meine Anwendung ganz konkret wie viel Geld verdienen? Dabei kann er als Experte oft auch Vorschläge für mögliche Szenarien machen, die die Nicht-ITler der Führungsebene noch gar nicht im Blick hatten.

Die Kosten im Blick

Natürlich ist Software-Entwicklung immer sehr kostenintensiv. Wenn ein Software-Architekt nach der »besten« Lösung für ein Anwendungsproblem sucht, muss er häufig zwischen kurz- und mittelfristigen Kosten und möglichen langfristigen monetären Vorteilen abwägen. Soll er beispielsweise eine Microservice-Architektur aufsetzen, die langfristig eine bessere horizontale Skalierbarkeit bietet, aber durch aufwendigere Entwicklung und komplexes Monitoring kurzfristig höhere Kosten verursacht als ein Monolith? Sollte er in den Betrieb einer Messaging-Infrastruktur investieren, mit dem Ziel, nach und nach die Anwendung als asynchron kommunizierendes reaktives System zu realisieren?

Diese Entscheidungen hängen natürlich davon ab, welche Benutzerzahlen mittel- und langfristig prognostiziert sind und wie wahrscheinlich es ist, dass diese Prognosen tatsächlich eintreffen. Wichtig ist nur: Die entstehenden Kosten sind immer ein entscheidender Aspekt auch in der Abwägung zwischen rein technischen Realisierungsalternativen. Man sollte sie realistisch betrachten, genauso wie man die umsetzbaren nicht-funktionalen Eigenschaften für die verschiedenen Alternativen realistisch betrachtet.

Hinterfragen für Fortschritt

Architekten müssen natürlich im Grunde ihres Herzens Optimisten sein und an den Projekterfolg glauben, sonst könnten sie den Job nicht machen. Auf dem Weg dahin ist aber zu viel Optimismus oder Begeisterung bei einzelnen Architektur-Entscheidungen nicht immer angebracht.

Gesunde Paranoia

Architektur beschäftigt sich häufig mit sehr großen und missionskritischen Anwendungen. Und in diesem Zusammenhang ist die Einstellung, dass eine Software mit 99,99% Zuverlässigkeit doch super ist, oft nicht gut genug: Wenn nach 100.000 Online-Bestellungen beim Jahresabschluss 10 Rechnungen nicht mehr auffindbar sind, weil die Netzwerkkommunikation zwischen Services leider manchmal Probleme macht, dann sind Buchhaltung und Wirtschaftsprüfer in heller Aufregung, weil sie das bei der nächsten Außenprüfung dem Finanzamt erklären müssen.

Daher sollten es Architekten mit Murphy's Law halten und annehmen, dass alles, was schiefgehen kann, auch irgendwann schiefgehen wird. Im Software-Fall kommt noch eine Besonderheit hinzu: Manche Probleme zeigen sich erst mit steigender Auslastung des Systems. Zum Beispiel treten Deadlocks in Datenbanken oft erst bei vielen gleichzeitigen Transaktionen auf oder ein Server-Prozess stürzt plötzlich ab, weil bei vielen gleichzeitigen Anfragen irgendeine Ressource überbelastet wird. Außerdem können Timing-Aspekte dazukommen: Unter Last steigen die Latenz des Netzwerks und die Antwortzeiten einzelner Services, woraufhin andere Teile der Anwendung einen Timeout registrieren und Fehler melden, anstatt Prozesse richtig zu Ende zu führen.

Wie weit man diese Einstellung treiben kann und manchmal sollte, zeigen manche großen Player der Tech-Industrie, die ihre Anwendungen in Test-Setups regelmäßig überlasten oder zufällig einzelne Anwendungsteile zeitweilig abstürzen lassen, nur um zu schauen, wie die Gesamtanwendung darauf reagiert.

Aber diese Einstellung hat natürlich Grenzen, daher geht es eben um gesunde Paranoia: In vielen Bereichen ist vielleicht 99,99% Zuverlässigkeit eben doch ausreichend. Wenn man beispielsweise aus Angst vor der unvollständigen Transaktionalität von NoSQL-Datenbanken den Warenkorb im Onlineshop in einer relationalen Datenbank ablegt, kauft man sich ein unnötiges Bottleneck ein: Wenn in Ausnahmefällen etwas schiefgeht, lädt der Benutzer vielleicht einfach die Seite noch mal, und alles ist wieder in Ordnung. Nur beim rechtsverbindlichen Kauf ganz zum Schluss brauchen wir mehr Zuverlässigkeit, aber das passiert ja nur relativ selten und dann ist auch eine transaktionale Verarbeitung machbar und sinnvoll.

Gesunde Skepsis

In der Architektur gibt es grundsätzlich nicht die eine perfekte Lösung, und Gewinne an einer Stelle muss man fast immer durch Mehraufwand und erhöhte Komplexität an anderer Stelle einkaufen: No Silver Bullet und No Free Lunch eben.

Auf der anderen Seite lebt der Fortschritt der Software-Architektur von begeisterten Fürsprechern neuer Technologien (engl. technology evangelists), die mit einem bestimmten Ansatz in Projekten gute Erfahrungen gemacht haben und diese anschließend verbreiten. Und natürlich stellen Frameworks auf ihren Websites und in zugehörigen Blogs erst einmal die besonderen Leistungen heraus.

Für den Architekten ist es dann nicht immer ganz einfach, den Gewinn eines Ansatzes oder einer Technologie im eigenen Projekt realistisch einzuschätzen. Zum einen werden die Voraussetzungen von Erfolgen nicht immer klar dargestellt, beispielsweise das notwendige Vorwissen oder die Einarbeitungszeit im Team. Zum anderen werden selten die Einschränkungen und die Nachteile, beispielsweise in Form einer höheren Komplexität oder nicht mehr gangbarer klassischer Lösungen, herausgearbeitet.

Wenn man also eine Technologie analysiert und bewertet, sollte man immer skeptisch sein und Aussagen kritisch hinterfragen: Was kostet das scheinbare Free Lunch am Ende im Projekt? Welche Lösungselemente, die man in anderen Ansätzen als gegeben hinnimmt, werden vielleicht gar nicht unterstützt? Manchmal muss man auch mit eigenem Wissen hinter die Marketing-Geschichte schauen. Auf der Website einer NoSQL-Datenbank fand ich beispielsweise die Erklärung, dass die Vermeidung von Redundanz in relationalen Datenbanken vor allem dem teuren Speicher in früheren Zeiten geschuldet ist. Weil das heute natürlich keine Rolle mehr spielt, können wir endlich hochskalierbare NoSQL-Datenbanken nutzen. Aber das ist natürlich Quatsch: Die Redundanzvermeidung zielt vor allem auf Datenkonsistenz und Anomalievermeidung, und wenn man Redundanz zulässt oder sie sogar aus Effizienzgründen erforderlich ist, wird die Anwendungslogik für die Datenverwaltung komplexer.

Eine gesunde Skepsis bei der Technologie- und Framework-Auswahl ist auch deshalb immer angebracht, weil Hype-driven Development häufig in die Sackgasse führt. Die »moderne« Art, Dinge zu tun, ist nicht automatisch besser als die klassische und gut erprobte. Wenn ein Hersteller die FUD-Marketing-Strategie (Fear, Uncertainty, Doubt) bedient, sollte man sich lieber fragen, ob er keine besseren, positiven Argumente hat. Und wenn inhaltlich schwierige Ziele wie Decoupling, Flexibilität und Skalierbarkeit als quasi-automatische Folgen eines Ansatzes propagiert werden, sollte man besonders skeptisch sein.

Pragmatismus

Eine Anwendung ist nie ein Selbstzweck, sondern unterstützt von außen vorgegebene Ziele. Alles, was hilft, diese Ziele schneller und mit geringeren Kosten zu erreichen, ist willkommen. Dabei ist einiger Pragmatismus angebracht, beispielsweise in folgenden Fällen:

Eine etablierte Technologie mit einem großen Ökosystem, mit der sich das Team auskennt, hilft normalerweise mehr als eine moderne, gerade trendende Alternative, mit der das Team erst Erfahrung sammeln muss und von der noch nicht klar ist, ob sie in 5 Jahren noch weiterentwickelt wird.

Microservices skalieren zwar vielleicht langfristig besser und sind auch strategisch flexibler, aber zu Beginn vereinfacht ein Monolith das Deployment und ist auch flexibler, weil man die inneren Strukturen einfacher anpassen kann, ohne gleich Schnittstellen und Protokolle zu überarbeiten.

Wenn ein Ansatz performant genug ist für die erwarteten Nutzerzahlen, kann man ihn nehmen, auch wenn er nicht hochskalierbar ist. Oder wie Donald Knuth es bekanntlich formulierte: Premature optimization is the root of all evil.

Das richtige Werkzeug für den Job ist nicht immer das neueste, hippeste, sondern oft das, mit dem das Team am meisten Erfahrung hat. Die Möglichkeit, verschiedene Technologie-Stacks in verschiedenen Anwendungsteilen einzusetzen, bringt also nichts, wenn das Team so klein ist, dass man keine entsprechenden Experten hat.

Wenn andererseits die bisherigen Ansätze nicht weiterhelfen, muss man eben neue finden. Es darf nicht dazu kommen, wie man es auf Englisch sagt: If all you have is a hammer, everything looks like a nail.

Die Liste ließe sich beinahe beliebig fortsetzen, aber ein erster Eindruck reicht.

Das Not-Invented-Here-Syndrom

Eine besondere Haltung in vielen Entwicklungsteams ist das Not-Invented-Here-Syndrom: Die Teams bevorzugen es, für Teilaufgaben eigene Lösungen zur realisieren, anstatt auf die Suche nach vorhandenen Bibliotheken und Frameworks zu gehen oder auch nur die Lösung eines anderen Teams im gleichen Unternehmen zu übernehmen. Das passiert besonders dann, wenn die Teilaufgabe intellektuell herausfordernd ist und gleichzeitig auf den ersten Blick übersichtlich erscheint.

Im Hintergrund steht häufig die Überlegung, dass die eigene Aufgabe so speziell ist, dass jede fertige Lösung an irgendeiner Stelle die Anforderungen nicht mehr unterstützen wird. Und weil man die Entwicklung des fremden Codes natürlich nicht in der Hand hat, kann man dann nicht selbst eingreifen. Alternativ besteht umgekehrt die Vermutung, dass die eigene Anwendung die Allgemeinheit des Frameworks gar nicht braucht und man mit einer kleineren, speziellen Lösung besser fährt.

Als Software-Architekt sollte man drei Fragen kritisch im Blick behalten:

Sind die Mehrkosten einer Eigenentwicklung für den erwarteten Gewinn wirklich gerechtfertigt?

Ist es zu erwarten, dass das Team neben dem Tagesgeschäft wirklich eine bessere Lösung findet als ein anderes Team, das sich schon ausführlich mit der Thematik auseinandergesetzt hat?

Sind im fertigen Framework, vor allem wenn es weit verbreitet und lange etabliert ist, nicht schon Anwendungsfälle angedacht, die das eigene Team so noch gar nicht im Blick hat?

Alle drei Fragen laufen auf ein weiteres Problem hinaus: Neben den direkten Kosten läuft man schnell in die Gefahr einer Sunk Cost Fallacy: Wenn sich in der Mitte des Projekts herausstellt, dass die eigene Lösung unvollständig ist, hat man schon viel in sie investiert. In dieser Situation neigt man dazu, weiter zu investieren, obwohl es