Die Qvest Digital Architekturleitplanken

Eine gemeinsame Grundlage für Architekturarbeit in Software-Projekten

Die System-Architektur ist ein zentrales Element bei der Entwicklung von Softwaresystemen. Sie definiert die Struktur, die Komponenten, deren Interaktionen und beeinflusst maßgeblich die Entwicklung, den Betrieb und die Wartung des Systems. Um sicherzustellen, dass die Architektur einer Softwarelösung den Anforderungen und Zielen des Kunden entspricht und dabei gleichzeitig flexibel, performant, sicher und wartbar ist, setzen wir bei Qvest Digital auf Architekturleitplanken.

In diesem Artikel erklären wir, was wir bei Qvest Digital unter unseren Architekturleitplanken verstehen, warum wir sie aufstellen und welchen Nutzen wir uns davon versprechen. Wir beschreiben, in welchem Scope die Leitplanken bei uns Anwendung finden und wie sie in die Architekturarbeit integriert werden.

Architektur, die lebt

Die Architekturleitplanken bei Qvest Digital sind projektübergreifende Werte, die eine gemeinsame Grundlage für unsere Architekturarbeit in Projekten liefern sollen. Sie sollen nicht nur aufgeschrieben, sondern auch gelebt werden und bei der Softwareentwicklung im Projektalltag ihre Anwendung finden.

Primär geht es bei den Leitplanken um die Anwendungs- oder System-Architektur, wenngleich dies nicht überschneidungsfrei mit Softwarearchitektur und Enterprise Architektur ist. Während sich die System-Architektur auf die Architektur innerhalb einer Art fiktiven Anwendungsgrenze konzentriert, betrachtet die Enterprise Architektur die Architektur eines großen Unternehmens. Eine solche Organisation ist in der Regel zu groß, um ihre gesamte Software in einer Art zusammenhängender Gruppierung zu subsumieren, so dass eine Koordinierung zwischen Teams mit vielen Codebases erforderlich ist, die isoliert voneinander entwickelt wurden und deren Budgetierung und Benutzer unabhängig voneinander arbeiten.

Die Leitplanken verfolgen keinen Absolutheitsanspruch und passen nie zu 100% zu jedem Projekt. Es sollte aber gut begründet und demnach dokumentiert werden können, warum sie nicht passen oder warum sie nicht berücksichtigt werden können.

Was ist System-Architektur?

Die System-Architektur gibt einem Softwaresystem eine Form und erleichtert die Entwicklung, den Einsatz, den Betrieb und die Wartung des in ihr enthaltenen Softwaresystems. Eine gute Architektur zeichnet sich durch Flexibilität, Kosteneffizienz, Nachhaltigkeit, Performance, Sicherheit, Wartbarkeit, Beherrschbarkeit und Robustheit aus.

Entscheidungen zur Architektur sollten daher anhand von Rahmenbedingungen wie Business-Zielen, Anforderungen und Charakteristiken sinnvoll getroffen und dokumentiert werden. Bei der Architekturarbeit setzen wir moderne Werkzeuge und Methoden ein und haben eine Sammlung an Best Practices entwickelt, um mit Entscheidungen umzugehen.

Integration in die Kundenorganisation

Für Qvest Digital als Dienstleister ist die Integration der Architekturarbeit in die jeweilige Kundenorganisation eine zentrale Herausforderung. Hierbei ist es uns wichtig, dass wir nicht aus dem Elfenbeinturm heraus agieren, sondern eng mit den Entwicklungs­teams und den verantwortlichen Personen unserer Kunden zusammenarbeiten. Dabei haben wir diejenigen im Blick, die die Architekturarbeit nach und mit uns weiterführen und entwickeln werden. Hier können wir gemeinsam Schulungen und Trainings durchführen, um das notwendige Know-how zu vermitteln und die Weiterbildung der Entwicklungs­teams und Verantwortlichen im Kundenunternehmen zu fördern.

Nicht zuletzt lebt eine agile System-Architektur von der Pflege, Weiterentwicklung und – leider unabdingbar – Dokumentation dieser. Hierbei sollte stets von allen Beteiligten darauf geachtet werden, Entscheidungen nicht in Dokumenten zu begraben, sondern dafür sorgen, dass sie aktiv im Projektalltag Anwendung finden. Eine regelmäßige Überprüfung und Aktualisierung der System-Architektur ist ebenfalls empfehlenswert, um sicherzustellen, dass sie immer noch relevant ist und den aktuellen Anforderungen und Rahmenbedingungen entspricht.

Grundkonzepte & Best Practices

Um eine gute Architektur für digitale Plattformen zu entwickeln, gibt es einige grundlegende Konzepte und bewährte Vorgehensweisen, die wir im Folgenden vorstellen möchten. Dabei orientieren wir uns an den Prinzipien des agilen Manifests und betrachten sowohl organisatorische als auch technische Aspekte.
 

Architekturschnitt und Organisationsstruktur

Conway’s Law besagt, dass die Architektur von Systemen stark von der Organisationsstruktur beeinflusst wird, die sie entwickelt. Wenn die Kommunikationsstrukturen in der Organisation nicht berücksichtigt werden, kann es zu Reibungsverlusten, fachlicher Durchmischung und unsauberer Datenarchitektur kommen. Um dies zu vermeiden, müssen wir die Bounded Contexts, also die fachlich abgeschlossene Kontexte verstehen, da sie uns eine klare Abgrenzung zwischen Produkt-Scopes, Teams und letztlich auf technischer Ebene, Self-Contained-Systems beziehungsweise Microservices, ermöglichen. Dies ist eine Methode, die sich für uns bewährt hat, um den Big-Ball-of-Mud™ sowohl auf organisatorischer, als auch auf technischer Ebene aufzulösen oder gar gänzlich zu verhindern.
 

Self-Contained-Systems und Microservices

Bei Self-Contained-Systems und Microservices handelt es sich um fachlich geschnittene Services, die – je nach Anforderung – jeweils eine eigene UI, Domain-Logik und Persistierung besitzen können. Die Kommunikation zwischen den Systemen erfolgt dabei vorzugsweise asynchron. Der Vorteil von Microservices liegt in ihrem starken Fokus auf einer bestimmten Fachlichkeit, die eine einfachere Erstellung von Tests erlauben und aufgrund ihrer Größe im Zweifelsfall geringere Änderungsaufwände nach sich ziehen. Auch die Flexibilität in der Technologieauswahl und die gezielte Skalierbarkeit sprechen für diesen Ansatz. Allerdings erfordern sie auch einen höheren Aufwand bei Infrastruktur, Betrieb sowie Releasemanagement und sind tendenziell anfälliger für die Fallacies of distributed computing.

Um nun nach Conway’s Law und dem Microservice Ansatz einen fachlichen Schnitt von Komponenten zu erreichen, bieten sich Konzepte, wie Strategic- sowie Domain-Driven-Design, als mögliche Methodik an. Dabei müssen die Bounded Contexts fachlich abgeschlossene Kontexte sein, die sowohl organisatorisch als auch technisch voneinander getrennt sind. Dies ermöglicht eine klare Abgrenzung der Verantwortlichkeiten und eine bessere Skalierbarkeit der Systeme. Es ist nicht das Ziel des fachlichen Schnittes, ein quantitatives Mapping zwischen Services und Bounded Context herzustellen. Grundsätzlich ist eine detaillierte Betrachtung und die damit einhergehende technische Entscheidung, wie viele Microservices zur Realisierung der Abläufe innerhalb eines Bounded Context notwendig sind, nicht in der System-Architektur zu verorten. Die System-Architektur verfolgt hingegen das Ziel, die Abgrenzung und Schnittstellen zwischen Bounded Contexts transparent und nachvollziehbar zu machen.
 

Lose vs. harte Kopplung

Sowohl bei den Übergängen zwischen Bounded Contexts, also den jeweiligen Schnittstellen, als auch hinsichtlich der Integration von Bestandssystemen, ist es unabdingbar, dass verteilte Systeme über Protokolle kommunizieren. Hierbei unterscheiden wir zwischen Protokollen mit loser und harter Kopplung. Eine harte Kopplung entsteht, wenn Nachrichten bzw. synchrone Kommunikationsarten verwendet werden, da hierdurch eine implizite Erwartung an den Empfänger entsteht. Durch asynchrone Events hingegen wird eine lose Kopplung erreicht – hierbei wird folglich keine explizite Reaktion oder Vereinbarung zwischen den beteiligten Systemen impliziert. Ein Event ist zunächst eine reine Benachrichtigung über signifikante Änderung innerhalb des Systems, die keine nachgelagerte Reaktion oder gar zwingend einen Empfänger erwartet. Allerdings gilt es zu beachten, dass durch eine lose Kopplung eine transaktionale Sicherheit systemübergreifend nur durch sehr hohen Aufwand zu erreichen ist. Vielmehr empfiehlt es sich die Transaktionsklammern neu zu definieren. Dabei ist eine Transaktion immer dann abgeschlossen, wenn das produzierende System diese für sich beendet und als Event publiziert hat. Es entsteht ein kohärentes Verständnis von Transaktionen, welches es dem Gesamtsystem erlaubt, selbst ohne architektonisch bedingte strikte Konsistenz, Geschäftsprozesse korrekt abzuhandeln. Das eher strategische Konsistenzversprechen der Eventual Consistency, wird häufig als Nachteil der gewählten System-Architektur angesehen, bietet jedoch den besten Kompromiss aus verteilter Last und Datenkonsistenz auf Kosten eines, vorzugsweise kleinen, zeitlichen Versatzes. 

Dies stellt besondere Anforderungen an die Kommunikationsinfrastruktur, welche durch die lose Kopplung zwischen den einzelnen Komponenten das zentrale Rückgrat der System-Architektur übernimmt. Ein robustes, hochverfügbares, skalierbares und performantes System ist dabei unabdingbar. Letztlich gilt es hierbei auch die richtige Technologie für den gewünschten Ansatz einzusetzen. Dabei unterscheiden wir generell zwischen Message Bus, Event Broker und Event Store, welche jeweils unterschiedliche Funktionen erfüllen. Die Hub-and-Spoke-Architektur bietet darüber hinaus die Möglichkeit, die Funktionen der Kommunikationsinfrastruktur zu bündeln und die an sie gesendeten Events oder Nachrichten zu verstehen, sie zu übersetzen und an die entsprechenden Systeme weiterzuleiten beziehungsweise sie für konsumierende Systeme zugänglich zu machen.
 

Enterprise Integration Patterns und Data Mesh

Denkt man diesen kommunikationszentrierten Ansatz weiter, lassen sich daraus gegebenenfalls data-driven Prinzipien erkennen und entwickeln. Im Enterprise Umfeld ist es nicht selten, dass sich IT-Systeme in der Gesamtbetrachtung aus hunderten einzelnen Komponenten zusammensetzen. Dabei trifft man häufig auf eine Mischung aus Custom-Software, aktuellen Third-Party Produkten und Legacy Systemen. Ein Konzept, das uns bei der Integration dieser Umsysteme helfen kann, sind Enterprise Integration Patterns. Diese beinhalten bewährte Muster zur Integration im Enterprise-Kontext und in dezentral angewandter Form, die Grundlage des Trends data-driven Unternehmen nach den Prinzipien von Data Mesh zu organisieren. Auch hierbei geht es um die Organisation von Daten in fachlich abgegrenzten Kontexten, die in größeren Unternehmen, durch einen dezentralen Ansatz, einen flexibleren Umgang mit den Daten in ihrem jeweiligen Kontext erlaubt.

Unser Vorgehen

Besonders beim Onboarding, wie auch während der Laufzeit eines Projekts, ist es notwendig, die Ist-Situation regelmäßig zu prüfen und die Fachlichkeit zu verstehen. Um einen ersten Eindruck über die direkten Handlungsfelder zu gewinnen, haben wir die folgende Checkliste erstellt. Sie orientiert sich an den DORA Research: Four Key Metrics und beleuchtet weitere nicht-funktionale Aspekte, die in bestehenden Architekturen erfahrungsgemäß erste Ansatzpunkte darstellen können:

1. Lead Time: Wie lange dauert es von Commit bis Production?
2. Deploy Frequency: Wie oft wird auf Production deployed?
3. Time to Restore: Wie lange dauert es allgemein, bis ein Service nach einem Problem wieder verfügbar ist?
4. Change Fail Percentage: Wie viel % der getätigten Releases erzeugen Probleme und erfordern Mitigation?
5. Decision Process: Wer trifft zur Zeit Architekturentscheidungen und wie ist das Verfahren dazu?
6. KPIs & Observability: Wie wird Monitoring, Logging und Analytics umgesetzt?
7. Security: Wie wird Sicherheit gewährleistet?
8. Quality: Wie wird Qualitätssicherung durchgeführt?

Dazu gehören Workshops mit (Key-)Usern sowie Stakeholdern und das Nachvollziehen der Business-Prozesse, um zu klären, wer die Datenhoheit hat und wo diese technisch liegt. Event Storming ist dabei eine Methode, die uns unterstützt, komplexe Geschäftsprozesse besser zu verstehen und die fachlichen Zusammenhänge zu visualisieren. Durch das Aufbrechen komplexer Prozesse erhalten wir die Möglichkeit, Verantwortung technisch, wie auch inhaltlich, durch die Entwicklungs­teams und die jeweilige Domäne eigenständig übernehmen zu lassen. Je klarer dabei Aufgabenstellung sowie Zuständigkeitsverstädnis sind, desto verbindlicher können die Beteiligten einer Domäne ein Commitment zu ihrem fachlichen Scope abgeben. Das Prinzip „You build it, you run it“ fördert, unserer Erfahrung nach, darüber hinaus Motivation und Verantwortungsbewusstsein der jeweiligen Entwicklungs­teams. Geknüpft an diese Verantwortung sind nicht nur Entscheidungen, die während der Software-Entwicklung getroffen werden und die Software-Architektur betreffen, sondern auch die nachvollziehbare Dokumentation dieser.

Eine vollständig lückenlose und genaue Dokumentation der Architektur ist ehrlicherweise in der Praxis meist eine Utopie. Vielmehr ist die Architektur-Dokumentation vor allem zur Kommunikation gedacht. Eine High-Level-Übersicht kann dabei bereits helfen, komplexe Zusammenhänge schnell zu erfassen. Das C4-Modell eignet sich für eine solche Übersicht, da es erlaubt, komplexe Zusammenhänge zu abstrahieren und bei Bedarf weiter aufzubrechen. Ein weiteres wirksames Mittel sind Architectural Decision Records (ADR), um Architekturentscheidungen nachzuvollziehen und zu dokumentieren. ADRs können sowohl in der System-Architektur, als auch innerhalb von Entwicklungs­teams zur Dokumentation der Software-Architektur und getroffenen Entscheidungen genutzt werden. Ferner bieten sich Wardley Maps als Methode an, um übergreifende Strategien für digitale Produkte zu entwickeln und können bedingt auch Entscheidungs- wie Dokumentations-Grundlage von System-Architekturen sein. Dem gegenüber steht das eher klassisch orientierte arc42-Konzept, welches sich für uns in der Praxis jedoch gelegentlich als zu statisch erwiesen hat. Ungeachtet des gewählten Formats und unabhängig vom Detail-Level der jeweiligen Architekturentscheidung, sollte der Entscheidungsprozess jedoch immer im Konsensverfahren stattfinden.

Was noch? Ach ja, Security!

In der Regel bauen wir Systeme, die im Internet exponiert sind. Daher müssen wir zu jedem Zeitpunkt unserer Architekturentscheidungen, sowohl innerhalb der System- als auch der Software-Architektur, alle Sicherheitsaspekte berücksichtigen. Dazu gehört natürlich in erster, aber keinesfalls letzter Linie, der Code, den wir selbst produzieren. Abhängigkeiten, Container/VM-Images, die Betriebsumgebung (zur Laufzeit und zum Build-/Deploymentzeitpunkt) müssen dabei genauso berücksichtigt werden und sollen in der Gesamtbetrachtung ein Observe & Respond Vorgehen komplementieren. Tools wie SonarCloud, Dependabot, OWASP Dependency-Check sowie weiteren Static-Analyzers sind dabei inzwischen so salonfähig, dass es für uns in der Regel keine Diskussion mehr wert ist, diese grundsätzlich zu integrieren und wichtige Observationen sowie qualitätssteigernde Maßnahmen im Entwicklungsprozess zu automatisieren. Darüber hinaus gibt es Aspekte, die wir zum Zeitpunkt des produktiven Betriebs sicherstellen und somit bereits zu Beginn der System-Architektur berücksichtigen müssen. Verschlüsselung, besonders auch auf Anwendungsebene hinsichtlich des Datenschutzes, ist die Grundlage vieler Sicherheitsmechanismen. Daraus ergibt sich, dass das Schlüsselmanagement, besonders auch in Cloud-Umgebungen, eine wichtige Aufgabe ist. Allgemein empfiehlt sich das Prinzip des Zero Trust, also dem Misstrauen aller interagierenden Systeme, gekoppelt mit einer Automatisierung der Schlüssel-Generierung sowie ihres Rollouts. Letzteres wird oftmals als interner Walled-Garden missverstanden, der Entwicklungs­teams vom Zugriff auf die Produktionsumgebung ausschließen soll. Vielmehr bietet Zero-Trust jedoch, richtig umgesetzt, eben eine sehr gute Möglichkeit zum sicheren und datenschutzkonformen Umgang mit den Daten der Produktionssysteme. Somit sollen sensible Informationen natürlich auch für Entwicklungs­teams nicht im Klartext einzusehen sein, jedoch in obfuskierter Weise eine Option bieten, wichtige Analysen, Tracing und Debugging dennoch nachvollziehbar durchführen zu können.

Kontinuierliche Wertschöpfung, Effizienz und Nachhaltigkeit

Operational Excellence, beziehungsweise die Wegweisung dahin, ist ein wichtiger Bestandteil unserer Architekturarbeit und bezieht sich auf die Fähigkeit, effektiv, effizient und nachhaltig digitale Plattformen zu betreiben. Wir verstehen es als unsere Aufgabe, Kunden so weit zu begleiten, dass sie ihre Operational Excellence in Eigenregie fortführen und weiterentwickeln können. Dabei betrachten wir kontinuierliche Wertschöpfung, Effizienz und Nachhaltigkeit als holistische Anforderungen, um den Erfolg von digitalen Plattformen langfristig sicherzustellen.

Um die kontinuierliche Wertschöpfung zu gewährleisten, müssen wir – folglich – kontinuierlich und iterativ daran arbeiten, den Wert der digitalen Plattformen unserer Kunden und ihrer Nutzer zu erhöhen. Wir verproben also die Entwicklung neuer Funktionen und Dienste unter Betrachtung der daraus resultierenden Benutzererfahrungen, um den sich ändernden Anforderungen gerecht zu werden, zunächst in kleinen Experimenten. Unsere Architekturleitplanken erlauben diesen Ansatz durch ein sorgfältig ausgewähltes und Test-of-Time erprobtes Vorgehen, die Befähigung zur Selbstorganisation und Verantwortungsübernahme durch die jeweiligen Domänen und ihrer Beteiligten, sowie der technologischen Kapselung von Domänen-Logik in untereinander lose gekoppelten Microservices. Dies erlaubt darüber hinaus, dass unsere Kunden die Wettbewerbsfähigkeit ihrer digitalen Plattformen auf dem Markt aufrechterhalten und ausbauen können.

Effizienz bezieht sich darauf, wie schnell und kosteneffektiv digitale Plattformen betrieben werden können. Wir stellen also mit den Architekturentscheidungen sicher, dass die Systeme auf eine Weise entwickelt werden, die schnellere Bereitstellung und reibungslose Betriebsabläufe beflügeln. Eine Möglichkeit, dies zu erreichen, ist die Automatisierung von Abläufen sowie Infrastruktur inklusive ganzer Umgebungen (Infrastructure-as-Code) und die Belebung von DevOps als kulturelle Praxis. Cloud-native Technologien und SaaS/PaaS Produkte verstehen wir dabei als Bestandteile unserer Toolbox, die wir einsetzen sollten, wenn sie Mehrwert bringen, angemessen sind und die Skalierbarkeit sowie Verfügbarkeit von Systemen erhöhen, ohne dass dies zu hohen Kosten führt.

Nachhaltigkeit ist ein weiterer Kernaspekt der Operational Excellence und ein Wert, der Qvest Digital nicht nur als solches wichtig ist, sondern – unserem eigenen Anspruch nach – Anwendung und Berücksichtigung in unserer Leistung finden muss. Digitale Plattformen müssen umweltfreundlich gestaltet sein und die zur Verfügung stehenden Ressourcen effizient nutzen, wenn wir sie für die heutigen und noch kommenden Anforderungen entwerfen und realisieren wollen. Hierbei kann die Verwendung skalierbarer on-demand Kapazitäten bis hin zur Abbildung von ganzen Features als Cloud-Functions, das Entwerfen von energiesparenden Algorithmen und z.B. im IoT-Kontext die Implementierung von ressourcenschonender, spezialisierter Hardware-Komponenten helfen.

Letztlich erreichen wir eine transparente Operational Excellence durch die Erhebung von Bewegungsdaten der Systeme, Messungen von KPIs und analytischen Auswertungen auf dieser Basis. Dass diese Daten erhoben und in sinnvolle Relation gebracht werden können, sind folglich weitere Anforderungen an die System-Architektur, die es zu berücksichtigen gilt. Für die Umsetzung und Auswertung gibt es eine ganze Reihe an Tools, die uns zielgerichtet unterstützen können. Das Vorgehen dahinter nennt sich FinOps und ist wesentlich größer als sich das in nur wenigen Worten hier fair zusammenfassen ließe. Daher gehts hier zu dem hervorragenden Vortrag: Cloud Observability: Was ist FinOps? von meinem Kollegen Alex!

Recap

Insgesamt zeigt sich für uns immer wieder, dass bedarfsgerechte Architekturarbeit ein entscheidender Erfolgsfaktor für digitale Plattformen und Produkte ist. Richtig umgesetzt und auf die Herausforderung adaptiert, lässt sich so nicht nur ein guter Grundstein für den initialen Erfolg legen, sondern kann durch gelebte Praxis ein Schlüssel zum langfristigen Erfolg sein. Da die Herausforderungen und Anforderungen, die uns im Alltag begegnen, jedoch hoch individuell sein können und sich, wie so vieles, nicht trennscharf in a) oder b)  kategorisieren lassen, finden sich in unseren Architekturleitplanken z.B. keine verbindlichen Technologien, Programmiersprachen, Frameworks oder Datenbanktypen wieder. Dies entspricht auch nicht unserem Anspruch an eine System-Architektur. Vielmehr möchten wir einen Rahmen bieten, in dem diese wichtigen Entscheidungen – empirisch belegt und von den richtigen Personen – getroffen werden können und leiten an, wie dieser Rahmen kontinuierlich an die sich ändernden Bedürfnisse unserer Kunden anzupassen ist – eben, als Leitplanken.