Agile Architecture Belfast Software Architecture User Group
- 1. Agile Architecture Agile and Architecture are not traditional bedfellows, this talk takes a look at the case for Agile and Architecture and seeks to make some practical suggestions on how an Agile Architecture approach can effectively deliver working software which endures the test of time.
- 2. Kainos 92 Telesoft Technologies 00 Pramerica 06 Liberty IT 97 Paul Wallace https://uk.linkedin.com/in/pwwallace Senior Technical Architect at Pramerica Systems Ireland
- 4. Why AGILE?
- 7. "All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.” —Grady Booch
- 9. Agile says work it out as you go, but Architecture says plan ahead. Look at the Agile manifesto through an Architecture lens.
- 10. " Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.” —Agile Manifesto Principle #2
- 11. " Continuous attention to technical excellence and good design enhances agility.” —Agile Manifesto Principle #9
- 12. " The best architectures, requirements, and designs emerge from self-organizing teams.” —Agile Manifesto Principle #11
- 13. "Agile Architecture is a set of values and practices that support the active evolution of the design and architecture of a system, concurrent with the implementation of new business functionality.” —Scaled Agile Framework Defining Agile Architecture
- 14. Intentional Architecture is a set of purposeful, planned architectural initiatives to enhance solution design, performance, and usability Agile Architecture Concepts
- 15. Emergent Design is where the design evolves hand-in-hand with business functionality. It is constantly tested and enabled by Refactoring, Test-First, and Continuous Integration Agile Architecture Concepts
- 16. Agile Architecture combines Emergent Design with Intentional Architecture driven by collaboration Agile Architecture Concepts
- 17. Collaborating to Evolve the System - Scaled Agile Framework
- 19. Organisational Model OPTION 01 OPTION 01 OPTION 01 Kanban Strategic Portfolio OPTION 01 OPTION 01 OPTION 01 Kanban Product Vision Program OPTION 01 OPTION 01 OPTION 01 Scrum Component Design Team Enterprise Architect Solution Architect Technical Architect Enterprise / Corporate CTO Head of Engineering Technical Lead Startup / S/w House
- 20. Intentional Architecture ensures we plan enough architecture to enable the immediate deliverables and avoids Big Design Up Front Defer Architectural decisions to the “Last Responsible Moment”, the point where you have the most information Design for reversibility, make decisions in such a way that you'll be able to reverse it later on without too much difficulty Just Enough Architecture
- 21. Diagramming is a communication tool Maximise the audience for your diagrams, but context is key Use specific design notation (Archimate, BPMN, etc) only when needed Diagram for All
- 22. C4 diagrams from Simon Brown: Context diagram: Business stakeholders Container diagram: DevOps and Infrastructure teams Component diagrams: High Level for Dev Teams Class diagrams (UML): Detail Design or to illustrate a pattern Diagram for All
- 23. Key to emerging design: Define the touch points between architecture and development during iterations Define the architectural artefacts, or contracts, between the architect and the dev team Define what constitutes “done” for the architectural collaboration Define your Architectural Collaboration
- 24. Develop a Ubiquitous Language for the project domain with business partners Utilise patterns to make communication more effective in all aspects of the project; Architecture, Development, Testing, DevOps, etc. Communicating with Language and Patterns
- 25. Architectural tests to cover non functional requirements, e.g. ‘ilities Use constraints to drive architectural tests. E.g. number of concurrent users Same rules apply to architectural tests as other tests, i.e. Independent, Automated, Verifiable – Principles of Test Automation Architectural Tests
- 26. Conclusion Agile and Architecture are necessary disciplines in a modern software development process Agile approaches need to include architectural activities as part of the delivery plan Architecture needs to be an iterative and adaptive process centred on the collaboration between the architect and the development team
Editor's Notes
- #6: Risk mitigation is a benefit of Agile
- #8: Some people refer to architecture as strategic design Making good architectural decisions saves money in the long run If we don’t manage the significant design decisions in the right way then change will be costly
- #10: Reading agile documentation you could be lead to believe that there should be no up front design, hence no architecture Where as architecture requires up to consider the parts of the system which are going to be costly to change
- #11: Challenge or Opportunity If we accept that requirements will change, then we must accept that architecture can change too Agile is creating an opportunity to be more adaptive in our architectural approach
- #12: The devil is in the detail. If architecture is design, then having a good architecture will enhance agility
- #13: The best architectures emerge, this points to the need to developing your architecture over the lifetime of the project
- #14: We can evolve the architecture while continuing to deliver business value
- #15: Leveraging common architectural patterns, design constraints and implementation technologies Building and maintaining architectural runway
- #16: As we are continually delivering software then our design and architecture are continually being tested and improved
- #17: Lets look at the iterative process of intentional architecture and emergent design
- #20: Blue - Project management Orange - Task management Gray - Architectural focus
- #21: Last responsible moment concept comes from the military but from a software point of view it was popularised by Lean Thinking I prefer to think of it as the point where you have the most information e.g. If you decide to implement a rules engine up front before you know the nature and complexity of the business rules you may have wasted your time when you find out you could have done it in code (or god forbid a stored procedure) Reversibility is a key concept in agile architecture as it enables change e.g. don’t hard code jdbc connection from business layer to persistence layer, use a repository pattern, you may need to implement remote persistence via an API
- #24: This speaks to the interaction between the solution architect and the dev team
- #25: Ubiquitous Language concept comes from the Domain Driven Design world Need to enable faster and more frequent communication in an agile project e.g. DevOps pattern – Orchestrator: controls a multi step activity
- #26: Conclusion next