Beschleunigte Softwaretechnik für Architekten: Best Practices für Effizienz und Effektivität

Martin Lehmann: „Beschleunigte Softwaretechnik für Architekten: Best Practices für Effizienz und Effektivität“.

20. iSAQB Architekturtage (ObjektSPEKTRUM Information Days), Leipzig,
21. November 2013

Transcript

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 Ü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. 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
4. 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)
5. 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
6. 10 Vorgehensstrategie Analyse Architektur Entwicklung Test Projektmanagement Umgebung Die Domänen (=Hauptaufgabengebiete) des Software-Engineerings
7. 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.
8. 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.
9. 13 Aufgabenorientierte Herangehensweise an Architektur Aufgabenorientiert: Architektur ist, was ein Architekt tut. Strukturorientiert: Architektur ist, wie ein System aufgebaut ist.
10. 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
11. 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.
12. 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.
13. 18 BeST-Framework: Ziele, Aufgaben, Methoden Domäne Architektur Ziele (warum?) Aufgaben (was?) Methoden (wie?) Artefakte (was,womit?)
14. 19 Domäne Architektur 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“.
15. 20 BeST-Framework: Ziele, Aufgaben, Methoden Analyse Architektur Entwicklung Test Umgebung Projektmanagement
16. 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
17. 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)
18. 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. !
19. 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
20. 25 Strukturorientierte Herangehensweise an Architektur Aufgabenorientiert: Architektur ist, was ein Architekt tut. Strukturorientiert: Architektur ist, wie ein System aufgebaut ist.
21. 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.
22. 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.
23. 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.
24. 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).
25. 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.
26. 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.
27. 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
28. 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
29. 36 Analogie zum Bauwesen 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 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
30. 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
31. 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
32. 40 BeST Practice #4 im Entwurf: „Architektur“ vorab und „Design“ immer iterativ – unabhängig vom speziellen Vorgehensmodell , Sprint Iteration Basiskonzeption 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
33. 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. !
34. 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
35. 46 Softwarearchitektur: Das ist die Königsdisziplin des Software-Engineering. Ernst Denert (im Vorwort zum „Quasar“-Buch)
36. 47 aber
37. 48 Lassen Sie uns in Kontakt bleiben … • www.accso.de • twitter.com/accso • Xing • Facebook • blog.accso.de
38. Begeisterung für die anspruchsvollen Aufgaben unserer Kunden Individuelle Kernsysteme Beschleunigte Softwaretechnik Team