Softwarearchitektur für alle!?...Microservices-Stil Softwarearchitektur für alle!? embarc.de 16 These. “Moderne Architekturansätze wie beispielsweise Microservices und Self-contained

11.09.17

1

Softwarearchitektur wird Entwicklerskill

STEFAN ZÖRNER, EMBARC

Java Forum Nord 2017

Hannover, 12.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.

11.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

11.09.17

3


1 Worum geht es?

2 Was ist zu tun?


4 Wo fangt Ihr an?


Agenda

1


Was ist Softwarearchitektur?

wichtig := n  fundamental n  im weiteren Verlauf nur schwer zu ändern n  entscheidend für den Erfolg des Softwaresystems

Softwarearchitektur :=

∑ wichtige Entscheidungen

11.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.“

11.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“ n  „Alte Welt“ vs. „Neue Welt“

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.

11.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   Vermeidung von Fehlern in kritischen

Bereichen durch erprobte Konzepte   Geringere Kosten durch weniger Produkte

(Lizenzen, Ausbildung von Spezialisten)   Wiederverwendung von Lösungen über

Applikationsgrenzen hinweg leichter ...

11.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 ...

11.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

11.09.17

9


1 Worum geht es?

2 Was ist zu tun?


4 Wo fangt Ihr an?


Agenda

2


Zu allererst: 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:

11.09.17

10


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


Themenkomplexe für Entscheidungen

Interaktion mit Benutzern und

Fremdsystemen

1

"Unter der Haube“

2

Entwicklung und Weiterentwicklung

3

Zielumgebung und Betrieb

4

11.09.17

11


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


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

Dennis Kieselhorst: Mehr als nur Schnittstellenbeschreibung: Die OpenAPI Specification aka Swagger

Oliver Zeigermann: Moderne Web Entwicklung mit React und TypeScript

Die 7 Todsünden des Workflow Managements (Bernd Rücker)

Benutzeroberflächen (UI) Kommunikation und Integration

Ablauf-, Dialog- und

Workflow-Steuerung

11.09.17

12


Themenkomplex 2

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

"Unter der Haube“


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

Was modernes SQL alles kann, dir aber niemand gesagt hat (Markus Winand)

Crypto 101 (Oliver Milke)

Riding the Jet-Stream (Christoph Engelbert)

Eine kleine Reise durch NoSQL (Christian Mennerich)

Persistenz

Persistenz

Sicherheit

Parallelisierung und Threading

11.09.17

13


Themenkomplex 3

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



„Passende“ Talks auf der Konferenz Entwicklung und Weiterentwicklung

Selbstorganisierte agile Teams - zwischen Autonomie, Selbstbeschränkung und Chaos (Frank Düsterbeck)

It's all about the domain, honey - Fachliche Architektur für Java mit DDD (Henning Schwentner)

Gitlab, GitlabCI, Docker, Maven und wie man damit code shared (Niklas Grebe)

Vorgehen

Modellierung

Build-Management

11.09.17

14


Themenkomplex 4

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



„Passende“ Talks auf der Konferenz Zielumgebung und Betrieb

Wer braucht schon einen Server? Serverless Java in der Cloud! (Lars Röwekamp)

Cloud Native Java EE mit WildFly Swarm (Matthias Wessendorf)

Ihr redet über Resilience und wisst nicht was CAP & Co ist? (Ch. Mennerich & J. Arras)

Virtualisierung

Zielumgebung

Resilienz, Verfügbarkeit

11.09.17

15


Entscheidungen und Konzepte

Interaktion mit Benutzern und

Fremdsystemen

1

"Unter der Haube“

2


3


4

Lösungsoptionen Architekturmuster Architekturprinzipien Architekturstile 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

11.09.17

16


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



11.09.17

17


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



11.09.17

18


“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

11.09.17

19


Iterative Architekturarbeit


Ein paar nützliche Werkzeuge

Qualitätsziele (Aufgabenanalyse)

arc42 (Architekturdokumentation)

Architekturvision (Architekturentwurf)

Lösungsstrategie (Architekturbewertung)

11.09.17

20


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

11.09.17

21


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

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)

ì

î

11.09.17

22


Typische Wechselwirkungen

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

11.09.17

23


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

Architektur-/Qualitätsziele

Die Brücke schlagen ...

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

Siehe Themenkomplexe aus Abschnitt 2

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

11.09.17

24


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

11.09.17

25


arc42 Ein Gliederungsvorschlag für Architekturbeschreibungen.

Aufgaben-analyse

Architektur-entwurf



è  arc42.org


arc42 – Struktur.

11.09.17

26


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

11.09.17

27


Stufen der Softwarearchitektur

zufällig 0 explizit 1

nachvollziehbar 2 wirkungsvoll 3

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


Kommunikation

Wie werden bei Euch Fragen nach Architektur-entscheidungen, -ansätzen, -konzepten beantwortet?

n  „Historisch gewachsen …“

n  Es findet ein Austausch über die Architektur über Produkt-/Teamgrenzen hinweg statt.

n  Architekturansätze sind im Team bekannt und können neuen Mitarbeitern nachvollziehbar erklärt werden.

n  „Da musst Du Rene fragen …“

11.09.17

28


Struktur

Wo finde ich die Struktur der Lösung?

n  nur im Quelltext

n  Teile/Komponenten werden (wo sinnvoll) über Teamgrenzen hinweg wiederverwendet

n  die Strukturen (z.B. Schichten, fachliche Zerlegung, Begriffe) sind nachvollziehbar an den Anforderungen ausgerichtet.

n  in Diagrammen / Modellen und konsistent dazu im Quelltext


Übergreifende Konzepte Wie wird mit übergreifenden Aspekten und Fragestellungen umgegangen?

n  Tendenziell gibt es keine. Die Lösung ist inkonsistent. Makro- und Mikroarchitektur sind unscharf.

n  Einzelne Konzepte sind durchgängig eingehalten.

n  Die Konzepte sind an den Qualitätszielen ausgerichtet.

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

n  Lösungen für einheitliche Konzepte werden, wo sinnvoll, über Team- und Produktgrenzen geteilt.

11.09.17

29


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

11.09.17

30



The risk is in the blocks! Risiken im Team erarbeiten Hilfsmittel •  Jenga-Spiel •  Flipchart (zum Festhalten der

Risiken)

Mitspieler •  Team, inkl. PO, ggf. Kunde

11.09.17

31


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


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

11.09.17

32


1 Worum geht es?

2 Was ist zu tun?


4 Wo fangt Ihr an?


Agenda

5


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

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

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.

11.09.17

33


Buchtipp: Vorgehensmuster für Softwarearchitektur

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

27


Spicken erlaubt! Unsere Architektur-Spicker beleuchten die konzeptionelle Seite der Softwareentwicklung.

è  embarc.de/architektur-spicker/

11.09.17

34


Hier auf dem Java Forum Nord ...

3 Ausgaben unserer Architektur-Spicker im Bündel zum Mitnehmen ...

-  Microservices -  Architektur-Reviews -  Cloud-Anwendungen

Vielen Dank. Ich freue mich auf Eure Fragen!

[email protected]

xing.to/szr

@StefanZoerner

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

Bei uns arbeiten?

11.09.17

35


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!?...Microservices-Stil Softwarearchitektur für alle!? embarc.de 16 These. “Moderne Architekturansätze wie beispielsweise Microservices und Self-contained