Carola Lilienthal: Langlebige Software-Architekturen

Carola Lilienthal: Langlebige Software-Architekturen

Carola Lilienthal
Langlebige Software-Architekturen – Technische Schulden analysieren, begrenzen und abbauen

3., überarbeitet und erweiterte Auflage
Dezember 2019, 316 Seiten, Broschur
dpunkt.verlag
ISBN: 978-3-86490-729-6

Informationen zum Buch im Katalog der Deutschen Nationalbibliothek.



Langlebige Software-Architekturen verfolgt die Frage, wie die Architektur einer bestehenden Software visualisiert und verbessert werden kann. Dabei geht die Autorin sehr praxisorientiert vor.

Alles in allem ist Langlebige Software-Architekturen eine zu empfehlende Lektüre zum Thema Software-Architektur, die durch jeweilige Aktualisierungen und Erweiterungen (aktuell 3. Auflage) bestrebt ist aktuell und relevant zu bleiben.


Inhalt

Einleitung

„Softwaresysteme gehören mit Sicherheit zu den komplexesten Konstruktionen, die Menschen erdacht und erbaut haben“ – so fängt Carola Lilienthals Buch Langlebige Software-Architekturen an (S. 1). Software altert, Architektur erodiert, technische Schulden machen die Wartung der Softwareprodukte immer schwieriger und teurer. Nur durch eine saubere Architektur und durch das Vermeiden und Beheben von technischen Schulden können Änderungs- und Erweiterungskosten niedrig gehalten werden – nur dann ist die „Langlebigkeit“ der Software gegeben.

Die Architektur einer Software dient dazu, die Komplexität zu senken. „Leitplanken für die Architektur“ schränken ein und weisen die einzunehmende Richtung (S. 3), entsprechend schreibt die Autorin, dass eines der Ziele des Buches die Identifikation von geeigneten Leitplanken zur Erhöhung der Langlebigkeit von Architekturen sei (S. 3).

In der zweiten Hälfte der Einleitung identifiziert Lilienthal vier Ursachen für technische Schulden und bespricht diese (vgl. S. 7ff):

  • Die Illusion, dass jemand der programmieren kann, gleichzeitig befähigt ist, gute Software zu bauen, ist gefährlich.
  • Software bauen ist ein komplexes Unterfangen mit inhärenten Schwierigkeiten.
  • Die Erosion der Architektur kann sich als schleichender Prozess manifestieren.
  • Manager und Kunden haben kein Verständnis für die Notwendigkeit einer sauberen Architektur, die obendrauf auch noch ständig gewartet werden muss.

Aufspüren von technischen Schulden

Das zweite Kapitel führt im weiteren Verlauf des Buches verwendete Begrifflichkeiten ein und stellt die Software Sotograph der Firma hello2morrow anhand eines Open-Source-Projektes vor. Sotograph ist ein Tool zur visuellen (und automatisierten) Analyse von Architekturen, das extensiv im gesamten Buch Verwendung findet.

Wichtige Begrifflichkeiten im Rahmen der Architekturanalyse sind die des Bausteins, der Soll- und Ist-Architektur. Bausteine werden weiter in

  • Programmierkonstrukte
  • Modellierungskonstrukte und
  • Generierte Konstrukte (durch IDEs und Build-Umgebungen)

unterteilt. Diese Unterteilungen werden ihrerseits weiter in insgesamt neun Kategorien untergliedert.

Architektur in Programmiersprachen

Das dritte Kapitel untersucht wie sich Architektur im Quellcode und in der Organisation der Bausteine manifestiert. Dabei wird für folgende Programmiersprachen: Java, C#, C++, ABAP, PHP und TypeScript jeweils untersucht welche Bausteine die Architektur vorgeben.

Architekturanalyse und -verbesserungen

Das vierte Kapitel beginnt mit einem bemerkenswerten Satz: „Die Architekturanalyse und -verbesserung ist ein Prozess von Menschen mit Menschen“ (S. 61). Dieser Satz ist bemerkenswert, weil viel zu oft die Wichtigkeit des Sozialen beim Erstellen von Software missachtet oder nicht zur Genüge berücksichtigt wird.

Der Autorin ist das Soziale jedoch wichtig und weist auf Schwierigkeiten in Workshops zur Verbesserung der Architektur hin. Der Modularity Maturity Index (MMI), ein selbst entwickelter Index zur Bewertung der Modularität einer Software, wird vorgestellt.

Kognitive Psychologie und Architekturprinzipien

Das Soziale und Menschliche tritt im fünften Kapitel besonders zu Tage. Hier zeigt Lilienthal, dass die Prinzipien, welche die Qualität eines Programms definieren, nicht Selbstzweck sind, sondern durch die kognitive Psychologie begründet sind.

So werden Modularität, die Verwendung von Mustern und hierarchische Strukturierung damit begründet, dass Menschen besser mit Wissenseinheiten (Chunks) arbeiten können, sich einfacher Schemata merken können und besser mit hierarchischen Strukturen als mit nichthierarchischen umgehen können. So werden nach und nach wichtige Prinzipien wie Separation of Concerns, Interface Segregation Principle und Law of Demeter hergeleitet und/oder begründet.

Architekturstile gegen technische Schulden

Logisch auf das Vorhergehende aufbauend werden nun die wichtigsten Architekturstile kurz präsentiert: Schichtenarchitekturen, Microservices und Domain-Driven Design (DDD). Weitere Themen auf die eingegangen wird, sind fachliche und technische Schichtung und Infrastrukturschichten. Hexagonale, Onion und Clean Architecture finden Erwähnung.

Die Autorin geht besonders auf Mustersprachen ein (Werkzeug-Automat-Material-Ansatz und Domain-Driven Design). Richtig eingesetzt sollen Mustersprachen Semantik, Konsistenz, Modularität und Zyklenfreiheit leicht ermöglichen (vgl. S. 108f.). Die qualitätsvolle Architektur vieler der besprochenen Projekte wird auf den richtigen Einsatz von Mustersprachen zurückgeführt.

Muster in Softwarearchitekturen

Das siebte Kapitel vertieft die Thematik der Architekturstile und geht besonders auf die Themen fachliche und technische Schichtung, Monolithen und Microservices und Schnittstellen ein.

Im Unterkapitel Der Wunsch nach Microservices wird die bodenständige Denkweise der Autorin klar ausgedrückt:

Ziele [für den Einsatzes von Microservices], die mir [der Autorin – Anm. des Rezensenten] genannt wurden, sind häufig bessere Skalierbarkeit und eine diffuse Idee von einer besseren Architektur durch Microservices, weil das ja alle Welt gerade macht. Wenn dann noch Themen wie DevOps und automatisierte Deployment-Pipeline hinzukommen, dann haben wir den gesamten Hype beisammen.

S. 140

Ohne diese Themen infrage zu stellen, unterstreicht Lilienthal, dass es ihr um die „Verständlichkeit der Architektur“ gehe (S. 140). Dabei müssen die Voraussetzungen für eine Microservice-Architektur erstmals gegeben sein. Diese werden in diesem Kapitel ebenfalls besprochen.

Mustersprachen – der architektonische Schatz

Die Thematik der Mustersprachen, deren Beschreibung und Diskussion im Kapitel Architekturstile gegen technische Schulden begonnen wurde, wird nun weitergeführt.

Chaos in Schichten – der tägliche Schmerz

Das neunte Kapitel fährt fort mit der Diskussion von Modularisierungsmöglichkeiten und Zyklen. Dabei wertet die Autorin Projekte, die sie beratend unterstützt hat, aus. So stellt sie fest, dass Projekte, die eine Schichtenarchitektur einsetzen eher Zyklen aufweisen als solche, die Mustersprachen verwenden.

Modularität schärfen

Um die Modularität zu verbessern kann auf bestimmte Metriken geachtet werden. So geht dieses Kapitel näher auf Kohäsion, zyklomatische Komplexität, Kopplung und Größe von Klassen und Methoden und auf Beziehungen zwischen diesen ein.

Geschichten aus der Praxis

Das bei weitem längste Kapitel des Buches diskutiert sechs Projekte, welche durch die Autorin im Rahmen von Kundenworkshops analysiert wurden. Alles, was in den vorherigen Kapiteln mehr oder minder theoretisch besprochen wurde, wird nun anhand der sechs Fälle veranschaulicht. Dabei präsentiert Liliental Systeme unterschiedlicher Größen, die in unterschiedlichen Sprachen geschrieben wurden (zwei Java-Systeme, eine Java/C#-Software und jeweils ein C#-, ein C++- und ein ABAP-Programm). Bis auf eins der Systeme ist die Fachlichkeit anonymisiert.

Fazit: der Weg zu langlebigen Architekturen

Das Fazit fasst sehr kurz Möglichkeiten der Überprüfung und Vermeidung von technischen Schulden zusammen und listet weitere Themen, die für einen Architekten wichtig sind, jedoch im Buch nicht behandelt werden.

Analysewerkzeuge

Der Anhang stellt kurz eine Reihe von Analysewerkzeugen, mit welchen die Autorin Erfahrung sammeln konnte, vor. Konkret geht es um Lattix, Sonargraph Architect, Sotograph und SotoArc.

Diskussion

Die Autorin hat sehr viel Erfahrung und ihre Kompetenz ist offensichtlich. Nicht nur weiß sie wie eine „langlebige“ Architektur auszusehen hat, sondern sie weiß auch wieso das der Fall ist. Beides kann sie in ihrem Buch sehr gut vermitteln. Dass sie sich mit ihrer Arbeit identifiziert, ist anzunehmen. Als sie am Anfang der Geschichten aus der Praxis vom „Charm einer Architekturanalyse“ schreibt (S. 215), kann davon ausgegangen werden, dass das keine Floskel ist.

Leser könnten mehr „Theorie“ erwarten: sprich detailliertes Beschreiben von Prinzipien und Mustern. Langlebige Software-Architekturen bietet dies nur in einem begrenzten Umfang an. Ziel ist vielmehr die Frage, wie eine Architektur visualisiert werden kann, wie kann diese von außen betrachtet werden und welche Metriken können als Indikatoren für Güte angewendet werden. Letztendlich geht es darum, wie kann die Komplexität einer Software beherrscht werden. Es handelt sich um ein sehr praktisch orientiertes Buch. Somit kann ich mir gut vorstellen, dass viele Entwickler und auch Architekten durch das Lesen des Buches eine neue Sichtweise auf das Thema Architektur entwickeln können. Eine gewisse Erfahrung wird jedoch vom Leser erwartet.

Lilienthals Schreibstil ist sehr persönlich und sehr direkt. Was nicht per se schlecht ist, kann jedoch gewöhnungsbedürftig sein. Ebenfalls ist das ausschließliche (bis auf ein Open-Source-Projekt) Fokussieren auf Projekte ihrer Kunden eine Schwäche des Buches, vor allem auch weil diese größtenteils vollkommen anonymisiert sind. Eine Analyse von frei verfügbaren Projekten wäre durch die vielleicht nicht immer nachvollziehbaren Intentionen der Entwickler schwieriger gewesen, aber der Leser hätte davon mehr profitieren können, da er im Nachhinein selbst die Zusammenhänge im Code hätte überprüfen können.

Alles in allem ist aber Langlebige Software-Architekturen eine zu empfehlende Lektüre zum Thema Software-Architektur, die durch jeweilige Aktualisierungen und Erweiterungen (aktuell 3. Auflage) bestrebt ist aktuell und relevant zu bleiben.


Zur Autorin

Carola Lilienthal ist Geschäftsführerin der Firma WPS – Workplace Solutions GmbH in Hamburg und hat etwa 25 Jahre Erfahrung als Architektin und Beraterin.

Sie hat an der Universität Hamburg mit der Arbeit Komplexität von Softwarearchitekturen – Stile und Strategien promoviert. Ihre Dissertation kann hier eingesehen werden. Lilienthal ist weiterhin Autorin, Übersetzerin und tritt als Rednerin auf Konferenzen auf.

Quelle: Die Information über die Autorin ist ihrem LinkedIn-Profil entnommen – letzter Zugriff am 18.04.2020.


Folgende Bücher könnten Sie ebenfalls interessieren:

Petre Sora

Petre Soras Interessen sind vielfältig und befinden sich an der Schnittstelle zwischen Mensch und Informationstechnologie. Als studierter Psychologe und Software Engineer war er sechs Jahre als Java-Entwickler in mehreren Unternehmen tätig. Mit der Gründung der Rezensionsplattform nososo hat er sich entschieden eigene Wege zu gehen.

Schreibe einen Kommentar