Post on 28-Nov-2014
description
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
Back To School, © Hans van Vliet, 2011 3
Pre-architecture life cycle
requirements qualitystakeholders
(few) requirements quality(few)
agreement
development
Back To School, © Hans van Vliet, 2011 4
Architecture in the life cycle
stakeholders(many)
requirements quality
architecture
tagreement
development
Back To School, © Hans van Vliet, 2011 5
Global workflow in architecture design
context architecturesynthesis
evaluation
backlog evaluation
requirementsevaluation
results
Back To School, © Hans van Vliet, 2011 6
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.)
Back To School, © Hans van Vliet, 2011 7
Software Architecture
statementstatement
procedurep
module
(design) pattern
architecture
Back To School, © Hans van Vliet, 2011 8
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
Back To School, © Hans van Vliet, 2011 9
Software Architecture, definition (4)
S ft hit t d i ( t &Software architecture = design (components & connectors) + design decisions
Back To School, © Hans van Vliet, 2011 10
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.”
Back To School, © Hans van Vliet, 2011 11
Agenda
A hit tArchitecture
AgilityAgility
Architecture and agilityg y
Case studies of A&A
Back To School, © Hans van Vliet, 2011 12
Waterfall Model
reqs engineering
d i
V & V
design
implementation
V & V
implementation
testing
V & V
g
maintenance
V & V
V & V
Back To School, © Hans van Vliet, 2011 13
Another waterfall model
testingg
implementation
feedback
implementation
design
requirementsengineering
Back To School, © Hans van Vliet, 2011 14
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
Back To School, © Hans van Vliet, 2011 15
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
Back To School, © Hans van Vliet, 2011 16
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
Back To School, © Hans van Vliet, 2011 17
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
Back To School, © Hans van Vliet, 2011 18
Scrum process
Back To School, © Hans van Vliet, 2011 19
Survey of development methods
Back To School, © Hans van Vliet, 2011 20
D. West & J. Hammond, The Forrster Wave: Agile Development Management, 2010
Agenda
A hit tArchitecture
AgilityAgility
Architecture and agilityg y
Case studies of A&A
Back To School, © Hans van Vliet, 2011 21
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
Back To School, © Hans van Vliet, 2011 22
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
Back To School, © Hans van Vliet, 2011 23
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
Back To School, © Hans van Vliet, 2011 24
Not all design is architecture
reality
perception
P. Abrahamsson et al, Agility and Architecture,
can they coexist
Back To School, © Hans van Vliet, 2011 25
can they coexistIEEE Software, 2010
Context
P. Abrahamsson et al, Agility and Architecture,
Back To School, © Hans van Vliet, 2011 26
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
Back To School, © Hans van Vliet, 2011 27
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
Back To School, © Hans van Vliet, 2011 29
George Fairbanks, Just Enough Architecture, Crosstalk, 2010
Global workflow in architecture design
context architecturesynthesis
evaluation
backlog evaluation
requirementsevaluation
results
Back To School, © Hans van Vliet, 2011 30
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
Back To School, © Hans van Vliet, 2011 31
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
Back To School, © Hans van Vliet, 2011 32
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”
Back To School, © Hans van Vliet, 2011 33
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
Back To School, © Hans van Vliet, 2011 34
Agenda
A hit tArchitecture
AgilityAgility
Architecture and agilityg y
Case studies of A&A
Back To School, © Hans van Vliet, 2011 35
A printer product line
Back To School, © Hans van Vliet, 2011 36
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)
Back To School, © Hans van Vliet, 2011 37
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
Back To School, © Hans van Vliet, 2011 38
Tension tacit-explicit knowledge
Tacit KnowledgeTacit Knowledge
Explicit Knowledge
Back To School, © Hans van Vliet, 2011 39
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
Back To School, © Hans van Vliet, 2011 40
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
Back To School, © Hans van Vliet, 2011 41
How much should the architect tell
I don’t care Verification boomerang
Back To School, © Hans van Vliet, 2011 42
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%
Back To School, © Hans van Vliet, 2011 43
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
Back To School, © Hans van Vliet, 2011 44
Documentation: the hot potato
Tacit KnowledgeComponent Architects
Tacit Knowledge
Lead (SPL) Architects
Explicit Knowledge Project Developers
Back To School, © Hans van Vliet, 2011 45
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
Back To School, © Hans van Vliet, 2011 48
Role of roadmaps
standards marketingg
architecturetechnology competitors
Back To School, © Hans van Vliet, 2011 49
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
Back To School, © Hans van Vliet, 2011 51
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
Back To School, © Hans van Vliet, 2011 53
Boundary spanners
R. Baskerville et al,Post-agility: What follows
Back To School, © Hans van Vliet, 2011 54
A decade of agility?IST, 2011
Lightweight Software Engineering ontology
Back To School, © Hans van Vliet, 2011 55
Search results for ‘configuration’
Back To School, © Hans van Vliet, 2011 56
Search results for ‘configuration’
Back To School, © Hans van Vliet, 2011 57
Filter class functional requirement
Back To School, © Hans van Vliet, 2011 58
Filter class functional requirement
Back To School, © Hans van Vliet, 2011 59
Filter class functional requirement
Back To School, © Hans van Vliet, 2011 60
Filter class functional requirement
Back To School, © Hans van Vliet, 2011 61
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, …
Back To School, © Hans van Vliet, 2011 62
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
Back To School, © Hans van Vliet, 2011 63