Die Ubiquitous Language der Softwareentwicklung

Die Ubiquitous Language der Softwareentwicklung

Erste Versionen des Cartoons stammen aus den 1960ern. (Illustrator unbekannt)

Feix

Axel Feix

Axel Feix hat langjährige Projekterfahrung als Analyst und Softwarearchitekt. Er unterstützt Kunden als Senior Consultant und Trainer bei der Einführung und Umsetzung von Software-Engineering, Requirements-Engineering, Softwarearchitektur-Management und Architekturdokumentation. Er interessiert sich für was fliegt, alles was man visualisieren und spielen kann, und was die Welt zusammenhält.

Vor vielen Tausend Jahren bestrafte Gott die Menschen in der Stadt Babylon dafür, dass sie sich erdreisteten, einen Turm bis in den Himmel zu bauen. Er sorgte dafür, dass die Menschen sich untereinander nicht mehr verstanden und so musste das Turmbauprojekt eingestellt werden. Seitdem spricht man von der babylonischen Sprachenverwirrung.

Der Turmbau zu Babel als Auslöser der babylonischen Sprachverwirrung

„Ein Redner kann sehr gut informiert sein, aber wenn er sich nicht genau überlegt hat, was er heute diesem Publikum mitteilen will, dann sollte er darauf verzichten, die wertvolle Zeit anderer Leute in Anspruch zu nehmen.“

(Lee Iacocca *1924).

Wenn im IT-Team aneinander vorbeigeredet wird

IT-Teams sind schon ein Volk für sich, und das ist durchaus positiv gemeint. Die ITler bilden oft einen „fachlichen Mikrokosmos“ in einem Unternehmen und bleiben gerne unter sich. Das heißt aber noch lange nicht, dass Entwickler:innen, Softwarearchitekt:innen, Tester:innen, Projektmanager:innen, Scrum Master und Deployment Manager (alle Geschlechter) auch nur ansatzweise eine gemeinsame Sprache sprechen – von Abteilungsleitung, Fachabteilungen und Management einmal ganz abgesehen. Unterschiedliche Ausbildungswege und fachliche Schwerpunkte, aber auch individuelle Unternehmens- und Projekterfahrungen führen in der Regel dazu, dass Fachtermini und Domänenbezeichner nicht durchgängig bekannt sind oder von Mitarbeiter:in zu Mitarbeiter:in anders verstanden werden. Die resultierenden Missverständnisse können gravierende Auswirkungen auf Effizienz und Projekterfolg haben und im Zweifel eine Menge Geld kosten. Was dabei herauskommen kann, sieht man in dem obigen Bild. Aber was tun?

Und die Lösung heißt: Domain-Driven Design (DDD)

Seit Anfang der 2000er-Jahre gibt es mit dem Domain-Driven Design (DDD) eine ganzheitliche Vorgehensweise zur Modellierung komplexer Software. Im DDD geht man dabei von zwei Grundgedanken aus:

  1. Fachlichkeit und Fachlogik sollten den Schwerpunkt im Softwaredesign bilden
  2. Ein Modell der Anwendungsdomäne sollte die Grundlage für den Entwurf komplexer Fachlichkeit bilden

Im Domain-driven Design (DDD) führt die Fachlichkeit und nicht die Technik

Die Anwendungsdomäne soll also die Grundlage für den Softwareentwurf bilden. Um diese adäquat zu beschreiben, sollte eine Ubiquitous Language in allen Stufen der Softwareerstellung, d. h. von der Modellierung über die Implementierung bis zum Softwaretest verwendet werden. Objekte und Beziehungen aus den Objekten und Beziehungen im Domänenmodell finden sich also im Sourcecode und Testcode wieder und alle Projektbeteiligten sprechen innerhalb des Projekts dieselbe (Fach-) Sprache. Diese Sprache wird aber nicht einmalig im Domänenmodell entwickelt und dann überall verwendet. Sie wird evolutionär weiterentwickelt und bei Änderungen in der Implementierung hat dies gegebenenfalls auch Auswirkungen auf das Domänenmodell (und alle anderen Artefakte). Damit ist jeder Stakeholder in der Lage, sich in allen Projektartefakten (Modell, Implementierung, Tests, Datenbank etc.) zurechtzufinden und sich an Diskussionen zu beteiligen.

Wenn Sie mehr zu Domain-driven Design (DDD) lernen möchten

Einige Vorzüge einer gemeinsamen Sprache zur Beschreibung des Problemraums und der Anwendungsdomäne haben Sie jetzt kennengelernt. Wenn Ihnen als Softwarearchitekt:in nun noch das nötige Rüstzeug fehlt, um DDD im Umgang mit Stakeholdern und dem Entwicklungsteam einzuführen, empfehlen wir Ihnen unser 3-tägiges Softwarearchitektur-Training ‚Domain Driven Design (DDD)‘. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture-Advanced Level (CPSA-A ®) anstreben, erhalten Sie mit diesem DDD Training 20 Credit Points im Kompetenzbereich Methodik und 10 Credit Points im Kompetenzbereich Kommunikation.

Was ist Ihre Meinung?

Schon Wilhelm von Humboldt wusste: Die gemeinsame Sprache ist der Schlüssel zur Welt. Wie gehen Sie in Ihren Projekten mit den Fachsprachen der jeweiligen Experten um? Schreiben Sie es uns in die Kommentare. Wir freuen uns auf den Austausch!

Architekturdokumentation – Schluss mit „Das war schon immer so“

Architekturdokumentation – Schluss mit „Das war schon immer so“

Das Dokumentieren einer Softwarearchitektur ist für den Projekterfolg unabdinglich. Entwürfe, Entscheidungen und Lösungen müssen nachvollziehbar und wirkungsvoll festgehalten werden. Hierzu gehört idealerweise auch die Beschreibung der verworfenen Alternativen. Denn es stellt sich die Frage, wer nach einem Monat oder auch länger noch alle Gründe weiß, weshalb man sich nun für die eine oder andere Variante entschieden hat. Oder eben auch gegen die eine oder anderen Variante.

Typische Fragen in Softwareprojekten sind beispielsweise:

„Wie sieht das Schichtenmodell aus?”

„Welche Design Patterns wurden verwendet?”

„Welche externen Webservices werden verwendet?”

„Wieso habt Ihr das so gemacht? Ist das nicht zu kompliziert?”

 

Und wenn die Antworten dann lauten:

„Das war schon so, als ich ins Projekt kam.”

„Es wurde in einem Meeting entschieden.”

„Es gibt keine Dokumentation, weil wir agil vorgehen.”

…dann entfachen immer wieder die gleichen Diskussionen. Durch die Entwürfe, die Diagramme und die Konzepte der Architekturdokumentation sollen allen Projektbeteiligten bessere Antworten auf diese Fragen in Softwareprojekten parat stehen. Eine ausführliche Architekturdokumentation kann also sehr klärend wirken, die Kommunikation unterstützen und Konflikte vorbeugen. Der Softwarearchitekt hat folglich die Aufgabe, eine angemessene Lösung zu entwerfen, um eine Nachvollziehbarkeit und gleichzeitig Lerneffekte zu gewährleisten.

Für alle Arten von Architekturdokumentation gelten daher einige übergreifende Anforderungen und Regeln, die Sie bei der Erstellung solcher Dokumente berücksichtigen sollten. Softwarearchitekten benötigen dabei ein grundlegendes Verständnis der Beschreibung von Softwarearchitekturen. Lernen Sie effektiv und praxisorientiert Softwarearchitekturen zu dokumentieren und zielgruppengerecht zu kommunizieren. Erfahren Sie, wie die Architekturdokumentation zu einem integralen Kommunikations- und Arbeitsmittel wird. Lernen Sie architekturrelevante Einflussfaktoren und zentrale Entscheidungen festzuhalten.

Unser 2-tägiges Softwarearchitektur-Training ‚Architekturdokumentation (ADOC)‘ vermittelt neben fachlichen Aspekten auch die wichtigen organisatorischen und sozialen Faktoren der Architekturdokumentation. Neben den Grundbegriffen der Architekturdokumentation bekommen Sie das Wissen rund um die Bestandteile, Vorgehensmodelle, Werkzeuge, Vorgaben und Bewertung an die Hand.

Am Ende dieses Softwarearchitektur-Trainings haben Sie das Rüstzeug, um die Architekturdokumentation eines mittleren oder großen Systems zu erstellen, zu bewerten und das Vorgehen zur Dokumentation eines solchen Systems zu definieren. Das Softwarearchitektur-Training ‚Architekturdokumentation (ADOC)‘ deckt einen Bereich der methodischen Kompetenzen des CPSA Advanced Levels (CPSA-A) ab und ist entsprechend beim iSAQB lizenziert. Wenn Sie die CPSA-A Zertifizierung anstreben, können Sie sich mit der Teilnahme 20 Credit Points anrechnen lassen.

Hier kommen Sie zu weiteren Informationen und zur Anmeldung.

Bei Fragen beraten wir Sie gerne unter training@itech-progress.com oder +49 621 595702 41

OOP digital 2021 – wir sind dabei!

OOP digital 2021 – wir sind dabei!

 Full Day Tutorial mit Mahbouba Gharbi und Tom Asel
 
 Digitaler Austausch mit unserem Team via 1:1 Chat über Softwarearchitektur, Trainings, Consulting, Projektunterstützung und Karrieremöglichkeiten 
 
 Verlosung eines iSAQB CPSA Trainings Ihrer Wahl über unsere Präsenz im Event Hub
 
 100€ Rabattcode für alle Trainings über unsere Präsenz im Event Hub

Unter dem Motto “Back to the Future” findet die diesjährige OOP rein digital statt und wir sind wie immer mit dabei! Wir freuen uns bereits aus dem Home Office heraus mit Ihnen in den Austausch zu kommen. Sie finden unsere Teammitglieder über den 1:1 Chat oder Sie besuchen ITech Progress und die ITech Academy direkt im Event Hub.

Full Day Tutorial: 
Wardley Maps als Werkzeug in der Architekturanalyse –
Eine Group Mapping Session für Architekten und Entscheider
 
Datum und Uhrzeit:
Mo, 08.02.2021 von 10:00 – 17:00 Uhr
 
Mit:
Mahbouba Gharbi und Tom Asel
 
Publikum:
Maximal 30 Teilnehmer*innen
l
Abstract:

Der Workshop richtet sich sowohl an interessierte Einsteiger:innen als auch an bereits erfahrene Mapper. Im Plenum werden Wardley Maps als Werkzeug in der Toolbox der Software-Entwickler:innen diskutiert und im Rahmen einer ausgiebigen Group-Mapping-Session in der Praxis erprobt. Am praktischen Beispiel der Digitalisierung eines Möbelhauses wird gezeigt, wie Maps dabei helfen, Lagebewusstsein zu schaffen, Risiken zu erkennen und eine Strategie zu entwickeln.

Wir untersuchen die Systemlandschaft, führen eine Architekturanalyse durch und verorten die Ergebnisse wieder auf unserer Landkarte.

Der Workshop zeigt, warum Trägheit ein Unternehmen scheitern lassen kann, wie Softwarearchitektur und Unternehmens-Strategie zusammenhängen und wie Wardley Maps dabei helfen, beides zu kommunizieren.

.
Clean Code als Architekturaufgabe

Clean Code als Architekturaufgabe

Clean Code als Architekturaufgabe – Wer nun fragend zum Himmel oder an die Zimmerdecke schaut, sei an das gleichnamige Buch von Robert Martin erinnert, in dem ein erster zielführender Standard für sauberen Quellcode geschaffen und mit einer Vielzahl sachdienlicher Hinweise zu dessen Strukturierung ausgestattet wurde. Tatsächlich beschreibt Clean Code aber nicht nur eine Arbeitsweise, sondern auch eine Bewusstseinshaltung des Entwicklers dahingehend, sich selbst und Nachfolgende nicht mit faktisch unzureichender Codequalität, unsinnigen Entscheidungen und unpräzisen Designs zu belasten. Der Clean-Code-Entwickler übernimmt Verantwortung nicht nur für das Endprodukt, sondern auch für dessen „inneren Werte“ im Hinblick auf Verständlichkeit und Wartbarkeit.

Zugegeben, das alles bezieht sich auf den Entwickler und seine Arbeit. Es mag deshalb in der Tat verwirren, wenn Architekten angeregt werden, sich mit Clean Code als Verbesserungsansatz in der Softwarearchitektur zu beschäftigen. „Was geht mich der Code an?“ lautet meist die Antwort. „Das ist Sache des Programmierers!“ Die Antwort ist ebenso richtig wie falsch: Mit Clean Code zu arbeiten ist eine strategische Architekturentscheidung, die sinnvollerweise begründet in der Konzeptphase getroffen und vom Management abgesegnet wird. Die Entscheidung wird zumeist im Hinblick auf die langfristige Codequalität und die Weiterentwicklungskosten gefällt, und sie ist anspruchsvoll, wie wir noch sehen werden. Sie kann in einem Projekt eine erhebliche Tragweite entwickeln und Auswirkungen bis hin zur personellen Besetzung der Teams.

Wenn Clean Code eine Architekturvorgabe an ein Projekt ist, liegt sie auch im Verantwortungsbereich des Architekten. Softwarearchitekten in Clean-Code-Projekten sollten deshalb auch in der Lage sein, die Einhaltung der Anforderungen im Projekt zu steuern und den Code auf konsequente Umsetzung zu prüfen, beispielsweise mit Tools wie Sonarqube. Und damit öffnen wir schon mal die ersten beiden Schubladen der Konfliktkommode. Denn zum einen sehen Entwickler die tägliche Codehygiene gerne als einen Teil ihrer Intimsphäre an und verzichten nur zu gerne auf „väterliche“ Kontrollgänge des Architekten. Zum anderen nagt die Umsetzung von Clean Code unaufhörlich speziell an der Ressource, die für den Entwickler ohnehin die knappste ist: Zeit. Zumindest ein leiser Protest im Team scheint damit vorprogrammiert. Aber hatte jemand behauptet, der Job des Softwarearchitekten sei ein leichter?

Es gibt noch eine dritte Schublade, nicht minder relevant: Clean Code als Anforderung muss nicht nur dem Projektteam vermittelt, sondern auch dem Management verkauft werden. Auch das kann durchaus schwierig werden. Moderationsfähigkeit und Überzeugungskraft gehörten deshalb ebenso zum Handwerk des Architekten, wie das methodische und technische Wissen.

Auf dieser Basis stellt sich für uns nicht die Frage, ob Clean Code seinen Platz in einem fortgeschrittenen Architekturtraining haben sollte oder nicht, sondern lediglich, in welchem Umfang und welchem Tiefgang das Thema besprochen gehört. In unserem iSAQB-akkreditierten Training „Evolution und Verbesserung von Softwarearchitekturen (IMPROVE)“ befähigen wir die teilnehmenden ArchitektInnen zur Entscheidungsfindung, ob und wann Clean Code in einem Projekt Sinn ergibt. Weiterhin werden die wesentlichen Grundlagen und Tools sowie weiterführende Literatur vorgestellt, um eine Beschäftigung mit dem Thema über die Schulung hinaus zu ermöglichen.

Prüfungsstress im Projekt: Welche NOTE bekommt meine Architektur?

Prüfungsstress im Projekt: Welche NOTE bekommt meine Architektur?

Der Abnahmetermin für die Software steht bevor und das Review der Softwarearchitekturen sorgt für schlaflose Nächte. Eine Architekturbewertung soll durchgeführt werden um die Stärken und Schwächen der Softwarearchitektur zu ermitteln. Wurden die relevanten Qualitätsmerkmale erfüllt und alle Ziele erreicht?

Grundlegend geht es bei der Architekturbewertung darum, herauszufinden, ob eine Softwarearchitektur die in sie gesetzten Erwartungen erfüllt oder nicht. Was sind die Stärken und Schwächen einer Architektur und welche Risiken und Probleme ergeben sich daraus?

Als Vergleich zur Softwarearchitekturbewertung nehmen wir einmal die Bewertung von sportlichen Leistungen. Genau wie bei der Softwarearchitektur lassen sich auch sportlichen Leistungen je nach Disziplin mehr oder weniger gut beurteilen. Wer läuft schneller? Wer springt höher? Wer wirft weiter? Wer schießt mehr Tore?  Diese Fragen sind noch einfach zu beantworten. In der Softwarearchitektur sind die Fragen natürlich ein wenig anders: Wie viele gefundene Fehler gibt es pro Paket? Wie hoch ist der Resscourcenverbrauch? Wie viel Zeit wird für die Verarbeitung bestimmter Funktionen oder Anwendungsfälle benötigt?

Doch nicht alle Fragen sind immer so leicht zu beantworten. Die Bewertung von Turniertänzern oder Eiskunstläufern ist schon etwas komplizierter und lässt sich nicht nach einfachen Zahlen bemessen, sondern funktioniert nach einem komplizierten Schema. Die Qualität entscheidet!

Wie ist das nun in der Softwarearchitektur? Gibt es hier sowas wie Messlatten und Schiedsrichter? Wie sieht hier das Ergebnis aus? Im Sport ist das klar: Der Gewinner bekommt die Goldmedaille.

  • Wie zuverlässig läuft das System?
  • Wie sicher ist das System?
  • Kann die Software ihr Leistungsniveau unter festgesetzten Bedingungen über einen bestimmten Zeitraum aufrechterhalten?
  • Wie sparsam ist die Software zur Lösung eines festgelegten Problems bezüglich der Ressourcen, Zeitverhalten bei Anfragen und Bearbeitungen sowie Speicherplatz?
  • Wie hoch ist der Aufwand zur Fehlerbeseitigung, zur Umsetzung von Verbesserungen oder zur Anpassung an Umgebungsveränderungen?
  • Ist die Software auch auf anderen Systemen (Hard- und Software) einsetzbar?

In der Softwarearchitektur gibt es verschiedene Methoden und Werkzeuge, die zu unterschiedlichen Zeitpunkten eingesetzt werden können. Bei der Bewertung einer Architektur gibt es jedoch zwei Ansätze: der qualitative Ansatz und der quantitative Ansatz.

 

Qualitativer Ansatz zur Architekturbewertung

Der qualitative Ansatz ermöglicht eine Bewertung nach Beschaffenheit oder Güte der Softwarearchitektur und hilft frühzeitig Risiken zu identifizieren, die die Erreichung der Qualitätsziele gefährden können. Ein Qualitätsmodell (wie z.B. ISO 25010) kann verwendet werden. Das ISO Modell definiert acht Qualitätsmerkmale: Benutzbarkeit, Effizienz, Funktionale Eignung, Kompatibilität, Sicherheit, Übertragbarkeit, , Wartbarkeit und Zuverlässigkeit.

Die qualitative Bewertung sollte jedoch regelmäßig und so früh wie möglich stattfinden. Eine der führenden Methoden im Bereich der Softwarearchitekturbewertung ist ATAM. ATAM seht für Architecture Tradeoff Analysis Method und bezeichnet eine Szenario-basierte Methode zur Bestimmung der Stärken, Schwächen und den getroffenen Kompromissen einer Softwarearchitektur. Ein ATAM-Workshop dauert in der Regel 3 – 4 Tage und wird gemeinsam mit den Stakeholdern durchgeführt.

 

Quantitativer Ansatz zur Architekturbewertung

Der quantitative Ansatz ist eine Bewertung der Artefakte in Zahlen und kann helfen, kritische Teile innerhalb von Systemen zu identifizieren. Im Gegensatz zur qualitativen Bewertung liefert sie keine Aussage über die Funktionsfähigkeit der Software. Zur Bewertung wird eine Reihe von Messungen und Metriken verwendet, wie beispielsweise die Anzahl der geänderten Anforderungen pro Zeiteinheit, die Anzahl der Testfälle, die Anzahl der gefundenen Fehler pro Paket, die Anzahl der neuen Codezeilen oder die Zyklomatische Komplexität. Der Vorteil ist, dass die Messungen automatisierbar sind und leicht wiederholt werden können. Es besteht jedoch auch die Gefahr von Missdeutungen, da ein fachlicher und technischer Kontext benötigt wird, um vergleichbar zu sein. Gesammelte Daten aus Vergleichsprojekten können hierbei hilfreich sein.

Insgesamt gesehen ist die Architekturbewertung ein wichtiges Hilfsmittel zur Bestimmung der Qualität einer Software bei der es aber weniger darum geht die Architektur zu benoten, sondern eher mehr Durchblick zu bekommen.

 

Sie möchten noch mehr erfahren?

Das 2-tägige iSAQB-akkreditierte Training “Architekturbewertung (AWERT)” vermittelt das notwendige Wissen und die Fähigkeiten, um Softwarearchitekturen bewerten zu können. Ziel ist die Beantwortung der Frage: Wie findet man heraus, ob eine Architektur die Erwartungen erfüllt?

Zu den Terminen

Das Doppelpack für die moderne Architektur

Das Doppelpack für die moderne Architektur

Während die Skyline unserer Softwarewelt nach wie vor von Monolithen geprägt ist, hat sich der Trend zu flexiblen Architekturmodellen mit Microservices, Continuous Deployment, DevOps und hohen Automatisierungsgraden auf möglichst allen Ebenen inzwischen durchgesetzt. Und in der Tat: kompaktere, weitestgehend autarke Softwaremodule mit eigenen spezialisierten Teams bieten eine Menge Vorteile – von der Konzeption über Entwicklung und Testen bis in die Wartung. Verbesserte Stabilität, adaptive Reaktion auf veränderliche Anforderungen, Effizienz- und Kostenvorteile in der Weiterentwicklung sind Argumente, bei denen jedes Entscheiderherz höher schlagen sollte.

Aus architektonischer Sicht ist eine flexible Sortwarearchitektur allerdings leichter gesagt, als getan. Welche Methodik ist für mein Projekt die richtige? Anhand welcher Kriterien lassen sich Module zielführend abgrenzen? Wie kann ich von Anfang an vermeiden, dass sich bei zusätzlichen oder sich verändernden Anforderungen mit der Zeit der berühmt-berüchtigte Big Ball of Mud bildet?

Vorteile

  • Fokussierung auf die Fachlichkeit des Unternehmens
  • Vereinfachte Modularisierung in Microservices
  • Verbesserte Stabilität
  • Adaptive Reaktion auf veränderliche Anforderungen
  • Effizienz- und Kostenvorteile

Für viele Softwarearchitekten ist Domain Driven Design (DDD) die Antwort auf diese und andere gängige Fragestellungen im Vorfeld einer flexiblen Architektur. DDD setzt konsequent auf die Fachlichkeit, und die liegt im Business des Unternehmens begründet, nicht im technischen Jargon des Entwicklerteams. Aus dem Business heraus lassen sich bereits in frühen Phasen des strategischen Designs inhaltliche und funktionale Einheiten als Bounded Contexts separieren. Aber auch im taktischen Design können sich sinnvolle Modularisierungsoptionen ergeben. So bildet die Fachlichkeit letztendlich die Basis für die Abgrenzung der Microservices und die Herausbildung dedizierter Teams.

Architekten, die ihr Handwerk in diese Richtung entwickeln möchten, finden in den iSAQB-akkreditierten Trainings Flexible Architektur­modelle, Microservices & Self-Contained Systems (FLEX) und Domain Driven Design (DDD) ein starkes Doppelpack, in denen alle relevanten Grundlagen anschaulich und praxisnah vermittelt werden. In unserer ITech Academy zählt die Kombination von FLEX und DDD bereits seit über zwei Jahr zu den am stärksten nachgefragten, oft und gerne ergänzt durch das Modul Agile Softwarearchitektur (AGILA).