Devnology Back to School IV - Agility en Architectuur
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Devnology Back to School IV - Agility en Architectuur

on

  • 1,192 views

 

Statistics

Views

Total Views
1,192
Views on SlideShare
728
Embed Views
464

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 464

http://devnology.nl 464

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Devnology Back to School IV - Agility en Architectuur Presentation Transcript

  • 1. Passen Agility en Architectuur op één kussen, of komt de duivel daartussen? Hans van Vliet Vrije Universiteit Amsterdam
  • 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. 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 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. 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.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. 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 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. 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 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. 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 KnowledgeLead (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 architecturetechnology 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 conceptsAntony 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