Architektur agiles vorgehen seacon 2013

© OPITZ CONSULTING GmbH 2013 Seite 1Vom Zusammenhang zwischen Architekturen und agilem Vorgehen

Dr. Ralf Sigmund, Solution Architect

OPITZ CONSULTING

Vom Zusammenhang zwischen Architekturen und agilem Vorgehen

Hamburg, 17. Mai 2013

Don't supersize me!


Agenda

1. Das Projekt bei der freenet GmbH

2. Also agil? Konsequenzen für die Architektur und die Plattformauswahl

3. Architekturentscheidungen Systematisch treffen und dokumentieren

4. Fazit Welche Plattform war für freenet die richtige?


1Das Projekt Wasabi bei der freenet GmbH


E-Commerce bei freenet

Customer Frontend

Customer Database

Bonität

Wirksysteme

Billing SAP

Callcenter

Mail-Gateway

Business Intelligence


Prozessorientiertes Vorgehen

Produktwelten mail, singles

Vertragsabschluss

Upgrade

Kündigung

<<Subprozess>> Provisionierung


Projektziele

Automatisierung

Vereinfachung

SaaS

agil


BPMN 2.0 ist agil ;-)


Prozessmodelle

Strategisches Prozessmodell

Operatives Prozessmodell

Technisches Prozessmodell

Business

IT


Transparenz

Modell Engine Monitoring

Transparenz


2 Also agil?


awareness

Wissens-silos

Probleme spät

erkannt

Lange Zyklen

:-(


desire Produktivität

Engagement,

Zufriedenheit

Faster Time to Market

Höhere Qualität


agil: if it ain’t perfect keep improving

nicht agil: if it ain’t broke do not fix it

motif


1975 Fred BrooksAll repairs tend to destroy structure, increase entropy and disorder. Less and less effort is spent fixing original design flaws, more and more time fixing flaws introduced by earlier fixes. Sooner or later, fixing ceases to gain any ground. Also usable, the system has worn out as a base for progress. Machine, configuration and requirement changes eventually dictate ground-up redesign.

Modifikationen (Bugs, neue Features)

Ent

opie

Aber Entropie / Unordnung


Simplicity is the ultimate sophistication.Leonardo da Vinci

Simple made easyRich Hickey


Agile

Emergent Design

Refactoring

Test Driven Development

Automated Tests

Excellent technical Practice


ability

Als Team denken, selbst verantwortlich

sein

Collective code ownership

Excellent technical practice

Emergent Design


easy

WizardsBPELZero Coding


easy ???

Refactoring?Merging?Codebasis lesen und verstehen?


Zeit

Pro

dukt

ivitä

t

Rich Hickey http://www.infoq.com/presentations/Simple-Made-Easy

easysimple

simple versus easy


Exkurs - Komposition


Verflechtung durch Zustand


Agiles Vorgehen erfordert zwingend exzellente technische Praxis

Continuous testing

Refactor

Simple

System

Michael Feathers definiert Legacy Code als “Code ohne automatisierte Tests”.


3 Architekturentscheidungen

• Systematisch treffen und dokumentieren


Qualität ist orthogonal zu Funktionalität

Funktionalität - User Stories“als Kunde mit einem Basic Vertragwenn ich ein Upgarde auf einen PAID-Vertrag durchführe und die Bonitätsprüfung erfolgreich war,dann wird das Mailbox-Volumen auf 100GB erhöht.”

Qualität“die Anbindung einer neuen Reseller-Marke ist mit einem Aufwand von 20 PT implementierbar”


Geschäftsziele


planen entwickeln testen releasen betreiben

Zeit

Geschäftsqualität - Time to Market


Time to market

Cost and benefit

Projected lifetime

Rollout schedule

Geschäftsqualitäten


Architektur System

Geschäfts-QualitätQualität

Qualitäten wirken sich aufeinander aus

Qualität


Analysis scheitert an Systemen

Analysis Systemdenken

StoriesEpicsMMFs, MVPs Emergent Design Architektur


System

Funkt-ionalität

Zuver-lässigkeit

Benutz-barkeit

Effizienz

Wartbar-keit

Übertrag-barkeit

Qualität in Software Systemen


ISO 9126ISO/IEC 25012:2008


Alle Qualitäten sind erstrebenswert


Aber, Tradeoffs sind unvermeidlich


Architecture Tradeoff Analysis Methodhttp://www.sei.cmu.edu/reports/00tr004.pdf

Lightweight Architecture Alternative Assessment Methodhttp://technogility.sjcarriere.com/2009/05/11/its-pronounced-like-lamb-not-like-lame/

Qualitätsmerkmale und Tradeoffs methodisch angehen

Szenarien Risiken

Sensitivity points

TradeoffsAttribute

Requirements

Architektur-ansätze

Analyse

http://www.sei.cmu.edu/reports/00tr004.pdf

http://www.sei.cmu.edu/reports/00tr004.pdf

http://technogility.sjcarriere.com/2009/05/11/its-pronounced-like-lamb-not-like-lame/


Quelle:

Stimulus: Antwort:

Antwort-Maßzahl:

Artefakt:

Umgebung:

Software Architecture in Practice (2nd Ed.)

Qualitäts-Attribute in Szenarien konkretisieren

http://www.sei.cmu.edu/library/abstracts/books/0321154959.cfm


Quelle:

Stimulus: Antwort:

Antwort-Maßzahl:

Artefakt:Prozess

Umgebung:

System-Extern

UnerwarteteNachricht(ein Fehler) Normaler Betrieb

Operator informieren, Verarbeitung fortführen Keine Ausfallzeit

Ein Szenario zur Verfügbarkeit


Quelle:QA / Produktion

Artefakt:Prozesse /

Codebasis / DeliverablesStimulus: Antwort:

Antwort-Maßzahl:Umgebung:

Fehler in der Prozesslogik

Korrektur in Produktion ohne Seiteneffekt In 5 Stunden

System > 200 FTE Implementierung

Modifizierbarkeit – Korrektur von Fehlern


Quelle:Architektagiles Team

Artefakt:Prozesse /



System vereinfachenRefactoring

Verbesserte Code-Struktur erreicht ohne Seiteneffekt In einem

Sprinttag

System > 200 FTE Implementierung

Modifizierbarkeit – Refactoring


Modfizierbarkeit – Refactoring – Testbarkeit

https://github.com/sistar/camunda-fox-demo-app-oc

https://github.com/sistar/camunda-fox-demo-app-oc


Quelle:Analyst

Artefakt:Prozesse /



Änderung einer Geschäftsregel

Änderung durchgeführt ohne Seiteneffekt Ohne Beteiligung

des Entwickler-Teams

Analyst kennt BPMN 2.0, Rules.Kennt nicht technische Details

Benutzbarkeit – Zero Coding


Qualität / Utility

Effizienz AntwortzeitFrontend - Eine

Cluster-Node bei normaler Last <2s

Funktionalität SicherheitKein Zugriff auf

interne Daten durch Frontend

Zuverlässigkeit RobustheitKein Ausfall bei falschem Aufruf durch Frontend

Wartbarkeit

Modifizierbarkeit

Fehler-Korrektur der Prozesslogik in

5h

Refactoring Verbesserte Code Struktur in einem

Sprinttag

Testbarkeit

Testgetriebene Entwicklung

Prozess Unit Test < 1 Minute

Benutzbarkeit Erlernbarkeit

Business / IT gemeinsames Prozessmodell

Zero Coding - Änderung von

Geschäftsregel ohne Entwicklerteam

Qualitätsszenarien als Utility Tree


Qualität / Utility

Effizienz AntwortzeitFrontend - Eine

Cluster-Node bei normaler Last <2s

Funktionalität SicherheitKein Zugriff auf

interne Daten durch Frontend

Zuverlässigkeit RobustheitKein Ausfall bei falschem Aufruf durch Frontend

Wartbarkeit

Modifizierbarkeit

Fehler-Korrektur der Prozesslogik in

5h

Refactoring Verbesserte Code Struktur in einem

Sprinttag

Testbarkeit

Testgetriebene Entwicklung

Prozess Unit Test < 1 Minute

Benutzbarkeit Erlernbarkeit

Business / IT gemeinsames Prozessmodell

Zero Coding - Änderung von

Geschäftsregel ohne Entwicklerteam

Ranking im Utility Tree

Ranked Attribute Weights:

-> 0,262

-> 0,461

-> 0,163

-> 0,094

-> 0,045

-> 0,75

-> 0,25

1

2

1->0,75

2->0,25

0,26

0,46

0,16

0,05

0,017

0,023

0,03

0,01

1->0,75

2->0,25


Priorisierte Liste der Qualitätsszenarien

Sicherheit / Kein Zugriff auf interne Daten durch Frontend

Effizienz / Antwortzeit Frontend - Eine Cluster-Node bei normaler Last <2s

Robustheit Kein Ausfall bei falschem Aufruf durch Frontend

Wartbarkeit / Fehler-Korrektur der Prozesslogik in 5h

Testbarkeit / Testgetriebene Entwicklung Prozess Unit Test < 1 Minute

Erlernbarkeit / Business / IT gemeinsames Prozessmodell

Erlernbarkeit / Zero Coding - Änderung von Geschäftsregel ohne Entwicklerteam


Sensitivity Points

Sicherheit / Kein Zugriff auf interne Daten durch Frontend

Effizienz / Antwortzeit Frontend - Eine Cluster-Node bei normaler Last <2s

Robustheit Kein Ausfall bei falschem Aufruf durch Frontend

Wartbarkeit / Fehler-Korrektur der Prozesslogik in 5h

Testbarkeit / Testgetriebene Entwicklung Prozess Unit Test < 1 Minute

Erlernbarkeit / Business / IT gemeinsames Prozessmodell

Erlernbarkeit / Zero Coding - Änderung von Geschäftsregel ohne Entwicklerteam


Assesment (exemplarisch)

Szenario Gewicht Camunda BPM

OracleBPM

Testgetriebene Entwicklung Prozess Unit Test < 1 Minute

0,023 Exzellent (4)0,092

Mäßig (1)0,023

Zero Coding Änderung von Geschäftsregel ohne Entwicklerteam

0,01 Mäßig (1)0,01

Exzellent (4)0,04

Architekturalternativen

0,102 0,063Summe


4 Fazit


It depends…

Zeit

Pro

du

ktiv

ität

easysimple

Zeit

Pro

du

ktiv

ität

Code zentrisch Tool- /Plattformzentrisch

Standard

Organisatorisch

Klare Ziele und Anforderungen

Individuell

Zentral für Wertschöpfung

agil


Danke! Fragen und Antworten

[email protected]: @sistar Xing Ralf Sigmund

Technology

Architektur agiles vorgehen seacon 2013