Softwarearchitektur: Viel harte Arbeit, plus Wissen und Erfahrung

Uwe Friedrichsen ist CTO von codecentric und unterstützt die Kunden in diversen Rollen. Er ist Speaker auf zahlreichen Konferenzen, Autor vieler Fachartikel und Mitglied des iSAQB.

iX: Sie sagen, dass die Entwicklung guter Anwendungen anspruchsvoller denn je geworden ist, aber gleichzeitig behaupten viele Technologieanbieter, dass ihre Lösungen dies einfacher denn je machen. Wie passt das zusammen?

Ich denke, wir müssen zunächst einmal die üblichen Marketingübertreibungen abziehen. Jeder behauptet, seine Produkte seien zumindest revolutionär und würden mit Sicherheit die Welt, wie wir sie kennen, verändern. Der Realitätscheck ergibt jedoch fast immer eine Geschichte, die deutlich weniger spannend ist.

Aber um fair zu sein: Es gibt Fortschritte, und einige der Lösungen bieten interessante, neuartige Ansätze, die es vorher nicht gab. Denken Sie nur an die Entwicklung der Public Cloud seit ihren Anfängen vor 18 Jahren. Es ist faszinierend, welche zusätzlichen Optionen Public-Cloud-Lösungen bieten und wie sie das Design und die Implementierung von Lösungen beschleunigen können.

All diese Entwicklungen haben jedoch ihren Preis. Wir müssen deutlich mehr Optionen als in der Vergangenheit berücksichtigen, die mit unterschiedlichen Kompromissen verbunden sind. Es reicht nicht aus, die Marketingbroschüre zu lesen. Wir müssen auch im Detail verstehen, was die Optionen bieten und wo ihre Grenzen liegen. Wir müssen herausfinden, welche Kombinationen zu dem Problem passen, das wir lösen müssen.

Um die Sache noch anspruchsvoller zu machen, ist heutzutage jedes System – von seltenen Ausnahmen abgesehen – ein verteiltes System. Das bringt komplizierte und schwer zu verstehende Fehlermodi mit sich, die weit über einfache Absturzfehler hinausgehen. Wir müssen über die Auswirkungen der Verteilung nachdenken, darüber, was die Angebote der Toolanbieter leisten können und was nicht.

Welche Themen stehen dabei im Mittelpunkt?

Wir müssen auch über Themen nachdenken wie die mehrschichtige Cloud, mobile Geräte, IoT-Geräte und vielleicht ihre digitalen Zwillinge, Plattformen, den Entwurf guter APIs, Verfügbarkeit in Zeiten von 24x7, echtzeitnahe Informationsverbreitung durch die gesamte Systemlandschaft. Ebenso gilt es die Daten, die mindestens genauso wichtig geworden sind wie Anwendungen, und die Security zu beachten.

Ein weiteres wichtiges Thema ist Nachhaltigkeit in all ihren Dimensionen: ökologische, ökonomische, soziale/menschliche und technische Nachhaltigkeit. Und es gilt zu beachten, wie man die ständig wachsende Komplexität der Systemlandschaft in Schach hält, statt sie mit einer neuen Lösungsidee zu vervielfachen.

Dann müssen wir eine Lösung entwerfen, die all dies berücksichtigt, die zum Problem passt, und sich so gut wie möglich in die bestehende Systemlandschaft einfügt, die den Zeit- und Budgetrahmen einhält, die die beteiligten Personen nicht überfordert und die zumindest offen ist für die wahrscheinlichen künftigen Änderungsanforderungen, die ein hochdynamischer und unsicherer Markt stellt. Und wir haben noch gar nicht über die Macken, Launen und Eigenheiten der beteiligten Menschen gesprochen, über Politik, Überzeugungen und all die Dinge, die unweigerlich mit im Spiel sind, wenn Menschen beteiligt sind.

Software Architecture Gathering

Dieses Jahr findet das iSAQB Software Architecture Gathering 2024 wieder vor Ort statt. Für die internationale Konferenz am 12. und 13. November haben die Veranstalter, International Software Architecture Qualification Board (iSAQB) und iX, das Magazin für professionelle IT, Berlin als Veranstaltungsort ausgewählt. Vor und nach den Konferenztagen gibt es am 11. und 14. November zusätzliche Workshops.

Das Programm der Konferenz bietet 40 englischsprachige Vorträge und vier Keynotes, darunter

• Generative AI Meets Software Architecture
• Secure Architectures for AI-Based Software
• Can We Measure Developer Productivity?
• Modern Architectural Work: From Defining to Enabling
• Make Your Security Policy Auditable
• Domain-Driven Transformation – How to Improve the Structure of Legacy Systems

Uwe Friedrichsen hält auf der Konferenz den Vortrag "Where Do We Go From Here? – Mastering the Changed Needs of Architectural Work" und veranstaltet einen ganztägigen Workshop zum Thema "Architektur-Kickstart".

All das müssen wir berücksichtigen, wenn wir ein neues System entwerfen, und noch viel mehr. Das ist ein kreativer (und oft auch diplomatischer) Akt, bei dem uns alle Lösungen der Technologieanbieter nicht helfen können. Manchmal haben wir Glück und eine solche Lösung passt perfekt zu der gestellten Aufgabe und erleichtert uns tatsächlich die Arbeit. Aber meistens ist es einfach harte Arbeit, kombiniert mit viel Wissen und Erfahrung.

Übrigens: Auch KI wird diese Herausforderung nicht lösen – zumindest nicht in naher Zukunft. Sie mag geeignet sein, uns auf einem niedrigeren Komplexitätsniveau zu unterstützen. Aber das ist ein anderes Spiel und ich denke, es wird noch lange Zeit qualifizierte und erfahrene Menschen brauchen, um es erfolgreich zu spielen.

Die einzige Konstante ist der Wandel. Sind die Dinge wirklich schwieriger geworden oder stehen wir jetzt einfach vor ähnlichen Herausforderungen einer sich entwickelnden technologischen Landschaft wie die Generationen vor uns?

Ich denke, die Antwort auf diese Frage ist zweigeteilt, je nach Perspektive. Wie erwähnt müssen wir heute eine Menge Dinge berücksichtigen, die es vor 20 Jahren einfach noch nicht gab oder für die sich zumindest niemand interessierte. Denken Sie nur an die Cloud, mobile Geräte, die ganze IoT-Bewegung, Big Data, polyglotte Persistenz, den Aufstieg öffentlicher APIs und darauf basierender Plattformen und Marktplätze, maschinelles Lernen, künstliche Intelligenz und all ihre Auswirkungen.

Denken Sie auch an die Auswirkungen der laufenden digitalen Transformation – neuartige IT-gestützte Geschäftsmodelle, die vor 20 Jahren noch undenkbar waren und die wiederum die Art und Weise verändern, wie wir über IT denken müssen. Die Dinge sind definitiv schwieriger geworden.

Andererseits haben sich viele der zentralen Herausforderungen nicht geändert. Wir kämpfen immer noch mit den grundlegenden Konzepten eines guten Softwareentwurfs: Verbergen von Informationen, Trennung von Belangen, hohe Kohäsion und geringe Kopplung. Wir sehen es überall: Gute APIs, die all das umsetzen, sind schwer zu finden.

Die gesamte DDD-Bewegung (Domain-driven Design) kämpft darum, Antworten auf die Herausforderungen zu finden, die wir schon vor mehr als 50 Jahren hatten. Zugegeben, sie liefert eine Menge guter Ideen, Ansätze und Heuristiken. Allerdings findet man in der freien Wildbahn weitaus mehr schlechte Entwürfe, die sich als DDD bezeichnen, als gute.

Hinzu kommt, dass die Abstimmung zwischen Business und IT in den meisten Unternehmen immer noch mangelhaft ist und wir uns schwer tun, gute Modelle für die Zusammenarbeit zu entwickeln, die tatsächlich die gewünschte Wirkung entfalten. Wenn wir die IT aus diesem Blickwinkel betrachten, kommen wir zu dem Schluss, dass unsere Herausforderungen ähnlich sind, nur die Technologie hat sich geändert.

Alles in allem läuft es wohl darauf hinaus: Wir stehen vor neuen Herausforderungen, ohne die alten gelöst zu haben.

Verfügen wir heute über bessere Instrumente oder Methoden zur Bewältigung dieser Herausforderungen als noch vor 20 Jahren?

Unser Instrumentarium – einschließlich der Methoden – hat sich definitiv verbessert. Die Herausforderungen sind jedoch mindestens im gleichen Tempo gewachsen, wenn nicht sogar schneller. Hinzu kommt, dass die Herausforderungen und die Fähigkeiten der Werkzeuge an verschiedenen Stellen unterschiedlich gewachsen sind.

Wenn wir beispielsweise das Schreiben von Code betrachten, verbessert sich das Tooling kontinuierlich. Die Unterstützung, die eine moderne IDE den Entwicklern bietet, ist beeindruckend. Betrachtet man jedoch die Softwarearchitektur und das Design, so ist die Verbesserung der Werkzeuge deutlich geringer, während die Anforderungen massiv gestiegen sind.

Warum gibt es Ihrer Meinung nach überall – von der Softwareentwicklung bis zum Management – so wenig Bewusstsein für die Architekturarbeit, und wie könnten wir diese Situation verbessern?

Ich bin mir nicht sicher, ob ich diese Beobachtung bestätigen kann. Vor zehn bis fünfzehn Jahren hätte ich definitiv zugestimmt. Damals predigten viele agile Rattenfänger die Geschichte, dass Softwareentwicklung keine Architekturarbeit erfordere. Das war jedoch eine Kombination aus falsch verstandener Agilität, einer Gegenbewegung zur übertriebenen Architekturzentriertheit in den 1990er Jahren, einem latenten Konflikt zwischen Architekten und Entwicklern in vielen Unternehmen und einem stumpfen Wunsch nach Popularität und Ruhm der Rattenfänger.

Um die Geschichte kurz zu rekapitulieren, wie ich sie erlebt habe: In den 1990er Jahren waren wir mit einer übermäßigen Architekturzentrierung konfrontiert. Architekten brauchten Monate und Jahre, um übermäßig komplexe Architekturen zu erstellen, die vorgaben, alles zu lösen (was sie aber nie taten). Außerdem verhielten sich viele Architekten sehr arrogant gegenüber allen anderen Beteiligten, insbesondere gegenüber Entwicklern. Es ist mehr als offensichtlich, dass die Entwickler diese Art der Behandlung nicht mochten. Erschwerend kommt hinzu, dass in vielen Unternehmen der Architekt mehr galt (und gilt) als der Entwickler, was die Sache nicht besser macht.

Mit dem Aufkommen der Agilität war die Stunde der Rache gekommen: Architektonische Arbeit wurde für irrelevant erklärt. Die Architektur würde aus der Arbeit der Entwickler hervorgehen. Ein kontinuierlicher Test-, Implementierungs- und Refactoring-Zyklus würde ausreichen, um eine minimale geeignete Architektur zu entwickeln – ohne dass man auf dem Weg dorthin Architekten bräuchte. Und die Rattenfänger schürten die lange unterdrückten Rachegelüste der Entwickler. Infolgedessen war Architekturarbeit eine ganze Weile lang ein Thema von geringem Interesse.

Besteht der Konflikt weiterhin oder hat sich die Wahrnehmung inzwischen geändert?

Nach meinen Beobachtungen hat sich die Wahrnehmung im Laufe der Zeit geändert. Sicher, es gibt immer noch ein paar eingefleischte Lager von dogmatischen "Agilisten", aber die meisten Menschen haben erkannt, dass Testen, Coden und ein bisschen Refactoring allein nicht ausreichen, um eine nicht triviale Anwendung zu implementieren, die die geforderten Qualitätseigenschaften für Laufzeit und Entwicklungszeit aufweist.

Ich glaube, dass die meisten Menschen inzwischen verstanden haben, dass wir explizite architektonische Arbeit benötigen, um die gewünschten Lösungen zu schaffen, die die gewünschten Laufzeit- und Entwicklungszeitqualitätseigenschaften implementieren. Die Menschen haben verstanden, dass sich eine gute Architektur nicht von selbst ergibt, sondern in Form von Leitprinzipien, Strukturen und Einschränkungen festgelegt werden muss, an die sich alle halten.

Natürlich gehen die Auffassungen darüber weit auseinander, wie viel architektonische Arbeit erforderlich ist und wann sie durchgeführt werden sollte. Dass es dafür keine einfache Regel gibt, macht die Sache nicht einfacher. Manchmal müssen wir eine ganze Menge architektonischer Arbeit im Vorfeld leisten. In anderen Situationen können wir mit einem winzigen Teil an Vorarbeit auskommen.

Daher fürchte ich, dass dieser Teil immer eine nicht triviale Diskussion bleiben wird. Der beste Rat, den ich geben kann, ist, die architektonische Arbeit im Hinblick auf den Wert zu betrachten, den sie schafft. Was versuchen wir eigentlich zu erreichen und was müssen wir wann tun, um die gewünschten Ergebnisse zu erzielen? Dies schützt uns vor einer unüberlegten architektonischen Arbeit auf der Grundlage von Gewohnheiten und hilft uns, uns auf die wertschöpfenden Teile zu konzentrieren. Das reduziert meiner Erfahrung nach die Diskussionen darüber, wie viel architektonische Arbeit wir wann leisten müssen, weil die Leute sofort verstehen, welchen Wert sie hat.

Betrachten Sie Ihren "Architektur-Kickstart" als Ausweg für Situationen, in denen uns die Zeit und die Ressourcen für "echte" Architekturarbeit fehlen, oder würden Sie ihn in alle neuen Projekte integrieren?

Der "Architektur-Kickstart" versucht, ein Dilemma zu entschärfen, mit dem viele Architekten konfrontiert sind. Bei den meisten IT-Projekten besteht der Druck, frühzeitig Ergebnisse zu liefern (besser wäre es, einen Mehrwert zu liefern, aber das ist eine andere Geschichte). Das führt oft zu blindem Handeln: Es wird mit dem Programmieren begonnen, ohne zuerst über das Design nachzudenken, nur um schnell einige Punkte von der Implementierungsliste abzuhaken.

Andererseits müssen wir im Vorfeld einige architektonische Arbeiten durchführen, um sicherzustellen, dass wir hinsichtlich der erforderlichen Qualitätseigenschaften der Lösung auf dem richtigen Weg sind. Wir müssen sicherstellen, dass wir uns auf die erforderlichen Leitprinzipien, Einschränkungen und Strukturen geeinigt haben, die für die Implementierung einer Anwendung erforderlich sind, die zur Laufzeit und zur Entwicklungszeit die erforderlichen Qualitätsmerkmale aufweist.

Ohne diese Vereinbarung im Vorfeld ist es wahrscheinlich, dass Teams Software erstellen, die zwar funktional korrekt ist, aber nicht den geforderten Qualitätszielen für die Laufzeit und die Entwicklungszeit entspricht. Mit anderen Worten: Höchstwahrscheinlich entsteht Code, der nicht den Anforderungen entspricht und später stark überarbeitet oder im schlimmsten Fall komplett neu geschrieben werden muss.

Daher müssen wir zumindest ein wenig architektonische Arbeit leisten, bevor wir mit dem Coden beginnen – einfach um das Risiko zu verringern, eine Lösung zu schaffen, die die Aufgabe verfehlt. Wir wollen die minimale gemeinsame Basis schaffen, die wir für unsere Entwicklungsaktivitäten benötigen, um sicherzustellen, dass die verschiedenen Codeteile zueinander passen. Wir wollen sicherstellen, dass wir keine übermäßige Komplexität schaffen, weil jeder Teil seinen eigenen Konventionen folgt und wir am Ende mehrere Lösungen für dasselbe Problem haben. Und wir wollen sicherstellen, dass unser Code die erforderlichen Qualitätseigenschaften implementiert – insbesondere die Laufzeitqualitätseigenschaften, die zur Entwicklungszeit viel zu oft vernachlässigt werden.

Aber wir wollen damit nicht zu viel Zeit verbringen. Wir wissen, dass unser Wissen noch unvollständig ist und wir im Laufe der Zeit lernen und unsere Architektur verfeinern werden. Wir wollen die Falle der "analytischen Lähmung" vermeiden, indem wir versuchen, im Vorfeld eine "perfekte" Lösung zu finden – die niemals perfekt ist. Stattdessen wollen wir so schnell wie möglich so viele Informationen wie möglich sammeln und daraus eine erste sinnvolle Architektur erstellen – gerade genug Architektur, um die notwendige gemeinsame Basis zu schaffen, von der aus wir unsere Implementierung starten können, ohne Gefahr zu laufen, die Aufgabe zu verfehlen.

Darum geht es beim "Architektur-Kickstart". Es handelt sich um eine minimale Anzahl von Aktivitäten, die ich in meinen Projekten als äußerst nützlich empfunden habe. Diese Aktivitäten haben mir geholfen, in sehr kurzer Zeit einige sinnvolle erste Leitprinzipien, Einschränkungen und Strukturen zu entwickeln. Darüber hinaus helfen die Aktivitäten dabei, Übereinstimmung zwischen den verschiedenen Stakeholder-Gruppen zu schaffen, was mindestens genauso wichtig ist wie das Entwickeln einer sinnvollen Anfangsarchitektur.

Daher würde ich es weder als Umgehung noch als ein Muss bezeichnen. Ich denke, es ist ein nützliches Werkzeug, das ein Architekt einsetzen kann, wenn es in die Situation passt. Es ist "echte" Architekturarbeit. Es konzentriert die Arbeit einfach auf das Wesentliche, um schnell loslegen zu können. Ich denke, dass ein schneller Start oft nützlich ist, aber es gibt auch Situationen, in denen andere, ausführlichere Ansätze als der "Architektur-Kickstart" besser geeignet sind. Nennen wir es also einfach ein nützliches Werkzeug für den Werkzeugkasten eines Architekten.

Das Interview führte Lukas Zühl

(rme)