Continuous Architecture and Emergent Design: Disciplined Agile Strategies
Download as PPTX, PDF18 likes6,035 views
The document discusses Continuous Architecture and Emergent Design, highlighting common myths about agile architecture and outlining the realities that emphasize its importance throughout the development lifecycle. It presents principles and practices from Disciplined Agile Delivery (DAD), emphasizing goal-driven approaches, collaboration with enterprise teams, and the necessity of documentation and architectural considerations. Additionally, it addresses potential challenges and strategies to ensure effective architectural decisions during iterative development.
![Thank You!
scott [at] scottambler.com
@scottwambler
AgileModeling.com
AgileData.org
Ambysoft.com
DisciplinedAgileConsortium.org
DisciplinedAgileDelivery.com
ScottAmbler.com
Disciplined Agile Delivery
Disciplined Agile Delivery
© Scott Ambler + Associates 34](https://image.slidesharecdn.com/amblercontinuousarchitectureandemergentdesign-130807072111-phpapp02/85/Continuous-Architecture-and-Emergent-Design-Disciplined-Agile-Strategies-34-320.jpg)
Continuous Architecture and Emergent Design: Disciplined Agile Strategies
- 1. © Scott Ambler + Associates 1 Continuous Architecture and Emergent Design Scott W. Ambler Senior Consulting Partner scott@scottambler.com @scottwambler
- 2. © Scott Ambler + Associates 2 Agenda 1. Myths and misunderstandings 2. Ideas from Disciplined Agile Delivery (DAD) 3. Getting started 4. Emergence 5. Stuff happens 6. Parting thoughts
- 3. Myths and Misunderstandings © Scott Ambler + Associates 3
- 4. Common Myths Surrounding Agile Architecture 1. Agilists don’t “do architecture” 2. Agilists start coding right away 3. Agilists don’t follow enterprise architecture strategies 4. Agilists don’t model 5. Agilists don’t document © Scott Ambler + Associates 4
- 5. Realities of Agile Architecture 1. Architecture is so important agilists address it throughout the entire lifecycle 2. Disciplined agilists invest in some up front envisioning 3. Discipline agilists work closely with enterprise professionals 4. Disciplined agilists explicitly model in a lightweight manner throughout the lifecycle 5. Disciplined agilists write deliverable documentation continuously © Scott Ambler + Associates 5
- 6. Disciplined Agile © Scott Ambler + Associates 6
- 7. DAD Role: Architecture Owner • Guides the creation and evolution of the solution’s architecture • Mentors and coaches team members in architecture practices and issues • Understands the architectural direction and standards of your organization and ensures that the team adheres to them • Ensures the system will be easy to support by encouraging appropriate design and refactoring • Ensures that the system is integrated and tested frequently • Has the final decision regarding technical decisions, but doesn’t dictate them • Leads the initial architecture envisioning effort 7 © Scott Ambler + Associates
- 8. DAD Teams Are Enterprise Aware • DAD teams strive to leverage and enhance the existing organizational eco system wherever possible • Implications for architecture and design: – Work with enterprise architects – Follow existing roadmap(s) where appropriate – Leverage existing assets – Enhance existing assets © Scott Ambler + Associates 8
- 9. Scrum Construction Lifecycle © Scott Ambler + Associates 9
- 10. A Scrum Delivery Lifecycle © Scott Ambler + Associates 10
- 11. Unbranded Agile Delivery Lifecycle © Scott Ambler + Associates 11
- 12. Governed Delivery Lifecycle © Scott Ambler + Associates 12
- 13. Disciplined Agile Delivery: Basic Lifecycle © Scott Ambler + Associates 13
- 14. DAD is Goal-Driven, Not Prescriptive 14 © Scott Ambler + Associates
- 15. Disciplined Agilists Take a Goal Driven Approach © Scott Ambler + Associates 15 Goal Issue Advantages Disadvantages Considerations * Option Default Option * Explore the Initial Scope Form the Initial Team Address Changing Stakeholder Needs Source Team size Team structure Team members Geographic distribution Supporting the team Availability Co-located Partially dispersed Fully dispersed Distributed subteams
- 16. Initial Architecture © Scott Ambler + Associates 16
- 17. Goal: Identify Initial Technical Strategy © Scott Ambler + Associates 17
- 18. Goal: Align With Enterprise Direction © Scott Ambler + Associates 18
- 19. © Scott Ambler + Associates Survey Says: Initial Architecture Efforts • 25% use enterprise or industry architecture models as references • 77% performed high-level initial architecture envisioning • 28% performed detailed initial architecture modeling • 92% performed some form of up-front architecture modeling • 97% performed some initial modeling OR worked from an existing legacy architecture Source: SA+A 2013 Agile Project Initiation Survey Ambysoft.com/surveys/ 19
- 20. © Scott Ambler + Associates 20 Non-functional requirements are critical drivers of your architecture
- 21. You’ll Need Several Views © Scott Ambler + Associates 21 Some Architecture Frameworks: Zachman TOGAF DoDAF 4+1
- 22. Emergence © Scott Ambler + Associates 22
- 23. © Scott Ambler + Associates 23 Continuous Architecture Practices Architectural vision guides development efforts Initial architectural envisioning Architecture owner facilitates architectural decisions throughout Construction Architecture handbook and models updated as required Architecture spikes to explore a technical issue Reduce risk early by proving the architecture works
- 24. Emergent Design Practices © Scott Ambler + Associates 24 Discuss design implications during iteration planning/modeling Test-Driven Design (TDD) throughout Construction Look-ahead modeling for upcoming complex work items Consider design issues of incoming requests from production
- 25. Agile Model Driven Development (AMDD): Project Level © Scott Ambler + Associates 25
- 26. Goal: Prove Architecture Early © Scott Ambler + Associates 26
- 27. Goal: Produce a Potentially Consumable Solution 27 © Scott Ambler + Associates
- 28. Goal: Leverage and Enhance the Existing Infrastructure © Scott Ambler + Associates 28
- 29. © Scott Ambler + Associates 29 Stuff Happens…
- 30. What if… You don’t think all the issues through from the very beginning? © Scott Ambler + Associates 30 There is a major requirements change that forces you to rethink the architecture in the middle of construction? Another team needs to update the solution years from now? The team gets hit by a truck?
- 31. © Scott Ambler + Associates 31
- 32. General Solution Architecture Principles Architecture owners should understand why Look beyond technology Adopt a multi-view approach Architecture is driven by requirements Architectures should be loosely coupled Architectural elements should be highly cohesive © Scott Ambler + Associates 32
- 33. Principles of Agile Solution Architecture Think about the future, but wait to act Learn early, learn fast Simplicity first Build quality in Model in an agile manner Be enterprise aware © Scott Ambler + Associates 33
- 34. Thank You! scott [at] scottambler.com @scottwambler AgileModeling.com AgileData.org Ambysoft.com DisciplinedAgileConsortium.org DisciplinedAgileDelivery.com ScottAmbler.com Disciplined Agile Delivery Disciplined Agile Delivery © Scott Ambler + Associates 34
- 35. Recommended Resources © Scott Ambler + Associates 35
- 36. Backup Slides © Scott Ambler + Associates 36
- 37. 37 Disciplined Agile Delivery (DAD) Disciplined Agile Delivery (DAD) is a process decision framework The key characteristics of DAD: – People-first – Goal-driven – Hybrid agile – Learning-oriented – Full delivery lifecycle – Solution focused – Risk-value lifecycle – Enterprise aware © Scott Ambler + Associates
- 38. Goal Diagram Notation © Scott Ambler + Associates 38 Goal Issue * Option Default Option * Indicates a preference for the options towards the top
Editor's Notes
- #8: Challenges for an Architecture OwnerTraditional architects who don’t make the transition to agileArchitecture owners also codeSmart techie without technical leadership skillsThe architecture owner should not also be the product ownerNeglecting enterprise assets in favor of building your ownDictating architecture vs. “self-organizing design”Architecture gold-plating
- #18: Identify how much modeling you need to doGet the right people involvedChoose the right level of formalityOne initial strategy or several?Formal vs. informal modeling sessionsSingle vs. multiple candidate architectures
- #22: No single view sufficesTOGAFZachmanDODAF
- #26: Source: http://www.agilemodeling.com/essays/amdd.htmFirst, let’s start with how to read the diagram. Each box represents a development activity. The envisioning includes two main sub-activities, initial requirements envisioning and initial architecture envisioning. These are done during iteration 0, iteration being another term for cycle or sprint. “Iteration 0” is a common term for the periodbefore you start into development iterations, which are iterations one and beyond (for that release). The other activities – iteration modeling, model storming, reviews, and implementation – potentially occur during any iteration, including Inception. The time indicated in each box represents the length of an average session: perhaps you’ll model for a few minutes then code for several hours.