Passen Agility en Architectuur  op één kussen, of komt de     duivel daartussen?              Hans van Vliet       Vrije U...
My personal history1967    computer operator, programmer                 operator1973-        MSc Mathematics/CS19781979  ...
Agenda A hit t  Architecture Agility Architecture and agility                    g y Case studies of A&A              ...
Pre-architecture life cycle  stakeholders       (few)       requirements                quality                           ...
Architecture in the life cycle                         stakeholders                              (many)               requ...
Global workflow in architecture design                                 synthesis          architecture  context           ...
Software architecture, definition (1) The architecture of a software system defines that system in terms of computational ...
Software Architecture                  statement                                         p                  procedure    ...
Other points of view A hit t  Architecture is high-level design               i hi h l    ld i Architecture is overall s...
Software Architecture, definition (4) S ft  Software architecture = design (components &              hit t       d i (  ...
Where did it start? 1992: Perry & Wolf 1987: J.A. Zachman; 1989: M. Shaw 1978/79: David Parnas, program families       ...
Agenda A hit t  Architecture Agility Architecture and agility                    g y Case studies of A&A              ...
Waterfall Model       reqs engineering            V&V                      design                      d i                ...
Another waterfall model                                          testing                                                g ...
Activity versus phase                                              Integration     Acceptance           Phase    Design   ...
The Agile Manifesto Individuals and interactions over processes and  tools Working software over comprehensive  document...
13 practices of XP Wh l team: client part  Whole t       li t     t    T tdi                               Test-driven  ...
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...
Scrum process                Back To School, © Hans van Vliet, 2011   19
Survey of development methods      D. West & J. Hammond, The Forrster Wave: Agile Development Management, 2010            ...
Agenda A hit t  Architecture Agility Architecture and agility                    g y Case studies of A&A              ...
Can Agile and Architecture Co-exist? A il practices are amateurish, only fit for small-  Agile    ti            t  i h   ...
Agile-architecture conflictT Tension between adaptation and anticipation     i b t        d t ti      d ti i ti   Agile ...
Different levels to understand the conflictSSemantics: what does architecture mean. Not all         ti     h td         h...
Not all design is architecture   reality perception                                                P. Abrahamsson et al,  ...
Context                               P. Abrahamsson et al,                              Agility and Architecture,        ...
Architect’s role: inward or outward A hit t reloadus: maker and keeper of big  Architectus l d          k     dk         ...
Opinions of agile developers A hit t  Architecture is important?               i i     t t?   Never: 5%   Always: 45%  ...
Just Enough Architecture Identify and prioritize risks   E g tricky quality requirements distributed teams    E.g.,     ...
Global workflow in architecture design                                 synthesis          architecture  context           ...
How to choose from the backlog?FFocus on revenue Focus on risk   Identify fail scenarios (what if …) and add cost * pro...
Technical Debt M t h to represent consequences of taking  Metaphor t             t                  f t ki  shortcuts to ...
Technical debt quadrant                             reckless vs prudent          “we don t have time           we don’t   ...
Tension traditional -- agileH How t position oneself in this dimension?     to   iti        lf i thi di      i ? How muc...
Agenda A hit t  Architecture Agility Architecture and agility                    g y Case studies of A&A              ...
A printer product line                         Back To School, © Hans van Vliet, 2011   36
Characteristics P d t lines for both wide format printing and  Product li  f b th id f        t i ti       d  document pr...
Software Product Lines A software product li i “a set of software-       ft        d t line is “     t f ft  intensive sy...
Tension tacit-explicit knowledge                  Tacit Knowledge                 Explicit Knowledge                      ...
TensionsH How much t d        h to document?                    t?   Everything upfront? – classic approach   Nothing? ...
Example issues we investigatedH How much should the architect tell        h h ld th       hit t t ll Who should communic...
How much should the architect tell     I don’t care                 Verification boomerang                          Back T...
Categories of issues D b t d (opinions differ): 30%  Debated ( i i     diff )   Usually user interaction/experience Omi...
Insights gained A hit t tends to specify  w.r.t. previous product  Architect t d t      if        t      i       d t It...
Documentation: the hot potato                                                                   Component Architects      ...
Survey topicsD Documented k           t d knowledge: how much is needed,                   l d    h      hi      d d what...
Findings: Documentation:   More is needed   Disagreement as to who should write it Responsibilities:   Overall agreem...
Findings (2) All roles need information from each other, but  sometimes do not know where to get it Tacit understanding ...
Role of roadmaps       standards                          marketing                                                  g    ...
Roadmapping F planning new features and functions for new  For l    i         f t       df   ti   f  products Manage hig...
Roadmap coordination issuesKKnowledge ownership – “I do not know what I need        l d          hi     d    tk        h ...
Message Ch ll  Challenge: further improve timely exchange of              f th i          ti l     h        f  (roadmap) ...
How to bridge the gap?B Boundary spanners     d Tool support   Semantic wikis   +notifications when contents change  ...
Boundary spanners                                            R. Baskerville et al,                                        ...
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 software repositories (source code  Mine ft               it i (           d  repositories, issue tracki...
Readings P Ab h  P. Abrahamsson et al, Agility and Architecture, can                    t l A ilit    d A hit t  they coe...
Upcoming SlideShare
Loading in …5
×

Devnology Back to School IV - Agility en Architectuur

1,103
-1

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,103
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Devnology Back to School IV - Agility en Architectuur

  1. 1. Passen Agility en Architectuur op één kussen, of komt de duivel daartussen? Hans van Vliet Vrije Universiteit Amsterdam
  2. 2. My personal history1967 computer operator, programmer operator1973- MSc Mathematics/CS19781979 PhD, ALGOL 681986 Professor Software Engineering, VU University Engineering1983 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. 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. 4. Pre-architecture life cycle stakeholders (few) requirements quality agreement development Back To School, © Hans van Vliet, 2011 4
  5. 5. Architecture in the life cycle stakeholders (many) requirements quality architecture agreement t development Back To School, © Hans van Vliet, 2011 5
  6. 6. Global workflow in architecture design synthesis architecture context backlog evaluation evaluationrequirements 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. 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. 8. Software Architecture statement  p procedure  module  (design) pattern  architecture Back To School, © Hans van Vliet, 2011 8
  9. 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. 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. 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. 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. 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. 14. Another waterfall model testing g feedback implementation design requirements engineering Back To School, © Hans van Vliet, 2011 14
  15. 15. Activity versus phase Integration Acceptance Phase Design Implementation Activity testing testing Integration testing 4.7 43.4 26.1 25.8Implementation (& 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. 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. 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. 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. 19. Scrum process Back To School, © Hans van Vliet, 2011 19
  20. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 30. Global workflow in architecture design synthesis architecture context backlog evaluation evaluationrequirements 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. 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. 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. 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 vsinadvertent “now we know how we “what’s layering?” should have done it” Erin Lim, 2010 Back To School, © Hans van Vliet, 2011 33
  34. 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. 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. 36. A printer product line Back To School, © Hans van Vliet, 2011 36
  37. 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. 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. 39. Tension tacit-explicit knowledge Tacit Knowledge Explicit Knowledge Back To School, © Hans van Vliet, 2011 39
  40. 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. 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. 42. How much should the architect tell I don’t care Verification boomerang Back To School, © Hans van Vliet, 2011 42
  43. 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. 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. 45. Documentation: the hot potato Component Architects Tacit KnowledgeLead (SPL) Architects Explicit Knowledge Project Developers Back To School, © Hans van Vliet, 2011 45
  46. 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. 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. 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. 49. Role of roadmaps standards marketing g architecturetechnology competitors Back To School, © Hans van Vliet, 2011 49
  50. 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. 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. 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 conceptsAntony Tang et al, Building Roadmaps: A Knowledge Sharing Perspective, SHARK 2011 y g g g g 52
  53. 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. 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. 55. Lightweight Software Engineering ontology Back To School, © Hans van Vliet, 2011 55
  56. 56. Search results for ‘configuration’ Back To School, © Hans van Vliet, 2011 56
  57. 57. Search results for ‘configuration’ Back To School, © Hans van Vliet, 2011 57
  58. 58. Filter class functional requirement Back To School, © Hans van Vliet, 2011 58
  59. 59. Filter class functional requirement Back To School, © Hans van Vliet, 2011 59
  60. 60. Filter class functional requirement Back To School, © Hans van Vliet, 2011 60
  61. 61. Filter class functional requirement Back To School, © Hans van Vliet, 2011 61
  62. 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. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×