Architektur in einer

Beschleunigten Softwaretechnik Markus Voß, Architekturen 2012, 2./3. Juli 2012, Paderborn

2

Dr. Markus Voß

46 Jahre, verheiratet, 3 Kinder (Teenager!)

Studium der Informatik und Mathematik an der Universität Bonn

Promotion an der Universität Karlsruhe

Einstieg bei sd&m in 1996

Dutzende industrielle Softwareprojekte als Projektmanager, Architekt und Berater

Geschäftsbereichsleiter von 2000-2005

Leiter sd&m Research von 2006-2007

Niederlassungsleiter Frankfurt von 2008-2010

Gründer und Geschäftsführer bei Accso – Accelerated Solutions GmbH in Darmstadt in 2010 www.accso.de

Lehrbeauftragter an der Hochschule Darmstadt für Software-Architektur und SOA

Mitglied im Industriebeirat des Instituts für angewandte Informatik Darmstadt (aiDa)

Mitglied im Präsidium der Gesellschaft für Informatik (GI) seit 2008

Gründungsmitglied der Fachgruppe Software-Architektur

3

Agenda

Accso und BeST

Architekturbegriff

Ausgewählte BeST-Practices zur Architektur

4

Beschleunigte IT-Lösungen und hochkarätige Technologie- und Architekturberatung

Unser Angebot

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

Technologie- und Architektur-Beratung (Schwerpunkte sind in diesem Bereich EAM, SOA, IT-Modernisierung, Security, u.a.)

Management von Software-Projekten

Integration dedizierter Software-Produkte (Schwerpunkt: CMS)

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 das ZDF, der SWR, der HR, der DuMont-Verlag, die Deutsche Telekom, Vodafone, die Deutsche Bahn, die Deutsche Flugsicherung, der Deutsche Wetterdienst, die DekaBank und weitere.

5

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

49 Mitarbeiter (Stand 1.7.2012)

Software-Ingenieure und IT-Berater

Exzellent ausgebildet (100% der Mitarbeiter haben einen Hochschulabschluss, 25% mit Promotion)

sehr erfahren (> 90% mit langjähriger Berufserfahrung)

hoch motiviert

0

5

10

15

20

25

30

35

40

45

50

Jul 10Aug 10Sep 10Okt 10Nov 10Dez 10Jan 11Feb 11Mrz 11Apr 11Mai 11Jun 11Jul 11Aug 11Sep 11Okt 11Nov 11Dez 11Jan 12Feb 12Mrz 12Apr 12Mai 12Jun 12

- €

500.000 €

1.000.000 €

1.500.000 €

2.000.000 €

2.500.000 €

3.000.000 €

3.500.000 €

4.000.000 €

4.500.000 €

5.000.000 €

Jul 10 Sep10

Nov10

Jan11

Mrz11

Mai11

Jul 11 Sep11

Nov11

Jan12

Mrz12

Mai12

Mitarbeiter

Umsatz

6

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

7

Unsere Beschleunigte Softwaretechnik (BeST) entwickelt etablierte Softwaretechnik weiter - hin zu mehr Effizienz

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 den Aspekt der Effizienz

Ganzheitlich (optimiert alle Dimensionen), Angemessen („quick“, aber nicht „dirty“), Skill-Orientiert (fordert exzellentes Team)

8

Struktur

BeST-

Practices

9

Agenda

Accso und BeST

Architekturbegriff

Ausgewählte BeST-Practices zur Architektur

10

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

11

Eine kleine Verschärfung meinerseits

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

12

Begriffswelt der Softwaretechnik mit klarer Unterscheidung von Architektur, Design und Technologie

Bestandssystem (optional)

Analyse (in Form von Funktionen,

Aktivitäten, Prozessen, Domänen, Anwendungsfällen, Services)

Design (Konkrete Komponenten,

Beziehungen und Interaktionen)

Architektur (Arten von Komponenten,

Beziehungen und Interaktionen)

Referenz- Architekturen

(z.B. Quasar)

Auswahl und Zuschnitt

Instanziierung Vom „was“ zum „wie“

Strukturierung

Technologien (z.B. JEE5)

Implementierung

Auswahl

Reverse Engineering

System (Code)

Strukturierung

funktional nicht-funktional

Anforderungen (Was Stakeholder wollen)

Auswahl

Auswahl

13

Beispiel aus der Software-Entwicklung

ud Library

Accounting Application

Library Application

Librarian

Customer

Accountant

Reminding

Accounting

Borrowing

Registration

Book Management

Search

I want a library management system to be built (FA): • Customers of a library can apply for a library

membership. Then, they can search for books and borrow them. They have to return the borrowed books according to specific loan periods.

• Librarians manage the book stock in the library. They register new customers in the library application. They enter the loan of a book by a customer in the system. Books that are overdue result in a reminding /dunning process. The librarian manages this process.

• Registration and reminding fees are to be paid by customers. Accountants deal with those payments with a separate accounting application.

And I want sustainability / maintainability (NFA)

class Library

datamanagement

borrowing

registration

reminding

accounting

«use case»

Reminding

«use case»

Registration

«use case»

Accounting

«entity class»

Inv oice

«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

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

• Wir verwenden A-Komponenten bestehend aus • A-Fällen • A-Verwaltern (Entity Controller) • A-Entitäten (Entities)

@Stateless @TransactionAttribute(TransactionAttributeType.REQUIRED) public class BookManagerImpl implements BookManager { @PersistenceContext private EntityManager em; void edit(Book book); void destroy(Book book); Book findById(Long id); List findAll(); Book create(Book book); List findByTemplate(Book book); }

• Konkret gibt es die A-Komponenten Accounting, BookManagement, … • mit den A-Fällen Registration, Search, …, • den A-Verwaltern BookManager, LoanManager, … und • den A-Entitäten Book, Loan, Reminder, Person, …

• Implementierung des A-Verwalters BookManager in JEE5

14

Analogie Bauwesen (Ursprung des Begriffs Architektur)

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 (Elemente rot 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.

Design des Kölner Doms

Der Kölner Dom

15

In der bewussten Unterscheidung zwischen dem Grundsätzlichen und dem Spezifischen 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.”

Grady Booch*

* In https://www.ibm.com/developerworks/mydeveloperworks/blogs/gradybooch

Architektur Design

grundsätzlich wesentlich signifikant

teuer

spezifisch

16

Agenda

Accso und BeST

Architekturbegriff

Ausgewählte BeST-Practices zur Architektur

17

BeST-Practice

Auch agile Software-Projekte brauchen eine klare Architektur

Beispiel: Aktuelles Entwicklungsprojekt bei Accso

- Entwicklung von drei neuen Backend-Services - 200 PT Aufwand und nur 7 Wochen Zeit - 9 Mitarbeiter, von 0 aufzubauen

(3 Erfahrene, 4 Neueinsteiger, 2 Werkstudenten)

- Agiles Vorgehen (Mittel aus Scrum und Kanban)

Nur aufgrund der klaren Architektur ist das selbstorganisierte Team in der Lage, die Aufgaben effizient zu verteilen.

Kartenfarbe = Fachliche Komponente Karten = Aufgaben + Schichten !

18

?

BeST-Practice

Es sollte sichergestellt sein, dass ein ausgewiesener Architekt im Team ist.

Architektur benötigt Erfahrung!

„Daher muss der Architekt begabt sein und fähig und bereit zu wissenschaftlich-theoretischer Schulung. Und er muss im schriftlichen Ausdruck gewandt sein, des Zeichenstiftes kundig, in der Geometrie

ausgebildet sein, mancherlei geschichtliche Ereignisse kennen, fleißig Philosophen gehört haben, etwas von Musik verstehen, nicht

unbewandert in der Heilkunde sein, juristische Entscheidungen kennen, Kenntnisse in der Sternkunde und vom gesetzmäßigen Ablauf der

Himmelserscheinungen besitzen.“ ;-)

Vitruv

Auch höchste Motivation im selbstorganisierten Team ersetzt nicht die Erfahrung. !

Architektur ist Teamsache!

„Die besten Architekturen, Anforderungen und Entwürfe

entstehen durch selbstorganisierte Teams.“

Das agile Manifest

19

BeST-Practice

Die Architektur sollte vorab definiert werden, das Design darf sich hingegen ruhig iterativ entwickeln.

Architektur Design

vorab inkrementell

gesteuert -inkrementelles Vorgehen agiles Vorgehen, z.B. nach Scrum

Basiskonzeption Envisioning

Iteration Sprint

Unabhängig vom konkreten Vorgehensmodell ist des Wesentliche frühzeitig zu klären. !

20

BeST-Practice

Referenzarchitekturen sind nützlich, müssen aber unbedingt auf die speziellen nicht-funktionalen Anforderungen zugeschnitten werden.

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 Technologieunabhängigkeit

(Einlassen auf moderne Enterprise Technologien wie JEE5/6)

Der Trade-Off zwischen Anforde-rungen und architektonischer Komplexität muss explizit erfolgen. Das benötigt viel Erfahrung.

!

Begeisterung für die anspruchsvollen Aufgaben unserer Kunden

Individuelle Kernsysteme

Beschleunigte Softwaretechnik

Team