Devnology Back to School IV - Agility en Architectuur

Passen Agility en Architectuur op één kussen, of komt de

duivel daartussen?

Hans van VlietVrije Universiteit Amsterdam

My personal history

1967 computer operator programmer1967 computer operator, programmer

1973-1978 MSc Mathematics/CS

1979 PhD, ALGOL 68

1986 Professor Software Engineering VU University1986 Professor Software Engineering, VU University

1983 Software Engineering textbook (2000, 2008)

1996- Research Software Architecture (ALMA, GRIFFIN, Stephenson)

2008 Journal of Systems and Software (EiC)

Back To School, © Hans van Vliet, 2011 2

Agenda

A hit tArchitecture

AgilityAgility

Architecture and agilityg y

Case studies of A&A


Pre-architecture life cycle

requirements qualitystakeholders

(few) requirements quality(few)

agreement

development


Architecture in the life cycle

stakeholders(many)

requirements quality

architecture

tagreement

development


Global workflow in architecture design

context architecturesynthesis

evaluation

backlog evaluation

requirementsevaluation

results


Christine Hofmeister et al, Generalizing a model of software architecture Design, Journal of Systems and Software, 2007

Software architecture, definition (1)

The architecture of a software system defines that system in terms of computational components and interactions among those components.

(from Shaw and Garlan Software Architecture(from Shaw and Garlan, Software Architecture, Perspectives on an Emerging Discipline, Prentice-Hall, 1996.)


Software Architecture

statementstatement

procedurep

module

(design) pattern

architecture


Other points of view

A hit t i hi h l l d iArchitecture is high-level design

Architecture is overall structure of the systemArchitecture is overall structure of the system

Architecture is the structure, including the , gprinciples and guidelines governing their design and evolution over time

Architecture is components and connectors


Software Architecture, definition (4)

S ft hit t d i ( t &Software architecture = design (components & connectors) + design decisions


Where did it start?

1992: Perry & Wolf1992: Perry & Wolf1987: J.A. Zachman; 1989: M. Shaw1978/79: David Parnas, program families, p g1972 (1969): Edsger Dijkstra, program families1969: I.P. Sharp @ NATO Software Engineering

conference:conference:“I think we have something in addition to software engineering [..] This is the subject of software

hit t A hit t i diff t farchitecture. Architecture is different from engineering.”


Agenda

A hit tArchitecture

AgilityAgility


Case studies of A&A


Waterfall Model

reqs engineering

d i

V & V

design

implementation

V & V

implementation

testing

V & V

g

maintenance

V & V

V & V


Another waterfall model

testingg

implementation

feedback

implementation

design

requirementsengineering


Activity versus phase

Design Implementation Integrationtesting

AcceptancetestingPhase

Activity

Integrationtesting 4.7 43.4 26.1 25.8

Implementation(& unit testing) 6.9 70.3 15.9 6.9

Design 49.2 34.1 10.3 6.4


The Agile Manifesto

Individuals and interactions over processes and toolstools

Working software over comprehensive documentation

Customer collaboration over contract negotiation Responding to change over following a plan


13 practices of XP

Wh l t li t t T t d i Whole team: client part of the team

Metaphor: common

Test-driven development: tests developed first

analogy for the system The planning game,

based on user stories

Design improvement (refactoring)

Collective codebased on user stories Simple design Small releases (e.g. 2

k )

Collective code ownership

Continuous integration: system always runsweeks)

Customer tests Pair programming

system always runs Sustainable pace: no

overtimep g g Coding standards


SCRUM

D l t i i t (t i ll 2 4 k )Development in sprints (typically 2-4 weeks)

Features to be implemented come from the backlogFeatures to be implemented come from the backlog

Backlog can change on the fly; sprint backlog g g y; p gcannot

Development is time-boxed

Daily buildsDaily builds


Scrum process


Survey of development methods


D. West & J. Hammond, The Forrster Wave: Agile Development Management, 2010

Agenda

A hit tArchitecture

AgilityAgility


Case studies of A&A


Can Agile and Architecture Co-exist?

A il ti t i h l fit f llAgile practices are amateurish, only fit for small-scale web applications

Architecture is a useless Big Design Up-Front, leading to YAGNI features: You Ain’t Gonna Need It


Agile-architecture conflict

T i b t d t ti d ti i tiTension between adaptation and anticipation Agile – adaptation: decide on the last possible moment Architecture – anticipation: plan in advance

Tension between tacit and explicit knowledge Agile – knowledge is tacit, in the heads of people Architecture – knowledge is explicit, in documents


Different levels to understand the conflict

S ti h t d hit t N t llSemantics: what does architecture mean. Not all design is architectureScope: depends on contextScope: depends on contextLife cycle: when? EarlyRole: inward looking vs outward lookingDocumentation: not all documentation is badMethods: they do existValue and cost: cost is visible, value is hard to

establish


Not all design is architecture

reality

perception

P. Abrahamsson et al, Agility and Architecture,

can they coexist


can they coexistIEEE Software, 2010

Context

P. Abrahamsson et al, Agility and Architecture,


g ycan they coexist

IEEE Software, 2010

Architect’s role: inward or outward

A hit t l d k d k f biArchitectus reloadus: maker and keeper of big decisions, focusing on external coordination

Architectus oryzus: mentor, prototyper, troubleshooter, focusing on internal issues, code-f ifacing


M. Fowler

Opinions of agile developers

A hit t i i t t?Architecture is important? Never: 5% Always: 45% When it’s complex: 50%

Many requirements: 33% Many stakeholders: 29% Many stakeholders: 29% Global: 19% Other: 19%

Back To School, © Hans van Vliet, 2011

Falesi et al: Peaceful coexistence, IEEE Software March 2010

28

Just Enough Architecture

Identify and prioritize risks E g tricky quality requirements distributed teamsE.g., tricky quality requirements, distributed teams

Select and apply set of architecture techniques to mitigate risks Choices should vary

Three tier system First tier: user interface, exposed to internet, biggest risks: , p , gg

usability and security Second tier: business rules and persistence, biggest risks:

throughput, scalabilityg p , y different modeling techniques

Re-evaluate remaining risks


George Fairbanks, Just Enough Architecture, Crosstalk, 2010

Global workflow in architecture design

context architecturesynthesis

evaluation

backlog evaluation

requirementsevaluation

results


Christine Hofmeister et al, Generalizing a model of software architecture Design, Journal of Systems and Software, 2007

How to choose from the backlog?

FFocus on revenueFocus on risk Identify fail scenarios (what if …) and add cost * probability ofIdentify fail scenarios (what if …) and add cost probability of

those fail scenarios Cost of decision = cost to undue that decision


Eltjo Poort & Hans van Vliet, Architecting as a Risk- and CostManagement Discipline, WICSA, 2011

Technical Debt

M t h t t f t kiMetaphor to represent consequences of taking shortcuts to deliver a product fasterNeeds to be repaid, e.g. through refactoringNeeds to be repaid, e.g. through refactoringCost of debt is interest: extra effort/cost to work

around the shortcutsThe longer it takes to repay, the more interest is

accrued

Lehman’s Laws of software evolution(1970s): increasing complexity, declining quality


Technical debt quadrant

reckless vs prudent

“we don’t have time “we must ship now and

deliberatevs

we don t have timefor design”

we must ship now anddeal with the consequences”

vsinadvertent

“what’s layering?”“now we know how weshould have done it”


Erin Lim, 2010

Tension traditional -- agile

H t iti lf i thi di i ?How to position oneself in this dimension?

How much upfront architecture is appropriate?How much upfront architecture is appropriate?

Too much waste because things changeg g

Too little waste because of many refactorings


Agenda

A hit tArchitecture

AgilityAgility


Case studies of A&A


A printer product line


Characteristics

P d t li f b th id f t i ti dProduct lines for both wide format printing and document printing

Many products under development/in operation

Controller software: ~250 people

3 sites, in 3 countries (& legal relations differ)


Software Product Lines

A ft d t li i “ t f ftA software product line is “a set of software-intensive systems sharing a common set of features that satisfy the specific needs of a particular market segment and that are developed from a common set of core assets in a prescribed way”way .

How to combine agility and software product lines?g y p


Tension tacit-explicit knowledge

Tacit KnowledgeTacit Knowledge

Explicit Knowledge


Tensions

H h t d t?How much to document? Everything upfront? – classic approach Nothing? – pure agile Somewhere in between, just-in-time, just-enough

How much to plan?How much to plan? Grand upfront design? – enterprise architecture/product line

architecture document Let all flowers bloom Somewhere in between? – “Owen” model


Example issues we investigated

H h h ld th hit t t llHow much should the architect tell

Who should communicate whatWho should communicate what

How much do people know of roadmapsp p p


How much should the architect tell

I don’t care Verification boomerang


Categories of issues

D b t d ( i i diff ) 30%Debated (opinions differ): 30% Usually user interaction/experience

Omissions (missing info in spec): 28%Omissions (missing info in spec): 28% Unanticipated complexity Retrospective improvement

I diff ( l i t) Indifference (e.g. manual insert)

Misunderstanding (of spec): 27%Wrong spec: 11%Wrong spec: 11%New insight (potential improvements): 4%


Insights gained

A hit t t d t if t i d tArchitect tends to specify w.r.t. previous product

It is important to know what other team members It is important to know what other team members know

Rahul Premraj et al The Boomeranged Architect WICSA 2011Rahul Premraj et al, The Boomeranged Architect, WICSA 2011


Documentation: the hot potato

Tacit KnowledgeComponent Architects

Tacit Knowledge

Lead (SPL) Architects

Explicit Knowledge Project Developers


Survey topics

D t d k l d h h i d dDocumented knowledge: how much is needed, what is needed

Perceived responsibilities: how is responsibility aligned between roles

Task ownership: who should DO it

46

Findings:

Documentation: More is needed Disagreement as to who should write it

Responsibilities:Responsibilities: Overall agreements as to who is responsible Diagreements when it comes to clarify requirements and

designs

Task ownership Disagreements as to who should write certain documentationDisagreements as to who should write certain documentation,

who should clarify requirements, who can demand what information from whom

47

Findings (2)

All roles need information from each other, but sometimes do not know where to get itsometimes do not know where to get it

Tacit understanding as to who should do what

Leads to expectation mismatches

Antony Tang et al, On the Interplay between Software Architects andy g ySoftware Engineers in an Agile Environment, SSE 2011


Role of roadmaps

standards marketingg

architecturetechnology competitors


Roadmapping

F l i f t d f ti fFor planning new features and functions for new productsManage high-level, future requirementsManage high level, future requirements Involves different stakeholders: Product and marketing stakeholders (requirements, market

d )needs) Architects (feasibility, technology trends, planning architecture

design) Project managers (schedules, planning)

50

Roadmap coordination issues

K l d hi “I d t k h t I dKnowledge ownership – “I do not know what I need to know”Knowledge distribution – unused sharedKnowledge distribution unused shared

knowledge & unshared knowledgeTiming of knowledge sharing – too late, or too earlyCoordination of the roadmapping process – how

many roadmaps are needed, who is responsible


Message

Ch ll f th i ti l h fChallenge: further improve timely exchange of (roadmap) knowledge between architectsMuch knowledge is created but not sharedMuch knowledge is created but not shared

effectivelyPersonalization strategy alone does not sufficeWe propose to use a semantic wiki to index

roadmapping concepts

Antony Tang et al, Building Roadmaps: A Knowledge Sharing Perspective, SHARK 2011

52

y g g g g

How to bridge the gap?

B dBoundary spanners

Tool supportTool support Semantic wikis +notifications when contents change Expert finders based on data mining


Boundary spanners

R. Baskerville et al,Post-agility: What follows


A decade of agility?IST, 2011

Lightweight Software Engineering ontology


Search results for ‘configuration’


Filter class functional requirement


Expert finder

Mi ft it i ( dMine software repositories (source code repositories, issue tracking systems, mail, …) to connect people to shared artifacts, e.g. components they both worked onCodebook (Microsoft), social network service that

helps find connections with colleagueshelps find connections with colleagues Hoozizat: who is responsible for some API, feature, … Deep Intellisense: shows complete history of events for any

program identifier clicks on: code changes, bugs, blog entries, …


Readings

P Ab h t l A ilit d A hit tP. Abrahamsson et al, Agility and Architecture, can they coexist, IEEE Software, 2010

R. Premraj et al, The Boomeranged Architect, WICSA 2011

R. Baskerville, Post-agility: what follows a decade of agility Information and Software Technologyof agility, Information and Software Technology, 2011


Devnology Back to School IV - Agility en Architectuur

Technology

Transcript of Devnology Back to School IV - Agility en Architectuur