1. Passen Agility en Architectuur
op één kussen, of komt de
duivel daartussen?
Hans van Vliet
Vrije Universiteit Amsterdam

2. My personal history
1967 computer operator, programmer
operator
1973-
MSc Mathematics/CS
1978
1979 PhD, ALGOL 68
1986 Professor Software Engineering, VU University
Engineering
1983 Software Engineering textbook (2000, 2008)
2008 Journal of Systems and Software (EiC)
1996- Research Software Architecture (ALMA, GRIFFIN, Stephenson)
Back To School, © Hans van Vliet, 2011 2

3. Agenda
 A hit t
Architecture
 Agility
 Architecture and agility
g y
 Case studies of A&A
Back To School, © Hans van Vliet, 2011 3

4. Pre-architecture life cycle
stakeholders
(few) requirements quality
agreement
development
Back To School, © Hans van Vliet, 2011 4

5. Architecture in the life cycle
stakeholders
(many)
requirements quality
architecture
agreement
t
development
Back To School, © Hans van Vliet, 2011 5

6. Global workflow in architecture design
synthesis architecture
context
backlog evaluation
evaluation
requirements
results
Christine Hofmeister et al, Generalizing a model of software architecture Design,
Journal of Systems and Software, 2007
B To S
ack chool, © Hans van Vliet, 2011 6

7. 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
Garlan, Architecture,
Perspectives on an Emerging Discipline, Prentice-
Hall, 1996.)
Bc T Sho ©Hn vnV t, 2 1
ak o col, as a lie 0 1 7

8. Software Architecture
statement

p
procedure

module

(design) pattern

architecture
Back To School, © Hans van Vliet, 2011 8

9. Other points of view
 A hit t
Architecture is high-level design
i hi h l ld i
 Architecture is overall structure of the system
 Architecture is the structure, including the
, g
principles and guidelines governing their design
and evolution over time
 Architecture is components and connectors
Back To School, © Hans van Vliet, 2011 9

10. Software Architecture, definition (4)
 S ft
Software architecture = design (components &
hit t d i ( t
connectors) + design decisions
Back To School, © Hans van Vliet, 2011 10

11. Where did it start?
 1992: Perry & Wolf
 1987: J.A. Zachman; 1989: M. Shaw
 1978/79: David Parnas, program families
,p g
 1972 (1969): Edsger Dijkstra, program families
 1969: I.P. Sharp @ NATO Software Engineering
conference:
“I think we have something in addition to software
engineering [..] This is the subject of software
architecture. Architecture is different from
hit t A hit t i diff tf
engineering.”
Bc T Sho ©Hn vnV t, 2 1
ak o col, as a lie 0 1 11

12. Agenda
 A hit t
Architecture
 Agility
 Architecture and agility
g y
 Case studies of A&A
Bc T Sho ©Hn vnV t, 2 1
ak o col, as a lie 0 1 12

13. Waterfall Model
reqs engineering
V&V
design
d i
V&V
implementation
V&V
testing
g
V&V
maintenance
V&V
Back To School, © Hans van Vliet, 2011 13

14. Another waterfall model
testing
g
feedback
implementation
design
requirements
engineering
Back To School, © Hans van Vliet, 2011 14

15. Activity versus phase
Integration Acceptance
Phase Design Implementation
Activity testing testing
Integration
testing
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

16. The Agile Manifesto
 Individuals and interactions over processes and
tools
 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

17. 13 practices of XP
 Wh l team: client part
Whole t li t t  T tdi
Test-driven
of the team development: tests
 Metaphor: common developed first
analogy for the system  Design improvement
 The planning game, (refactoring)
based on user stories  Collective code
 Simple design ownership
 Small releases (e.g. 2  Continuous integration:
weeks)
k ) system always runs
 Customer tests  Sustainable pace: no
 Pair programming
p g g overtime
 Coding standards
Back To School, © Hans van Vliet, 2011 17

18. SCRUM
D
Development i sprints (t i ll 2-4 weeks)
l t in i t (typically 2 4 k )
 Features to be implemented come from the backlog
 Backlog can change on the fly; sprint backlog
g g y; p g
cannot
 Development is time-boxed
 Daily builds
Back To School, © Hans van Vliet, 2011 18

19. Scrum process
Back To School, © Hans van Vliet, 2011 19

20. Survey of development methods
D. West & J. Hammond, The Forrster Wave: Agile Development Management, 2010
Back To School, © Hans van Vliet, 2011 20

21. Agenda
 A hit t
Architecture
 Agility
 Architecture and agility
g y
 Case studies of A&A
Back To School, © Hans van Vliet, 2011 21

22. Can Agile and Architecture Co-exist?
 A il practices are amateurish, only fit for small-
Agile ti t i h l f ll
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

23. Agile-architecture conflict
T
Tension between adaptation and anticipation
i b t d t ti d ti i ti
 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

24. Different levels to understand the conflict
SSemantics: what does architecture mean. Not all
ti h td hit t N t ll
design is architecture
 Scope: depends on context
 Life cycle: when? Early
 Role: inward looking vs outward looking
 Documentation: not all documentation is bad
 Methods: they do exist
 Value and cost: cost is visible, value is hard to
establish
Back To School, © Hans van Vliet, 2011 24

25. Not all design is architecture
reality
perception
P. Abrahamsson et al,
Agility and Architecture,
can they coexist
IEEE Software, 2010
Back To School, © Hans van Vliet, 2011 25

26. Context
P. Abrahamsson et al,
Agility and Architecture,
g y
can they coexist
IEEE Software, 2010
Back To School, © Hans van Vliet, 2011 26

27. Architect’s role: inward or outward
 A hit t reloadus: maker and keeper of big
Architectus l d k dk f bi
decisions, focusing on external coordination
 Architectus oryzus: mentor, prototyper,
troubleshooter, focusing on internal issues, code-
facing
f i
M. Fowler
Back To School, © Hans van Vliet, 2011 27

28. Opinions of agile developers
 A hit t
Architecture is important?
i i t t?
 Never: 5%
 Always: 45%
 When it’s complex: 50%
 Many requirements: 33%
 Many stakeholders: 29%
 Global: 19%
 Other: 19%
Falesi et al: Peaceful coexistence, IEEE Software March 2010
Back To School, © Hans van Vliet, 2011 28

29. Just Enough Architecture
 Identify and prioritize risks
 E g tricky quality requirements distributed teams
E.g., requirements,
 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, scalability
g p , y
  different modeling techniques
 Re-evaluate remaining risks
George Fairbanks, Just Enough Architecture, Crosstalk, 2010
Back To School, © Hans van Vliet, 2011 29

30. Global workflow in architecture design
synthesis architecture
context
backlog evaluation
evaluation
requirements
results
Christine Hofmeister et al, Generalizing a model of software architecture Design,
Journal of Systems and Software, 2007
B To S
ack chool, © Hans van Vliet, 2011 30

31. How to choose from the backlog?
FFocus on revenue
 Focus on risk
 Identify 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 Cost
Management Discipline, WICSA, 2011
B To S
ack chool, © Hans van Vliet, 2011 31

32. Technical Debt
 M t h to represent consequences of taking
Metaphor t t f t ki
shortcuts to deliver a product faster
 Needs to be repaid, e.g. through refactoring
 Cost of debt is interest: extra effort/cost to work
around the shortcuts
 The longer it takes to repay, the more interest is
accrued
 Lehman’s Laws of software evolution(1970s):
increasing complexity, declining quality
Bc T Sho ©Hn vnV t, 2 1
ak o col, as a lie 0 1 32

33. Technical debt quadrant
reckless vs prudent
“we don t have time
we don’t “we must ship now and
we
for design” deal with the consequences”
deliberate
vs
inadvertent
“now we know how we
“what’s layering?”
should have done it”
Erin Lim, 2010
Back To School, © Hans van Vliet, 2011 33

34. Tension traditional -- agile
H
How t position oneself in this dimension?
to iti lf i thi di i ?
 How much upfront architecture is appropriate?
 Too much  waste because things change
g g
 Too little  waste because of many refactorings
Bc T Sho ©Hn vnV t, 2 1
ak o col, as a lie 0 1 34

35. Agenda
 A hit t
Architecture
 Agility
 Architecture and agility
g y
 Case studies of A&A
Back To School, © Hans van Vliet, 2011 35

36. A printer product line
Back To School, © Hans van Vliet, 2011 36

37. Characteristics
 P d t lines for both wide format printing and
Product li f b th id f t i ti d
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

38. Software Product Lines
 A software product li i “a set of software-
ft d t line is “ t f ft
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 p
g y product lines?
Back To School, © Hans van Vliet, 2011 38

39. Tension tacit-explicit knowledge
Tacit Knowledge
Explicit Knowledge
Back To School, © Hans van Vliet, 2011 39

40. Tensions
H
How much t d
h to document?
t?
 Everything upfront? – classic approach
 Nothing? – pure agile
 Somewhere in between, just-in-time, just-enough
 How much to plan?
 Grand upfront design? – enterprise architecture/product line
architecture document
 Let all flowers bloom
 Somewhere in between? – “Owen” model
Bck T S
a o chool, ©H nsva V t, 2011
a n lie 40

41. Example issues we investigated
H
How much should the architect tell
h h ld th hit t t ll
 Who should communicate what
 How much do people know of roadmaps
p p p
Back To School, © Hans van Vliet, 2011 41

42. How much should the architect tell
I don’t care Verification boomerang
Back To School, © Hans van Vliet, 2011 42

43. Categories of issues
 D b t d (opinions differ): 30%
Debated ( i i diff )
 Usually user interaction/experience
 Omissions (missing info in spec): 28%
 Unanticipated complexity
 Retrospective improvement
 I diff
Indifference (e.g. manual i
( l insert)
t)
 Misunderstanding (of spec): 27%
 Wrong spec: 11%
 New insight (potential improvements): 4%
Back To School, © Hans van Vliet, 2011 43

44. Insights gained
 A hit t tends to specify  w.r.t. previous product
Architect t d t if t i d t
 It is important to know what other team members
know
Rahul Premraj et al The Boomeranged Architect, WICSA 2011
al, Architect
Back To School, © Hans van Vliet, 2011 44

45. Documentation: the hot potato
Component Architects
Tacit Knowledge
Lead (SPL) Architects
Explicit Knowledge Project Developers
Back To School, © Hans van Vliet, 2011 45

46. Survey topics
D
Documented k
t d knowledge: how much is needed,
l d h hi d d
what is needed
 Perceived responsibilities: how is responsibility
aligned between roles
 Task ownership: who should DO it
46

47. Findings:
 Documentation:
 More is needed
 Disagreement as to who should write it
 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 documentation
documentation,
who should clarify requirements, who can demand what
information from whom
47

48. Findings (2)
 All roles need information from each other, but
sometimes 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 and
y g y
Software Engineers in an Agile Environment, SSE 2011
Back To School, © Hans van Vliet, 2011 48

49. Role of roadmaps
standards marketing
g
architecture
technology competitors
Back To School, © Hans van Vliet, 2011 49

50. Roadmapping
 F planning new features and functions for new
For l i f t df ti f
products
 Manage high level, future requirements
high-level,
 Involves different stakeholders:
 Product and marketing stakeholders (requirements, market
needs)
d )
 Architects (feasibility, technology trends, planning architecture
design)
 Project managers (schedules, planning)
50

51. Roadmap coordination issues
KKnowledge ownership – “I do not know what I need
l d hi d tk h t d
to know”
 Knowledge distribution – unused shared
knowledge & unshared knowledge
 Timing of knowledge sharing – too late, or too early
 Coordination of the roadmapping process – how
many roadmaps are needed, who is responsible
Back To School, © Hans van Vliet, 2011 51

52. Message
 Ch ll
Challenge: further improve timely exchange of
f th i ti l h f
(roadmap) knowledge between architects
 Much knowledge is created but not shared
effectively
 Personalization strategy alone does not suffice
 We propose to use a semantic wiki to index
roadmapping concepts
Antony Tang et al, Building Roadmaps: A Knowledge Sharing Perspective, SHARK 2011
y g g g g
52

53. How to bridge the gap?
B
Boundary spanners
d
 Tool support
 Semantic wikis
 +notifications when contents change
 Expert finders based on data mining
Bck T S
a o chool, ©H nsva V t, 2011
a n lie 53

54. Boundary spanners
R. Baskerville et al,
Post-agility: What follows
A decade of agility?
IST, 2011
Back To School, © Hans van Vliet, 2011 54

55. Lightweight Software Engineering ontology
Back To School, © Hans van Vliet, 2011 55

56. Search results for ‘configuration’
Back To School, © Hans van Vliet, 2011 56

57. Search results for ‘configuration’
Back To School, © Hans van Vliet, 2011 57

58. Filter class functional requirement
Back To School, © Hans van Vliet, 2011 58

59. Filter class functional requirement
Back To School, © Hans van Vliet, 2011 59

60. Filter class functional requirement
Back To School, © Hans van Vliet, 2011 60

61. Filter class functional requirement
Back To School, © Hans van Vliet, 2011 61

62. Expert finder
 Mi software repositories (source code
Mine ft it i ( d
repositories, issue tracking systems, mail, …) to
connect people to shared artifacts, e.g.
components they both worked on
 Codebook (Microsoft), social network service that
helps 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,
…
Bck T S
a o chool, ©H nsva V t, 2011
a n lie 62

63. Readings
 P Ab h
P. Abrahamsson et al, Agility and Architecture, can
t l A ilit d A hit t
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 Technology
agility Technology,
2011
Bc T Sho ©Hn vnV t, 2 1
ak o col, as a lie 0 1 63