SOFTWARE-ARCHITEKTUREN IN DER PRAXIS - exxcellent.de · Architektur bildet die Grundlage für...

the essence for your business.

SOFTWARE-ARCHITEKTUREN IN DER PRAXIS

Benjamin Schmid Stefan Becker

Koblenz, 27.06.2017

2

Einleitung

Architektur-Beschreibung

Architekturmuster

Architektur in der Praxis

Wege zu einer guten Architektur

3

eXXcellent solutions

Die Referenten

Stefan Becker Software Engineer [email protected]

Benjamin Schmid Technology Advisor & Head of Division Darmstadt @bentolor

[email protected]

Einleitung Architektur-Beschreibung Architekturmuster Architektur in der Praxis Wege zu einer guten Architektur

4


Wer sind wir?

4 Standorte

130 Mitarbeiter

16,0 Mio € Umsatz p.a.

DIN EN ISO 9001:2015 / 14001:2015

Darmstadt

Stuttgart

Ulm München


Individuelle Software-Lösungen

Agil / Festpreis / Time & Material

„Kernprozesse von Unternehmen“

Java, Web & .NET, SAP HANA & Salesforce

5

Beratung & Consulting rund um IT-Lösungen

Business & Projekt Management

Technologie & Methodik


Was machen wir?


Eine Softwarearchitektur ist eine Zerlegung eines

Systems in Bausteine und deren Beziehungen

zueinander und zur Umgebung sowie den

Richtlinien, die den Entwurf und die Evolution des

Systems bestimmen.

Grundlagen der Softwaretechnik 2016 Universität Koblenz, Prof. Jan Jürjens

6

The highest-level breakdown of a system into its

parts; the decisions that are hard to change; there

are multiple architectures in a system; what is

architecturally significant can change over a

system's lifetime; and, in the end, architecture

boils down to whatever the important stuff is.

Martin Fowler

7

Warum ist Software-Architektur wichtig?

8

Zur Kommunikation zwischen Stakeholdern

Viele Akteure sind an der Entstehung von Software beteiligt

Jeder bringt einen anderen Hintergrund mit

Architektur schafft eine gemeinsame Sprache

Vermittelt einen Überblick zur Aufteilung

Architektur bildet die Grundlage für gemeinsame Diskussionen, Abstimmungen und Entscheidungen

Software Architecture in Practice (2013) Bass, Len., Clements, Paul. und Kazman, Rick



9

Als eine übertragbare Abstraktion eines Systems

Software-Architektur definiert ein Modell …

das beschreibt wie das System strukturiert ist

und wie die Komponenten zusammenarbeiten

Das Model kann auf andere Systeme mit ähnlichen funktionalen und nicht funktionalen Anforderungen übertragen werden




10

Um Anforderungen zu adressieren

Software muss Anforderungen genügen

Architektur plant Lösungsmuster für Probleme

Erlaubt so eine Verifizierung ob Anforderungen erfüllt sind

Software-Architektur alleine reicht nicht aus um alle Anforderungen zu erfüllen

Es muss aber mindestens sichergestellt sein, dass sie den Anforderungen nicht entgegen steht



11

Einleitung


Architekturmuster



Ist die Zielsetzung/Problemstellung präzise definiert?

Sind die zentraleren Lösungsansätze skizziert?

Gibt es einen abstrakten Gesamtüberblick?

Ist die Dokumentation für alle Beteiligten verständlich?

12

Was zeichnet eine gute Architektur-Dokumentation aus?

Für gute Dokumentation zählen die Inhalte …


13

Wichtige Inhalte einer Architektur-Dokumentation

Zielsetzung


Die Zielsetzung muss klar verständlich in wenigen Sätzen oder Stichpunkten zusammengefasst sein.

Build a platform and service patterns that provide highly available services without requiring the application services, platform services or infrastructure to be highly available. Zielsetzung für die Netflix Cloud Architecture von Adrian Cockcroft

14


Beschreibung der Architekturziele, deren Motivation und Lösungsansätze

Architekturziel Motivation Lösungsansatz

Hohe Verfügbarkeit Weltweites Angebot, Erwartung der Kunden

Betrieb in der Cloud (AWS), Circut Break Pattern

Skalierbarkeit Mehr als 98 Millionen Nutzer, Lastspitzen

Microservice

Unterstützung verschiedener Endgeräten

Kunden sollen Fernseher, Laptop, Tablets usw. nutzen können

Netflix Client API

… … …

Die wichtigsten Architekturziele sollten zusammen mit Lösungsansätzen dokumentiert werden.


15


Big Picture das Bestandteile und Zusammenhänge darstellt


http://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_media_02.pdf

kann ganz unterschiedlich beschrieben sein:

Dokument

Foliensatz

Wiki/Portal

Architektur-Flyer

Projekt-Wand

…

16

Was zeichnet eine gute Architektur-Dokumentation aus?

Eine gute Dokumentation …


17

Einleitung


Architekturmuster



18

Architekturmuster

Was ist eine Schichten-Architektur?

Die Schichten-Architektur ist ein verbreitetes Strukturierungsprinzip für Software-Systeme

Es gelten folgende Regeln:

Schichten erfüllen eine spezifische Art von Funktion

Zwischen den Schichten gibt es eine definierte Reinfolge

Schichten greifen nur auf direkt darunterliegende Schichten zu

Layer n+2

Layer n+1

Layer n


19

Architekturmuster

Was sind die Vorteile und Nachteile von Schichten-Architektur?

– Code-Abhängigkeiten werden reduziert

– Grundfunktionalität ist sauber strukturiert

– Schichten-Architektur bietet wenig Führung

– Saubere Trennung erfordert Planung und Disziplin

– Daten über mehrere Schichten hinweg auszutauschen kann sich negativ auf die Performance auswirken

– Vorteile – Nachteile


20

Architekturmuster

Was sind die Vorteile und Nachteile von Schichten-Architektur?

– Informationsfluss entgegen Schichtung erfordert Benachrichtigungsmechanismen, um Abhängigkeiten zu vermeiden

– Nach Möglichkeit sollte der korrekte Zugriff technisch sichergestellt werden

– Praktische Anwendung


21

Architekturmuster

Mein System™

Microservices sind eine Ausprägung einer verteilten Architektur bei der ein System in viele sehr kleine Services unterteilt wird.

Charakteristik von Microservices:

Ein Service kapselt genau eine fachliche Funktion

Die Services laufen jeweils in einem eigenen Prozess

Kommunikation über leichtgewichtige Mechanismen

Service

Service

Service

Service

Microservices


23

Architekturmuster

Was sind die Vorteile und Nachteile von Microservices?

– Services können einzeln

l entwickelt

l und deployed werden

– Hoher Freiheitsgrad bei Technologieauswahl

– Gezielte Skalierung von Fachlichkeit

– Immenser Kommunikations-Overhead

– Verteilte Systeme führen zu zusätzlicher Komplexität

l Entwicklung

l Testing

l Betrieb

– Teilweise redundante Datenspeicherung



24

Architekturmuster

Was sind die Vorteile und Nachteile von Microservices?

- Unglaublich Hipp und in aller Munde

- Unabhängiges Deployment ist nur dann möglich wenn sich die Fachlichkeit nur innerhalb eines Services ändert, Schnittstellen und auszutauschende Daten müssen gleich bleiben

- Der technische und organisatorische Overhead rentiert sich nur für (sehr) große Organisationen und Softwaresysteme

– Praktische Anwendung


25

Architekturmuster

Was ist ein Monolith?

Mein System™

Eine monolithische Architektur ist ein Architekturstil bei dem das gebaute System aus einer deploybaren Einheit besteht.

Das bedeutet allerdings nicht, dass das System intern nicht sinnvoll unterteilt ist!

Monolith

Service

Service Service

Service


26

Architekturmuster

Was sind die Vorteile und Nachteile von Monolithen?

– Gemeinsame, konsistente Datenbasis

– Refactoring ist einfacher, da keine Nachbarsysteme betroffen sind

– Aufrufe innerhalb eines Prozess sind sehr günstig

– Änderungen innerhalb des System erfordern ein vollständiges Deployment

– Wenig technologische Freiräume innerhalb des Systems



Architekturmuster

Wie skalieren Microservices und Monolithen?

Server 1

Service

Service

Service

Service

Service

Service Service

Service

Server 2

Service

Server 3

Service

Service

Service

Service

Server 4

Service

Service

Service

Service

Server 1

Monolith

Service

Service Service

Service

Server 2

Monolith

Service

Service Service

Service

Server 3

Monolith

Service

Service Service

Service

Server 4

Monolith

Service

Service Service

Service

28

Einleitung


Architekturmuster



29


Lösungsmuster / Patterns – Beispiel: Schichtenarchitektur

Layer n+2

Layer n+1

Layer n

…

…


UI Layer

Service Layer

Persistence Layer

30



Mein System™

UI Layer

Service Layer

Persistence Layer

Der „Archetyp“ der IT-Architektur Prevalenz:

gefühlt >90% der Projekte

In der Theorie:

sehr grobe Leitlinien

gibt nur wenig Antworten

In der Praxis:

…

31



Mein System™


Service Layer

UI Layer

32


Schichtenarchitektur – Die Praxis

Mein System™

Persistence Layer


… ist ein wesentlicher Erfolgsfaktor für:

ein gemeinsames Verständnis

die Reduktion der Komplexität

Ein guter Architektur-Schnitt ermöglicht:

gute Projektorganisation

leistungsfähige Lösungen

Wiederverwendung

gute Anpassbarkeit & Evolution

33


Eine gute Software-Architektur …


Architekturmuster

Schichtenarchitektur / 3-Schicht

Pipes & Filter Peer-to-Peer (P2P)

Command Query Responsibility Segregation (CRQS)

Entwurfsmuster

GoF: Proxy, Observer, Singleton

MapReduce

Inversion of Control

34


Lösungsmuster / Patterns

grob Granularität fein

…bewährte Lösungen für wiederkehrende Entwurfsprobleme

…beschreiben Kontext und Anwendbarkeit der Lösung

Pattern-Oriented Software Architecture: A System of Patterns by Buschmann F.; Meunier R.; Rohnert H.; Sommerlad P.; Stal M. (1996). Design Patterns: Elements of Reusable Object-Oriented Software by: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1994)

Model-View-Viewmodel (MVVM)

MapReduce

Data Transfer Objects (DTO)

Inversion of Control

35


Module & Softwareevolution

Benutzerverwaltung

Bestellungen


36



Benutzerverwaltung

Bestellungen


37



Benutzerverwaltung

Bestellungen

Session


38



Benutzerverwaltung

Authentifizierung Bestellungen

Session


39



Benutzerverwaltung


Session


40



Benutzerverwaltung Textfield


Session

Manager


41



„GUI“

Hans „Stammdaten“

Franziska

Benutzerverwaltung Textfield


Session

Manager


Stefan

… ist ein wesentlicher Erfolgsfaktor für:

ein gemeinsames Verständnis

die Reduktion der Komplexität

Ein guter Architektur-Schnitt ermöglicht:

gute Projektorganisation

leistungsfähige Lösungen

Wiederverwendung

gute Anpassbarkeit & Evolution

… denn sie zeichnet sich dadurch aus, dass:

1. kleine Änderungen auch nur kleine, lokale Systemänderungen erfordern

2. konzeptionell schlüssig ist & bleibt:

Klarheit

Einfachheit, Eleganz

Praktikabilität

Anforderungserfüllung

42


Eine gute Software-Architektur …


WORAN ERKENNE ICH EINEN GUTEN ENTWURF?

Preisfrage

43

A good modular, componentized design

means minimizing the knowledge and

dependency one part of the system has to

have about another.

Rolf Howarth

44

45



Modul

Modul

Modul


46


Woran erkenne ich einen guten Entwurf?

Daumennagelproben

Kennt jedes Team-Mitglied die Ziel-Architektur?

Kann jeder intuitiv und sofort beantworten „wo“ ein bestimmter Teil zu suchen ist?

Versteht jeder sofort, „wie“ eine bestimmte Funktionalität realisiert/zerlegt wird?

Gibt es wenige & unidirektionale Abhängigkeiten?

Beantwortet meine Architektur sowohl grundsätzliche als auch täglichen Detailfragen?

Kommunik.

Klarheit

Zerlegung

Abtraktions- Ebenen

47

Microservices to the rescue!

Martin‘s Life Pro-Tipp

I've noticed a common pattern:

1. Almost all the successful microservice stories have started

with a monolith that got too big and was broken up

2. Almost all the cases where I've heard of a system that was

built as a microservice system from scratch, it has ended

up in serious trouble.

This pattern has led many of my colleagues to argue that …

48

Martin‘s Life Pro-Tipp

[…] you shouldn't start a new project

with microservices, even if you're

sure your application will be big

enough to make it worthwhile.

Martin Fowler

https://martinfowler.com/bliki/MonolithFirst.html

49

50

Einleitung


Architekturmuster



51


Der Weg (Plan)

Problemstellung identifizieren

Lösungsstrategie entwickeln

Software-Design Lösungs-

architektur


52


Der Weg (Realität)

Problemstellung identifizieren

Lösungsstrategie entwickeln

Evolution des Software-Design

Lösungs- architektur

Neue Probleme/ Details/Anforderungen

Design-Refactoring

(Entwickler-Alltag!)

Große, neue Probleme/ Details/Anforderungen

Architektur-Refactoring

(ouch!)


Software-Design

Produktfunktionen

Funktionen die das System erfüllen können muss/soll, z.B. beschrieben über Use Cases

Technische Randbedingungen

Verfügbare Hard-/Software

Organisatorische Randbedingungen

Termine, Budgets, Schnitt der Abteilungen, Team, Kompetenz

Ziele & Risiken

Produktattribute (~illities)

Eigenschaften die das System besitzen muss

z.B. Scalability, Reliability, Flexibility, Usability, …

Funktionale Anforderungen Nicht-funktionale Anforderungen Randbedingungen


Rückschau: Wichtige Einflussfaktoren für eine Architektur

Grady Booch: Objektorientierte Analyse und Design. 1994, ISBN 978-3-89319-673-9, S. 291 f.

53



54

Das passenden Werkzeug!

ATAM (Architecture Trade-Off Analysis Method)

Eine Evaluationsmethode entwickelt in den ’90er an der Carnegie Mellon University

Zweck: Konsequenzen von Architektur- entscheidungen anhand von Qualitäts- eigenschaften bewerten

Hilft bei der Abschätzung wie eine Architekturentscheidung zentrale Eigenschaften beeinflusst

Qualitätsattribute werden über Szenarien der Stakeholder erarbeitet

Validierung des Architekturentwurf (Muster & Stil) über diese Szenarien & Qualitätsattribute

"ATAM: Method for Architecture Evaluation“ by Rick Kazman; Mark Klein; Paul Clements, 2000 https://www.sei.cmu.edu/reports/00tr004.pdf


55

Risiken

Kritische Punkte, die zentrale Produktattribute/ -funktionen in Frage stellen

Nicht-Risiken

Helfen bei Qualität & Zielerreichungsgrad

Schmerzpunkte

Neuralgische Bereiche die zentrale Qualitäten bedrohen

Tradeoffs

Abwägungen bei Ziel-Konflikten

Lenkt den Prozess um die richtigen Fragen an die Stakeholder zu stellen und regt den gegenseitigen Austausch an

Strukturierte, präzise und für die Stakeholder transparente Entscheidungsbasis mittels abgestimmten Qualitätsbaum und Szenarien

Tradeoffs werden identifiziert, benannt, mit den Stakeholdern abgestimmt und dokumentiert

Dokumentiert die Architekturentscheidungen & verworfene Architekturansätze

Konzepte Vorteile


ATAM - Übersicht



ATAM - Überblick

Geschäftsziele

Software-Architektur

Architektur- Ansätze

Qualitäts- Attribute

Szenarien

Architektur- Entscheidungen

Analyse

Tradeoffs

Sensitive Points

Nicht-Risiken

Risiken Risiko-

Kategorien

56


57


Mit ATAM zum Ziel

9 SCHRITTE

2 PHASEN


1. Vorstellung ATAM-Prozess

2. Vorstellung Geschäftsziele

3. Vorstellung Architekturentwurf

4. Architekturansätze

5. Erstellung Qualitätsbaum

6. Analyse der Architekturansätze

7. Szenarien: Analyse & Priorisierung

8. Analyse des Architekturentwurfs

9. Präsentation der Ergebnisse

ATAM – Vorstellung ATAM-Prozess V

ors

tell

un

g

An

aly

se

Te

st

Ko

mm

.

58


59


ATAM – Vorstellung ATAM-Prozess










Vo

rste

llu

ng

A

na

lyse

T

est

K

om

m.

Der ATAM-Prozess wird allen Beteiligten vorgestellt.

Ziel: Alle Beteiligte verstehen seinen Ablauf & Funktionsweise.


60












Vo

rste

llu

ng

A

na

lyse

T

est

K

om

m.

Die Stakeholder (Fachabteilungen) präsentieren Motivation und Geschäftsziele.

Damit werden auch die zentralen Treiber für die Systementwicklung benannt.


61












Vo

rste

llu

ng

A

na

lyse

T

est

K

om

m.

Allen Beteiligten (Manager, Fachabteilung, …) wird im angemessenem Detailgrad der Architekturentwurf präsentiert.

Schwerpunkt liegt dabei darauf, wie dieser Entwurf die zentralen Anforderungen und Geschäftsziele erfüllt bzw. nicht erfüllt.


62












Vo

rste

llu

ng

A

na

lyse

T

est

K

om

m.

Die verschiedene verschiedenen Architektur-Ansätze werden im Architekten-Team diskutiert, ohne sie aber im Detail zu analysieren.

Hier geht es um ein gemeinsames Bild der wesentlichen Eckpunkte der Ansätze zu erhalten.


63












Vo

rste

llu

ng

A

na

lyse

T

est

K

om

m.

In kleiner Runde werden mit den Stakeholdern die zentrale Qualitätsattribute erarbeitet und in einen Qualitätsbaum einsortiert

Dabei konkretisieren die Stakeholder über ausformulierte Szenarien ihre Anforderungen (Beschreibung: Stimulus und Reaktion).

Die identifizierten Qualitätsattribute werden der Ziel-Architektur gegenübergestellt.



Beispiel für ATAM-Szenarien

Ein vollständiger Datenimport darf max. 4h dauern.

Login über Twitter in 2 Tagen implementierbar.

Jederzeit möglich, Bestellungen aufzugeben.

Bei Stromausfall dürfen keine Daten verloren gehen.

64


Beispiel für ATAM-Szenarien

Ein vollständiger Datenimport darf max. 4h dauern.

Login über Twitter in 2 Tagen implementierbar.

Jederzeit möglich, Bestellungen aufzugeben.

Bei Stromausfall dürfen keine Daten verloren gehen.

65

Performance > Durchsatz

Erweiterbarkeit

Verfügbarkeit

Unerwartete Ereignisse


66

ATAM Qualitätsbaum („utility tree“)



67

ATAM Qualitätsbaum („utility tree“)

Kritikalität Priorität

High / Middle /Low

1) Qualität

3) Szenario Kontext und Umgebung Stimulus & Reaktion

2) Qualitätsattribut

68












Vo

rste

llu

ng

A

na

lyse

T

est

K

om

m.

Die Architekten suchen nun einen Architektur- entwurf, welcher den Qualitätskriterien gerecht wird.

Dabei wird für jede einzelne Szenario/Qualitätsattribut dokumentiert:

Umgebung, Auslöser & Reaktion

resultierende Architekturentscheidung mit Risiko, Sensitivität, Tradeoff

Begründung

Diese kann von theoretischen Überlegungen bis zu evaluatorischen Prototypen reichen.


69












Vo

rste

llu

ng

A

na

lyse

T

est

K

om

m.

In größerer Runde wird jedes Szenario erneut einzeln betrachtet.

Diese werden ggf. angepasst / ergänzt, so dass sie möglichst gut den Erwartungen der Stakeholder entsprechen:

Anwendungs-Szenarien (Use Cases)

Änderungs-Szenarien (Wachstum, Störung)

Über z.B. eine Wahl werden alle Szenarien/Attribute abschließend priorisiert.


70












Vo

rste

llu

ng

A

na

lyse

T

est

K

om

m.

Wiederholt im Kern Schritt #6, ergänzt um das neue Detailwissen & Prioritäten alle Stakeholdern.

Idealerweise wird hier nur der Entwurf aus #6 umfangreicher belegt & bestätigt. Im Bedarfsfall nachgebessert.


71












Vo

rste

llu

ng

A

na

lyse

T

est

K

om

m.

Es werden alle Ergebnisse und erarbeiteten Dokumente allen Stakeholdern präsentiert:

Architekturentwurf & verworfene Ansätze

Qualitätsbaum

Szenarien

spezifische Fragen & Antworten zu einzelnen Qualitätskriterien/Szenarien

Risiken

Schmerzpunkte

getroffene Tradeoffs & Begründungen


1. Übergang zwischen „Software-Architektur“ und „Software-Design“ ist fließend

2. Verständlichkeit / Kommunizierbarkeit einer Architektur ist entscheidend

3. Ein weiterer Schlüsselaspekt ist die praktische Tauglichkeit der Architektur

4. Strukturierte Planung (ATAM) zahlt sich aus


Fazit: Details matter!

72


the essence for your business.


We are hiring!

Softwareentwickler / Business Analysten / Abschlussarbeiten / Praktikanten https://www.exxcellent.de/karriere/

https://www.kununu.com/de/exxcellentsolutions

Darmstadt

Stuttgart

Ulm München

https://www.exxcellent.de/karriere/





SOFTWARE-ARCHITEKTUREN IN DER PRAXIS - exxcellent.de · Architektur bildet die Grundlage für...

Documents

Transcript of SOFTWARE-ARCHITEKTUREN IN DER PRAXIS - exxcellent.de · Architektur bildet die Grundlage für...