Yearly Archives

2016

Treffpunkt für Softwarearchitekten – embarc auf dem Architecture Gathering 2016

By | Allgemein | No Comments

Nach der Premiere im letzten Jahr fand das Architecture Gathering dieses Jahr im Oktober erneut in München statt und erfreute sich zahlreicher Besucher. Wir waren mit zwei Vorträgen & unserem Stand auf der Konferenz dabei.

Harm Gnoyke gab in seinem Vortrag ganz praktische Tipps wie Sie Ihren Monolithen möglichst charmant in ein Microservices-System verwandeln. Dabei ergaben sich unterhaltsame Parallelen zwischen den Beziehungen von Projektteams zu ihren Softwarelösungen und den Trennungsphasen des realen Lebens. Ja und selbst die Aufnahmen des Titelhelden (Matthew McConaughey) passten sich im Verlauf der Session dem leichtgewichtigeren Architekturstil an… also ein wenig zumindest (Folieneinblicke).

Unsere Session von Oliver Zeigermann lud am zweiten Veranstaltungstag zum Erfahrungsaustausch zu Best-Practices in der Web-Entwicklung ein und zeigte wo deren Grenzen liegen. Mittels einer kurzen Filmsequenz gab es Einblicke in die Gefühlswelt eines Entwicklers (beim 2-Wege-DataBinding) und am Ende beantwortete Oliver nicht nur die Frage aus „Wissen-20“, sondern noch einige mehr… (nachzulesen auf github).

Gute Gespräche und Austausch am embarc-Stand und auf der Konferenz rundeten den Besuch für uns in München ab und ließen zudem jede Menge frisch gedruckter Architektur-Spicker schwinden.

Aber Bilder sagen ja bekanntlich mehr als Worte…

 
 
(Fotos: SigsDatacom, embarc)

Vortrag Java Forum Nord 2016: Nörgeln ist einfach (Architekturbewertung)

By | Publikationen, Vorträge | No Comments
„Nörgeln ist einfach. Aber was (genau) ist eigentlich Architekturbewertung?“
Logo Java Forum Nord
Nörgeln ist einfach. Aber was (genau) ist eigentlich Architekturbewertung?
Sprecher: Stefan Zörner
Vortrag auf dem Java Forum Nord
Donnerstag, 20. Oktober 2016, 16:00 Uhr
Hannover, Hotel Dormero

Folien Download (PDF)

Statler: „Nein, nein, das hätten sie wirklich anders machen sollen.“
Waldorf: „So, wie denn nach Deiner Meinung?“
Statler: „Besser!“
(aus der Muppet Show)

Jedes interessante Softwaresystem hat eine Softwarearchitektur. Diese ist kunstvoll geplant oder zufällig entstanden, meist aber irgendwas dazwischen. Hätte man es anders machen sollen? In diesem Vortrag stelle ich vor, wie Sie Ihre Softwarearchitektur bewerten! Sind Sie auf dem richtigen Weg? Können Ihre Architekturideen in der Umsetzung aufgetretene Probleme effektiv lösen? Helfen diese bei der Erreichung Ihrer Ziele oder behindern sie diese eher? Architekturbewertung kann Sicherheit schaffen und Risiken aufzeigen und damit helfen die Aufwände im Projekt zu fokussieren. Sie lernen quantitative und qualitative Analysemethoden kennen. Was argumentative, Workshop-basierte Verfahren wie ATAM leisten thematisiere ich ebenso wie welche Aspekte Ihrer Architekturziele sich mit statischen Code-Analysen verknüpfen lassen.

Download Vortragsfolien (PDF)

 

Zur Veranstaltung

The Architecture Gathering ’16: Was uns C64 Programmierung über JavaScript Architekturen lehren kann

By | Publikationen, Vorträge | No Comments
„Was uns C64 Programmierung über JavaScript Architekturen lehren kann“

The Architecture Gathering

Was uns C64 Programmierung über JavaScript Architekturen lehren kann
Sprecher: Oliver Zeigermann
Vortrag beim The Architecture Gathering
Donnerstag, 13. Oktober 2016, 10:30 – 11:30 Uhr
NH München Dornach, Einsteinring 20 in München – Aschheim

Folien Download (github)

Die Programmierung des C64, des bekanntesten Heimcomputers der 80er Jahre, mit seinem eingebauten Basic war vor allem eins: leicht zu erlernen, aber wenig mächtig. Einfache Dinge konnte man innerhalb weniger Minuten lösen, aber bei wirklichen Aufgaben musste man auf andere Ansätze wechseln.

Ähnliche Erfahrungen haben viele Entwickler erst mit dem JavaScript Framework jQuery und später dann mit AngularJS gemacht. Eben wie bei der C64-Programmierung kommt es auch bei der Webentwicklung darauf an, dass man einen Architektur-Ansatz findet, der dem Problem gerecht wird. Nicht zu einfach, aber auch nicht zu komplex. Dabei kommen insbesondere durch den mächtigen Ansatz von Single-Page Applications ganz neue Anforderungen auf uns zu.

In diesem Talk werden wir uns diese Herausforderungen ansehen und passende Architekturmuster am Beispiel der gängigen JavaScript Web-Frameworks wie Angular 2 und React erarbeiten. Zur Sprache kommen dabei sowohl optimierte Komponenten-Hierarchien, als auch moderne Flux-Architekturen. Man darf gespannt sein, wie sich dabei ehemalige Anti-Patterns – z.B. globaler Zustand – zu Best-Practices wandeln.

Download Vortragsfolien (github)

follow us on Twitter – @embarced

The Architecture Gathering ’16: Wie werde ich ihn los – in 10 Tagen? Vom Monolithen zu Microservices…

By | Publikationen, Vorträge | No Comments
„Wie werde ich ihn los – in 10 Tagen? Vom Monolithen zu Microservices…“

The Architecture Gathering

Wie werde ich ihn los – in 10 Tagen? Vom Monolithen zu Microservices…
Sprecher: Harm Gnoyke
Vortrag beim The Architecture Gathering
Mittwoch, 12. Oktober 2016, 14:15 – 15:15 Uhr
NH München Dornach, Einsteinring 20 in München – Aschheim

Folien Download (PDF)

Viele Projektteams sind eine langjährige Beziehung mit einem Monolithen eingegangen – auch wenn Sie diese Entscheidung gar nicht selbst getroffen haben – und sind mit dieser Situation unglücklich. Mittlerweile gibt es viele große Microservice-Systeme, die ungleich attraktiver erscheinen: Entwickeln in unabhängigen Teams, evtl. sogar mit verschiedenen Technologien, einfaches Austauschen einzelner Services, beliebige Skalierbarkeit sind die bekanntesten Vorteile. Doch wie verabschieden Sie sich möglichst elegant von Ihrem Monolithen und wechseln zu einem Microservice-System?

In diesem Vortrag diskutieren wir zunächst die Beweggründe für einen Wechsel. Ist die Entscheidung gefallen, steht der Umzug an: Was lassen Sie zurück und was nehmen Sie mit ins neue Microservice-System? Wir zeigen eine schrittweise Ablösestrategie und weisen auf typische Stolperfallen hin. Als Abschluss zeigen wir wie sich der Umzug auf die Test-Strategien auswirkt. Insbesondere dort tickt der Neue nämlich anders…

Download Vortragsfolien (PDF)

follow us on Twitter – @embarced

jug-essen-logo-vorschau

Vor Ort bei der JUG Essen – Softwarearchitektur Speed-Dating

By | Publikationen, Vorträge | No Comments
„Softwarearchitektur­ Speed-Dating“
Logo JUG Essen
Softwarearchitektur Speed-Dating
Moderation: Stefan Zörner
Interaktiver Vortrag bei der JUG Essen
20. Februar 2017, ab 18:30 Uhr
Anmeldung über Meetup
Lazarettstraße 15, 45127 Essen (Anfahrt / Karte)

Zeitgemäße Softwarearchitektur ist nicht das Werk einzelner. Architekturansätze und Ideen entstehen im Team und werden gemeinsam reflektiert. Alle Entwickler müssen sie zumindest verstehen und mittragen können. Aber was genau müsst Ihr vermitteln? Reicht aufschreiben? Hilft UML?

Stefan Zörner zeigt auf lebendige Weise, wie Ihr Eure Softwarearchitektur wirkungsvoll kommunizieren könnt. Nach kurzen theoretischen Inputs rund um Architekturdokumentation und -bewertung probiert Ihr das Gehörte gleich aus. Ihr lernt die Lösungen anderer Teilnehmer kennen und erfahrt Schritt für Schritt, welche Zutaten in einem Architekturüberblick keinesfalls fehlen sollten – egal wie kurz er ist. Ihr lernt die richtigen Fragen zu stellen und passende Antworten parat zu haben.

Bringt bitte die Bereitschaft mit, Euch über Eure Projekte und Softwarelösungen auszutauschen, und anderen Teilnehmern Feedback zu geben. Die sonst üblichen Speed-Dating-Themen wie Kinderwünsche klammern wir aus.

zur Veranstaltungsseite

follow us on Twitter – @embarced

Softwarearchitektur­ Speed-Dating Ende November in Magdeburg

By | Publikationen, Vorträge | No Comments

Am 29. November ist Stefan Zörner in Magdeburg bei der Softwerkskammer zu Gast.

„Softwarearchitektur­ Speed-Dating (interaktiver Vortrag)“
Logo Softwerkskammer
Monolith sucht Resilienz — Softwarearchitektur Speed-Dating
Moderation: Stefan Zörner
Interaktiver Vortrag bei der Softwerkskammer Magdeburg
29. November 2016, 18:00 – 20:00 Uhr
SelectLine Software GmbH, Otto-von-Guericke-Straße 67, 39104 Magdeburg

Zeitgemäße Softwarearchitektur ist nicht das Werk einzelner. Architekturansätze und Ideen entstehen im Team und werden gemeinsam reflektiert. Alle Entwickler müssen sie zumindest verstehen und mittragen können. Aber was genau müsst Ihr vermitteln? Reicht aufschreiben? Hilft UML?

Stefan Zörner zeigt auf lebendige Weise, wie Ihr Eure Softwarearchitektur wirkungsvoll kommunizieren könnt. Nach kurzen theoretischen Inputs rund um Architekturdokumentation und -bewertung probiert Ihr das Gehörte gleich aus. Ihr lernt die Lösungen anderer Teilnehmer kennen und erfahrt Schritt für Schritt, welche Zutaten in einem Architekturüberblick keinesfalls fehlen sollten – egal wie kurz er ist. Ihr lernt die richtigen Fragen zu stellen und passende Antworten parat zu haben.

Bringt bitte die Bereitschaft mit, Euch über Eure Projekte und Softwarelösungen auszutauschen, und anderen Teilnehmern Feedback zu geben. Die sonst üblichen Speed-Dating-Themen wie Kinderwünsche klammern wir aus.

zur Veranstaltungsseite

follow us on Twitter – @embarced

Die sieben Regeln für gute Dokumentation in Stein gemeißelt? — Tafel 3 (von 3)

By | Allgemein, Inhaltliches

In den zwei vorherigen Beiträgen hatte ich bereits mit der kurzen Diskussion der klassischen sieben Regeln für gute Dokumentation begonnen. Ich schließe sie in diesem Beitrag mit den beiden verbleibenden Regeln 3 und 7 ab. Hier noch einmal kurz zur Erinnerung alle sieben im Überblick:

Sieben Regeln für gute Dokumentation
book
1. Schreibe aus Sicht des Lesers. (Tafel 1)
2. Vermeide unnötige Wiederholungen. (Tafel 2)
3. Vermeide Mehrdeutigkeit. Erkläre Deine Notation. (Tafel 3)
4. Verwende eine Standardstrukturierung. (Tafel 2)
5. Halte Begründungen für Entscheidungen fest. (Tafel 1)
6. Halte Dokumentation aktuell, aber auch nicht zu aktuell. (Tafel 2)
7. Überprüfe Dokumentation auf ihre Gebrauchstauglichkeit. (Tafel 3)

Vermeide Mehrdeutigkeit. Erkläre Deine Notation (Regel 3)

Es ist unstrittig, dass sich bestimmte Informationen mit Bildern besser kommunizieren lassen als mit Text allein. Das gilt für Strukturen (Elemente und deren Beziehungen untereinander) ebenso wie für Abläufe (Folgen von Aktionen mit Alternativen, Wiederholungen, Parallelität). Ab einer gewissen Komplexität lässt sich das mit Stichpunkten oder Prosa nicht gut beschreiben. Diagramme und mitunter auch Screenshots kommen ins Spiel, bei Diagrammen ist in der Softwarearchitektur immer noch UML recht verbreitet.

In diesem Zusammenhang höre ich in Projekten oft: „Wir benutzen für unsere Architekturdiagramme UML. Die Notation ist standardisiert. Kann jeder lesen.“ Das mit dem standardisiert stimmt, meine Erfahrungen mit „kann jeder lesen“ sind andere.

In der Projektpraxis werden übrigens oft gar keine Architekturdiagramme angefertigt. Auch weil die Teammitglieder unsicher in der Notation sind. Sie glauben sie müssten UML nehmen aber haben Angst sich damit zu blamieren. Aus meiner Sicht ist UML zu verwenden kein Automatismus, und bei den vielen Zielgruppen (vgl. Regel 1) wird auch bei der UML Erklärungsbedarf da sein.

In diesem Zusammenhang zwei persönliche Ratschläge von mir rund um Diagramme:

  • Schreibt zu jedem Diagramm einen Satz der auf den Punkt bringt was zu sehen ist (“Mission Statement”, Kernaussage). In der Dokumentation (egal ob Dokument, Wiki, Poster …) platziert Ihr diesen Satz oberhalb der Abbildung.
  • Lasst Euch nicht von der Notation behindern. Benutzt stattdessen wenige Elemente, und erklärt diese in einer Legende.

Der erste Tipp sorgt zum einen dazu, dass Betrachter nicht rätseln müssen, was Ihr mit dem Bild sagen wollt. Zum anderen (und das ist das Entscheidende) hilft es Euch zu entscheiden, ob etwas „noch ins Bild reingehört“ oder nicht. Ihr vermeidet Diagramme voller Prachtfülle, in denen der Leser die relevanten Informationen dann aber suchen muss wie in einem Wimmelbild. Hier ein schönes Fundstück aus dem Netz dazu (Quelle, beachtet die beschönigende Überschrift).

complex-system-architecture-diagram-2292510

Immerhin: Eine Legende hat dieses Diagramm. Die Regel „Erkläre Deine Notation“ wende ich durchaus auch auf UML an. Und wenn Ihr dort wenige Elemente verwendet braucht Ihr auch nur wenig erklären. Die wenigen UML-Elemente dann aber bitte richtig verwenden. Sonst verwirrt Ihr diejenigen, die UML lesen können (gibt es auch).

Überprüfe Dokumentation auf ihre Gebrauchstauglichkeit (Regel 7)

Hinter dieser Regel stecken Reviews, zumindest suggeriert das Wort „überprüfen“ das. Dokumentation kann man auf zwei Arten überprüfen. Die erste nenne ich gern „Überprüfung auf Standardkonformität“. Hier werden Kriterien an die Dokumentation gelegt und Fragen folgender Art gestellt (Beispiele):

  • Hat die Architekturbeschreibung mindestens 60 Seiten?
  • Ist sie nach arc42 gegliedert?
  • Ist jeder Abschnitt ausgefüllt?
  • Wird für die Diagramme als Notation UML verwendet?
  • Hat jedes Diagramm eine Legende?

Fragen dieser Art eignen sich prima für Checklisten, diese können in der Regel von einer QS-Abteilung abgearbeitet werden. Mitunter erfordern regulative Randbedingungen einen solchen Check auf Standardkonformität. Mit der Überprüfung auf Gebrauchstauglichkeit ist aber etwas anderes gemeint.

Nämlich dass die Dokumentation tatsächlich bei der Arbeit unterstützt. Diejenigen, welche Architektur kommunizieren wollen, und diejenigen, welche sich dafür interessieren. Also für Architekturtreiber, Lösungsansätze, Entscheidungen, Konzepte. Die geschlossenen Fragen von oben können das nicht leisten.
Architektur-Spicker #1, Seite 3
Die Überprüfung auf Gebrauchstauglichkeit findet als Test mit den Zielgruppen statt. Und hier schließt sich der Kreis von Regel 7 zu Regel 1 („Schreibe aus Sicht des Lesers“). Das Anfertigen eines Architekturüberblicks stelle ich überhaupt gerne als Kreislauf dar (initial klein Starten, dann schrittweise Verfeinern). Eine Darstellung dieser Idee findet Ihr zum Beispiel in unseren Architektur-Spicker #1 („Der Architekturüberblick“, Download als PDF) auf Seite 3 oben.

JUG Saxony Day 2016: Architekturdokumentation heute vs. 1999

By | Publikationen, Vorträge | No Comments
„Architekturdokumentation heute: Die 7 Regeln in Stein gemeißelt?“
Logo JUG Saxony Day
Sprecher: Stefan Zörner
Vortrag auf dem JUG Saxony Day 2016
Freitag, 30. September 2016, 11:30 – 12.30 Uhr
Radebeul bei Dresden, im Radisson Blu Park Hotel & Conference Centre

Download Folien Download (PDF)

„Schreibe aus Sicht des Lesers! Erkläre Deine Notation! Verwende eine Standardgliederung! …“ Die klassischen sieben Regeln für gute (Architektur-)dokumentation sind so alt, dass Ihr sie vielleicht gar nicht kennt.

Doch die Frage, wie Ihr Eure Lösungskonzepte festhaltet, kommuniziert und wirkungsvoll in der Umsetzung verankert, bleibt – und ihre Relevanz nimmt in Zeiten selbstorganisierter Teams eher noch zu.

Dieser Vortrag ruft Euch die Regeln nicht nur (falls nötig) in Erinnerung, sondern diskutiert und hinterfragt sie im heutigen Kontext. In dem leichtgewichtige Formen Schwergewichte wie die UML mehr und mehr verdrängen und in dem Entwickler die Architekturarbeit verantworten.

Lernt anhand praktischer Beispiele zeitgemäße Formen eines Architekturüberblicks und ein schlankes Vorgehen für dessen Erstellung kennen. Sowie Möglichkeiten, wie Ihr die Dokumentation näher an die Entwicklung bringt, und die Umsetzung Eurer Architektur dort angemessen überprüft. Von Richtlinien zu Prinzipien und Tests. Der Quelltext erzählt nicht die ganze Geschichte …

Download Vortragsfolien (PDF)

follow us on Twitter – @embarced

Experten-Check auf JAXenter: Was ist schöner Code?

By | Artikel, Publikationen | No Comments
„Was ist guter Code für Software-Architekten?“ (Teil 1 der Themenserie)

JAXenter Logo

Teil 1: Was ist guter Code für Software-Architekten?
Autoren: Milad Jason Daivandy, Stefan Zörner und Uwe Friedrichsen
Architektur (Teil 1) auf JAXenter
erschienen am 12. September 2016

In dem JAXenter Themen-Schwerpunkt “Schöner Coden” werden die Fragen aufgeworfen: Was ist eigentlich schöner Code? Welche Eigenschaften hat schöner Code aus Sicht eines Software-Architekten? Und umgekehrt: Was macht schlechten Code aus? Hilft ein bestimmtes Tool oder Framework dabei, schöneren Code zu schreiben? Im ersten Teil des Experten-Check beantworten Milad Jason Daivandy, Stefan Zörner und Uwe Friedrichsen diese Fragen und lassen ihre Erfahrungen einfliessen. (…mehr)

„Was macht die Schönheit von gutem Code für Web-Experten aus?“ (Teil 4 der Themenserie)

JAXenter Logo

Teil 4: Was macht die Schönheit von gutem Code für Web-Experten aus?
Autoren: Niko Köbler, Karsten Sitterberg und Oliver Zeigermann
Web (Teil 4) auf JAXenter
erschienen am 19. September 2016

Was ist schöner Code für Web-Experten? Was hilft technisch um schöneren Code zu schreiben? Im vierten Teil des Experten-Check stehen Niko Köbler, Karsten Sitterberg und Oliver Zeigermann Frage und Antwort und erläutern wie wichtig Lesbarkeit und Code-Reviews für sie sind und bei welchen Fehlern sich den Experten im wahrsten Sinne „die Fußnägel hochrollen“. (…mehr)

In der Reihe „Experten-Check: Was ist schöner Code?“ sind die folgenden fünf Artikel auf JAXenter erschienen:

Teil 1: Schöner Code aus Sicht von Software-Architekten (mehr)
Teil 2: Was macht schönen Code für Tester aus? (mehr)
Teil 3: Was ist schöner Code für Mobile und UI-Experten? (mehr)
Teil 4: Was ist schöner Code für Web-Experten? (mehr)
Lesetipps von den JAXenter-Experten: Nach dieser Lektüre schreibst Du schönen Code (mehr)

BEDcon 2016: Die 7 Regeln für gute Dokumentation in Stein gemeißelt?

By | Publikationen, Vorträge | No Comments
„Architekturdokumentation heute: Die 7 Regeln in Stein gemeißelt?“
Logo BEDcon
Stefan Zörner
Vortrag auf den Berlin Expert Days 2016
16. September 2016, 11:40 – 12:40 Uhr
Berlin, in der Urania

Download Folien Download (PDF)

„Schreibe aus Sicht des Lesers! Erkläre Deine Notation! Verwende eine Standardgliederung! …“ Die klassischen sieben Regeln für gute (Architektur-)dokumentation sind so alt, dass Ihr sie vielleicht gar nicht kennt.

Doch die Frage, wie Ihr Eure Lösungskonzepte festhaltet, kommuniziert und wirkungsvoll in der Umsetzung verankert, bleibt – und ihre Relevanz nimmt in Zeiten selbstorganisierter Teams eher noch zu.

Dieser Vortrag ruft Euch die Regeln nicht nur (falls nötig) in Erinnerung, sondern diskutiert und hinterfragt sie im heutigen Kontext. In dem leichtgewichtige Formen Schwergewichte wie die UML mehr und mehr verdrängen und in dem Entwickler die Architekturarbeit verantworten.

Lernt anhand praktischer Beispiele zeitgemäße Formen eines Architekturüberblicks und ein schlankes Vorgehen für dessen Erstellung kennen. Sowie Möglichkeiten, wie Ihr die Dokumentation näher an die Entwicklung bringt, und die Umsetzung Eurer Architektur dort angemessen überprüft. Von Richtlinien zu Prinzipien und Tests. Der Quelltext erzählt nicht die ganze Geschichte …

Download Vortragsfolien (PDF)

follow us on Twitter – @embarced