All Posts By

Stefan Zörner

Die Programmiersprache Go für Java-Entwickler auf dem JUG Saxony Day

By | Publikationen, Vorträge | No Comments
Go ist eine statisch getypte Programmiersprache von Google, die Syntax ähnlich zu C, C++ oder Java. Stefan Zörner nahm auf dem JUG Saxony Day im September die Programmiersprache unter die Lupe: 

Das wichtigste zu Go aus Java-Sicht

„Ein Kind der Cloud. Das wichtigste zu Go aus Java-Sicht“
Sprecher: Stefan Zörner

Vortrag auf dem JUG Saxony Day 2020
25. September 2020
Remote

Foliendownload (PDF)

Ich bin Anfang der 90er mit C groß geworden und habe Jahre professionell in Java entwickelt. Software zu bauen wandelte sich mit der Zeit, sie zu betreiben noch viel mehr. Trendthemen rückten andere Programmiersprachen ins Licht. So befeuerte Machine Learning das große Interesse an Python, es entstehen beeindruckende Browser-UIs in JavaScript. Das Cloud-Kind Go behauptet von sich effizient zu sein wie C und sich gleichzeitig anzufühlen wie eine Skript-Sprache.

In dieser Session zeige ich Go ganz unaufgeregt aus Sicht eines Java-Entwicklers. Zur Sprache kommen etwa Modularisierung und Unit-Tests aber auch webbasierte Services und ihr Bereitstellen als Docker-Image. Ihr könnt danach direkt loslegen. Oder informiert entscheiden, dass Ihr vielleicht doch nichts verpasst habt.

Das wichtigste zu Go aus Java-Sicht

JUG Saxony Day

Umfrageergebnisse

Hier die Ergebnisse der kleinen Umfrage für die Teilnehmer am Morgen, die später in der Go-Session dabei sein wollten. Ging ganz schnell, ingesamt 5 Fragen. 58 Leute hatten sich vorab beteiligt. Vielen Dank fürs Mitmachen!

Frage 2 Frage 2 Frage 3 Frage 4 Frage 5

Stefan Zörner mit einem Workshop beim Microservices Summit

By | Inhaltliches, Vorträge | No Comments

Summit Logo

„Continuous Documentation – Eure Microservices-Architektur gemeinsam beschreiben“
Sprecher: Stefan Zörner


Workshop auf dem Microservices Summit 2020
Montag, 08. Juni 2020, 14 – 17.30 Uhr (Remote)
@MicroservSummit

 

Vorhaben mit vertikalen Architekturstilen wie Microservices setzen auf technologische Freiheiten und unabhängige Teams. Gleichwohl bauen sie eine gemeinsame Anwendung, die sich zumindest aus Benutzer- und Betriebssicht zu einem gewissen Grad auch einheitlich darstellen soll. Dieses Spannungsfeld lässt sich auflösen, wenn Ihr den richtigen Rahmen schafft. Und genau einen solchen Unterbau lernt Ihr in diesem Workshop kennen!

Wir diskutieren methodisch unerlässliches Handwerkszeug wie Architekturvision und Makroarchitektur. Ihr lernt die Fragestellungen kennen, die jedes Vorhaben diskutieren sollte. Und wir schauen uns praktikable Ansätze an, wie Ihr Eure Microservices-Architektur gescheit festhaltet und teamübergreifend kommuniziert.

Schlussendlich geht es in diesem Workshop um den Entwurf, die Dokumentation und die Reflektion Eurer Microservices-Architektur. Zielformat ist aber eher ein Pixie-Buch als 100 Seiten. EDUF — Enough Design Up Front, um auf lange Sicht angemessen auf Änderungen reagieren zu können. Und gleichzeitig ein stimmiges Systemerlebnis zu bieten. Euren Anwendern und Euren Teams.

Microservices Summit 2020

SoftwarearchitekTOUR-Podcast bei heise zu Fitness Functions und Evolutionärer Architektur

By | Inhaltliches, Publikationen | No Comments


„Episode 71: Fitness Functions und evolutionäre Architektur“
Sandra Parsick im Gespräch mit Stefan Zörner
SoftwareArchitekTOUR (Podcast-Serie bei heise online)
veröffentlicht Dienstag, 07.April 2020

Link zum Podcast

Evolutionäre Architektur denkt Dinge anders als klassische Softwarearchitektur. So lädt sie Teams zu Anpassungen ihrer Lösungsansätze an neue Gegebenheiten geradezu ein. Aber taugen die neuen Ideen? Wie testet man überhaupt Softwarearchitektur? In dieser Folge diskutieren Sandra Parsick und Stefan Zörner Fitness Functions als eine Möglichkeit, um als Team frühzeitig und im Extremfall sogar automatisch Rückmeldung über die Wirkung der Architektur zu erhalten.

SoftwareArchitekTOUR Podcast

Wie sehen iSAQB CPSA-Advanced Prüfungsaufgaben eigentlich aus?

By | Allgemein, Inhaltliches | One Comment

diploma-3Der iSAQB-Einstiegslevel Foundation der Certified Professional for Software Architecture-Zertifierung (kurz: CPSA-F) sieht einen Multiple Choice Test als Prüfung vor. Bei der zweiten Stufe, dem Advanced Level (kurz: CPSA-A), bearbeitet der Prüfling hingegen eine Hausarbeit. Seine Lösung verteidigt er (bzw. sie) dann im Rahmen eines Interviews vor zwei Prüfern, die diese vorher durchgesehen und gegen Kriterien gehalten haben.

Bei einem Multiple Choice Test (also bei CPSA-F) ist relativ klar, was auf den Prüfling zukommt. Auch wenn einzelne Lernziele mit Ankreuzfragen nur schwer überprüfbar sind, und man sich konkrete Fragen dazu vielleicht nicht direkt vorstellen kann, gilt das zumindest für die Form der Prüfung. Zum Advanced-Level höre ich in Workshops oder per Mail dagegen immer wieder die Frage: Wie sieht eine solche Prüfungsaufgabe inhaltlich aus? Das ist nicht unmittelbar offensichtlich.

Nun sind die Prüfungsaufgaben selbst natürlich vertraulich (genau wie die Prüfungsfragen im Foundation Level). Vorlagen und Checklisten zur Erstellung von Aufgaben sind jedoch frei zugänglich (auf der Webseite des iSAQB). Sie sind nicht unbedingt leicht verdaulich — falsche Zielgruppe: sie sind für Leute gedacht, die sich neue Aufgaben ausdenken. Ich beschreibe daher im Folgenden mal, wie Aufgaben aufgebaut sind – für Leute, die demnächst ein solche Aufgabe lösen müssen. Was Sie als Advanced-Prüfling also grob erwartet…

Wie sieht eine Aufgabe grundsätzlich aus?
Das Fallbeispiel
Ihre Aufgabe
Ein Beispiel
Häufige Fragen zu Prüfungsaufgaben
Weitere Informationen
Überblick Prüfungsaufgabe

Wie sieht eine Aufgabe grundsätzlich aus?

Die Aufgabenstellung einer Prüfungsaufgabe für CPSA-Advanced umfasst mindestens 10 Seiten und höchstens 25 (siehe Abbildung rechte, die Seitenzahlen sind Beispielwerte).

Jede Aufgabe ist einer Systemart zugeordnet. Aktuell sind das

  • Informationssystem
  • Embedded System
  • Websystem

Ein Kandidat gibt bei der Anmeldung zur Prüfung die gewünschte Systemart an und erhält dann eine Aufgabe aus diesem Bereich. Damit soll verhindert werden, dass ein Prüfling mit einem Umfeld konfrontiert wird, das ihm völlig fremd ist. Auf Wunsch erhält der Prüfling kurze Abstracts (2-3 Sätze) von zwei verschiedenen Aufgabenstellungen und entscheidet sich dann für eine davon.

Jede Aufgabe selbst zerfällt dann in zwei grobe Blöcke: Ein Fallbeispiel in Form inhaltlicher Inputs, und die Aufgabenstellung selbst. Letztere ist in Teilaufgaben gegliedert. Die konkreten Prüfungsaufgaben variieren dabei in der Zusammenstellung der inhaltlichen Inputs und den Teilaufgaben erheblich.

Das Fallbeispiel

Prüfungsaufgaben: FallbeispielBeim Fallbeispiel handelt es sich um ein fiktives Projekt, eine Produktentwicklung, eine Migration oder ähnliches. Nach einem kurzen Überblick liegen konkrete Informationen dazu in Form inhaltlicher Inputs vor. Im Wesentlichen sind das Anforderungen, die der Prüfling in den späteren Teilaufgaben berücksichtigen muss. Denkbar sind etwa folgende Inhalte:

  • Funktionale Anforderungen (z.B. wichtige Use Cases, User Stories, …)
  • Qualitätsziele, ggf. verfeinert in Szenerien
  • Stakeholder (z.B. Liste, Personas)
  • Interviews mit Stakeholdern
  • Technische und/oder organisatorische Rahmenbedingungen
  • Fachlicher Kontext, Benutzer und Fremdsysteme
  • Normen und Konventionen
  • Risiken

Nicht jede Aufgabenstellung enthält dabei alle diese Inhalte. Weiterhin kann es sein, dass bestimmte Anforderungen explizit genannt sind, andere jedoch im Rahmen der Aufgabe erarbeitet werden müssen. Beispielsweise liegen mitunter Interviews mit Stakeholdern vor und die Rahmenbedingungen oder Qualitätsziele muss der Prüfling dann im Rahmen einer Teilaufgabe herausarbeiten und ggf. priorisieren.

Ihre Aufgabe

Prüfungsaufgaben: TeilaufgabenGanz ähnlich wie das Fallbeispiel mit seinen inhaltlichen Inputs, ist auch die Aufgabe unterteilt — in mindestens 5 und maximal 10 Teilaufgaben, die unterschiedliche Aspekte der Architekturarbeit abdecken. In Summe soll die Bearbeitung zeigen, dass der Prüfling in der Lage ist, aus Anforderungen methodisch eine Architektur zu entwerfen und festzuhalten, sie zu reflektieren und zu kommunizieren. Analog zu den denkbaren Inputs oben beim Fallbeispiel hier mögliche Teilaufgaben:

  • Kontext abgrenzen
  • Qualitätsziele identifizieren, Qualitätsbaum und -szenarien erarbeiten
  • Offene Fragen an Stakeholder formulieren
  • Lösungsstrategie/Architekturvision anfertigen
  • Architekturentscheidungen treffen
  • Technische Fragestellung inkl. Alternativen und Begründung bearbeiten
  • System strukturieren, fachlich zerlegen, Verantwortlichkeiten festlegen
  • Schnittstellen entwerfen
  • Technische und/oder übergreifende Aspekte bearbeiten
  • Lösung qualitativ bewerten
  • Risiken identifizieren und adressieren

Es gibt dabei Überschneidungen in inhaltlichen Inputs und Teilaufgaben: Der Systemkontext könnte etwa mit dem Fallbeispiel gegeben sein (als inhaltlicher Input) oder muss alternativ als Teilaufgabe erarbeitet werden.

Ein Beispiel

Das iSAQB stellt eine Beispielaufgabe bereit: „BigSpender“. Es handelt sich um eine echte Aufgabe, die früher gestellt, mittlerweile aber aus dem Pool genommen wurde, nachdem sie einige Prüflinge bearbeiten durften. Sie können die Prüfungsaufgabe hier als PDF herunterladen.

Inhaltlich geht es in der Aufgabe um Spesenabrechnungen. Das Fallbeispiel enthält dabei folgende Inhalte:

  • Input 1 – Überblick (1 Seite, Text)
  • Input 2 – Fachlicher Kontext (Diagramm und kurze Beschreibung der Akteure)
  • Input 3 – Fachklassenmodell (Diagramm) und Glossar (als Tabelle)
  • Input 4 – Stakeholder (knapp gehaltene Liste)
  • Input 5 – Interview mit dem Auftraggeber (recht umfangreich, ca. 3 Seiten)
  • Input 6 – Exemplarische User Stories (10 Stück)
  • Input 7 – Verfügbarkeit des Systems (Anforderung, als Szenario)
  • Input 8 – Technische Randbedingungen (als kurzer Text)
  • Input 9 – Mengengerüst (Tabelle, Aussagen zu Benutzern, Standorten, Vorgängen …)

Die eigentliche Aufgabe besteht dann aus 6 Teilen.

  • Teilaufgabe 1 – Qualitätsanforderungen herausarbeiten, in Form von Qualitätszielen und -szenarien
  • Teilaufgabe 2 – Lösungsstrategie entwickeln, Umfang ca. eine Seite
  • Teilaufgabe 3 – Technischen Kontext abgrenzen, Diagramm und Beschreibung zu Akteueren und Kommunikation
  • Teilaufgabe 4 – Fachliche Strukturierung erarbeiten (Bausteinsicht)
  • Teilaufgabe 5 – Technologie-Entscheidungen treffen
  • Teilaufgabe 6 – Bewertung der Lösung vornehmen, anhand der Qualitätsszenarien aus Teilaufgabe 1

Details entnehmen Sie dem PDF. Und beachten Sie, dass sich die Prüfungsaufgaben wie geschildert stark unterscheiden und es sich bei „BigSpender“ um ein Beispiel handelt – wenn auch um ein echtes.

Prüfungsaufgaben: FAQ

Häufige Fragen zu Prüfungsaufgaben

Wie wird sichergestellt, dass die Aufgabe zu den von mir besuchten Schulungen passt?

Eigentlich gar nicht. Durch die Angabe der Systemart (z.B. Web, Embedded) wird lediglich abgesichert, dass es technologisch grob passt. Ansonsten sind die Aufgaben nicht an bestimmte Module gebunden. Die Teilaufgaben (+ Interview) decken lediglich die drei Kompetenzbereiche („Säulen“) des Advanced-Levels ab (methodisch, technisch und kommunikativ).

Welchen Umfang hat meine Lösung?

Sie halten Ihre Lösung auf maximal 40 DIN A4-Seiten (inklusive Abbildungen) fest. Dazu haben Sie maximal 3 Monate Zeit (Details siehe Prüfungsordnung). Vom Aufwand sind die Teilaufgaben so bemessen, dass ein Prüfling sie in 40 Stunden erledigen kann.

Was wenn Technologien oder Methoden gefordert sind, die ich nicht beherrsche?

Die Aufgabenstellungen lassen Ihnen angemessenen Spielraum bezüglich Technologien, Werkzeugen, Notation und Ähnlichem. Wenn etwas explizit gefordert ist, so ist sichergestellt, dass Informationen dazu frei zugänglich sind. Entweder es liegt der Aufgabe bereits in den inhaltlichen Inputs oder in einem Anhang bei, oder es wird darauf verwiesen. Es kann natürlich vorkommen, dass Sie sich zur Lösung der Aufgabe noch Wissen aneignen müssen.

Was wenn mir die gegebenen Anforderungen zur Lösung nicht ausreichen?

Wie im richtigen Leben kann es sein, dass Ihnen zur Lösung der Aufgabe Informationen fehlen. Im Einzelfall scheinen sich Anforderungen sogar zu widersprechen (beispielsweise Aussagen in Interviews von Stakeholdern mit unterschiedlichen Prioritäten). Normalerweise klären Sie das im Projekt mit den Beteiligten, finden Kompromisse, etc.. Da Ihnen die Leute im Rahmen Ihrer Hausaufgabe nicht zur Verfügung stehen, treffen Sie Annahmen. Diese kennzeichnen Sie in Ihrer Lösung explizit als solche. Achten Sie darauf, dass diese sinnvoll und konsistent untereinander und zur Aufgabenstellung sind.

Soll ich meine Lösung nach arc42 strukturieren?

Die Antwort ist hier ein klares nein. arc42 ist ein verbreiteter Gliederungsvorschlag für Architekturbeschreibungen, daher wäre die Idee naheliegend. Für Ihre Lösung ist aber ganz klar die Vorgabe, dass Sie diese den Teilaufgaben entsprechend strukturieren. Also pro Teilaufgabe ein Abschnitt. Sie ermöglichen den Prüfern auf diese Weise die einfache Durchsicht and den Abgleich mit Kriterien.

Weitere Informationen

Ich hoffe, ich konnte einen Eindruck vermitteln, wie die Prüfungsaufgaben im CPSA-Advanced-Level grundsätzlich aussehen. Wenn Sie Fragen zu dem Thema haben, kommen Sie gerne auf mich zu. Ansonsten: Auf der iSAQB-Seite finden Sie vieles rund um den Advanced-Level. Hier noch ein paar weiterführende Links …

Eine erste Fassung dieses Beitrags erschien im Juni 2016. Sie wurde regelmäßig aktualisiert, zuletzt im April 2020.

Seminare bei embarc

Ein Steckbrief für das Erarbeiten von Fitness-Functions

By | Inhaltliches | No Comments

Evolutionäre Architektur ist als Trend schon lange im Gespräch. Konkret finden wir sie zum Beispiel auf dem Technology Radar bei Thoughtworks bereits 2010. Im entsprechenden O’Reilly-Buch von 2017 findet sich diese Definition:

„Eine evolutionäre Architektur unterstützt geleitete, inkrementelle Veränderungen über mehrere Dimensionen hinweg“. (N. Ford, R. Parsons, P. Kua, Patrick: Building Evolutionary Architectures)

Evolutionäre Architektur denkt einige Dinge anders als „klassische“ Softwarearchitektur. So werden dort Architekturentscheidungen nicht als schwer änderbar hingenommen. Stattdessen sind Änderungen in der Architektur aufgrund von Überraschungen willkommen und normal.

Ein Konzept, das eng mit Evolutionärer Architektur verknüpft ist, sind Fitness-Functions. Eine Fitness-Function misst objektiv, wie gut eine Lösung die an sie gesetzten Ziele erreicht. Fitness-Functions unterstützen genau die geleiteten Veränderungen, von denen in der Definition von Evolutionären Architektur die Rede ist. Sind wir mit unserer Lösung (noch) auf dem richtigen Weg? Halten neue Ideen, was sie versprechen? Wie bewerten wir Experimente, zum Beispiel mit neuen Technologien?

SteckbriefIm Rahmen unserer Coaching-Einsätze haben wir einen kleinen Steckbrief (oder „Canvas“) entwickelt, der uns und unsere Kunden bei der Entwicklung von Fitness-Functions unterstützt.

Teilnehmer des Workshops „Die Wirksamkeit Eurer Architektur automatisiert testen“ von Sandra Parsick und mir beim Software Architecture Summit in München dieses Jahr konnten diesen Steckbrief im Rahmen der Übungen für ihre eignen Projekte ausprobieren. Ich möchte dem Wunsch folgen, ihn hier zum Download bereit zu stellen … (Druckvorlage für 3 Steckbriefe inkl. Leitfragen zur Umsetzung).

Wie arbeitet Ihr mit dem Steckbrief? Tatsächlich steht das Erarbeiten und Umsetzen der Fitness Funktion nicht am Anfang. Im Workshop haben wir unser Vorgehen in 6 Schritten skizziert (Details in den Folien, insbesondere auch zu den Kategorien) – zu Beginn stehen die Architekturziele, verfeinert durch Beispielszenarien.

  1. Identifikation der Architekturziele
  2. Ausarbeitung von Beispielszenarien
  3. Auswahl für die Überprüfung
  4. Formulierung der Test-Idee
  5. Umsetzung und Automatisierung der Auswertung
  6. Sichtbarmachen der Resultate

Die Steckbriefe sammeln die Ergebnisse aus den Schritten 1, 2 und 4 im Vorgehen zusammen, und geben Input für 5 und 6. Pro Szenario gibt es dann eine Fitness-Funktion und dafür jeweils einen eigenen Steckbrief. Ausgefüllt sieht das Ganze z.B. so aus:

Fitness-Function Steckbrief, ausgefülltLassen wir uns ein kleines Beispiel durchspielen! Nehmen wir an, Eurer Team entwickelt eine Software, die lange leben soll. Ihr setzt dabei verschiedene Fremdbibliotheken ein. Oft werden diese Abhängigkeiten in Build-Skripten mit einer Version eingepflegt, diese dann aber nie aktualisiert. Was, wenn Ihr auf eine neue Version umsteigen müsst (z.B. weil dort ein Security-Problem gefixt wurde, das für Euch relevant ist …

Wir formulieren daher als Architekturziel zur Kompatibilität:

„Unsere Software läuft mit den aktuellen Versionen der eingesetzten Fremdbibliotheken.“

Das ganze verfeinern wir durch ein Beispielszenario (Über Qualitätsszenarien könnt Ihr z.B. in unserem arc42-Starschnitt nachlesen):

„Ein Open Source Projekt veröffentlicht eine neue Version einer von uns verwendeten Fremdbibliothek. Unsere Software lässt sich ohne Änderungen mit der neuen Version bauen und funktioniert damit einwandfrei.“

Zu diesem Szenario lässt sich eine Fitness Function formulieren, die absichert, dass bei Austausch einer verwendeten Fremdbibliothek x in Version n durch eine neuere Version n+1 die Software weiterhin baut und alle Tests besteht.

Umsetzen und automatisiert Auswerten lässt sich eine entsprechende Test-Idee durch

  1. Online-Überprüfung, ob zu einer Bibliothek eine neue Version verfügbar ist (Scannen der Repos),
  2. gezieltes Update der Bibliothek im Build-File in einem separaten Branch und
  3. Bauen des Branches und Durchlaufen der vorhandenen Tests.

Wenn Bauen und/oder Testen fehlschlagen weiß das Team frühzeitig, dass seine Software mit der neueren Version der Bibliothek nicht ohne Anpassungen funktioniert.

Dependabot bietet die beschriebene Funktion “von Hause aus” an. Wenn Schritt 1 eine neue Version für eine verwendete Abhängigkeit liefert (was Dependabot anhand des Build-Skripts prüft) legt das Werkzeug in GitHub einen eigenen Branch dafür an, modifiziert das Build-Skript, baut und meldet das Ergebnis. Im Erfolgsfall erzeugt es passende Pull-Requests zum Mergen:

Dependabot BeispielDas Team entscheidet, wie es mit dieser Erkenntnis umgeht. Mitunter kann es veraltete Funktionalität (Stichwort “deprecated”) der Fremdbibliothek durch neuere ersetzen, und den Test bestehen, ohne tatsächlich schon ein Update durchzuführen. Oder es stellt das Update als Aktivität unter “technische Schulden beheben” ein.

Bei kontinuierlichem Aktualisieren (oder dem Experimentieren damit) schlummern bei größeren Umbauten (z.B. neue Java-Version) keine unbekannten Risiken, die automatisierte Überprüfung mit Werkzeugen wie Dependabot nimmt dem Team hier Arbeit ab, die sich im Projektgeschäft manuell keiner macht.

Der Steckbrief hilft durch eine Kategorisierung im rechten oberen Bereich, Eure Test-Idee zu schärfen, und zur Umsetzung zu bringen. Die Kategorien sind in den Folien zum Workshop erklärt. Darüber hinaus haben wir ein paar „Leitfragen“ definiert, die Euch bei der Implementierung der Fitness-Funktion helfen. Sie sind auch in der Druckvorlage enthalten.

  • Wann, wie und wo führen wir die Testfunktion aus?
  • Wie kommen wir an die benötigten Daten?
  • Wie werten wir die Daten aus?
  • Was passiert, wenn die Ergebniskontrolle einen Fehler anzeigt?
  • Was passiert, wenn der Test selbst fehlschlägt?
  • Wie kommunizieren wir das Ergebnis ? Wie oft? Und an wen?

Die folgende Abbildung gibt einen Überblick über den Steckbrief und stellt die Bereiche in den Bezug zu den Schritten des Vorgehens oben.

Ausfüllen erklärt

Die Wirksamkeit Eurer Architektur automatisiert testen mit Sandra Parsick und Stefan Zörner

By | Publikationen, Vorträge | No Comments

Nicht-manuelle Tests stellen die Qualität einer Softwarelösung auf effiziente Weise sicher und sind Standard in der Software-Entwicklung. Auch weil die Automatisierung in der Regel früher Rückmeldung gibt zu Fehlern und anderen Unschönheiten. Der Ansatz ist auf verschiedenen funktionalen Ebenen gängig — Unit-Tests, Modul-Tests, Integrationstests… Wäre es nicht toll, auch Aspekte Eurer Softwarearchitektur automatisch testen zu können?

Was heißt es überhaupt, Eure Architektur zu testen? In diesem Workshop diskutieren wir zunächst kurz verschiedene Ansatzpunkte und Möglichkeiten dazu. Und wir räumen mit Mythen und Missverständnissen auf. So ist eine Überprüfung, ob eine Implementierung bestimmte Vorgaben einhält, zwar für einzelne Aspekte problemlos möglich. Wenn die Vorgaben nichts taugen ist das Ergebnis gleichzeitig uninteressant (und die Tests sind Verschwendung).

Konsequenterweise konzentrieren wir uns anschließend auf effektive Ansätze aus dem Chaos Engeneering und Fitness Functions. Denn diese können bei richtiger Anwendung die Wirksamkeit Eurer Architekturansätze langfristig absichern. Und sie erlauben eine zielgerichtete Weiterentwicklung Eurer Softwarelösung.

Anders als typische Literatur über Evolutionäre Architekturen hören wir nicht da auf, wo es konkret wird. Sondern zeigen Real-World-Beispiele und Implementierungsoptionen im Freiflug.

Interaktive Elemente und die Anwendung der Konzepte auf Eure Softwarlösungen runden den Workshop ab.

Graphic Recording von Lisa Moritz

Lisa Moritz (@Teapot4181) hat im Workshop live mit visualisiert. Hier das Resultat. Ein Dickes Danke dafür!!

Software Architecture Summit 2020

Ohne Firlefanz. Artikel zu prägnanten Architekturüberblicken auf Informatik Aktuell

By | Artikel, Publikationen | No Comments
Architektur ohne Firlefanz – Ihre Lösung auf einem Bierdeckel

Informatik Aktuell Logo


Viele interessieren sich für Ihre Softwarelösung oder zumindest für Teilaspekte davon: Neue im Team, teamfremde Kollegen, Manager, Kooperationspartner … – Wie geben Sie diesen Leuten einen prägnanten Einstieg? In diesem Beitrag erfahren Sie, wie Sie Schritt für Schritt einen prägnanten Architekturüberblick anfertigen. Ich diskutiere, was mindestens hineingehört und welche Formate sich in unterschiedlichen Situationen bewähren.

Artikel Online Lesen

Stefan Zörner live beim Special Day „Architektur“ der Java User Group Hamburg

By | Publikationen, Vorträge | No Comments

duke_JUG_Hamburg

„Architektur auf dem Bierdeckel – Eure Lösung in kurz und knackig“
Sprecher: Stefan Zörner
Special Day „Architektur“ der Java User Group Hamburg
Donnerstag, 19. September 2019, 14:00 bis 20:00
COYO GmbH, Gasstraße 6A, 22761 Hamburg

Foliendownload (PDF)

Viele interessieren sich für Eure Softwarelösung oder zumindest für Teilaspekte Eurer Lösung: Neue im Team, teamfremde Kollegen, Manager, Kooperationspartner … – Wie gebt Ihr diesen Leuten einen prägnanten Einstieg?

In dieser Session erfahrt Ihr, wie Ihr Schritt für Schritt einen prägnanten Architekturüberblick anfertigt. Ich diskutiere, was mindestens dazu gehört, welche Konzepte helfen, und welche Formate, Notationen und Werkzeuge sich in unterschiedlichen Situationen bewähren. Ihr lernt wie Ihr Euren Überblick aktuell haltet und in welchen Situationen Ihr besser mehr parat habt als das Minimum.

Der Vortrag ist gespickt mit Erfahrungswissen, Rezepten und Beispielen. Als Schmankerl zeige ich, wie ein methodisch clever gemachter Überblick es nicht nur ermöglicht, Eure Architektur wirkungsvoll zu kommunizieren. Sondern sie auch zu reflektieren und Risiken aufzudecken. Ob wir dabei mit den 107mm Durchmesser eines Bierdeckels auskommen, lasse ich hier mal offen …

follow us on Twitter – @embarced