Teilnehmer meiner Softwarearchitektur-Seminare fragen mich öfters, welche Werkzeuge sie als Architekt einsetzten sollen und möchten konkreten Empfehlungen dazu. Deshalb möchte ich in diesen Artikel einen Überblick über Tools geben, die meiner Meinung nach Relevanz für die Softwarearchitektur haben.
Werkzeuge für Architekten
Sehen wir uns als erstes verschiedene Kategorien von Werkzeugen an, die wir in der Architektur oft verwenden. Je nach dem, welche Aufgaben die Architektenrolle bei Ihnen beinhaltet, könnte diese Auflistung unvollständig oder überkomplett für Sie sein.
In diesen Abschnitt beschreibe ich kurz, welche Arten von Tools es gibt und wobei sie helfen können.
Anforderungsmanagement
Bevor wir mit dem Entwurf einer Architektur anfangen können, benötigen wir Anforderungen. Daher ist es oft nötig, auch als Architekt beim Anforderungsmanagement mitzuarbeiten. Wir prüfen beispielsweise die technische Machbarkeit von funktionalen Anforderungen, finden Lücken und Randfälle, definieren, präzisieren und operationalisieren Qualitätsanforderungen oder finden die technischen Randbedingungen des Systems.
Bei all diesen Tätigkeiten helfen uns Anforderungsmanagementwerkzeuge. Im einfachsten Fall können Anforderungen in einem Tabellenkalkulationsprogramm wie Microsoft Excel oder Google Sheets geführt werden. Es gibt aber auch spezielle Werkzeuge, die bei der Analyse, Priorisierung und Verifikation der Anforderungen helfen. Auch die Rückverfolgbarkeit von Anforderungen zu Codeänderungen, Tests und Testabdeckung können diese Tools unterstützen.
Diese „ausgewachsenen“ Varianten sind in vor allem für regulierte Branchen, wo zum Beispiel Nachweispflichten herrschen, interessant. In einem Umfeld, in denen keine strikten Vorgaben zu Richtlinien und Nachweise gemacht werden, kann auch ein informellerer Ansatz ohne Einsatz eines Anforderungsmanagementtools ausreichend sein.
Modellierung
Für mich ist Modellierung eine der wichtigsten Arbeitsmethoden in der Softwarearchitektur. Beim Modellieren erstellen wir eine abstrakte Repräsentation der Software (das Model), typischerweise mit Modellierungssprachen wie UML, BPMN oder ArchiMate. Die Modellierungssprache hängt hierbei von der Architekturdomäne ab, die ich modelliere. Für Softwarearchitektur verwende ich in der Regel UML, für die Unternehmensarchitektur ArchiMate und für Geschäftsarchitektur BPMN.
Modellierung unterstützt den Entwurf der Architektur, insbesondere, wenn man einen strukturierten Modellierungsansatz verfolgt. Durch das Modell können automatisch (bzw. mit wenig Aufwand), Diagramme, Dokumentation und teilweise sogar Code erzeugt werden.
Risikomanagement
Das technische Risikomanagement gehört ebenso zu den Aufgaben eines Architekten. Risiken sollten frühzeitig und regelmäßig identifiziert und bewertet werden. Ein Werkzeug zum Risikomanagement hilft beim Auffinden und Verwalten der Risiken. Es können Maßnahmen festgelegt und der Erfolg der Maßnahmen bewertet werden.
Dabei ist es wichtig, vom Risikomanagement auch umsetzbare Aufgaben zu erhalten. Die Umsetzung der Aufgaben inklusiver derer Ergebnisse sollten ebenso im Risikomanagement-Tool abgebildet sein.
Statische Code Analyse
Um quantitative Qualitätsbewertungen durchzuführen, werden Statische Code Analysetools eingesetzt. Diese ermitteln Metriken, basierend auf dem vorhandenen Quellcode. Die Analysen können sowohl automatisiert per Build-Pipeline ausgeführt werden oder auch manuell mittels Ad-Hoc-Analyse.
Da diese Werkzeuge statisch arbeiten, d. h. den Programmcode voraussetzten, sind sie in der Regel beschränkt auf bestimmte Sprachen. Software wie NDepend unterstützt dezidiert nur .NET-Sprachen. SonarQube unterstützt hingegen eine Vielzahl von Sprachen wie Java, C#, Kotlin, JavaScript, PHP, Python, C, C++ und noch weiter. Nichtsdestotrotz ist die Sprachunterstützung bei diesen Programmen immer begrenzt.
Dokumentation
Warum Dokumentation wichtig ist, habe ich an andere Stelle schon erklärt. Wer sich dafür entscheidet, seine Dokumentation nicht direkt aus einem Modell abzuleiten, wird zusätzliche Software zum Schreiben der Dokumentation und für die Diagramme benötigen.
Klassische Vertreter von Dokumentationswerkzeugen sind Textverarbeitungsprogramme wie Microsoft Word oder Google Docs, Wikis und ähnliche Onlinetools oder auch LaTeX. Für Diagramme gibt es ebenso eine Vielzahl an Tools wie diagrams.net oder Lucidchart.
Weitere Tools
Neben diesen Core Tools gibt es noch viele weitere Werkzeuge, die das Leben des Architekten leichter machen können. Eine Versionsverwaltung wie Git, Mercurial oder Subversion hilft uns beim Verwalten von Änderungen unserer Arbeitsartefakte. Darin sollten sich also nicht nur Quellcode, sondern auch Modelle, Diagramme, Dokumentation, Analyseprojekte und alles weitere, was wir als Arbeitsergebnisse erzeugen, befinden.
Zur Überwachung von Produktivumgebungen sind Telemetriedaten äußerst wichtig. Häufig können wir das Verhalten unsers Systems in puncto Last und Performanz nur unter produktiver Verwendung tatsächlich sehen. Telemetriedaten bieten somit wertvolle Informationen, wie gut unser System den Qualitätsanforderungen entspricht. Einen ähnlichen Zweck kann man Mittels dynamischer Analyse, z. B. durch Profiler erreichen.
Schließlich sei noch die Entwicklungsumgebung (IDE) erwähnt. Es soll ja Architekten geben, die tatsächlich programmieren oder zumindest hin und wieder eine neue Technologie ausprobieren. 😉
Meine Toolauswahl
Kommen wir nun zu der Software, die ich für die jeweiligen Aufgabenbereiche verwende. In nachfolgender Tabelle habe ich die wichtigsten Programme aufgeschrieben und für welchen Zweck ich sie einsetze. Die Kreuze in Klammer bedeuten, dass ich das jeweilige Programm nur in Ausnahmefällen für den angegebenen Einsatzzweck verwende.
Sind das Empfehlungen? Es sind in erster Linie die Programme, die ich verwende. Ich bin aber mit allen relativ zufrieden und kann sie daher empfehlen, solange sie in einem ähnlichen Umfang eingesetzt werden, wie ich sie verwende. 😉
Enterprise Architect
Mit Enterprise Architect von Sparx Systems arbeite ich schon seit vielen Jahren und mach damit wahrscheinlich mehr als 50% meiner Architekturarbeit. Ich verwende EA zum Modellieren, für das Anforderungsmanagement und zur Dokumentation. Teilweise betreibe ich auch das Risikomanagement in Enterprise Architect, wobei ich hier häufiger auf Microsoft Excel zurückgreife.
Für so ziemlich jedes Architekturprojekt lege ich ein Modell in EA an, egal ob es sich um ein neues System handelt, für das eine Architektur entwickelt werden muss, oder um eine Bestandssoftware, für die ich eine Architekturanalyse erstelle. Typischerweise modelliere ich die Softwarearchitektur mit UML. Gegebenenfalls wird dieses Modell mit einer Geschäftsarchitektur erweitert, die ich in BPMN modelliere.
Aus dem Modell kann ich automatisch eine Dokumentation erzeugen. Hierbei unterstützt mich das Tool, da ich unterschiedliche Formate erzeugen kann und meine eigenen Vorlagen für verschiedene Dokumentationszwecke erstellen kann.
Enterprise Architect hat eine Perpetual License, die relativ erschwinglich ist. Es gibt unterschiedliche Edition, welche sich im Funktionsumfang unterscheiden. Ich persönlich verwende die Corporate-Edition und kann damit so ziemlich jede meiner Anforderungen gut abdecken. Für größere Teams sind die Floating Licenses interessant, die hier die Lizenz zwischen mehreren Teammitgliedern geteilt werden kann. Für Personen, die Modelle nur ansehen wollen, kann das kostenlose EA Lite verwendet werden.
Archi
Mit Archi können ArchiMate-Modelle erstellt werden. Enterprise Architect kann das zwar auch, aber ich bevorzuge hier einfach Archi, das als Standard im Enterprise Architecture Modelling gilt. Mit Archi können verschiedene Sichten einer Unternehmensarchitektur wie Geschäfts-, Anwendungs- und Technologiesicht. Die Modelle können innerhalb der Software validiert und als HTML oder Bilder exportiert werden.
Archi ist Open Source und kostenlos. Übrigens steht Archi aus diesem Grund auch nicht im ArchiMate Tool Certification Register, obwohl es der de facto Standard für ArchiMate ist. Das Register ist mit 11 Herstellern aber sowieso sehr übersichtlich.
Context Mapper
Context Mapper ist ein Modellierungsframework für Domain-Driven Design (DDD). Ich verwende als Context Mapper, wenn es darum geht, die Domänen und den Bounded Context eines Systems mittels DDD zu modellieren. Nach dem Erstellen der Domänen kann mittels Architectural Refactorings eine iterative Verbesserung der Bounded Contexts durchgeführt werden.
Das Tool kann als Extension für VS Code oder Plugin für Eclipse verwendet werden. Neben Diagrammen in grafischen Formaten kann Context Map auch weitere Artefakte erzeugen. Unter anderem PlantUML-Diagramme oder Microservice Domain Specific Language (MDSL)
Context Mapper ist Open Source und kostenlos.
Microsoft Excel
Excel wird zwar manchmal belächelt, aber es ist ein mächtiges Programm, dass viele Einsatzszenarien abdecken kann. Bei mir kommt Excel vor allem für das Anforderungs- und das Risikomanagement zum Einsatz.
In einer Excel-Tabelle können schnell Anforderungen erfasst werden. Das Format lässt sich gut mit anderen Projektbeteiligten austauschen, da so ziemlich jeder eine Excel-Datei öffnen und bearbeiten kann. Wenn sich im Laufe des Projektes die Notwendigkeit von Anforderungspriorisierung oder Rückverfolgbarkeit ergibt, so lassen sich diese zusätzlichen Informationen sukzessive in die Tabelle einbauen. Gerade im Bereich der Anforderungsanalyse weiß ich diese Flexibilität und Einfachheit zu schätzen.
Auch im Risikomanagement kann Excel gut Dienste leisten. Auch hier sind die Portabilität des Dateiformats und die Flexibilität (wie werden Risiken bewertet) ein großer Vorteil.
Microsoft Excel kann als Stand-Alone-Produkt (einmaliger Kauf) oder als Bestandteil von Microsoft 365 (monatliche Kosten) erworben werden.
NDepend
Um Architekturanalysen durchzuführen, setzte ich bevorzugt NDepend an. Zumindest wenn es sich um .NET-Anwendungen handelt. Mit NDepend können eine Vielzahl von Metriken (Komplexität, Lines-of-Code, Verletzungen von Regeln, etc.) gemessen werden, Abhängigkeiten analysiert und sogar Abschätzungen von technischer Schuld durchgeführt werden. Weiters können Testabdeckungsanalyse für Line Coverage (C0) und Branch Coverage (C1) durchgeführt werden.
NDepend verlangt einmalige Lizenzgebühren. Für den Einsatz auf Build-Maschinen ist aber eine eigene Lizenz notwendig.
SonarQube
Ein weiteres Werkzeug für statische Codeanalyse ist SonarQube. SonarQube setze ich vor allem ein, wenn das zu analysierende Projekt nicht in .NET geschrieben ist. Viele der Funktionen von NDepend finden sich auch in SonarQube wieder.
SonarQube kann in der Cloud (SonarCloud) oder Self-Managed On-Premises betrieben werden. Es hat insofern ein interessantes Preismodell, da hier pro Lines-of-Code (LOC) abgerechnet wird. Für eine gewisse Anzahl von LOC sind jährliche Lizenzgebühren fällig. Öffentliche (Open-Source) Projekte können mit SonarCloud aber immer kostenlos analysiert werden.
Microsoft Word
Zu guter Letzt möchte ich noch Microsoft Word erwähnen. Grundsätzlich erstelle ich meine Dokumentation aus den Architekturmodellen, aber hin und wieder nehme ich manuelle Korrekturen in Word vor. Außerdem verwende ich Word, wenn ich etwas dokumentieren muss, für das es überhaupt kein Architekturmodell gibt. Das ist zwar nur selten der Fall, kommt aber dennoch vor.
Das Preismodell von Word ist ähnlich wie bei Microsoft Excel.
Die richtige Werkzeugauswahl
Die Auswahl der richtigen Werkzeuge ist von vielen Faktoren abhängig, die ich im Rahmen des Artikels nur teilweise beschreiben konnte. Vor dem Anschaffen eines Werkzeugs sollte eine umfassende Werkzeugstrategie erstellt werden. Wie wir gesehen haben, kann ein Programm oft für mehrere Zwecke eingesetzt werden. Eine Werkzeugeinführung bedeutet auch immer Kosten für die Lizenzen und für die Schulungen sowie oft auch eine Anpassung der Arbeitsabläufe.
Ich helfe Ihnen gerne, eine konkrete Evaluierung nach Ihren Bedürfnissen durchzuführen und unterstütze Sie auch beim Einführungsprojekt Ihrer neuen Werkzeug-Suite.
