Softwarearchitektur für alle!? · 28.09.17 2 Softwarearchitektur für alle!? embarc.de 3 Stefan Zörner n Softwareentwickler + -architekt bei embarc in Hamburg n Vorher oose, IBM,

28.09.17

1

Softwarearchitektur wird Entwicklerskill

STEFAN ZÖRNER // EMBARC

JUG Saxony Day // #JSD2017

Radebeul, 29.09.2017

0

Softwarearchitektur für alle!?

2 Softwarearchitektur für alle!? embarc.de

Softwarearchitektur für alle!?

„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 zum Entwicklerskill. In jedem cross-funktionalen Team sollte genügend Wissen und Können rund um diese Disziplin vorhanden sein. In diesem Vortrag zeige ich Euch, 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.

28.09.17

2


Stefan Zörner

n  Softwareentwickler + -architekt bei embarc in Hamburg n  Vorher oose, IBM, Mummert + Partner, Bayer AG, …

Schwerpunkte: n  Softwarearchitektur (Entwurf,

Bewertung, Dokumentation) n  Java Technologien

[email protected]

@StefanZoerner

xing.to/szr


1 Worum geht es?

2 Was ist zu tun?

3 Wie mache ich das?

4 Wo fangt Ihr an?

5 Fazit und weitere Informationen

Agenda

28.09.17

3


1 Worum geht es?

2 Was ist zu tun?


4 Wo fangt Ihr an?


Agenda

1


Was ist Softwarearchitektur?

Softwarearchitektur :=

∑ wichtige Entscheidungen

wichtig := n  fundamental (betrifft viele) n  im weiteren Verlauf nur schwer zu ändern n  maßgeblich für den Erfolg Eures Softwaresystems

28.09.17

4


Themen für Entscheidungen

Technologie-Stack Programmiersprache(n), Bibliotheken, Frameworks Middleware (Kommunikation, Applikationsserver ...) Querschnittsthemen (Persistenz, Oberfläche ...) ...

Zielumgebung Wo läuft die Software? (Endanwender vs. RZ vs. Cloud) Verteilungsaspekte (Redundanz, Clustering) Virtualisierung ...

Zerlegung Module und Abhängigkeiten Komponentenbildung ...


„Verunfallte“ Softwarearchitektur?

aus Grady Booch: „The Accidental Architecture“ IEEE Software 2006

„Every interesting software-intensive system has an architecture. While some of these architectures are intentional, most appear to be accidental.“

28.09.17

5


Großer Konzern (z.B. Versicherung) n  Anwendungen oftmals nach dem immer gleichen Muster gestrickt

n  Insbesondere Technologie-Stack überall gleich n  einzelne Entwickler-Teams konzentrieren sich auf Fachlichkeit und Funktionalität.

n  Veränderungen im Technologie-Stack gleichen Eruptionen

n  große Initiativen „Neue Anwendungsarchitektur“

Szene 1: Konzern-IT


Szene 2: Microservices

Mega-Trend Microservices n  verspricht schnelle Reaktion auf Veränderung durch kleine, unabhängige Einheiten

n  Teams verantworten die individuelle Technologieauswahl bis hin zu Betriebssystem und Programmiersprache

n  Entwickler geben freimütig Antworten auf Fragen, die sich im klassischen Großkonzern aus Szene 1 niemand stellt.

28.09.17

6


Makro- vs. Mikro-Architektur


Vorteile standardisierter Lösungen   Entwickler wechseln leicht zwischen Teams

und Projekten

  Konzentration auf Applikationsspezifika (z.B. Fachlichkeit) leichter möglich

  Wiederverwendung von techn. Lösungen

  Vermeidung von Fehlern in kritischen Bereichen durch erprobte Konzepte

  Geringere Kosten durch weniger Produkte (Lizenzen, Ausbildung von Spezialisten)

28.09.17

7


“Konzern-IT”


Vorteile individueller Lösungen

  Einsatz optimaler Lösungen für spezifische Probleme möglich

  Neue Trends lassen sich schneller aufgreifen

  Fehlentscheidungen haben geringere Relevanz

  Geringere Abhängigkeit von einzelnen Lieferanten ...

28.09.17

8


Microservices-Stil


These.

“Moderne Architekturansätze wie beispielsweise Microservices und

Self-contained Systems bieten Entwicklerteams mehr Spielraum für

konzeptionelle Arbeit. Softwarearchitektur wird

Entwickler-Skill.”

-- Stefan Zörner

28.09.17

9


1 Worum geht es?

2 Was ist zu tun?


4 Wo fangt Ihr an?


Agenda

2


Zu allererst: Den Kontext festlegen

n Ganzes n Teile

28.09.17

10


Den Kontext festlegen

Worüber reden wir eigentlich?

Optionen (Auswahl):   Eine Anwendung die in Module, Services,

Komponenten ... zerfällt? (Self-contained Systems, Microservices …)

  Eine Produktfamilie oder -linie, die in Varianten oder Ausprägungen zerfällt?

  Eine Systemlandschaft, die in Anwendungen zerfällt?

  ...

n Ganzes n Teil

Farbcode:


Nun: Makro- vs. Mikroarchitektur

Entscheidungen ... Welche Aspekte sind für alle Bestandteile gleich?

(Makro) Wo ist Spielraum?

(Mikro)

Damit Ihr das für Eurer Vorhaben oder Eure Welt erschließen könnt, hier eine Themensammlung ...

28.09.17

11


Themenkomplexe für Entscheidungen

Interaktion mit Benutzern und

Fremdsystemen

1

"Unter der Haube“

2

Entwicklung und Weiterentwicklung

3

Zielumgebung und Betrieb

4


Themenkomplex 1

n  Benutzeroberflächen (UI) n  Kommunikation und Integration n  Internationalisierung n  Ergonomie, Barrierefreiheit n  Plausibilisierung und Validierung n  Ausnahme-/ Fehlerbehandlung n  Ablauf-, Dialog- und Workflow-Steuerung n  ...

Interaktion mit Benutzern / Fremdsystemen

28.09.17

12


JUG Saxony Day 2017, Programm


„Passende“ Talks auf der Konferenz Interaktion mit Benutzern und Fremdsystemen

Barrierefrei von Anfang an - Software für alle bedienbar machen (Saskia Bader)

GraphQL, das bessere REST? (Jörg Adler + Benjamin Otto)

Cross Mobile Platform programming mit Go (Dr. Felix Socher + Johannes Tandler)

Integration

Ergonomie

Benutzeroberflächen

Refactoring to a system of systems (Oliver Gierke) Kommunikation

28.09.17

13


Themenkomplex 2

n  Persistenz n  Sicherheit, Authentifizierung / Autorisierung n  Transaktionsbehandlung n  Session- und Zustandsbehandlung n  Ereignis- und Fehlerbehandlung n  Parallelisierung und Threading n  Caching n  Geschäftsregeln n  ...

"Unter der Haube“


„Passende“ Talks auf der Konferenz "Unter der Haube“

OrientDB: Graphen in der Datenbank statt Knoten im Kopf (Jochen Binder)

Hibernate Tipps ’n’ Tricks - Schnelle Lösungen für typische Probleme und Anwendungsfälle (Thorben Janssen )

Persistenz

Persistenz

Going reactive with Spring Christoph Strobl Ereignisbehandlung

Rundungsfehler (Michael Wiedeking) Geschäftsregeln

28.09.17

14


Themenkomplex 3

n  Vorgehen, z.B. Scrum, BDD, UCD n  Modellierung n  Versionsverwaltung n  Build-Management n  Testen n  Code-Generierung n  Konfigurieren, Automatisieren n  Migration n  ...



„Passende“ Talks auf der Konferenz Entwicklung und Weiterentwicklung

Dein „Agiles Selfie“ (Jan Gentsch und Julia Dellnitz) Vorgehen

Git Advanced Topics (Alexander Groß) Versionsverwaltung

Es muss nicht gleich Docker sein - IT Automation, die zu einem passt (Sandra Parsick)

Build-Management

Konfigurieren

Der Technical Debt Manager (Jens Nerche) Vorgehen

28.09.17

15


Themenkomplex 4

n  Zielumgebung n  Verteilung, Deployment n  (Hoch-)verfügbarkeit, Disaster-Recovery n  Virtualisierung, Container n  Skalierung n  Resilienz n  Logging und Tracing n  Systemmanagement und Administrierung n  ...



„Passende“ Talks auf der Konferenz Zielumgebung und Betrieb

Überwache deine Microservices (Philipp Krenn)

Cut The Drama - Der Weg zu Continuous Deployments (Sascha Krüger und Fabian Linz)

Systemmanagement

Deployment

Skalierbare Webanwendungen (Thomas Bachmann )

Skalierung

Ihr redet über Resilience und wisst nicht was CAP & Co ist? (Christian Mennerich und Joachim Arrasz) Verteilung, Resilience

28.09.17

16


Interaktion mit Benutzern und

Fremdsystemen

1

"Unter der Haube“

2


3


4

Entscheidungen und Konzepte

Lösungsoptionen Architekturstile Architekturmuster Architekturprinzipien Bibliotheken Frameworks Middleware Modellgetrieben Aspektorientierung …


“Zeitlose” Softwarearchitektur

Wie Ihr zu den „richtigen“ Entscheidungen kommt ist langlebiger als Trends und konkrete Technologien. Vier wichtige Disziplinen:

Aufgaben-analyse

Architektur-entwurf

Architektur-bewertung

Architektur-dokumentation

28.09.17

17


Aufgabenanalyse: Tätigkeiten

  Kontext abgrenzen   Qualitätsziele verstehen   Rahmenbedingungen klären

Aufgaben-analyse

Architektur-entwurf




Architekturentwurf: Tätigkeiten

  Entscheidungen treffen   Strukturen definieren   Lösungskonzepte erarbeiten

Aufgaben-analyse

Architektur-entwurf



28.09.17

18


Architekturbewertung: Tätigkeiten

  Entscheidungen absichern   Risiken aufdecken   Zielerreichung prüfen   Kompromisse finden

Aufgaben-analyse

Architektur-entwurf




Architekturdokumentation: Tätigkeiten

  Entscheidungen festhalten   Lösungsideen breit kommunizieren   Architekturverwässerung vorbeugen

Aufgaben-analyse

Architektur-entwurf



28.09.17

19


“Klassische” Softwarearchitektur?

Aufgaben-analyse

Architektur-entwurf



Phasen? Nicht Dein Ernst, oder? WTF …


1 Worum geht es?

2 Was ist zu tun?


4 Wo fangt Ihr an?


Agenda

3

28.09.17

20


Iterative Architekturarbeit

Quelle: S. Toth, Vorgehensmuster für Softwarearchitektur


Ein paar nützliche Werkzeuge

Qualitätsziele (Aufgabenanalyse)

arc42 (Architekturdokumentation)

Architekturvision (Architekturentwurf)

Lösungsstrategie (Architekturbewertung)

28.09.17

21


Qualitätsziele

Aufgaben-analyse

Architektur-entwurf



Die wichtigsten geforderten Qualitätsmerkmale, um beim Treffen von Entscheidungen Orientierung zu geben, und um die Architektur nachvollziehbar zu machen.


Einflüsse auf Entscheidungen

-  schränken die Lösung ein

-  schließen Optionen aus

-  formen die Lösung -  nachher schwierig

“einzubauen” Qualitätsanforderungen Benutzbarkeit, Sicherheit ...

Rahmenbedingungen technisch organisatorisch

28.09.17

22


Qualitätsmerkmale

Zuverlässigkeit (Reliability)

Ist das System verfügbar, tolerant gegenüber Fehlern, nach Abstürzen schnell wieder hergestellt? ...

Begriffe nach Norm ISO 25010

Funktionalität (Functionality)

Sind die berechneten Ergebnisse korrekt / exakt, ist die Funktionalität angemessen? ...

Wartbarkeit (Maintainability)

Ist die Software leicht zu ändern, erweitern, testen, verstehen? Lassen sich Teile wiederverwenden? ...

Benutzbarkeit (Usability)

Ist die Software intuitiv zu bedienen, leicht zu erlernen, attraktiv?

Sicherheit (Security)

Ist das System sicher vor Angriffen? Sind Daten und Funktion vor unberechtigtem Zugriff geschützt? ...

Kompatibilität (Compatibility)

Ist die Software konform zu Standards, arbeitet sie gut mit anderen zusammen?

Effizienz (Performance)

Antwortet die Software schnell, hat sie einen hohen Durchsatz, einen geringen Ressourcenverbrauch? ...

Portabilität (Portability)

Ist die Software leicht auf andere Zielumgebungen (z.B. anderes OS) übertragbar?


Typische Wechselwirkungen

CAPTCHA := Completely Automated Public Turing test to tell Computers and Humans Apart.

28.09.17

23



Benutzbarkeit (Usability)

Ist die Software intuitiv zu bedienen, leicht zu erlernen, attraktiv?

Sicherheit (Security)

Ist das System sicher vor Angriffen? Sind Daten und Funktion vor unberechtigtem Zugriff geschützt? ...

Benutzer empfinden Sicherheitsmaßnahmen als störend (z. B. Passwortkomplexität, CAPTCHAs)

ì

î



28.09.17

24



Portabilität (Portability)

Ist die Software leicht auf andere Zielumgebungen (z.B. anderes OS) übertragbar?

Effizienz (Performance)

Antwortet die Software schnell, hat sie einen hohen Durchsatz, einen geringen Ressourcenverbrauch? ...

Abstraktionen (z. B. Schichten) reduzieren die Möglichkeit plattformspezifischer Optimierungen

ì

î

Qualitätsmerkmale hängen voneinander ab. Entscheidungen führen zu Kompromissen (engl. „Tradoff“).


Qualitative Architekturbewertung

ATAM Architecture tradeoff analysis method n  verbreitetste Methode zur

qualitativen Bewertung von Softwarearchitektur

n  früh anwendbar n  szenarienbasiert

28.09.17

25


Lösungsstrategie

Stellt Qualitätsziele und zugeordnete high-level Lösungsansätze einander gegenüber und erlaubt eine erste Bewertung.

Aufgaben-analyse

Architektur-entwurf




Architektur-/Lösungsansätze

Qualitätsziele

Die Brücke schlagen ...

Form: Tabelle, [ Ziele | Lösungsansätze ]

Quelle: S. Zörner, Softwarearchitekturen dokumentieren und kommunizieren

Siehe Themenkomplexe aus Abschnitt 2

28.09.17

26


Kategorien für Architekturansätze Typische Inhalte der rechten Spalte der Lösungsstrategietabelle, jeweils mit einem Beispiel und passendem Ziel (in Klammern).

Architekturstile •  z. B. Microservices (schnelle Adaption neuer technologischer Trends) Architekturmuster •  z. B. Schichtenarchitektur (leichte Austauschbarkeit des Clients oder

einfache Portierung der Lösung) Architekturprinzipien •  z. B. Bevorzuge Standards vor proprietären Lösungen (niedrige

Wartungsaufwände) Architekturentscheidungen •  z. B. Verwendung eines Application Server Clusters (hohe

Ausfallsicherheit) Konzepte •  z. B. Caching-Konzept (Effzienz, gute Antwortzeiten) Vorgehen •  z. B. User centered design (intuitive Benutzbarkeit)


Beispiel: Netflix (Ausschnitt) Ziel Passende Lösungsansätze

Hohe Verfügbarkeit

•  Betrieb in Amazon Cloud (Entscheidung) •  Circuit Breaker pattern (Muster)

Exzellente Benutzbarkeit

•  Netflix Client API (Entscheidung, Konzept) •  Reative Extensions

Leichter Austausch

•  Microservices (Architekturstil) •  Komplette Automatisierung (Vorgehen)

Attraktiver Arbeitgeber

•  Freedom and Responsibility (Prinzip) •  Einsatz modernster Technologien

... ...

Quelle: Stefan Toth, Stefan Zörner “Gut das ist? Umgekehrte Architekturbewertung eines Internetgiganten”

28.09.17

27


Architekturvision

Konkreter, schlanker Vorschlag, wie viel Architekturarbeit vor dem Start in die Realisierung geleistet sein sollte.

Aufgaben-analyse

Architektur-entwurf




Was mindestens zu Beginn?

Quelle: S. Toth, Vorgehensmuster für Softwarearchitektur

28.09.17

28


arc42 Ein Gliederungsvorschlag für Architekturbeschreibungen.

Aufgaben-analyse

Architektur-entwurf



è  arc42.org


arc42 – Struktur.

28.09.17

29


arc42 – Ergebnisse festhalten ...

Kontext abgrenzen

Qualitätsziele verstehen

Rahmenbedingungen klären

Aufgabenanalyse

Entscheidungen treffen

Strukturen definieren

Lösungskonzepte erarbeiten

Architekturentwurf

Entscheidungen absichern

Zielerreichung prüfen Kompromisse finden

Risiken aufdecken

Architekturbewertung


1 Worum geht es?

2 Was ist zu tun?


4 Wo fangt Ihr an?


Agenda

4

28.09.17

30


Softwarearchitektur: Stufen

zufällig 0 explizit 1

nachvollziehbar 2 wirkungsvoll 3

Ein kleiner Selbsttest für Euch und Eurer Team, um Handlungsbedarf zu identifizieren ...


(1) Zerlegung Wo finde ich die Struktur Eurer Lösung?

✔  Nur im Quelltext.

✔  Zerlegungsbegriffe sind etabliert (und Eurer Team verwendet sie durchgängig und gleich).

✔  Eine grobe Zerlegung (inkl. Abhängigkeiten) ist visualisiert und passend dazu im Quelltext.

✔  Die Struktur ist nachvollziehbar an den Anforderungen ausgerichtet (z.B. fachliche Zerlegung, Schichten)

✔  Teile (z.B. Module) werden (wo sinnvoll) über Teamgrenzen hinweg wiederverwendet.

28.09.17

31


(2) Übergreifende Konzepte Wie geht Ihr mit übergreifenden Aspekten und Fragestellungen um?

✔  Makro und Mikro-Architektur sind unklar.

✔  Einzelne Konzepte sind durchgängig eingehalten.

✔  Die Auswahl der Themen für einheitliche Konzepte ist nachvollziehbar (inkl. bewusstes Weglassen).

✔  Es gibt einen (individuellen) Lebenszyklus für Konzepte (Best Practice vs. Blueprint).

✔  Konzepte werden, wo sinnvoll, über Team- und Projektgrenzen geteilt.


(3) Kommunikation Wie beantwortet Ihr Fragen nach Architekturansätzen, -konzepten, -entscheidungen?

✔  „Historisch gewachsen.“

✔  „Da musst Du Rene fragen ...“

✔  Architekturansätze sind im Team bekannt, jeder kann sie einem Neuen nachvollziehbar erklären.

✔  Es findet ein Austausch zu Architekturansätzen über Produkt-/Teamgrenzen hinweg statt.

28.09.17

32


Stufen der Softwarearchitektur

0 (zufällig) Softwarearchitektur ist implizit, Erfolg Zufall.

1 (explizit) Architekturansätze sind explizit vorhanden und benennbar (Beispiele: Verwendung von Mustern, Entscheidungen für Frameworks)

2 (nachvollziehbar) Die Lösung ist an Zielen und Anforderungen nachvollziehbar ausgerichtet. Umsetzung und Architektur entsprechen sich.

3 (wirkungsvoll) Die Lösung und das Vorgehen der Architekturarbeit sind reflektiert und angemessen. Die Architektur wirkt über Team-/Produktgrenzen hinaus.


Risikogetriebene Architektur

“You should pay as much attention to software architecture as it contributes risk to the overall project, since if there is little architecture risk, then optimizing it only helps little.“

(George Fairbanks)

Risiken in Softwarearchitektur n  später schwer zu ändern

n  Umsetzung eher teuer

n  sehr hohe qualitative Anforderungen

n  schwere Integration in Bestehendes

n  wenig eigene Erfahrung im Lösungsspektrum

28.09.17

33


The risk is in the blocks!

Risiken im Team erarbeiten

Format   Workshop

Mitspieler   Eurer Team, inkl. PO, ggf. Kunde

Hilfsmittel   Jenga-Spiel   Flipchart (zum Festhalten der

Risiken)


The risk is in the blocks! -- Ablauf

n  Jeder im Team, der ein Risiko sieht, nennt es und zieht einen Block aus dem Stapel

Ø  hohes Risiko == weiter unten wegnehmen

n  Risiken werden festgehalten (inkl. Höhe, z.B. H/M/L)

n  andere Teammitglieder dürfen Fragen stellen

n  Das „Spiel“ endet, wenn a)  keine Risiken mehr kommen b)  der Turm einstürzt

n  Anschließend: Nachbereitung

28.09.17

34


è http://tastycupcakes.org/2013/04/the-risk-is-in-the-blocks/


1 Worum geht es?

2 Was ist zu tun?


4 Wo fangt Ihr an?


Agenda

5

28.09.17

35


tl;dr (too long; didn’t read)

Trends und Technologien haben kurze Halbwertszeiten, methodische Werkzeuge sind langlebiger. Sichert mit schlanken Hilfsmitteln daraus wie Architekturvision und Lösungsstrategie Eure Vorhaben ab!

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.

Moderne Architekturansätze bieten Entwicklerteams mehr Spielraum für konzeptionelle Arbeit. Heute machen mehr Entwickler Architektur.


Buchtipp: Vorgehensmuster für Softwarearchitektur

Kombinierbare Praktiken in Zeiten von Agile und Lean Autor: Stefan Toth (embarc) Umfang: ca. 270 Seiten Verlag: Carl Hanser Verlag, 2. Auflage 2015 Sprache: Deutsch ISBN: 978-3-446-44395-2

27

è  www.swamuster.de

28.09.17

36


Architektur-Spicker Unsere Architektur-Spicker beleuchten die konzeptionelle Seite der Softwareentwicklung.

è  embarc.de/architektur-spicker/


Wissen auf den Punkt.

è  embarc.de/architektur-spicker/

PDF, 4-6 Seiten Kostenloser Download. …

28.09.17

37


JUG Saxony Day 2017, Programm

Vielen Dank. Ich freue mich auf Eure Fragen!

[email protected]

xing.to/szr

@StefanZoerner

DOWNLOAD FOLIEN: http://www.embarc.de/blog/

Bei uns arbeiten?

28.09.17

38


Klingt interessant? Sprich uns gerne direkt an oder Mail an [email protected]

Berater/in gesucht! für Softwarearchitektur / Agilität / CD & DevOps / Microservices (Standort flexibel in Deutschland oder Wien)

§  Du brennst für ein Thema und bist motiviert, Dich mit aktuellen Trends tiefer auseinander zu setzen?

§  Du hast eher zu viele Ideen als zu wenige? §  Du teilst Deine Erkenntnisse und Erfahrungen gerne mit Kollegen

und denkst Themen weiter? §  Du stehst auf Pragmatismus, nicht auf Mikro-Management?

embarc.de/karriere

„Wir glauben weniger an ausgefeilte interne Strategien, als an die Möglichkeiten die entstehen wenn sich leidenschaftliche Leute

zusammenschließen.“

Bereit zum Durchstarten? Da haben wir was...

Documents

Softwarearchitektur für alle!? · 28.09.17 2 Softwarearchitektur für alle!? embarc.de 3 Stefan Zörner n Softwareentwickler + -architekt bei embarc in Hamburg n Vorher oose, IBM,