Devnology Back to School IV - Agility en Architectuur

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Back To School, © Hans van Vliet, 2011 20

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

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

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

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

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

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

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

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

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

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

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

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

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

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 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 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

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

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

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

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 (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

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

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

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

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

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

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

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

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

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

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

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

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

Devnology Back to School IV - Agility en Architectuur

by Devnology on Nov 16, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 391

Statistics

Devnology Back to School IV - Agility en Architectuur — Presentation Transcript