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!

Soft Skills in der IT: Jeder hat sie, fast keiner schöpft ihr volles Potenzial aus

Soft Skills in der IT: Jeder hat sie, fast keiner schöpft ihr volles Potenzial aus

Neben den Hard Skills, also dem fachlichen Know-how, sind auch die richtigen Soft Skills eine wichtige Fähigkeit am Arbeitsplatz. Gerade im Projektmanagement sind “weiche” Fähigkeiten wie Moderation und Empathie entscheidend, da sowohl Projektleiter:innen als auch Softwarearchitekt:innen und -entwickler:innen stets mit anderen Abteilungen verbunden sind und effektiv kommunizieren müssen. In drei Teilen möchten wir Ihnen wichtige Soft Skills an die Hand geben, damit Sie Ihr Kommunikations- und Konfliktmanagement auf ein neues Level bringen! Im ersten Teil geht es um Best Practices in der Kommunikation und Gesprächsführung. Dabei ist es egal, ob sie Java-Entwickler:in, Scrum Master, Manager oder Product Owner (alle Geschlechter) sind: gerade im Hinblick auf agile Vorgehensweisen in der IT ist heute jedes Teammitglied kommunikativ gefordert.

„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).

Kommunikationsfähigkeit: nonverbal und verbal

Die Wirkung der Mimik, Gestik und Körpersprache wird oftmals unterschätzt, obwohl nonverbale Kommunikation mit über 90 % ein wesentlicher, erfolgsabhängiger Bestandteil unseres täglichen Lebens ist. Glaubwürdigkeit entsteht dadurch, dass die verbale und nonverbale Kommunikation miteinander übereinstimmen.

In Bezug auf die Gestik und die dazugehörige Körpersprache ist bei Meetings von mehreren Personen im Projekt darauf zu achten, dass die Positionierung der Teilnehmer:innen auf gleicher Augenhöhe stattfindet. Dadurch wird unnötiges Konfliktpotenzial, das sich aufgrund der ungleichberechtigten Positionierung der Gesprächspartner:innen ergibt, verhindert. Es sollte darauf geachtet werden, den persönlichen Raum aller Person nicht zu verletzen. Wenn Sie mit allen Gesprächspartner:innen an einem Tisch sitzen, achten Sie drauf, dass die relevanten Dokumente in der Mitte liegen. Noch besser ist es, Besprechungen vor einem Whiteboard durchzuführen, da hierdurch die gleiche Augenhöhe garantiert wird. Bei elektronischen Dokumenten sind Beamer und Flipchart als Präsentationsmedien zu bevorzugen.

Gruppengespräche

In der Gruppe zu sprechen, bedeutet auch, die Gruppe in Ihrer Gesamtheit zu integrieren. Wenn Ihnen eine Frage eines Gruppenmitglieds gestellt wurde, antworten Sie bitte immer in die Gruppe hinein. Führen Sie keine Einzelgespräche mit Gruppenmitgliedern. Gruppengespräche zeichnen sich durch Teamfähigkeit aus und das bedeutet konstruktiv zusammenarbeiten, Ideen durchsprechen und Meinungen diskutieren! Neben der Arbeitskoordination können in Gruppensitzungen anstehende Probleme gemeinsam gelöst und allgemein relevante Informationen ausgetauscht werden.

Einzelgespräche

Bei Einzelgesprächen ist es besonders wichtig, die Person direkt gegenüber anzusehen. Bei einer Frage direkten Blickkontakt zu suchen und die Körpersprache seines Gesprächspartners zu beobachten. Die Körpersprache sollte auch vor, während und nach der Antwort intensiv beobachtet werden, denn der Köper lügt nie.

Ein paar Hinweise, wie ein Gespräch gut gelingt:

  • Bereiten Sie sich auf die Inhalts- und Beziehungsebene des Gesprächs gut vor.
  • Behalten Sie das Gesprächsziel immer im Blick.
  • Bringen Sie immer Ihre Wertschätzung zum Ausdruck.
  • Bemühen Sie sich, ihre Gesprächspartner:innen zu verstehen und selbst verstanden zu werden

Stellen Sie Fragen, die das Gespräch vertiefen:

  • Wie kann ich das verstehen?
  • Was kann ich mir konkret darunter vorstellen?
  • Warum ist das so?
  • Klären Sie sofort Unklarheiten.
  • Benutzen Sie eine klare und anschauliche Sprache mit Beispielen.
  • Lassen Sie sich nicht unterbrechen, aber unterbrechen Sie einseitige Monologe.
  • Fassen Sie sich kurz!

Aktives Zuhören

Das aktive Zuhören ist eine zentrale Gesprächsführungstechnik, um von der Empfängerseite aus das Gespräch zu verbessern. Aktives Zuhören ist ein Basic für alle Softwarearchitekt:innen. Es hilft, Vertrauen aufzubauen, Missverständnisse zu vermeiden und durch non-direktives Feedback zu lernen. Aktives Zuhören zeichnet sich durch die offene und empathische Grundeinstellung, das authentische und gleichbleibende Auftreten und durch die positive Bewertung des Gesprächspartners oder der Gesprächspartnerin aus. Dabei wird nach Carl R. Rogers das Verstehen des Sprechers unterstützt durch:

  • Auf das Gegenüber einlassen, konzentrieren und dies durch die eigene Körperhaltung ausdrücken
  • Mit der eigenen Meinung zurückhaltend umgehen
  • Nachfragen bei Unklarheiten
  • Zuhören heißt nicht gutheißen
  • Pausen sind auszuhalten, sie können ein Zeichen sein für Unklarheiten, Angst oder Ratlosigkeit
  • Auf die eigenen Gefühle achten
  • Die Gefühle des Gegenübers erkennen und ansprechen
  • Bestätigende kurze Äußerungen
  • Geduld haben und den Gesprächspartner nicht unterbrechen, sondern ausreden lassen
  • Blickkontakt halten
  • Sich durch Vorwürfe und Kritik nicht aus der Ruhe bringen lassen
  • Empathie ausüben und sich innerlich in die Situation des Sprechers versetzen

Erfolgsrezepte für Ihr nächstes Gespräch

Daraus lassen sich eine ganze Reihe von Best Practices für Ihr nächstes Gespräch ableiten:

  • Paraphrasieren Sie die Aussage, also wiederholen diese mit Ihren eigenen Worten
  • Sprechen Sie direkt die Gefühle des Gegenübers an, indem Sie diese und somit auch ihn/sie widerspiegeln
  • Stellen Sie mehrfach Fragen zu den Inhalten
  • Ist Ihnen etwas unklar, bitte sofort nachfragen, um sich zu vergewissern
  • Im Anschluss zum Fortfahren animieren
  • Wägen Sie Inhalte für sich ab

Was ist Ihre Meinung?

Welche weiteren Praxis-Tipps haben Sie zum Thema Kommunikation und Gesprächsführung? Welches Thema darf auf keinen Fall in unserer Soft Skills Reihe fehlen? Schreiben Sie es gerne in die Kommentare. Wir freuen uns auf den Austausch!

Sie möchten Ihre Soft Skills auf ein neues Level bringen? Dann empfehlen wir Ihnen unser 3-tägiges Training ‚Soft Skills für Softwarearchitekten (SOFT)‘. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture-Advanced Level (CPSA-A ®) anstreben, erhalten Sie mit diesem Soft Skills Training 30 Credit Points im Kompetenzbereich Kommunikation. Zum Soft Skills Training

 

Im zweiten Teil unserer Soft Skills Reihe geht es um Feedback und das richtige Konfliktmanagement.

iSAQB CPSA-F Softwarearchitektur-Training jetzt neu in Spanisch und Französisch buchbar

iSAQB CPSA-F Softwarearchitektur-Training jetzt neu in Spanisch und Französisch buchbar

Hola! Nous avons de bonnes nouvelles! ITech Progress goes International

ITech Progress bietet jetzt neu als erster iSAQB® Accredited Training Provider das Grundlagentraining für Softwarearchitektur (CPSA® – Foundation Level) in Spanisch und Französisch an. Die ersten Termine für 2021 sind ab sofort buchbar! Im Anschluss an das Training können Teilnehmer:innen optional eine Online-Zertifizierungsprüfung zum CPSA-F® in Spanisch und ab Mai 2021 auch in Französisch absolvieren.

Das International Software Architecture Qualification Board (iSAQB®) bietet mit der Zertifizierung zum Certified Professional for Software Architecture (CPSA®) ein international anerkanntes und standardisiertes Aus- und Weiterbildungsprogramm für Softwarearchitekt:innen an. Die Trainings im Foundation Level vermitteln fundierte Grundlagen in der Softwarearchitektur, die im Advanced Level gezielt vertieft werden können.

Die beiden Architektur-Expert:innen Mahbouba Gharbi und Alfredo Delgado Sánchez geben in ihren viertägigen Online-Trainings zum CPSA-F® einen umfassenden Einblick in die Welt der Softwarearchitektur. Teilnehmer:innen lernen anhand von vielen praktischen Übungen wichtige Methoden, Techniken und Tools kennen. Das kompakte Grundlagen-Training richtet sich an alle Softwarearchitekt:innen, Senior-Entwickler:innen und an IT-Fachkräfte, die an Softwareprojekten beteiligt sind. Es verbessert durch eine gemeinsame Fachsprache die Kommunikation in Projektteams und hilft somit mehr Verständnis füreinander zu entwickeln. Daher eignet sich dieses Training auch optimal als projektbegleitende Weiterbildung für IT-Teams.

Schulungsinhalte:

  • Grundbegriffe der Softwarearchitektur
  • Entwurf, Entwicklung, Beschreibung und Kommunikation von Softwarearchitekturen
  • Methoden, Techniken und Tools für Softwarearchitekt:innen
  • Qualitätsmodelle, -merkmale, -anforderungen und -bewertung
  • Verantwortlichkeiten und Rollen von Softwarearchitekt:innen im Projekt
  • Praktische Beispiele und Übungen

Am Ende des Softwarearchitektur-Trainings sind Sie in der Lage problembezogene Entwurfsentscheidungen zu treffen, Softwarearchitekturen für kleine und mittlere Systeme zu entwerfen und zu dokumentieren. Im Anschluss an das Training können Sie die Zertifizierungsprüfung zum “Certified Professional for Software Architecture – Foundation Level” ablegen.

Die ersten Termine:

Das erste Online-Training auf Spanisch findet vom 18. – 21. Mai 2021 statt und das erste Online-Training auf Französisch vom 09. – 12. November 2021. Alle Termine, auch auf Deutsch und Englisch, finden Sie hierBis 6 Wochen vor Start des Trainings können Sie mit unserem Early-Bird-Rabatt 100€ pro Person sparen und wenn Sie sich gemeinsam mit einer Kollegin oder einem Kollegen anmelden weitere 100€ pro Person.

Auf Spanisch finden Sie beim iSAQB bereits eine Beispielprüfung und viele weitere informative Dokumente über das Foundation Level zum Download. Die französischen Dokumente folgen in Kürze!

    Vorteile unserer Online-Trainings:

    • Ortsunabhängiges Echtzeit-Lernen
    • Interaktiv durch Übungen, Breakout-Rooms und visuelle Zusammenarbeit (z.B. Miro)
    • Ideale Trainerbetreuung auch in den Breakout-Rooms
    • Kleine und intensive Lerngruppen aus maximal 12 Teilnehmer:innen
    Mahbouba Gharbi

    Mahbouba Gharbi

    Trainerin für CPSA-F auf Französisch, Deutsch und Englisch

    Mahbouba Gharbi ist seit über 20 Jahren Expertin für Softwarearchitektur und gibt ihr Wissen als Chefarchitektin, Beraterin, Dozentin, Trainerin und Autorin weiter. Sie beschäftigt sich mit der Konzeption und Realisierung von mittleren bis großen Softwaresystemen. Neben ihrer Tätigkeit als Geschäftsführerin der ITech Progress ist sie Mitgründerin und Vorstandsvorsitzende des iSAQB e.V. und gestaltet Lehrpläne und Prüfungen aktiv mit.

    Alfredo Delago Sánchez

    Alfredo Delago Sánchez

    Trainer für CPSA-F auf Spanisch

    Alfredo Delago Sánchez ist mit mehr als 30 Jahren Erfahrung Experte für die Entwicklung von IT-Lösungen. Neben seiner technischen Expertise in der Softwarearchitektur bringt er methodische und kommunikative Kompetenzen aus seinen Tätigkeiten als Dozent und IT-Projektmanager mit. Mit seinem Know-how rund um Good Practices, agile Methoden, Standards und Prozesse, hat er es sich zu Aufgabe gemacht, Fachwissen über Softwarearchitektur weiterzugeben.

    Wir beraten Sie bei Ihren Weiterbildungsplänen und begleiten Sie auf dem Weg zum Certified Professional for Software Architecture (CPSA®)! Bei Fragen helfen wir Ihnen gerne weiter unter +49 621 595702 41 und training@itech-progress.com

    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.