Beschleunigte Softwaretechnik: Warum sich Architekten mit Effizienz und
Effektivität beschäftigen müssen – und wie Best Pr...
2
Über meine Person
42 Jahre
Studium der Informatik an der Universität Würzburg
Berufsstart 1997
Einstieg bei sd&m 2001
Ve...
3
Beschleunigte IT-Lösungen und hochkarätige
Technologie- und Architekturberatung
Unser Angebot
Individuelle Softwarelösun...
4
Beschleunigte IT-Lösungen und hochkarätige
Technologie- und Architekturberatung
Fakten
Gegründet 2010 in Darmstadt
GmbH ...
5
Individuelle Kernsysteme in dynamischen Umfeldern entwickeln wir
sicher, mit hoher Qualität und besonders effizient
stan...
6
BeST: Gesamtübersicht der Elemente und effizienter Techniken
Analyse Architektur Entwicklung Test Umgebung Projekt-
mana...
7
Beschleunigte Softwaretechnik (BeST) entwickelt etablierte
Softwaretechnik weiter - hin zu mehr Effizienz und Effektivit...
8
Beschleunigte Softwaretechnik (BeST) liefert einen Ordnungsrahmen.
BeST-Prinzipien
(die Grundideen)
BeST-Framework
(die ...
9
Einen Schritt zurück:
Software-Engineering - Nichts Neues, sondern altbekannt?!
Friedrich L. Bauer,
dt. Informatik-
Pion...
10
Vorgehensstrategie
Analyse
Architektur
Entwicklung
Test
Projektmanagement
Umgebung
Die Domänen (=Hauptaufgabengebiete) ...
11
Es gibt zwei Wege, sich dem Begriff Architektur zu nähern
Strukturorientiert:
Architektur ist,
wie ein System
aufgebaut...
12
Für beide Interpretationen von Architektur gibt es wertvolle
BeST-Practices
Strukturorientiert:
Architektur ist,
wie ei...
13
Aufgabenorientierte Herangehensweise an Architektur
Aufgabenorientiert:
Architektur ist,
was ein
Architekt tut.
Struktu...
14
Effizienz (es richtig machen) und Effektivität (das Richtige machen)
Allgemein:
Es geht nicht um eine möglichst
große M...
15
Aristoteles
Das Ganze ist mehr als die
Summe seiner Teile.
Grundprinzip und erste Leitplanke: Ganzheitlichkeit im Vorge...
16
Grundprinzip und erste Leitplanke: Ganzheitlichkeit im Vorgehen!
Beschleunigte Softwaretechnik ist
ganzheitlich, berück...
17
Vorgehensstrategie
BeST-Framework
Analyse
Architektur
Entwicklung
Test
Projektmanagement
Umgebung
BeST-Prinzip
Ganzheit...
18
BeST-Framework:Ziele,Aufgaben,Methoden
Domäne Architektur
Ziele
(warum?)
Aufgaben
(was?)
Methoden
(wie?)
Artefakte
(was...
19
DomäneArchitektur
Ziele
(warum?)
Aufgaben
(was?)
Methoden
(wie?)
Artefakte
(was,womit?)
BeST-Practices sind die eigentl...
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
Stabi...
22
Diese Aufgaben erfordern Abstimmung mit allen
Domänen, d.h. Kommunikation mit allen Stakeholdern.
Architekt
Entwicklert...
23
BeST Practice #1 im Sinne der Ganzheitlichkeit:
Alle Aufgabenbereiche des Architekten berücksichtigen!
Ganz viele Hebel...
24
Auch höchste Motivation im selbstorganisierten Team ersetzt nicht die
Erfahrung eines Experten.
!
BeST Practice #2 für ...
25
Strukturorientierte Herangehensweise an Architektur
Aufgabenorientiert:
Architektur ist,
was ein
Architekt tut.
Struktu...
26
Grundprinzip und zweite Leitplanke: Angemessenheit im Vorgehen!
Vilfredo Pareto
Pareto-Prinzip
(80-20-Regel)
Aufwand Er...
27
Analyse
Architektur
Entwicklung
Test
Umgebung
Projektmanagement
Vorgehensstrategie
BeST-Framework: Wir wählen die Metho...
28
Agilität ist keine spezielle Methode, kein spezielles Vorgehensmodell.
Agilität ist eine Vorgehens- und Management-Phil...
29
Besser: Effizienz und Effektivität, Angemessenheit und Agilität kombiniert
Effizienz und Effektivität erzielen wir durc...
30
Besser: Effizienz und Effektivität, Angemessenheit und Agilität kombiniert
Vollständige Vorab-Planung
Vollständige Vora...
31
Jedes Projekt ist anders, aber für quasi alle Projekte gelten einige
grundlegende Erkenntnisse.
Anzahl Projekttypen
Tot...
32
(Strukturorientierte) Software-Architektur nach IEEE 1471
Architecture is defined as the fundamental
organization of a ...
33
Eine kleine Verschärfung hilft, sich auf das Grundsätzliche zu konzentrieren
Architecture is defined as the fundamental...
34
In der Unterscheidung zwischen dem Grundsätzlichen und den Details
liegt der Hebel für die Effizienz
All architecture i...
35
Damit folgt „Architektur“ insbes. den nicht-funktionalen Anforderungen.
„Design“ entsteht als deren konkrete Instanziie...
37
Analogie zum Bauwesen
Ich möchte ein neues Gotteshaus bauen.
Die Gemeinde von Köln soll dort den Gottesdienst
feiern kö...
38
Am Beispiel der Software-Entwicklung
Requirements
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
p...
39
BeST Practice #3 im Entwurf: Sich das Grundsätzliche
explizit anhand der NFAs klar machen
Es ist entscheidend, dass der...
40
BeST Practice #4 im Entwurf: „Architektur“ vorab und „Design“
immer iterativ – unabhängig vom speziellen Vorgehensmodel...
41
Strukturorientierte Herangehensweise an Architektur
Aufgabenorientiert:
Architektur ist,
was ein
Architekt tut.
Struktu...
42
BeST Practice #5 im Entwurf: Separation of Concerns –
Software-Architekturen in mindestens 2 Dimensionen entwerfen
Schi...
43
Eine klare Architektur ist damit auch wesentliches Strukturierungsmittel
für die Planung (von Iterationen und Teamgröße...
44
BeST Practice #6 im Entwurf:
Referenzarchitekturen nutzen und zuschneiden
cd Quasar Architecture
Alternatives
«Abstract...
45
BeST Practice #6a im Entwurf: Referenzarchitekturen auf die
speziellen nicht-funktionalen Anforderungen zuschneiden
Bei...
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
Softwaretechnik
Team≡≡...
Nächste SlideShare
Wird geladen in …5
×

Beschleunigte Softwaretechnik: Warum sich Architekten mit Effizienz und Effektivität beschäftigen müssen - und wie BeST Practices dabei helfen

713 Aufrufe

Veröffentlicht am

Vortrag auf den iSAQB Architekturtagen, 21. November 2013, Leipzig (20. ObjektSPEKTRUM Information Days)

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
713
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
9
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Beschleunigte Softwaretechnik: Warum sich Architekten mit Effizienz und Effektivität beschäftigen müssen - und wie BeST Practices dabei helfen

  1. 1. Beschleunigte Softwaretechnik: Warum sich Architekten mit Effizienz und Effektivität beschäftigen müssen – und wie Best Practices dabei helfen Martin 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 helfen Martin Lehmann, Accso GmbH – iSAQB Architekturtage November 2013, Leipzig
  2. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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 AngemessenheitGanzheitlichkeit BeST-Framework BeST-Training BeST-Praktika BeST-Foundation BeST-Module Team-Orientierung BeST-Philosophie
  7. 7. 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. 8. 8 Beschleunigte Softwaretechnik (BeST) liefert einen Ordnungsrahmen. BeST-Prinzipien (die Grundideen) BeST-Framework (die Organisation) BeST-Practices (die konkreten Hilfestellungen)
  9. 9. 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. 10. 10 Vorgehensstrategie Analyse Architektur Entwicklung Test Projektmanagement Umgebung Die Domänen (=Hauptaufgabengebiete) des Software-Engineerings
  11. 11. 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. 12. 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. 13. 13 Aufgabenorientierte Herangehensweise an Architektur Aufgabenorientiert: Architektur ist, was ein Architekt tut. Strukturorientiert: Architektur ist, wie ein System aufgebaut ist.
  14. 14. 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. 15. 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. 16. 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. 17. 17 Vorgehensstrategie BeST-Framework Analyse Architektur Entwicklung Test Projektmanagement Umgebung 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. 18. 18 BeST-Framework:Ziele,Aufgaben,Methoden Domäne Architektur Ziele (warum?) Aufgaben (was?) Methoden (wie?) Artefakte (was,womit?)
  19. 19. 19 DomäneArchitektur Ziele (warum?) Aufgaben (was?) Methoden (wie?) Artefakte (was,womit?) 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. 20. 20 BeST-Framework: Ziele, Aufgaben, Methoden Analyse Architektur Entwicklung Test Umgebung Projektmanagement
  21. 21. 21 BeST beschäftigt sich innerhalb der Domäne Architektur mit allen Aufgaben des Architekten Minimierung von Risiken Stabilität und Flexibilität Ziele Angemessenheit von Weg und Lösung Nachvollziehbarkeit von Entscheidungen Hohe Qualität der Lösung Beschleunigung (Effizienz und Effektivität) Dokumentieren und Kommunizieren Aufgaben Orientierung geben und Leitplanken etablieren Prüfen und bewerten Lösungsarchitektur entwerfen Anforderungen berücksichtigen Beraten und begleiten Methoden 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. 22. 22 Diese Aufgaben erfordern Abstimmung mit allen Domänen, d.h. Kommunikation mit allen Stakeholdern. Architekt Entwicklerteam PL / PM Betrieb andere Dienstleister Produktanbieter 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. 23. 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. 24. 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. 25. 25 Strukturorientierte Herangehensweise an Architektur Aufgabenorientiert: Architektur ist, was ein Architekt tut. Strukturorientiert: Architektur ist, wie ein System aufgebaut ist.
  26. 26. 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. 27. 27 Analyse Architektur Entwicklung Test Umgebung Projektmanagement 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. 28. 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 aus selbst 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. 29. 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. 30. 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. 31. 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. 32. 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. 33. 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. 34. 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. 35. 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
  36. 36. 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
  37. 37. 38 Am Beispiel der Software-Entwicklung Requirements @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); } 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äten class 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» Reminder 0..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
  38. 38. 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
  39. 39. 40 BeST Practice #4 im Entwurf: „Architektur“ vorab und „Design“ immer iterativ – unabhängig vom speziellen Vorgehensmodell , SprintIterationBasiskonzeption 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
  40. 40. 41 Strukturorientierte Herangehensweise an Architektur Aufgabenorientiert: Architektur ist, was ein Architekt tut. Strukturorientiert: Architektur ist, wie ein System aufgebaut ist.
  41. 41. 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. !
  42. 42. 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
  43. 43. 44 BeST Practice #6 im Entwurf: Referenzarchitekturen nutzen und zuschneiden cd Quasar Architecture Alternatives «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» Persistence Alternatives Klare Trennung zwischen Architektur von der Implementierungs- technologie! Referenzarchitekturen enthalten grundlegende rein architektonische Strukturierungen als Vorlage und „Pattern“. !
  44. 44. 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. !
  45. 45. 46 Softwarearchitektur: Das ist die Königsdisziplin des Software-Engineering. Ernst Denert (im Vorwort zum „Quasar“-Buch)
  46. 46. 47 aber
  47. 47. 48 Lassen Sie uns in Kontakt bleiben … • www.accso.de • twitter.com/accso • Xing • Facebook • blog.accso.de
  48. 48. Begeisterung für die anspruchsvollen Aufgaben unserer Kunden Individuelle Kernsysteme Beschleunigte Softwaretechnik Team≡≡≡≡

×