Beschleunigte Softwaretechnik: Warum sich Architekten mit Effizienz und

Effektivität beschäftigen müssen – und wie Best Practices dabei helfenMartin Lehmann, Accso GmbH – iSAQB Architekturtage November 2013, Leipzig

Beschleunigte Softwaretechnik: Warum sich Architekten mit Effizienz und

Effektivität beschäftigen müssen – und wie Best Practices dabei helfenMartin Lehmann, Accso GmbH – iSAQB Architekturtage November 2013, Leipzig

2

Über meine Person

� 42 Jahre

� Studium der Informatik an der Universität Würzburg

� Berufsstart 1997

� Einstieg bei sd&m 2001

� Verschiedene industrielle Softwareprojekte als Architekt, Projektmanager, Berater

� Mitarbeit bei sd&m Research zu Quasar von 2006-2007

� Seit 2010 Mitglied der Geschäftsleitung und CTO bei der

Accso – Accelerated Solutions GmbH in Darmstadt

www.accso.de

� Accso ist Fördermitglied des iSAQB seit 2013,

Mitarbeit in den Arbeitsgruppen Marketing und Internationalisierung

3

Beschleunigte IT-Lösungen und hochkarätige

Technologie- und Architekturberatung

Unser Angebot

� Individuelle Softwarelösungen für IT-Kernsysteme (Schwerpunkte: Java/JEE, .NET, Open Source, RIA, u.a.)

� Technologie- und Architektur-Beratung (Schwerpunkte: IT-Architektur und -Modernisierung, EAM, SOA,

BPM, Security, u.a.)

� Management von Software-Projekten

� Integration dedizierter Software-Produkte (Schwerpunkte: CMS, Portal)

Unsere Kunden

� Wir entwickeln individuelle Softwarelösungen für die Kernkompetenzen unserer Kunden und beraten in

aktuellen Fragestellungen von Technologie und Architektur.

� Accso arbeitet branchenübergreifend für namhafte Unternehmen, dazu zählen Deutsche Telekom,

Deutsche Bahn, Deutsche Flugsicherung, Deutsche Wetterdienst, DekaBank, AOK, ZDF, SWR, HR, WDR,

DuMont-Verlag, HRS, Maxdome, Vodafone und weitere.

4

Beschleunigte IT-Lösungen und hochkarätige

Technologie- und Architekturberatung

Fakten

� Gegründet 2010 in Darmstadt

� GmbH mit Kapitalbeteiligung des Landes Hessen

� Geschäftsführung: Jürgen Artmann,

Dr. Markus Voß

� Niederlassungen: Darmstadt, Köln

Unsere Mitarbeiter

� 68 Mitarbeiter (Stand 1.9.2013)

� Software-Ingenieure und IT-Berater

� Exzellent ausgebildet (fast alle Mitarbeiter haben

einen Hochschulabschluss, jeder sechste mit

Promotion)

� sehr erfahren (> 80% mit mehr- bzw. langjähriger

Berufserfahrung)

� hoch motiviert

Mitarbeiter

Umsatz

0

10

20

30

40

50

60

70

Jul 10 Jan 11 Jul 11 Jan 12 Jul 12 Jan 13 Jul 13

0

1.000.000

2.000.000

3.000.000

4.000.000

5.000.000

6.000.000

2010/11 2011/12 2012/13

5

Individuelle Kernsysteme in dynamischen Umfeldern entwickeln wir

sicher, mit hoher Qualität und besonders effizient

standardisierend

(Commodity)

differenzierend

(individuelle Kernsysteme)

Zielsetzung

des Projekts

Wesen des Projekts

interaktiv

dynamisch

innovativ

flexibel

eher kleiner

prozessorientiert

standardisierbar

arbeitsteilig

eher größer

Wettbewerbsfaktor

in diesem Bereich:

Minimierung der

Stückkosten durch

Offshoring

Unser wichtigster

Wettbewerbsfaktor:

Effizienz im Vorgehen

durch Beschleunigte

Softwaretechnik (BeST)� Erstellung individueller Softwarelösungen

für IT-Kernsysteme (Java-Technologie, .NET,

Open Source)

� Management von Software-Projekten

� IT-Beratung (Technologie und Architektur)

� Integration dedizierter Software-Produkte

6

BeST: Gesamtübersicht der Elemente und effizienter Techniken

Analyse Architektur Entwicklung Test Umgebung Projekt-

management

Vorgehensstrategie

� Refactoring

� Continous

Integration,

Deployment and

Delivery (Cx)

� RAD-Frameworks

(Grails, Lift, Roo)

� Polyglot Program-

ming (mit Groovy,

Scala, Clojure, ...)

� Vorkonfigurierte

integrierte

Werkzeuge out-of-

the-box (DSI)

� Virtualisierung

� Cloud-Computing

� Infrastructure as

Code

� DevOps

� Agile Methoden

(Scrum, Kanban)

� Lean Planning and

Controlling

� Forciertes

Umfangs-

Management

� Agile Spezifikation

� Effiziente

Moderations-,

Kommunikations-

und

Dokumentations-

techniken

� Modellgetriebene

Spezifikation

(MDx)

� Agile Architektur

� Referenzarchitek-

turen

� Skalierbare und

offene SW-

Architektur nach

True-SOA Prinzip

� Trade-Off Methode

für Software-

Architektur (ATAM)

� Test first

� Testgetriebene

Entwicklung (TDx)

� Test-

Automatisierung

� Testprozess-

optimierung

� Projektspezifische Methodenauswahl

und Methodenanwendung

� Agilitätsprofil (Reglermodell)

� Kontextspezifische BeST-Practices

An

gem

ess

en

he

itG

an

zhe

itlic

hke

it

BeST-Framework

BeST-Training

BeST-Praktika BeST-Foundation BeST-Module

Tea

m-O

rie

nti

eru

ng

Be

ST

-Ph

ilo

sop

hie

7

Beschleunigte Softwaretechnik (BeST) entwickelt etablierte

Softwaretechnik weiter - hin zu mehr Effizienz und Effektivität.

Beschleunigte

Softwaretechnik

Etablierte

Softwaretechnik

Frühe

Software-

entwicklung

� Definierte Vorgehensweisen und Prozesse

� Standardisierte Methoden, Architekturen,

Programmiersprachen, Komponenten, Frameworks

und Werkzeuge

� Wiederholbar, messbar, steuerbar

� Ad-hoc Vorgehensweisen, keine Standardisierung

� Kaum Aussagen über Ergebnisqualität und Einhaltung von

Zeit- und Budgetvorgaben möglich

� Basiert auf etablierter Softwaretechnik

� Betont besonders die Aspekte Effizienz und

Effektivität

� Ganzheitlich (optimiert alle Dimensionen),

Angemessen („quick“, aber nicht „dirty“),

Team-Orientiert (fordert exzellente Skills)

8

Beschleunigte Softwaretechnik (BeST) liefert einen Ordnungsrahmen.

BeST-Prinzipien(die Grundideen)

BeST-Framework(die Organisation)

BeST-Practices(die konkreten Hilfestellungen)

9

Einen Schritt zurück:

Software-Engineering - Nichts Neues, sondern altbekannt?!

Friedrich L. Bauer,dt. Informatik-

Pioneer

(u.a. Erfinder

des Stacks)

Definition für Software-Engineering

im Zuge der Diskussion zu „Software Crisis“, 1968:

Establishment and use of sound engineering

principles to obtain economically software that is

reliable and works on real machines efficiently.

Nato-Konferenz 1968 in Garmisch

10

Vorgehensstrategie

An

aly

se

Arc

hit

ek

tur

En

twic

klu

ng

Test

Pro

jek

tma

na

ge

me

nt

Um

ge

bu

ng

Die Domänen (=Hauptaufgabengebiete) des Software-Engineerings

11

Es gibt zwei Wege, sich dem Begriff Architektur zu nähern

Strukturorientiert:

Architektur ist,

wie ein System

aufgebaut ist.

Aufgabenorientiert:

Architektur ist,

was ein

Architekt tut.

12

Für beide Interpretationen von Architektur gibt es wertvolle

BeST-Practices

Strukturorientiert:

Architektur ist,

wie ein System

aufgebaut ist.

Aufgabenorientiert:

Architektur ist,

was ein

Architekt tut.

13

Aufgabenorientierte Herangehensweise an Architektur

Aufgabenorientiert:

Architektur ist,

was ein

Architekt tut.

Strukturorientiert:

Architektur ist,

wie ein System

aufgebaut ist.

14

Effizienz (es richtig machen) und Effektivität (das Richtige machen)

Allgemein:

Es geht nicht um eine möglichst

große Menge an Code oder Doku

bei gleichem Aufwand oder um

irgendeine Lösung bei möglichst

geringem Aufwand.

Es geht um eine, den eigentlichen

Kundenanforderungen

angemessene Lösung bei

möglichst geringem Aufwand.

Zudem ist überhaupt nur dann mit

einer signifikanten Steigerung der

Effizienz und Effektivität zu

rechnen, wenn das Projekt

ganzheitlich in allen Aspekten auf

Effizienz getrimmt wird.

1 2

Effizienz = Ertrag

Aufwand

In Software-Projekten:

Effizienz = Effekt

Projektaufwand

Ertrag = Effekt =Kundennutzen bzw.

Kundenzufriedenheit

15

Aristoteles

Das Ganze ist mehr als die

Summe seiner Teile.

Grundprinzip und erste Leitplanke: Ganzheitlichkeit im Vorgehen!

(frei nach) John Nash

Einzelne lokale Optimierungen

führen nicht zu einem globalen

Optimum.

16

Grundprinzip und erste Leitplanke: Ganzheitlichkeit im Vorgehen!

Beschleunigte Softwaretechnik ist

ganzheitlich, berücksichtigt also

alle Domänen der Softwaretechnik

über den gesamten Lebenszyklus

der Lösung.

Architektur steht demnach nicht

alleine (im Elfenbeinturm),

sondern muss mit allen Domänen zusammenarbeiten, um die

die Poteniale zur Effizienzsteigerung

auszuschöpfen.

Genau (nur) daraus ergibt sich ein wesentlicher Teil ihres Mehrwerts.

17

Vorgehensstrategie

BeST-Framework

An

aly

se

Arc

hit

ek

tur

En

twic

klu

ng

Test

Pro

jek

tma

na

ge

me

nt

Um

ge

bu

ng

BeST-Prinzip

Ganzheitlichkeit

� Wir betrachten alle Domänen

der Softwaretechnik im Sinne

von Hauptaufgabenbereichen

� Die Darstellung impliziert

keine zeitliche Abfolge der

einzelnen Tätigkeiten

(im Sinne eines Wasserfall-

modells).

� Sie ist unabhängig vom

konkreten Vorgehensmodell

BeST-Framework: Wir betrachten alle Domänen (=Hauptaufgabengebiete)

des Software-Engineerings ganzheitlich

18

Be

ST-Fram

ew

ork: Zie

le, A

ufgab

en

, Me

tho

de

n

Domäne Architektur

Ziele(warum?)

Aufgaben(was?)

Methoden(wie?)

Artefakte(was,womit?)

19

Do

mä

ne

Arc

hit

ek

tur

Zie

le(w

aru

m?

)

Au

fga

be

n(w

as?

)

Me

tho

de

n(w

ie?

)

Art

efa

kte

(wa

s,w

om

it?

)

BeST-Practices sind die eigentlichen und wesentlichen Hilfsmittel

BeST-Practices ...

... unterstützen konkret bei der

Auswahl geeigneter Methoden

zur Lösung einer Aufgabe

... geben konkrete Hinweise,

wie die gewählte Methode

genau anzuwenden ist

... und beziehen sind dabei oft

auf einen speziellen

Projektkontext bzw. sind nur in

diesem wirklich „best“.

20

BeST-Framework: Ziele, Aufgaben, Methoden

Analyse Architektur Entwicklung

Test Umgebung Projektmanagement

21

BeST beschäftigt sich innerhalb der Domäne Architektur

mit allen Aufgaben des Architekten

Minimierung von

Risiken

Stabilität und

FlexibilitätZie

le Angemessenheit von

Weg und Lösung

Nachvollziehbarkeit

von Entscheidungen

Hohe Qualität der

Lösung

Beschleunigung

(Effizienz und

Effektivität)

Dokumentieren und

Kommunizieren

Au

fga

be

n

Orientierung geben und Leitplanken etablieren

Prüfen und

bewerten

Lösungsarchitektur

entwerfen

Anforderungen

berücksichtigen

Beraten und begleiten

Me

tho

de

n

Anforderungen bewerten,

priorisieren und verfolgen

Rahmenbedingungen und

Einflussfaktoren beachten

Risiken identifizieren und

einschätzen

Lösungsideen entwickeln

Architektur strukturiert

entwerfen

Technische Konzepte ,

Technologien, Produkte

auswählen

Architektursichten

erstellen

Architektur angemessen

dokumentieren

Architektur den Stakeholdern

präsentieren

Architektur im Team etablieren

und entwickeln

Architekturreviews durchführen

(lassen)

Messkriterien für

Architektur definieren

Erfüllung von

Architekturrichtlinien prüfen

Architektur szenarienbasiert

bewerten (lassen)

Architekturprinzipien

festlegen

Architekturstrategie

festlegen

Aufwand schätzen und

Planung unterstützen

Machbarkeit, Kosten und

Nutzen betrachten

Projektsteuerung und –

organisation unterstützen

Implementierung

(beg)leiten

Testbarkeit und Kritikalität

bewerten

Qualitätsziele für

Architektur festlegen

Richtlinien für Entwicklung

festlegen

22

Diese Aufgaben erfordern Abstimmung mit allen

Domänen, d.h. Kommunikation mit allen Stakeholdern.

Architekt

Entwicklerteam

PL / PM

Betrieb

andere

DienstleisterProduktanbieter

CIO / Architekturboard

Fachbereich

Produktmanager

Auftraggeber

Projektteam Kunde

Externe

leitet,

begleitet

berichtet,

unterstützt

berät, klärt,

stimmt ab,

präsentiert,

„verkauft“

wählt aus,

leitet an,

kontrolliert

Architecture is

about People

(Norman Foster)

23

BeST Practice #1 im Sinne der Ganzheitlichkeit:

Alle Aufgabenbereiche des Architekten berücksichtigen!

Ganz viele Hebel der Effizienzsteigerung liegen in den begleitenden Aktivitäten des Architekten neben

dem reinen Entwurf der Lösungsarchitektur – insbesondere beim Management der Anforderungen.!

� Der Architekt tut viel mehr,

als nur die Lösungsarchitektur

zu entwerfen.

� Er ist Jongleur, Diplomat, Berater,

Moderator, Verkäufer, Trainer, …

� ... und insbesondere ist er

derjenige, der die eigentlichen

Kundenanforderungen

herauskitzeln und die

Lösungsarchitektur dazu passend

effizient entwickeln kann.

!

24

Auch höchste Motivation im selbstorganisierten Team ersetzt nicht die

Erfahrung eines Experten.!

BeST Practice #2 für „Beraten und Begleiten“:

Ausgewiesener Architekt als „Architecture Owner“ im Team

Architektur benötigt Erfahrung!

Daher muss der Architekt

begabt sein und

fähig und

bereit zu wissenschaftlich-

theoretischer Schulung. …

(Vitruv)

Architektur ist Teamsache!

Das agile Manifest: Die besten

Architekturen, Anforderungen und

Entwürfe entstehen durch

selbstorganisierte Teams.

Architecture should be a team effort.

(Scott Ambler)

Widerspruch?

Nein!

Architecture Owner

25

Strukturorientierte Herangehensweise an Architektur

Aufgabenorientiert:

Architektur ist,

was ein

Architekt tut.

Strukturorientiert:

Architektur ist,

wie ein System

aufgebaut ist.

26

Grundprinzip und zweite Leitplanke: Angemessenheit im Vorgehen!

Vilfredo Pareto

Pareto-Prinzip

(80-20-Regel)

Aufwand Ertrag

Peter Drucker

Es ist immer wieder

verblüffend, wie viele

Dinge wir tun,

die, wenn wir

sie nicht mehr tun,

keinem abgehen.

Jack Welch

Do first priority

things first,

do second priority

things never.

27

An

aly

se

Arc

hit

ek

tur

En

twic

klu

ng

Test

Um

ge

bu

ng

Pro

jek

tma

na

ge

me

nt

Vorgehensstrategie

BeST-Framework: Wir wählen die Methoden anhand der Projektspezifika

angemessen aus

BeST-Framework

� Mit den Mitteln der

Vorgehensstrategie wird das

konkrete Projektvorgehen

abhängig vom Projektkontext,

d.h. den speziell für das Projekt

geltenden Einflussfaktoren

optimal im Sinne der Effizienz

zugeschnitten

� Dabei werden Methoden der

einzelnen fachlichen Domänen

ausgewählt und spezifisch

zugeschnitten angewendet

� Zusammen mit der Festlegung

des Agilitätsprofils entsteht das

konkrete Vorgehensmodell

BeST-Prinzip

Angemessenheit

28

Agilität ist keine spezielle Methode, kein spezielles Vorgehensmodell.

Agilität ist eine Vorgehens- und Management-Philosophie.

Reicht nicht das „Wundermittel“ Agilität?

vs.

Agil Generalstabsmäßig

Projekte können gar nicht vollständig vorab durchgeplant

und Produkte nicht vollständig vorab spezifiziert werden.

Deswegen muss ein Projekt iterativ umgesetzt werden

und auf Änderungen, die auf jeden Fall kommen werden,

muss flexibel reagiert werden können.

Projekte müssen top-down durchgeplant werden, bevor

sie durchgeführt werden.

Produkte müssen vollständig spezifiziert werden, bevor

sie umgesetzt werden.

Die besten Lösungen entstehen ausselbst organisierenden Teams.

Teams brauchen eine Organisation mit klar definierten Rollen und Zuständigkeiten.

Es herrscht eine Kultur des Vertrauens. Alle relevanten Dinge sind vertraglich zu regeln.

29

Besser: Effizienz und Effektivität, Angemessenheit und Agilität kombiniert

Effizienz und Effektivität erzielen wir durch

Angemessenheit im Sinne einer

situationsgerechten und projektspezifischen Auswahl

aus den verschiedenen Handlungsalternativen:

So agil wie möglich, so generalstabsmäßig wie nötig.

Individuals and interactions over

Working software over

Customer collaboration over

Responding to change over

We have come to value:processes and tools

comprehensive documentation

contract negotiation

following a plan

So viel

wie

möglich

So viel

wie

nötig

Das entspricht auch dem Geist des „Agilen Manifests“

That is, while there is value in the items on the

right, we value the items on the left more

max.

min.

30

Besser: Effizienz und Effektivität, Angemessenheit und Agilität kombiniert

Vollständige Vorab-Planung

Vollständige Vorab-Spezifikation

Strikte Organisation und Rollenteilung

Kein Vertrauen

Agilitätsprofil (Reglermodell)

Keine Vorab-Planung

Keine Vorab-Spezifikation

Vollständige Selbstorganisation

Volles Vertrauen

Jedes Projekt ist anders: Projektkontext und Einflussfaktoren

unterscheiden sich von Projekt zu Projekt.

Entsprechend gibt es für jedes Projekt ein spezifisches optimales Agilitätsprofil im Hinblick

auf Effizienz und Effektivität seiner Durchführung.

31

Jedes Projekt ist anders, aber für quasi alle Projekte gelten einige

grundlegende Erkenntnisse.

Anzahl Projekttypen

Total agil Total generalstabsmäßig

� Grundlegende Aspekte der Planung und Spezifikation sollten in einer

frühen Projektphase vorab festgelegt werden (Basiskonzeption bzw. Envisioning).

Die Entwicklung der Details sollte danach iterativ erfolgen (in Iterationen bzw. Sprints).

� Grundlegende Aufgaben der Planung und Spezifikation sollten von Experten ihres Fachs

durchgeführt oder unterstützt werden, die damit auch Ergebnisverantwortung übernehmen

(z.B. Architecture Owner).

32

(Strukturorientierte) Software-Architektur nach IEEE 1471

Architecture is defined as the fundamental

organization of a system, embodied in its

components, their

relationships to each other

and to the environment,

and the principles governing its design and evolution.

33

Eine kleine Verschärfung hilft, sich auf das Grundsätzliche zu konzentrieren

Architecture is defined as the fundamental

organization of a system, embodied in its

types of components, their

types of relationships to each other

and to the environment,

and the principles governing its design and evolution.

34

In der Unterscheidung zwischen dem Grundsätzlichen und den Details

liegt der Hebel für die Effizienz

All architecture is design but not all design is architecture.

Architecture represents the significant design decisions

that shape a system, where significant is

measured by cost of change.

„Architektur“ „Design“

grundsätzlich

wesentlich

signifikant

teuer zu ändern

die Details

Vorschlag zur Benennung:

Grady Booch

35

Damit folgt „Architektur“ insbes. den nicht-funktionalen Anforderungen.

„Design“ entsteht als deren konkrete Instanziierung und Verfeinerung.

Analyse(in Form von Funktionen,

Aktivitäten, Prozessen, Domänen,

Anwendungsfällen, Services)

Design(Spezifische detaillierte

Komponenten, Beziehungen

und Interaktionen)

Architektur(Arten von Komponenten,

Beziehungen und

Interaktionen)

Referenz-

Architekturen(z.B. Quasar)

Auswahl und

Zuschnitt

Instanziierung und

Verfeinerung

Vom „was“

zum „wie“

Strukturierung

Technologien(z.B. JEE)

Implementierung

Auswahl

System(Code)

Strukturierung

funktional nicht-funktional

Anforderungen(Was Stakeholder wollen)

Auswahl

Auswahl

37

Analogie zum Bauwesen

Ich möchte ein neues Gotteshaus bauen.

Die Gemeinde von Köln soll dort den Gottesdienst

feiern können (funktionale Anforderung).

Im Inneren soll es möglichst hell sein

(nicht-funktionale Anforderung).

Gotische Architektur

(rote Elemente in der Abbildung):• Wir verwenden Spitzbögen, Kreuzrippengewölbe,

Strebewerke und Strebepfeiler

• Kreuzrippen und Strebewerk verwenden wir als

tragende Elemente. Das erlaubt eine Minimierung

der Wandflächen und eine Maximierung der

Fensterflächen. Dadurch wird es hell.

Der Kölner Dom

Design des Kölner Doms

38

Am Beispiel der Software-Entwicklung

Requirements

@Stateless@TransactionAttribute(TransactionAttributeType.REQUIRED)

public class BookManagerImpl implements BookManager {

@PersistenceContextprivate EntityManager em; void edit(Book book);

void destroy(Book book);Book findById(Long id);List findAll();Book create(Book book);List findByTemplate(Book book);

}

Software-System (in JEE)

Software-Architektur (nach Quasar)cd Application Kernel Interactions

«A Component»

Dialog

A-Component 1

A-Component 2 A-Component 3

UseCase 1.1

UseCase 2.1

UseCase 1.2

UseCase 2.2 UseCase 2.3 UseCase 3.1 UseCase 3.2

A-Controller

2.1

A-Entity 2.1

A-Controller

2.2

A-Entity 2.2 A-Entity 2.3

A-Controller

3.1

A-Controller

3.2

A-Controller

3.3

A-Entity 3.1 A-Entity 3.2 A-Entity 3.3

Software-Design

Konkrete A-Komponenten,

A-Fälle, A-Verwalter, A-Entitätenclass Library

datamanagement

borrowing

registration

reminding

accounting

«use case»

Reminding

«use case»

Registration

«use case»

Accounting

«entity class»

Invoice

«use case»

Borrowing

«use case»

BookManagement

«use case»

Search

«entity class»

BookOnStock

«entity class»

Loan

«entity class»

Book«entity class»

Customer

«entity class»

Reminder0..1

-loan

1

*

-customer 1

*

-bookOnStock

1

*

-book 1

ud Library

Accounting Application

Library Application

Librarian

Customer

Accountant

Reminding

Accounting

Borrowing

Registration

Book Management

Search

39

BeST Practice #3 im Entwurf: Sich das Grundsätzliche

explizit anhand der NFAs klar machen

Es ist entscheidend, dass der Architekt die/seine Software-Architektur grundsätzlich

versteht und über die passenden Grundstrukturen zielgerichtet entlang konkreter

nicht-funktionaler Anforderungen entscheiden kann.

Wie viel

brauche ich wirklich

und mit welchen Architekturmustern erreiche ich das?

!

Es soll

hell sein!

Execution Qualities Evolution Qualities

Performance, Security, Usability Testability, Maintainability, Extensibility, Scalability

40

BeST Practice #4 im Entwurf: „Architektur“ vorab und „Design“

immer iterativ – unabhängig vom speziellen Vorgehensmodell

, Sprint IterationBasiskonzeption

Das Wesentliche frühzeitig klären. Die Details dann klären, wenn sie „dran“ sind.!

Iterativ das

„Design“(die Details)

Vorab die

„Architektur“(das Wesentliche)

, Envisioning

41

Strukturorientierte Herangehensweise an Architektur

Aufgabenorientiert:

Architektur ist,

was ein

Architekt tut.

Strukturorientiert:

Architektur ist,

wie ein System

aufgebaut ist.

42

BeST Practice #5 im Entwurf: Separation of Concerns –

Software-Architekturen in mindestens 2 Dimensionen entwerfen

Schicht

Schicht

Schicht

fachliche

Komponente

fachliche

Komponente

fachliche

Komponente

fachliche

Komponente

Für jedes Software-Element (Paket, Klasse, Interface, …) ist somit klar, wo es hingehört.

Technische Schichtenarchitektur haben alle Projekt – dedizierte fachliche

Komponenten aber nur wenige. Dabei ist das mindestens genau so wichtig.!

43

Eine klare Architektur ist damit auch wesentliches Strukturierungsmittel

für die Planung (von Iterationen und Teamgröße/-aufbau etc.)

Beispiel:

Entwicklungsprojekt bei Accso

- Entwicklung von Backend-Services

- 200 PT Aufwand, nur 7 Wochen Zeit

- 9 Mitarbeiter (6 FTE), von 0 aufzubauen

(darunter 3 Erfahrene, 4 Neueinsteiger)

- Agiles Vorgehen (Mischung aus Scrum

und Kanban)

Backlog-Board

Karten = Tasks bezogen auf Schichten

Kartenfarbe = Fachliche Komponente

44

BeST Practice #6 im Entwurf:

Referenzarchitekturen nutzen und zuschneidencd Quasar Architecture

Al ternatives

«Abstract T Component»

Client Management«A Component»

Dialog

«Abstract T Component»

Application Kernel Facade

«A Component»

Application Component

«Abstract T Component»

Authorization

«Abstract T Component»

Transaction

«Abstract T Component»

Persis tence

Al ternatives

Klare Trennung zwischen Architektur von der Implementierungs-

technologie! Referenzarchitekturen enthalten grundlegende rein

architektonische Strukturierungen als Vorlage und „Pattern“.

!

45

BeST Practice #6a im Entwurf: Referenzarchitekturen auf die

speziellen nicht-funktionalen Anforderungen zuschneiden

Beispiel: Quasar

- z.B. bei reduzierten Anforderungen an Oberflächenkomplexität

- z.B. bei reduzierten Anforderungen an Plattformunabhängigkeit

- z.B. bei reduzierten Anforderungen an die Komplexität der Geschäftslogik

- z.B. bei reduzierten Anforderungen an Technologieunabhängigkeit

(Einlassen auf moderne Enterprise Technologien wie JEE oder .NET)

Der Trade-Off

zwischen Anforde-

rungen und

architektonischer

Komplexität muss

explizit erfolgen.

Das benötigt viel

Erfahrung.

!

46

Softwarearchitektur:

Das ist die Königsdisziplin

des Software-Engineering.

Ernst Denert(im Vorwort zum „Quasar“-Buch)

47

aber

48

Lassen Sie uns in Kontakt bleiben …

• www.accso.de

• twitter.com/accso

• Xing

• Facebook• blog.accso.de

Begeisterung für die

anspruchsvollen Aufgaben unserer Kunden

Individuelle

Kernsysteme

Beschleunigte

SoftwaretechnikTeam≡≡≡≡