43
Coach für effektive Produktentwicklung Matthias Bohlen Architektur versus Agilität oder: Wer braucht schon noch Architekten? +49 170 772 8545 [email protected] http://www.mbohlen.de @mbohlende Benutzer Entwickler Business Domänen- experte Architekt Fachbereich Analyst etc. Designer Programmierer Tester Kunde Donnerstag, 20. September 12

Architektur vs Agilität

Embed Size (px)

DESCRIPTION

Vortrag auf der "Jax on tour", September 2012: Sind die Zeiten, in denen man sich stolz Architekt nennen und sich darauf etwas einbilden konnte, vorbei? Wenn die Architektur ganz agil allen „gehört“, wozu dann eine herausgehobene Rolle? In diesem Vortrag wird auf die Auswirkungen moderner, leichtgewichtiger Vorgehensweisen auf die Architektenrolle eingegangen und gezeigt, was gleich bleibt, was sich verändern muss und welche Herausforderungen sich daraus ergeben, wenn der Architekt auf einmal ein gleichrangiges Teammitglied wird.

Citation preview

Page 1: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Architektur versus Agilitätoder: Wer braucht schon noch Architekten?

+49 170 772 [email protected]://www.mbohlen.de@mbohlende

Benutzer

Entwickler

Business

Domänen-

experte

Architekt

Fachbereich

Analyst

etc.

Designer

Programmierer

Tester

Kunde

Donnerstag, 20. September 12

Page 2: Architektur vs Agilität

3 Vorträge

2Donnerstag, 20. September 12

Page 3: Architektur vs Agilität

Foto: Casey Hussein Bisson

Wer ist ein Softwarearchitekt?

3Donnerstag, 20. September 12

Page 4: Architektur vs Agilität

OOPSLA 1992

4

Publikum:Mr. Beck, was istSoftwarearchitektur?

Softwarearchitektur?Das ist das, was Softwarearchitekten machen.

Publikum (kichert):Also dann, was ist einSoftwarearchitekt?

Hmm, Softwarearchitekt ist ein neuer pompöser Titel, den Programmierer auf ihrer Visitenkarte haben wollen, um ihre üppigen Bezüge zu rechtfertigen.

Donnerstag, 20. September 12

Page 5: Architektur vs Agilität

Extreme Programming Explained (2000)

5

"Softwarearchitektur ist in XP-Projekten genauso wichtig wie in irgendeinem Softwareprojekt.

... Nimm Dir für die erste Iteration einen Satz von Stories, der Dich zwingt, die ganze Architektur zu erschaffen. Am Ende dieser Übung wirst Du Deine Architektur haben. Es könnte sein, dass es nicht die ist, die Du erwartet hast, aber Du wirst etwas gelernt haben.

... Ich setze die Architektur rein, die ich jetzt brauche und vertraue auf meine Fähigkeit, sie später zu ändern."

Donnerstag, 20. September 12

Page 6: Architektur vs Agilität

Die elende Bau-Metapher

6Der Architekt erklärt

Der Entwickler baut

Foto: Anna Oakley

Donnerstag, 20. September 12

Page 7: Architektur vs Agilität

Wenn überhaupt Bau, dann...

7

Architekten und Entwickler

entwerfen

Der Compiler baut

Donnerstag, 20. September 12

Page 8: Architektur vs Agilität

Foto: Casey Hussein Bisson

Stille Post am Beispiel RUP

8Donnerstag, 20. September 12

Page 9: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Rational Unified Process

9Donnerstag, 20. September 12

Page 10: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

RUP: Das Metamodell

10Donnerstag, 20. September 12

Page 11: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

RUP: Die Rolle "Softwarearchitekt"

11Donnerstag, 20. September 12

Page 12: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

RUP: Die Rolle "Implementierer"

12Donnerstag, 20. September 12

Page 13: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

RUP: Aktivität "Implement Component"

13

Purpose:

To produce source code in accordance with the design model.

Purpose:

To produce source code in accordance with the design model.

Steps:Implement Operations, Implement States, Use Delegation to Reuse Implementation, Implement Associations, Implement Attributes, Provide Feedback to Design, Evaluate the Code

Steps:Implement Operations, Implement States, Use Delegation to Reuse Implementation, Implement Associations, Implement Attributes, Provide Feedback to Design, Evaluate the Code

Input Artifacts:Software Architecture Document, Design Package, Design Class, Design Model, Design Guidelines, Programming Guidelines, Supplementary Specifications, Test Case, Data Model, Test Interface Specification, Test Component

Resulting Artifacts:Component, Test Component

Role: ImplementerRole: Implementer

Donnerstag, 20. September 12

Page 14: Architektur vs Agilität

Foto: Casey Hussein Bisson

Der überforderte Architekt"Die ideale Architekt sollte des Schreibens mächtig sein, ein Mathematiker, vertraut mit historischen Studien, ein fleißiger Student der Philosophie, vertraut mit Musik, nicht unwissend in der Medizin, kundig in den Antworten der Rechtsgelehrten, vertraut mit Astronomie und astronomischen Berechnungen."

- Vitruv, circa 25 v. Chr.

14Donnerstag, 20. September 12

Page 15: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Aufgaben von SoftwarearchitektenAnforderungen und Randbedingungen klären, hinterfragen, verfeinern

insbesondere geforderte Qualitätsmerkmale

Strukturentscheidungen treffenBausteine und Schnittstellen festlegen

Übergreifende technische Konzepte entscheidenPersistenz, Kommunikation, GUI, etc.

Software-Architektur kommunizieren und dokumentieren

Umsetzung und Implementierung der Architektur überwachenRückmeldungen der beteiligten Stakeholder einarbeiten

Konsistenz von Quellcode und Softwarearchitektur sicherstellen

Software-Architektur bewertenhinsichtlich Risiken bezüglich der geforderten Qualitätsmerkmale

15

nach iSAQB CPSA-F

Donnerstag, 20. September 12

Page 16: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Aufgaben von Softwarearchitekten

Architektur des Systems definierenIntegrität der Architektur sicherstellenTechnische Risiken erkennenRisikomanagement-Strategien entwickelnAn der Projektplanung teilnehmenReihenfolge und Inhalt von Iterationen vorschlagenConsulting für Design-, Implementierungs- und Integrations-TeamsProduktmarketing mit neuen Visionen unterstützen

16

nach Philippe Kruchten

Donnerstag, 20. September 12

Page 17: Architektur vs Agilität

17Tech

nolo

gyCo

nsul

ting

Stra

tegy

What you KNOWWhat you KNOW What you DO What You ARE•Yourself •Set team context (vision)

•Make decisions (stick)•Build teams•Motivate

•You and others see you as a leader•Charismatic and credible•You believe it can and should be done, and can

lead the effort•You are committed, dedicated, passionate•You see the entire effort in a broader business

context

•Who the key players are in the organization

•What they want, both business and personal

•Communicate, communicate, communicate!•Listen, network, influence•Sell the vision, keep the vision alive•Take and retake the pulse of all critical

influencers of the architecture project

•Able to see from and sell to multiple viewpoints•Confident and articulate Ambitious and driven•Patient and not•Resilient•Sensitive to where the power is and how it flows

in your organization

•Your organization’s business strategy and rationale

•Your competition (products, strategies and processes)

•Your company’s business practices

•Influence business strategy•Translate business strategy into technical

vision and strategy•Understand customer and market trends•Capture customer, organizational and

business requirements on the architecture

•Visionary•Entrepreneurial

•Elicitation techniques•Consulting frameworks

•Build “trusted advisor” relationships•Understand what the developers want and

need from the architecture•Help developers see the value of the

architecture and understand how to use it successfully

•Mentor junior architects

•Committed to others’ success•Empathetic, approachable•An effective change agent, process savvy•A good mentor, teacher

•In-depth understanding of the domain and pertinent technologies

•Understand what technical issues are key to success

•Development methods and modeling techniques

•Modeling•Tradeoff analysis•Prototype/experiment/simulate•Prepare architectural documents and

presentations•Technology trend analysis/roadmaps•Take a system viewpoint

•Creative•Investigative•Practical/pragmatic•Insightful•Tolerant of ambiguity, willing to back-track,

seek multiple solutions•Good at working at an abstract level

Org

. Po

litic

sLe

ader

ship

Architect Competency FrameworkBredemeyer Consulting 2002

Donnerstag, 20. September 12

Page 18: Architektur vs Agilität

Foto: Casey Hussein Bisson

Agile, cross-funktionale Teams

18Donnerstag, 20. September 12

Page 19: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Kummunikation am Fließband

Das funktioniert nicht!Software hat keine physikalischen Gesetze, die die Korrektheit der Ergebnisse sicherstellen würden!

19

ArchitektBusiness EntwicklerKunde Tester

Donnerstag, 20. September 12

Page 20: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Entwicklung ist nicht Fertigung

Architekt wird zum zentralen Kommunikator,

also zum FlaschenhalsEr wartet oder entscheidet alles selbst

Es gibt keine Kommunikation, die an einer Stelle zum Abschluss kommt

Stille Post dauert zu langeMan braucht immer die Sicht aller Rollen

20Donnerstag, 20. September 12

Page 21: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Agile Architekturrunde:Gemeinsam sind wir Architekten !

21

Benutzer

Entwickler

Business

Domänen-

experte

Architekt

Fachbereich

Analyst

etc.

Designer

Programmierer

Tester

Kunde

Donnerstag, 20. September 12

Page 22: Architektur vs Agilität

22

Benutzer Business Kunde Domänen-experte

Entwickler

Benutzer

Business

Kunde

Domänen-experte

Entwickler

Feature-Priorität, Scope

Bequemlich-keit einkaufen

Produkt/Feature-Machbarkeit

Qualität und Funktiona-lität

Machbarkeit Standards Anforderungen klären

Machbarkeit Quelle von Einnahmen

Ein Markt Produkte und Leistungen

Standards schaffen

Standards einhalten

Quelle von Einnahmen

Spanne von Variabilität im Produkt

Angenehmer Arbeitsplatz

Bedarf an Standards

Domänen-Synergien und-Konflikte

Rahmenbe-dingungen für Technologie

Anforderungen klären

Angenehmer Arbeitsplatz

Beratung beim Ausliefer-prozess

Orientierung durch APIs, poka-yoke

Existieren-den Code verstehen

Stakeholder untereinander

Donnerstag, 20. September 12

Page 23: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Warum alle am Tisch sitzen müssen!

23

Stakeholder Beitrag zur Architektur

Benutzer Erwartungen, kognitives Modell

Kunde Zeit, Kosten, Produktkonfiguration je nach Zielmarkt angepasst

Business Umsatz, Kosten, Investment

Domänenexperte Erfahrung

Entwickler Machbarkeit, Testbarkeit

Donnerstag, 20. September 12

Page 24: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Beispiel: Make or Buy Entscheidung

24

Stakeholder Beitrag zur Architektur

Business Schlägt "buy" statt "make" vor

Kunde und Benutzer

Sagt, ob das gekaufte Etwas die Standards einhält

Domänenexperte Beurteilt Integrierbarkeit des gekauften Etwas

Entwickler Beurteilen Aufwand und Nebenwirkungen der Integration des gekauften Etwas

Tester Beurteilt, ob das integrierte System testbar sein wird

Donnerstag, 20. September 12

Page 25: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Conways Gesetz

Conway 1968:"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"

Coplien / Harrison 2004:"If the parts of an organization (e.g. teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble... Therefore: Make sure the organization is compatible with the product architecture"

25Donnerstag, 20. September 12

Page 26: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Die wesentliche Architektenaufgabe

Systemschnitt entwickelnEssenzielle Systemteile entkoppelnKopplung zwischen Systemteilen induziert Commitment zwischen Teams

lässt agile Teams aufeinander warten

Also müssen Architektur-Teams einen Systemschnitt entwerfen, der den anderen Teams erlaubt, eigenständig und schnell zu arbeiten.

26Donnerstag, 20. September 12

Page 27: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Zusammenarbeit

27

Architekturrunde

Saturn-

Team

Neptun-

Team

Architektur

Saturn-BacklogNeptun-Backlog

Saturn Neptun Delegation

Delegation

Donnerstag, 20. September 12

Page 28: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

PO, Architektekturrunde, Team

Architekturrunde liefert nicht-funktionale Backlog-ElementeProduct Owner entscheidet, ob und wann sie in die Entwicklung einfließen

28

Architekt ist jetzt Team-Mitglied (Domänenexperte), der "Bergführer", der "Kümmerer", der die Architektur-Energie aufrechterhält

Backlog

Product Owner

Team

Donnerstag, 20. September 12

Page 29: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Architekturarbeit gehört ins Backlog!

29

Stefan Toth (oose GmbH) :: Architekturbewertung – Der Schlüssel zur besseren Architektur(-arbeit)

Donnerstag, 20. September 12

Page 30: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Quality Story

Eine Quality Story wird ins Backlog zwischen zwei andere Stories einsortiert.Die Architektenrunde definiert die Q-Story, der Product Owner sortiert sie ein.

30

Story

Story

Q-Story

Donnerstag, 20. September 12

Page 31: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Quality Aspect

Ein Qualitätsaspekt kommt in die DoD einer oder mehrerer Stories.Die Architektenrunde definiert den Aspekt, der Product Owner lässt ihn zu.

31

Story

Definition of Done

Donnerstag, 20. September 12

Page 32: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Quality Policy

Eine Rahmenbedingung kommt als Merker auf die Backlog-Wand.Die Architektenrunde definiert die Rahmenbedingung, der Product Owner lässt sie zu.

32

Story

Story

Rahmen-

bedingungStory

Donnerstag, 20. September 12

Page 33: Architektur vs Agilität

Foto: Casey Hussein Bisson

Schlanke Architektur-Dokumentation

33Donnerstag, 20. September 12

Page 34: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Was ist SW-Architektur?

34

Form, Struktur, Verhalten, Stil

Ralph Johnson: "Architektur ist die Menge von Entscheidungen, von denen Sie wünschten, Sie könnten sie früh im Projekt richtig treffen (aber bei denen die Wahrscheinlichkeit, sie richtig zu treffen, nicht notwendigerweise größer ist als bei jeder anderen Entscheidung)."

Donnerstag, 20. September 12

Page 35: Architektur vs Agilität

Form versus Struktur

35

Struktur stützt FormForm ermöglicht Verhalten

Donnerstag, 20. September 12

Page 36: Architektur vs Agilität

Form versus Struktur

35

Struktur stützt FormForm ermöglicht Verhalten

Donnerstag, 20. September 12

Page 37: Architektur vs Agilität

Form versus Struktur

35

Struktur stützt FormForm ermöglicht Verhalten

Donnerstag, 20. September 12

Page 38: Architektur vs Agilität

Form versus Struktur

35

Struktur stützt FormForm ermöglicht Verhalten

Donnerstag, 20. September 12

Page 39: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Schlanke Architekturdokumentation

36

Aspekt Bedeutung Medien

Form Subsysteme, APIs, von außen sichtbares Verhalten

Bilder und Vodcasts im Wiki, APIs im Code

Struktur Subsystem-interne Klassen und Schnittstellen

Code

Verhalten wichtige Abläufe im System

Bilder im Wiki, den Rest im Code

Stil Entwurfsprinzipien Wiki

Donnerstag, 20. September 12

Page 40: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Auch wichtig zu dokumentieren!

QuerschnittskonzeptePersistenz, Logging, Transaktionsbehandlung, Authentifizierung, Autorisierung, usw.

Design-EntscheidungenDatum, Ausgangslage, Problemstellung, gewählte/verworfene Optionen, Entscheidungsweg/Begründung, Wiki

37Donnerstag, 20. September 12

Page 41: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Architektur ist nötig

Sie ermöglicht unabhängiges Handeln in den Teams

Alle zusammen sind "der Architekt"

Architektur bleibt schlank, wenn man sich konzentriert!

38

Zusammenfassung

Donnerstag, 20. September 12

Page 42: Architektur vs Agilität

Coach für effektive ProduktentwicklungMatthias Bohlen

Mehr Info? Hier melden!

Matthias BohlenCoach für effektive Produktentwicklung

Telefon: +49 170 772 8545E-Mail: [email protected]: http://www.mbohlen.de/Twitter: @mbohlende

Donnerstag, 20. September 12

Page 43: Architektur vs Agilität

Nächster Vortrag

40

15:30 Uhr

Donnerstag, 20. September 12