Toolbox of techniques for Architecture Reviews
•Download as PPTX, PDF•
6 likes•3,109 views
A collection of techniques for designing and running architecture reviews Presentation was given at the norwegian computer society SW2015 conference and Javazone 2015. Theres a video of the javazone talk online: https://vimeo.com/138848892
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Toolbox of techniques for Architecture Reviews
Similar to Toolbox of techniques for Architecture Reviews (20)
Recently uploaded
Recently uploaded (20)
Toolbox of techniques for Architecture Reviews
- 1. a toolbox of techniques for software architecture reviews jason baragry @jbaragry
- 3. essential problem “Identify the forces on the system Grok the system’s essential architecture. Generate scenarios that exercise the relevant forces against the architecture. Throw the essential architecture against those scenarios, then evaluate how they land relative to the relevant forces. Wash, rinse, repeat” - Grady Booch @jbaragry
- 4. @jbaragry active design reviews . take an active stance . plan in advance . ask open questions
- 5. plan your review software architecture review and assessment (SARA) report @jbaragry
- 6. @jbaragry structure of an architecture review
- 7. @jbaragry structure of an architecture review
- 8. @jbaragry structure of an architecture review
- 9. @jbaragry structure of an architecture review
- 10. @jbaragry structure of an architecture review
- 11. @jbaragry structure of an architecture review
- 12. evaluation criteria . system qualities . experience . scenarios . checklists . architecture smells @jbaragry
- 15. scenarios . (mini) quality attribute workshops . testable . benefit/cost @jbaragry
- 16. checklists . group by qualities . open questions @jbaragry
- 17. @jbaragry methods and techniques . scenario based . experience based . quality specific
- 18. scenario based methods @jbaragry . architecture tradeoff and analysis method (ATAM) . lightweight architecture alternative assessment method (LAAAM) . scenario-based ATAM design peer review
- 19. experience based methods @jbaragry . tiny architectural review approach TARA . siemens ”experience- based reviews”
- 20. quality focused methods . maintainability: ALMA . sustainability: MORPHOSIS . performance: CPASA . code metrics: cyclomatic complexity afferent and efferent coupling . formal correctness: TLA+ . security: OWASP, BSIMM, STRIDE, DREAD @jbaragry
- 21. pragmatics and people issues @jbaragry in-house / scheduled in-house / triggered external / scheduled external / triggered
- 22. tool selection and customisation Amount of Ceremony ∝ Consequence of Loss + Difficulty of Communication @jbaragry source: Alistair Cockburn on Agile Methods: http://alistair.cockburn.us/People+and+methodologies+in+software+development
- 23. using the toolbox for reviews . take an active stance . plan the review and adapt as needed . work through system qualities . develop the scenarios or checklists for those qualities . choose a scenario- or experience- based method . customise the appropriate level of ceremony . identify the people issues and adjust @jbaragry
- 24. using the toolbox for design test driven architecture . use quality attributes and test criteria early in the project . product owners also own quality . user stories, acceptance criteria or architecture reviews @jbaragry
- 25. @jbaragry more detail . swarchitectonics.blogspot.no or . miles.no/blogg
- 26. references • Booch on Architecture Reviews (Booch2010) • Industry study of how people use arch review techniques (Babar2009 [pdf]) • Active Design Reviews (Parnas1985 [pdf]) • ISO/IEC 25010 standard for software product quality • SARA Report (Obbink2002, [pdf]) • Quality Attribute Workshop • Mini Quality Attribute Workshop (and presentation video) • ATAM method • LAAM (Lightweight Architecture Alternative Assessment Method) • ATAM Peer Review • TARA (Tiny Architectural Review Approach) • Experience-based Reviews • TOGAF Architecture Compliance Checklists • Stackoverflow architecture checklist questions @jbaragry
- 27. image attribution • Title Slide / Todd Quackenbush / Creative Commons • Essential Problem / Republica / Creative Commons • Toolbox outline / freegr / Creative Commons • Hammer / BenjaminNelan / Creative Commons • Ruler / Jeff Sheldon / Creative Commons • Plan / Ales Krivec / Creative Commons • Evaluation Techniques/ Ales Krivec / Creative Commons • Quality Focussed / Alan / Creative Commons • Tool selection / Stux / Creative Commons • Toolbox / Florianric / Creative Commons • More Detail / Mike Kenneally / Creative Commons • Pragmatics / grisbonn1974 / Creative Commons • Test driven architecture / Lee John Phillips / The Shed Project @jbaragry
- 28. FAGLIG AUTORITET OG VARME @jbaragry
Editor's Notes
- most organisations use home-grown, informal, ad-hoc techniques . 40% that claim to use a structured approach very few have heard of or use any established technique improve what you do by becoming familiar with existing techniques and using them _as appropriate_
- . Massive amounts of information sent to everyone who might have an interest - swamped with information . Many reviews have no background in sw dev and don’t know what they are reviewing - many end up saying nothing or, worse, focussing on issues that are not relevant . “Review” workshop turns into a tutorial that explains how it works . Devolves into round-table discussion with a random list of suggestions for the designers Result: things that should be captured, discussed, and adjusted in the review process end up slipping through Tend to focus solely on functionality and not system qualities
- basic approach is pretty simple everything is just different ways to do this
- Simplest Tool From 30+years ago Which qualities are important and why? How will you evaluate them wrt to the architecture? Not “Is it reusable/service oriented/fast enough?” Instead: “Explain the flow bw the user interface and the customer DB“, “which information is maintained between client calls? How is that dealt with in a failover situation?” Other useful bits Most likely iterative approach. High level review followed by smaller reviews focusing on specific aspects / qualities You need something that is reviewable – architecture is more than box and line diagrams or 60 pages with prose
- 1999 : working group to collect industrial experience and research techniques. many participants from multiple organisations presented the SARA report at the ICSE in 2002 what steps to follow, what questions to ask, what information to collect and document, what documentation templates to use, and tips on how to manage the social, managerial, and technical issues that arise when reviewing an artifact as important and complicated as a software architecture.
- Inputs Outputs Methods and Techniques Review Workflow Pragmatics and People Issues see blog entry for more details - difficult to identify ASDs and ASRs
- Inputs Outputs Methods and Techniques Review Workflow Pragmatics and People Issues see blog entry for more details - difficult to identify ASDs and ASRs
- - Objectives: conformance, quality, opportunities, example - Scope: all quals (just perf)? whole sys (just domain)? all systems in value chain - Arch: context drives doc formality, objectives drive views, other artefacts are useful - Criteria: get some! will come back to this
- - Intangibles: can be most important (shared view, archs get to explain to others) - want to find significant reqs and design choices (not always known in advance) - Tradeoffs: not important to find "right and wrong", explain consequences of tradeoffs - Risks: what most people think of - but also outside the arch, eg: process - lastly: what didn't you review, who couldn't attend, etc
- - will come back to this - context will determine scenario v experience v code analysis etc
- - before: eg: does everyone have time in their calendar, do you have champion that can get them to attend? - after: who are you communicating for? how to summarise a lot of detail? - retrospective for yourself
- - will come back to this also: - huge difference between internal, regular, planned and external, triggered, one-off
- experience = evaluation criteria as tacit knowledge scenarios = specific to the project / domain checklists = use them across projects / domains
- Don’t call them NFRs Prioritise them You can’t check everything, you will need to make tradeoffs, so you need to specify what’s most important often come from business drivers
- Start with ISO 25010 standard for software product quality Extend it as you need: e.g: its security aspects are not very comprehensive, TTM is often a criteria Eg: for functional correctness Wikipedia list is huge
- After prioritising your quality attributes, then you need to testable criteria – either scenarios or experience based. Start with scenarios Some common for all projects, others need to be created per project/solution Scenario format: SMART or “given, when, then” - Tom Gilb to quantify everything Collect them during the course of the project – also leads to Test Driven Architecture good way to get stakeholders involved good way to build knowledge as an architect if you are relatively new to a domain BUT : scenarios are hard…
- most popular approach good for things that recur across projects – technology and detailed, application architecture related issues see also TOGAF and Stackoverflow lists important to group them and formulate them as open questions (not like this list)
- lots of specific methods exist most fall into 1 of 2 categories: experience-based and scenario-based
- ATAM stop the boat and run a big review 1. Present the ATAM. 2. Present business drivers. (iteration 1) Present architecture. 4. Identify architectural approaches. 5. Generate quality attribute utility tree. 6. Analyze architectural approaches. (iteration 2) 7. Brainstorm and prioritize scenarios. 8. Analyze architectural approaches. 9. Present results. Learn ATAM so that you can customise it to your needs. LAAAM – in-process technique just to get stakeholder to focus on qualities Peer Review – iterative, focussing on a few scenarios/qualities each time Important: ATAM as it is presented is usually is often too heavy to use in industrial settings (in enterprise domains) too hard to get all the stakeholders together at the same time too hard to set off that much time in a fast moving project, etc But it’s a very useful method to know about and understand so that you can customise it to your context
- Scenarios are hard scenario-based methods assume there is no existing system sometimes you already have something to review –much of industrial assessment is brown-field have a sponsor with a very specific goal that doesn’t need a full review often you have lots of tacit knowledge about a domain or the owner has a very explicit need, don’t need to get into scenario workshops (in practice, you already have the scenarios in that tacit knowledge) master-apprentice pattern to build up experience for other architects
- many more methods modifiability, long-lived applications, etc and there are 1001 methods just for security
- social, psychological, and managerial context Make developers feel confident, not defensive. presence of non-technical people or people from outside the project. pro and con. good for communication, can be bad for defensiveness using a review can help to make political games more rational. having an external reviewer is often the best approach, but it increases the tension with the project team planned, in-house reviews are a good way to spread knowledge, with minimal tension, but you risk missing things that external eyes will pick up stakeholder management ego, confrontation, self-defence are all consequences you need to deal with planning and finding time with people is a limiting factor focus on risk – don’t get sidetracked or bikesheded as a reviewer – bury your ego. There to raise issues not solve them
- most important tool – use your common sense “a fool with a tool is still a fool” amount of ceremony is proportional to the consequence of loss and the difficulty of communication how formal should the review be? how much documentation of the architecture do you need? is the goal to test all evaluation criteria or to make them visible and part of the design discussion?
- - build up your toolbox and choose the one that is appropriate to the context of your project
- also a toolbox for driving architecture design evaluation criteria are just test cases for your architecture = test driven architecture
- Just a taste in this presentation Writing up this topic as a series of articles on these blogs. Presenting more detail and links to tools, books, and articles you can use to build your toolbox