All Posts By

Stefan Zörner

JUG_Saxony_2017_Keynote_Stefan Zoerner

Softwarearchitektur­ für alle!? – Video zur Keynote des JUG Saxony Day 2017

By | Publikationen, Video, Vorträge | No Comments
„Softwarearchitektur für alle!? … Softwarearchitektur wird Entwicklerskill“
Logo JUG Saxony Day
Softwarearchitektur für alle!? … Softwarearchitektur wird Entwicklerskill
Sprecher: Stefan Zörner
Videomitschnitt von Stefan’s Vortrag auf Youtube
Foliendownload (PDF)
Keynote auf dem JUG Saxony Day 2017
Freitag, 29. September 2017 in Radebeul b. Dresden

In dieser Eröffnungs-Keynote für den JUG Saxony Day 2017 führe ich aus, was Softwarearchitektur heute für mich ist, und warum es für Entwicklungsteam durch aktuelle Trends interessanter wird, sich damit zu beschäftigen.

Zentrale These: “Moderne Architekturansätze wie beispielsweise Microservices und Self-contained Systems bieten Entwicklerteams mehr Spielraum für konzeptionelle Arbeit. Softwarearchitektur wird Entwickler-Skill.”

Kern des Vortrages sind das Entwurfsdoppel Makro- und Mikroarchitektur, die darin zu treffenden Entscheidungen sowie die Fähigkeiten, die Teams dazu benötigen.

Fazit: Heute machen mehr Entwickler Architektur. Eine Weiterentwicklung in diese Richtung ist heute kein sozialer Aufstieg für wenige, sondern eine logische Konsequenz, wenn Eurer Team auch in der Mikroarchitektur risikogetrieben vorgehen will!

Softwarearchitektur für alle!? ... Softwarearchitektur wird Entwicklerskill

Twitter-Einblicke…
Tweet @jugsaxony
Tweet @tobiasgloeckner
Tweet @BertilMuth

follow us on Twitter – @embarced

sZoerner_Cloud_Prognose_prev_tag17

Cloud-Prognose: Wolkig mit Aussicht auf Beweglichkeit – beim TAG’17

By | Publikationen, Vorträge | No Comments
„Cloud-Prognose: Wolkig mit Aussicht auf Beweglichkeit“

The Architecture Gathering

Cloud-Prognose: Wolkig mit Aussicht auf Beweglichkeit
Sprecher: Stefan Zörner
Vortrag beim The Architecture Gathering
Mittwoch, 11. Oktober 2017, 17 – 18 Uhr
NH München Dornach, Einsteinring 20 in München – Aschheim

Foliendownload (PDF)

Mehr und mehr Unternehmen erkennen das Potential von Cloud-Technologien für die IT. Womöglich beabsichtigt auch Ihre Organisation zukünftig für OpenShift, AWS & Co. zu entwickeln. Der Vortrag zeigt, was das heute bedeutet, wo es Nutzen stiftet und wo nicht. Sie erfahren welche Entscheidungen ganz zu Beginn anstehen.

Falls Sie neue Cloud-Anwendungen entwickeln: Worauf achten sie bei Architekturentwurf und Technologieauswahl? Wenn Sie eine bestehende Anwendung in die Cloud migrieren wollen: Wie gehen Sie vor? Vielleicht gibt es auch Bedenken bezüglich Cloud-Lösungen. Wie entkräften Sie diese? Wo ist was dran? Was sind Hindernisse in einem betont konservativen Umfeld? Zentrale Prinzipien für die Anwendungsentwicklung in der Cloud runden den Vortrag ab.

Cloud-Prognose: Wolkig mit Aussicht auf Beweglichkeit

embarc_JUGsaxony_Keynote-2017

Keynote JUG Saxony Day 2017: Softwarearchitektur wird Entwicklerskill

By | Publikationen, Vorträge | No Comments
„Softwarearchitektur für alle!? … Softwarearchitektur wird Entwicklerskill“
Logo JUG Saxony Day

„Die besten Architekturen … entstehen durch selbstorganisierte Teams.“ – So steht es zumindest in den Prinzipien des Agilen Manifestes (2001). Und tatsächlich treffen mittlerweile mehr und mehr Teams grundlegende Entscheidungen gemeinsam, anstatt dass ein klassischer Architekt dies alleine tut (und ihnen abnimmt).

Softwarearchitektur wird dadurch mehr und mehr zum Entwicklerskill. In jedem cross-funktionalen Team sollte genügend Wissen und Können rund um diese Disziplin vorhanden sein. In diesem Vortrag erfahrt ihr, welche grundlegenden Techniken und Methoden aus diesem Gebiet jeder Entwickler beherrschen oder zumindest kennen sollte, und wie viel (oder wenig) Softwarearchitektur Eurem Team gut zu Gesicht steht.

Softwarearchitektur für alle!? ... Softwarearchitektur wird Entwicklerskill

Einige Eindrücke via Twitter




follow us on Twitter – @embarced

SZ_JavaForumNord17_Hannover

Java Forum Nord 2017: Softwarearchitektur für alle!?

By | Publikationen, Vorträge | No Comments
„Softwarearchitektur für alle!? … Softwarearchitektur wird Entwicklerskill“
Logo Java Forum Nord
Softwarearchitektur für alle!? … Softwarearchitektur wird Entwicklerskill
Sprecher: Stefan Zörner
Vortrag auf dem Java Forum Nord
Dienstag, 12. September 2017
Hannover, Hotel Dormero, Hildesheimer Straße 34 – 38

Foliendownload (PDF)

„Die besten Architekturen … entstehen durch selbstorganisierte Teams.“ – So steht es zumindest in den Prinzipien des Agilen Manifestes (2001). Und tatsächlich treffen mittlerweile mehr und mehr Teams grundlegende Entscheidungen gemeinsam, anstatt dass ein klassischer Architekt dies alleine tut (und ihnen abnimmt).

Softwarearchitektur wird dadurch mehr und mehr zum Entwicklerskill. In jedem cross-funktionalen Team sollte genügend Wissen und Können rund um diese Disziplin vorhanden sein. In diesem Vortrag erfahrt ihr, welche grundlegenden Techniken und Methoden aus diesem Gebiet jeder Entwickler beherrschen oder zumindest kennen sollte, und wie viel (oder wenig) Softwarearchitektur Eurem Team gut zu Gesicht steht.

Softwarearchitektur für alle!? ... Softwarearchitektur wird Entwicklerskill

follow us on Twitter – @embarced

Softwarearchitektur_meetup_Sept17

Softwarearchitektur Meetup Hamburg: Diagramme der Moderne

By | Publikationen, Vorträge | No Comments
Meetup
 Diagramme der Moderne – Softwarearchitektur­ zeitgemäß visualisieren
Impuls und Moderation: Stefan Zörner
Veranstaltung beim Softwarearchitektur Meetup Hamburg
04. September 2017, 18:30 Uhr
Academic Work GmbH, Großer Burstah 50-52 in Hamburg

Foliendownload (PDF)

Die Kommunikation zentraler Architekturideen im Team und gegenüber anderen ist heute wichtiger denn je. Visualisierungen können dabei unterstützen, tun es aber nicht automatisch. An diesem Abend vermittelt Stefan Zörner Erfolgsfaktoren, um mit angemessenem Aufwand wirkungsvolle Abbildungen Eurer Softwarearchitektur zu erstellen und zu pflegen. Zur Sprache kommen Notationsoptionen, empfohlene Werkzeuge und Vorgehen. Das Gelernte übt Ihr direkt in kleinen, fokussierten Übungen.

Softwarearchitektur Meetup Hamburg: Diagramme der Moderne

Noch etwas Bildmaterial von dem Treffen:

Architektur-Spicker-5_Cloud-Anwendungen

Architektur-Spicker Nr. 5: Cloud-Anwendungen

By | Publikationen, Spicker | No Comments
Architektur-Spicker Nr. 5: Cloud-Anwendungen

Architektur-Spicker

Architektur-Spicker Nr. 5: Cloud-Anwendungen
Autor: Stefan Zörner
Referenzkarte bei architekturSPICKER PDF, 4 Seiten
Erschienen 22. Mai 2017

Download Spicker #5

Die aktuelle Ausgabe unseres Architektur-Spickers zeigt in gewohnt kompakter Form, wie Sie Anwendungen bauen, die das Potential einer Cloud-Umgebung voll ausschöpfen.

In dem vierseitigen PDF gehen wir unter anderem auf die folgenden Fragen ein:
 

  • Wie gehen Sie bei der Migration bestehender Anwendungen in die Cloud vor?
  • Sie entwicklen neue Cloud-Anwendungen. Worauf achten Sie bei Architekturentwurf und Technologieauswahl?
  • Wie vermeiden Sie Fehler? Wie bleiben Sie beweglich?

 

Architektur-Spicker 1-5
Architektur-Spicker #5

 

follow us on Twitter – @embarced

szoerner_jax2017_systemlandschaften

Schliemanns Erben – JAX 2017

By | Publikationen, Vorträge | No Comments
„Schliemanns Erben – Systemlandschaften wirkungsvoll (nach-)dokumentieren“
Logo W-Jax

Softwaresysteme wachsen historisch. Das gilt nicht als Idealzustand, aber so ist die Realität nun mal. Für Systemlandschaften gilt es erst recht. IT-Trendwellen schwappen über Unternehmen und hinterlassen ihre Spuren in den Anwendungen. Geglückte Würfe ebenso wie gescheiterte Initiativen.

(De-)Zentralisierung, Objektorientierung, SOA, Standardisierung, Cloud …manche Unternehmen haben Vermächtnisse (engl. Legacy) aus drei Jahrzehnten im Betrieb. In vielen Fällen wird das Wissen darum nur mündlich weitergegeben. Die Konsequenz: langwierige und lückenhafte Einarbeitung, Unsicherheiten bei Änderungen und Neuentwicklungen. Im Extremfall führt dies zu geringem Vertrauen bei Entscheidern. Dabei ist der Aufwand, das Wesentliche fest und aktuell zu halten, gar nicht groß.

In dieser Session zeige ich, wie ihr bestehende Systemlandschaften kartografiert und es allen Beteiligten leichter macht, sich zurechtzufinden und informierte Entscheidungen zu treffen. Mit Anlehnung an Methoden wie arc42 (das initial nur auf Einzelsysteme passt), Beispielen aus echten Ausgrabungen, aber ohne C14.

Systemlandschaften wirkungsvoll (nach-)dokumentieren

bild_szoerner_jug_darmstadt

JUG Darmstadt – Softwarearchitektur wird Entwicklerskill

By | Publikationen, Vorträge | No Comments
„Softwarearchitektur­ für alle!?“
Logo JUG Darmstadt
Softwarearchitektur für alle!?
Sprecher: Stefan Zörner
Vortrag bei der JUG Darmstadt
16. März 2017, ab 18:30 Uhr
TOP Tagungszentrum AG, Wittichstraße 2, 64295 Darmstadt

Download Vortragsfolien (PDF)

„Die besten Architekturen … entstehen durch selbstorganisierte Teams.“ – So steht es zumindest in den Prinzipien des Agilen Manifestes (2001). Und tatsächlich treffen mittlerweile mehr und mehr Teams grundlegende Entscheidungen gemeinsam, anstatt dass ein klassischer Architekt dies alleine tut (und ihnen abnimmt).

Softwarearchitektur wird dadurch mehr und mehr zum Entwicklerskill. In jedem cross-funktionalen Team sollte genügend Wissen und Können rund um diese Disziplin vorhanden sein.

In diesem Vortrag erfahrt ihr, welche grundlegenden Techniken und Methoden aus diesem Gebiet jeder Entwickler beherrschen oder zumindest kennen sollte, und wie viel (oder wenig) Softwarearchitektur Eurem Team gut zu Gesicht steht.

Download Vortragsfolien (PDF)

follow us on Twitter – @embarced

bild_OOP_2017_SZoerner

OOP 2017 – Systemlandschaften wirkungsvoll (nach-)dokumentieren

By | Publikationen, Vorträge | No Comments
„Schliemanns Erben – Systemlandschaften wirkungsvoll (nach-)dokumentieren“
Logo OOP 2017
Schliemanns Erben – Systemlandschaften wirkungsvoll (nach-)dokumentieren
Sprecher: Stefan Zörner
Vortrag auf der OOP 2017
31. Januar 2017 um 16:15 – 17:15 Uhr
ICM – Internationales Congress Center München, Am Messesee, 81829 München

Download Vortragsfolien (PDF)

Software-Systeme wachsen historisch. Das gilt nicht als Idealzustand, aber so ist die Realität nun mal. Für System-Landschaften gilt es erst recht. IT-Trendwellen schwappen über Unternehmen und hinterlassen ihre Spuren in den Anwendungen. Geglückte Würfe ebenso wie gescheiterte Initiativen.

(De-)Zentralisierung, Objektorientierung, SOA, Standardisierung, Cloud … Manche Unternehmen haben Vermächtnisse (engl. Legacy) aus drei Jahrzehnten im Betrieb. In vielen Fällen wird das Wissen darum nur mündlich weitergegeben. Die Konsequenz: langwierige und lückenhafte Einarbeitung, Unsicherheiten bei Änderungen und Neuentwicklungen. Im Extremfall führt dies zu geringem Vertrauen bei Entscheidern. Dabei ist der Aufwand, das Wesentliche fest und aktuell zu halten, gar nicht groß.

In dieser Session zeige ich, wie man bestehende Systemlandschaften kartographiert und es allen Beteiligten leichter macht, sich zurechtzufinden und informierte Entscheidungen zu treffen. Mit Anlehnung an Methoden wie arc42 (das initial nur auf Einzelsysteme passt), Beispielen aus echten Ausgrabungen, aber ohne C14.

Download Vortragsfolien (PDF)

follow us on Twitter – @embarced

Drei Dinge, die mich bei Architekturdiagrammen mit plantUML nerv(t)en

By | Allgemein, Inhaltliches | 8 Comments

plantIch sehe bei Kunden ab und an plantUML im Einsatz. Und noch häufiger fragen mich Teilnehmer in Workshops, was ich von plantUML halte, wenn es um Diagramme in der Dokumentation von Softwarearchitektur geht. Beispielsweise in den betreffenden Abschnitten von arc42 (Konkret: Kontextabgrenzung, Bausteinsicht, Laufzeitsicht …).

Um ehrlich zu sein fand ich plantUML dafür lange Zeit nicht so toll. Aus verschiedenen Gründen. Bei näherem Hinsehen ließ sich einiges davon aber auf Unkenntnis und Vorurteile meinerseits zurückführen. Und einige Unschönheiten lassen sich mit den richtigen Kniffs und Workarounds umgehen. Ein paar kleine Erkenntnisse zeige ich im Rahmen dieses Beitrags. Und beginne so meinen Frieden zu machen mit dem Werkzeug.

Aber zuvor: Was ist dieses plantUML überhaupt (für diejenigen, die es nicht kennen) und warum finde ich es (immernoch) nicht ganz so toll wie manche meiner Kunden?

plantUML

plantUML generiert UML-Diagramme als Graphik aus textuellen Beschreibungen. Die Syntax dazu ist recht einfach gehalten und schnell erlernt. Hier ein Minibeispiel. Aus der Eingabe links generiert plantUML das Diagramm rechts.cd_schach

@startuml

Schachbrett -> Figur 
Figur --> Farbe
Figur --> enum Art

enum Farbe { 
 SCHWARZ 
 WEISS
}

@enduml

 

Neben den besonders gut unterstützen Klassendiagrammen (wie im Beispiel oben, Details zur Syntax siehe hier) kann plantUML auch andere Diagrammarten der UML generieren (Sequenzdiagramme, Anwendungsfalldiagramme …).

plantUML ist Open Source, in Java geschrieben und leicht integrierbar. Entsprechend gibt es zum Beispiel Plugins für verschiedene Textsysteme (z.B. Asciidoctor), Build-Werkzeuge (z.B. Gradle) und Wikis (z.B. XWiki und Confluence). Gerade in diesen Fällen passt das Text-Format von plantUML sehr gut, fühlt es sich doch in der Versionsverwaltung ebenso wohl wie zwischen Wiki-Markup.

In der Regel nimmt der Autor beim Erstellen kaum Einfluss auf das Layout seiner Diagramme. Ich sehe das als Vorteil, kostet das Kästchenschubsen in graphischen Editoren bei Änderungen doch oftmals viel Zeit.

Drei Dinge, die ich an plantUML nicht mag

Trotz der unbestrittenen positiven Merkmale gibt es Dinge, die mir bei plantUML nicht so gut gefallen. Hier drei aus meiner Sicht besonders gewichtige:

  1. Der Technologie-Stack ist fragil
  2. Für Softwarearchitektur relevante Diagramme fehlen
  3. Die generierten Diagramme sehen altbacken aus

Der Technologie-Stack ist fragil

plantUML ist in Java geschrieben, der Download lediglich ein jar-File. Tatsächlich handelt es sich bei bei dem Tool aber eher um ein Frontend (oder wenn man mag einen Präprozessor) für das Werkzeug Graphviz.

binaryGraphviz ist eine leistungsfähige und recht verbreitete Open Source-Lösung zum Visualisieren von Graphen (also Knoten verbunden durch Kanten). Anders als plantUML wird es Betriebssystem-spezifisch als Binary installiert. Es muss lokal vorliegen (konkret: das Graphviz-Executable „dot“). plantUML greift darauf zu, es verwandelt die plantUML-Eingabe in eine Eingabe in der DOT-Sprache und lässt dann Graphviz die ganze Arbeit machen („Zwerge auf den Schultern von Riesen“).

Das Problem dabei: das Zusammenspiel zwischen plantUML und dot führt regelmäßig zu Reibung. Auch eine saubere Graphviz-Installation verweigert schon mal die Arbeit und führt zu Fehlermeldungen, lustigerweise in Form einer Graphik anstelle des erhofften Ergebnisses. Sieht dann zum Beispiel so aus:

Fehler beim Aufruf von not / Graphviz

In der Praxis heißt das etwa für ein Java-Projekt, das seine Architekturdokumentation in den Build integrieren will, dass es höhere Anforderungen an das Build-System stellt. Also an alle, die das Projekt bauen wollen. Java installieren reicht nicht (wie bei Gradle durch den Wrapper eigentlich üblich), es muss auch noch Graphviz da sein und mit plantUML zusammenspielen.  Das berühmte „It Works on My Machine“ war doch eigentlich überwunden (OK, die Pest ist schlussendlich auch noch nicht ausgestorben). Auch entsprechende Beiträge der Plugin-Benutzer in den Foren von XWiki und Confluence singen ein Lied von dem Problem.

Für Softwarearchitektur relevante Diagramme fehlen

plantUML unterstützt verschiedene Diagrammarten der UML, und die wiederum verschiedenen gut. Bei Klassendiagrammen geht mit Abstand am meisten. Gerade diese Diegrammart benötige ich allerdings in einem Architekturüberblick eher selten, bestenfalls für ein grobes Domänenmodell.

struktur_kleinBesonders wichtig sind mir methodisch gesehen die Kontextabgrenzung (Kapitel 3 in arc42, bzw. der Abschnitt „Context“ bei Simon Brown) und die statische Zerlegung (Kapitel 5 „Bausteinsicht“ in arc42). Eine Kontextabgrenzung lässt sich mit plantUML ganz gut visualisieren übrigens. Meine favorisierte Darstellung von Zerlegungshierarchien mit den Ports der Kompositionsstrukturdiagramme unterstützt plantUML leider nicht. Strukturen lassen sich zwar mit gruppierenden Elementen abbilden; Interaktionspunkte auf der „Membran“ (Ports, siehe kleine Skizze links) gehen hingehen nicht.

Die Diagramme sehen altbacken aus

Geschmäcker sind verschiedenen, mir persönlich gefällt die Darstellung von plantUML tatsächlich nicht sonderlich. Die Buchstaben-Icons bei Klassen, Aufzählungen etc. (E, C, … siehe Schach-Beispiel oben)  sind nicht mein Fall, und vor allem:  Die Farben (gelbe Kästen, rote Linien) haben die Anmutung alter Rational-Werkzeuge (kleine Zeitreise, Video). Die Zeit wünsche ich mir nicht zurück. Den Retro-Look der 90er-Jahre komplett machen dann Komponenten im Stil der UML 1. Als Beispiel hier ein rudimentärer Systemkontext (System mit einem Benutzer als Akteur) in plantUML, rechts wieder das resultierende Diagramm (das System als Komponente in UML 1-Notation):

@startumlsc_altbacken
[Webshop] <<system>>
:Kunde: - Webshop
@enduml

Auf Diagramme mit dieser Anmutung stolpere ich regelmäßig in Projekten. Dass mir die nicht übermäßig gefallen ist mein Problem, wenn die Teams es so mögen … Mein Problem könnt Ihr gleichzeitig beheben, bei plantUML läßt sich nämlich so ziemlich jede Stileigenschaft (Fonts, Farben, Strichbreiten …) konfigurieren. Aber wer hat da schon Lust zu? Der Aufwand mit all den Schaltern schreckt erstmal ab.

Die gute Nachricht: Es gibt recht große Schalter — Hebel sozusagen — welche mit wenig Aufwand viel Wirkung zeigen. Für das Beispiel oben reichen zwei dieser wirkmächtigen Hebel, und es sieht für mich deutlich passabler aus (siehe wieder Graphik rechts):

@startumlsc_modern
skinparam monochrome true
skinparam componentStyle uml2

[Webshop] <<system>>
:Kunde: - Webshop
@enduml

Das gefällt mir richtig gut schon. Derartige Skin-Parameter lassen sich übrigens auch in Dateien auslagern, von aussen in den plantUML-Prozessor reinreichen, etc. — So verschmutzen sie auch nicht alle plantUML-Quelltexte.

Fazit

Der Ansatz, aus text-basierten Beschreibungen Graphiken/Diagramme zu generieren, hat viel für sich. In vielen Fällen nutzen Teams ein Wiki oder Text-Systeme wie Asciidoc, um ihre Architekturdokumentation festzuhalten. Die Frage, wo die Diagramme herkommen, stellt sich dort stets, und plantUML ist zumindest eine Option. Mit wenigen Kniffen finde ich die Ausgabe zumindest optisch passabel, eine große Herausforderung bleibt das fragile Zusammenspiel mit Graphviz.

Ich spiele mit dem Gedanken hier ein geschlossenes Fallbeispiel bereitzustellen. Einen Architekturüberblick, in dem die Diagramme mit plantUML generiert sind, und dessen Inhalte sich an den Sichten von arc42 orientieren. Fänden Sie das interessant?