Why We Need Architects (and Architecture) on Agile Projects

12,943 views

Published on

This is an updated version of this talk which I will present at Agile 2013.

The rhythm of agile software development is to always be working on the next known, small batch of work. Is there a place for software architecture in this style of development? Some people think that software architecture should simply emerge and doesn’t require ongoing attention. But it isn’t always prudent to let the software architecture emerge at the speed of the next iteration. Complex software systems have lots of moving parts, dependencies, challenges, and unknowns. Counting on the software architecture to spontaneously emerge without any planning or architectural investigation is at best risky.
So how should architecting be done on agile projects? It varies from project to project. But there are effective techniques for incorporating architectural activities into agile projects. This talk explains how architecture can be done on agile projects and what an agile architect does.

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

No Downloads
Views
Total views
12,943
On SlideShare
0
From Embeds
0
Number of Embeds
361
Actions
Shares
0
Downloads
304
Comments
0
Likes
22
Embeds 0
No embeds

No notes for slide
  • Get something from skills for agile designers?Agile design values?Agile Developer values?
  • Incremental development means that different parts of a software project are continuously integrated into the whole, instead of a monolithic approach where all the different parts are assembled in one or a few milestones of the project.Iterative means that once a first version of a component is complete it is tested, reviewed and the results are almost immediately transformed into a new version (iteration) of this component.So as a first result: iterative development doesn't need to be incremental and vice versa, but these methods are a good fit.Agile development aims to reduce massive planning overhead in software projects to allow fast reactions to change e.g. in customer wishes. Incremental and iterative development are almost always part of an agile development strategy. There are several approaches to Agile development (e.g. scrum).
  • I would go further to say, develop the tools, tooling, and mechanisms that instrument the rates of change you need. And, you encapsulate the parts that do vary so that they don’t leak out/effect other areas. This may mean that if you have highly changing software you architect ways that drive this change via mechanisms that are “easier” to change than others—data driven techniques, meta techniques, whatever…. Fast redeploy/tested code…all are ways
  • Landing ZoneA small section of a deck that a pilot must touch down in to land the aircraft safely
  • And, based on exper, maybe we need to recalibarate the lz based on arch decisions/costs to achieve them.Drives ongoing tradeoffs, decisions, and risk mitigation investments
  • Explore potential pathsTalk to othersShort experimentsExtrapolateConclude based on experience, intelligence gathered & intuition
  • May or may not be a person designated as “architect”, but a role taken on by those who care about the system architecture
  • Because most systems that are successful have architectures that successfully evolve, too…
  • The architecture can (and may) need to evolve.
  • Why We Need Architects (and Architecture) on Agile Projects

    1. 1. Why We Need Architects (and Architecture) on Agile Projects Rebecca Wirfs-Brock rebecca@wirfs-brock.com www.wirfs-brock.com ©2013 Wirfs-Brock Associates
    2. 2. Three Questions… • How much architecting do you need and when? • How can you manage architecture risk on small as well as large, complex projects? • What is the role of an agile architect? ? ? ?
    3. 3. Agile Design Values • Core values: – Design Simplicity – Sustainable systems – Continuous improvement – Teamwork – Communication – Trust – Satisfying stakeholder needs • Constant learning
    4. 4. Qualities of Good Architecture • Pragmatic. Does what it needs to without extras • Designed for test • Modular • No unintentional data redundancy or overlapping functionality • Supports performance, reliability, modifiability, usability ,….
    5. 5. How Much Architecting Do You Need? Alistair Cockburn’s project characteristics grid
    6. 6. What’s a Small Project? • A team of 6-8 • Working on non-life critical projects • Architecture typically evolves along with implementation without much risk • May or may not need extra architecture attention
    7. 7. Small Project Architecture Practices: Design “Spikes” • Goal: Figure out a design approach • Time: Few hours to a few days • Tools: CRC Cards, exploratory coding, whiteboard sketching
    8. 8. Small Project Architecture Practices: Experiment on Branches • Goal: Experiment away from main code branch • Time: Few hours to a few days • When done: Merge or throwaway branch code
    9. 9. Small Project Architecture Practices: Incrementally Refine Abstractions • Goal: Refactor to eliminate redundant code • Time: Few minutes • When done: Whenever you spot duplication
    10. 10. Small Project Architecture Practices: Manage Technical Debt • Term invented by Ward Cunningham • Piles up when you continually implement without going back to reflect new understanding • Can have long term costs and consequences
    11. 11. All Tasks Aren’t Alike • The Core—fundamental to your software’s success • The rest—requires far less creativity or inspiration • The Revealing—lead to new, deeper understanding – Always a surprise – Require invention and innovation – Hard to predict when they will be done – Don’t neatly fit into a planned iteration cycle
    12. 12. Keeping Architecture in Mind • Sort tasks into “problem buckets”: core and the rest • Make sure each iteration gets enough core work accomplished • Get team involved on core issues • Use post-iteration reflections to ask why things were harder than they first appeared
    13. 13. Architectural Practice: Reduce Technical Debt • Integrate new learning into your code – Refactoring – Redesign – Rework – Code clean up • Unit tests (functionality) • Test for architectural qualities (performance, reliabilit y,…)
    14. 14. Best Practices for Small Project Architecture • Pay attention to architecture • Don’t only work on feature implementation • Strive for design consistency. “This is the way we do x” – Coding standards – Consistent implementation practices (API use, errors, logging…) • Code stewards for architecturally critical areas
    15. 15. THE MORE THERE IS TO COORDINATE The Bigger the Project….
    16. 16. Team Size Matters • >9 and any group splits into teams • No one knows everything or everybody – Expertise uneven – Skills varied – Specialists • Work needs coordination • Architecture allowed to “naturally” emerge often reflects the organizational structure
    17. 17. Types of Project Risks • Schedule & budget • Operational – execution – resources – communications • Technical – too complex – poorly defined – misunderstood
    18. 18. Risk Management Strategies • Avoid • Share: Insure or transfer • Retain: Accept and budget for • Reduce: Mitigate – Develop incrementally – Integrate often – Design innovate if needed
    19. 19. Iterative & Incremental Lifecycles Reduce Technical Risks
    20. 20. THE LAST POSSIBLE MOMENT Especially on Large Projects, Some Decisions are too Important to Leave Until
    21. 21. Agile Misconception: Upfront Thinking, Planning, Investigating, Archi tecting is Wasteful • A reaction to “too much” thinking without “doing”. • Reality: – You need to strike a balance: Find the right time and effort for your project • Some upfront planning is critical for large, complex projects • Ongoing thinking, prototyping, and architecture experiments are important too.
    22. 22. CHOOSE THE MOST RESPONSIBLE MOMENT A Better Way to Act:
    23. 23. Stuart Brand’s Shearing Layers • Buildings are made of components that evolve at different timescales. • Layers: site, structure, skin, services, space plan, stuff. Each layer has its own value, and speed of change (pace). • Buildings adapt because faster layers (services) are not obstructed by slower ones (structure). —Stuart Brand, How Buildings Learn
    24. 24. Yoder and Foote’s Software Shearing Layers “Factor your system so that artifacts that change at similar rates are together.”—Foote & Yoder, Ball of Mud Pattern • The platform • Infrastructure • Data schema • Standard frameworks and components • Abstract classes and interfaces • Classes • Code • Data LayersSlower Faster
    25. 25. Agile Architecture Values • Respect your system’s shearing layers – Understand the rates of what changes – Isolate rapidly changing parts/components from more stable ones • Make what is too difficult, time consuming, or tedious easier – Create tools, leverage design patterns, build or use frameworks, use data to drive behavior… • Don’t overdesign!!! • Don’t under architect • Architect for sustainable development/delivery of features and customer value
    26. 26. Being Agile Does Not Mean • You can make significant architecture changes at the last moment • Good architecture always emerges from “good” development practices • Sometimes you need to do more
    27. 27. Architecture Debt • Compromises in the system that have significant impacts • Not isolated • Costly to reverse • Examples: – reliance on a poorly designed framework – inconsistent service interfaces
    28. 28. Architecture Risk Reduction Tools for Larger Projects and Programs • Grooming and vetting project/product road maps and timelines • Landing zones • Architecture spikes • Risk reduction backlogs • Set-based design Component Design Choices Design Cycle Decision to Eliminate x x x
    29. 29. Product Roadmaps As Guides • Where you expect to go • What features and when? Relative time when feature is needed • Influence architecture work and efforts Sherwood, Oregon Portland International Airport
    30. 30. Product Landing Zones • A range of acceptable values for important system qualities – Minimal: OK, we can live with that – Target: Realistic goal, what we are aiming for – Outstanding: This would be great, if everything goes well
    31. 31. Good Landing Zone Criteria • Define acceptable range of values for some characteristic or system quality (performance, usability, reliability, etc.) – # transactions, average latency of a transaction under load, click through rate, up time…. • Broader in scope than an acceptance criteria • SMART • Specific • Measurable • Achievable (minimum value) • Relevant • Timely Within acceptable limits Within acceptable limits
    32. 32. Good Acceptance Criteria • Focused on a single thing (a rule or step of a process) • A specification of what should happen/what must be true written in the language of the domain • SMART • Specific • Measurable • Achievable • Relevant • Timely
    33. 33. What’s Different? Acceptance Criteria Free 2-day shipping is offered to Amazon Prime customers for all items in an order that are sold directly by Amazon If an Amazon prime customer wants faster shipping, they pay standard shipping fees. Automated tests can be written (fairly easily) Landing Zone Criteria Selection of shipping options should be completed with 99% customer accuracy Test, but usually in production or staging environment May require instrumenting “hooks” and making several measurements that are aggregated/interpreted
    34. 34. Too many landing zone criteria and you lose track of what’s important Define a core set, organize and group Break down aggregate targets into measurable architecture-specific goals/targets To be agile, re-calibrate values as you implement more functionality Managing Landing Zones Minimum Target Outstanding Throughput (loan payment txns per day) 50,000 70,000 90,000 Average loan payment txn time 2 seconds 1 second < 1 second Intersystem data consistency between x, y, z systems (per cent critical data attributes consistent) 95% 97% 97% ETL data accuracy for claims data 97% 99% >99% Performance Data Quality
    35. 35. Agreeing on Landing Zone Targets • Someone makes a first “rough cut” • Base targets on history & evidence • Discuss and fine-tune as a group – product manager, architects, QA lead • Informed consensus-building
    36. 36. How Architects Use & Interact with Landing Zones • Create them along with Product Owners and other Stakeholders • Identify high architecture risk items • Establish/verify target values • Explain architecture tradeoffs and costs • Monitor architecture health • Recalibrate landing zone values based on emerging design
    37. 37. Landing Zones on Agile Projects • Helps make sense of the bigger picture: – What happens when one attribute edges below minimum? – When will targets be achieved? – What do we need to do architecturally to achieve targets?
    38. 38. Architecture Spikes • Answer deep questions about potential solutions for achieving landing zone targets • Not as tactical or incidental as an XP Design Spike • Try out radical changes in how things are done before committing to them • How can we scale up, scale out, re-distribute, re- think…????
    39. 39. XP Design Spike “A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story’s estimate.” —Don Wells http://www.extremeprogramming.org/rules/spike.html
    40. 40. What You Do In an Architecture Spike – prototyping – design noodling – looking outside – experimenting – modeling – proving ideas
    41. 41. Criteria For an Architecture Spike: Answer Bounded Questions • Buys information – Feasibility – Reasonable design approach – Alternatives • Better estimates • Actionable
    42. 42. Criteria For an Architecture Spike: Actionable Results • Buy information that – Feeds into future release planning – Adjusts the release roadmap – Recalibrates your landing zone – Drives new development and design Actionable or evidence
    43. 43. Architecture Spikes • Example spikes: – Business transaction redesign – Document parsing investigation – Fact representation & rule simplification – Automated location of external resources
    44. 44. Architecture Spike Best Practices • Small, smart, goal-oriented teams – avoid us vs. them mentality • Evidence-based answers – working prototypes – existing similar things • Time-boxed – Limited scope and duration (2-6 weeks) • Failure is an option – permit answers that will shift your goals
    45. 45. 3 Ways To Manage Architectural Tasks
    46. 46. Architecturally meaty feature Design spike related task Architecture investigation Prototype Framework development Roadmap exploration What Can Go On An Architecture Backlog?
    47. 47. WHAT DO AGILE ARCHITECTS DO?
    48. 48. Primary Architecture Responsibilities system integrity balance elegancearchitecture views, explanations, sketches system structure design approach module subsystem system X 51
    49. 49. The Agile Architecture Landscape
    50. 50. The Integral Triad
    51. 51. Agile Architecture Wayfinding • Scouting—looking enough ahead • Exploring potential paths – Short experiments – Extrapolations – Conclusions based on experience, intellig ence gathered & intuition • Explaining and selling architectural ideas
    52. 52. Differences Between Agile and Traditional Architecture Traditional • Big picture thinking • Produces Models and blue prints • Not so hands-on • Focused on compliance Agile • Balances big picture & details • Produce what’s needed to make informed decisions • Hands-on • Focused on sustainability 55
    53. 53. Models “Big M” vs. “little m” • Lots of time invested • Intended to last • “Definitive” • Usually formal • May not be widely used or understood • Not a lot of time invested • Intended to communicate • Often discarded • Can be formal or informal • Made to be viewed Agile architects create models as needed
    54. 54. Model Maintain problem related info Broadcast change notification View Render the model Transform coordinates Model Controller Controller Interpret user input Distribute control Model View “A Laboratory For Teaching 
Object- Oriented Thinking,” Kent Beck, Apple Computer, Inc., Ward Cunningham, Wyatt Software Services, Inc. OOPSLA 89 CRC Cards: A “little m” model The First CRC Cards
    55. 55. Example: Component Responsibility Descriptions Application Support Business "Applications" Allowed to use Attribute Defintion Business Rule Customer xxx Price Definition Offering Term Underwriting Sourcing Note Custody Pooling Payment Management Default Relationship xxx Data Import/Export xxx xxx xxx Reporting Fraud Management Loan Account Contract Agreement xxx xxx xxxBusiness Infrastructure Attribute Defintion Key Business Subysystem “The Customer component is responsible for knowing the organizations and individuals. It includes authentication and role-based authorization for detailed tasks and contact information for organizations.”
    56. 56. Example: Database “Responsibilities”
    57. 57. Values Important to Agile Architects • Balance • Testable architectural qualities • Being hands-on – programming, des igning, reading code, building things… • Sustainable development
    58. 58. Sustainable Architecture • Stewardship – Follow through – Ongoing attention – Not ignoring the little things that can undermine our ability to grow, change and adapt our systems
    59. 59. Sustaining an Architecture • Minimize architectural debt: Support the ability to change/adapt what needs to change • Make what is too difficult, time consuming, or tedious easier • Decide at the most responsible moment, not the last possible moment • Learn and evolve 62 Keep the system “livable” for its users and developers
    60. 60. Agile Values Drive Architectural Practices • Do something. Don’t debate or discuss architecture too long. • Do something that buys you information • Prove your architecture ideas • Reduce risks • Make it testable • Prototype realistic scenarios that answer specific questions • Incrementally refine your architecture • Defer architectural decisions that don’t need to be immediately made Do something! Prove & Refine.
    61. 61. Indicators You’ve Paid Enough Attention to Architecture • Defects are localized • Stable interfaces • Consistency • Developers can easily add new functionality • New functionality doesn’t “break” existing architecture • Few areas that developers avoid because they are too difficult to work in • Able to incrementally integrate new functionality
    62. 62. 65

    ×