Architectural runway
- 1. Architectural Runway Dmitriy Viktorov AgileDays’10, St.Petersburg, September 17th 2010 Protecting the irreplaceable | f-secure.com
- 2. 2
- 3. 3
- 4. 4 © F-Secure Confidential
- 5. 5 © F-Secure Confidential
- 6. 6 © F-Secure Confidential
- 7. 7 © F-Secure Confidential 21 September,
- 8. Principles of Agile Architecture 1. The teams that code the system design the system 2. Build the simplest architecture that can possibly work 3. When in doubt, code it out 4. They build it, they test it 5. The bigger the system, the longer the runway 6. System architecture is a role collaboration 7. There is no monopoly on innovation 8. Implement architectural flow 8
- 9. 9
- 10. * Source : Scaling Software Agility by Dean Leffingwell Copyright © 2009 Leffingwell, LLC. 10
- 11. Architecture is role collaboration Architectural inputs, ideas, constraints Architectural Evolution 11
- 12. Building Architecture Runway Theme 1 Solution Epics Epic Epic Epic Architecture features, in which the 1 2 5 Solution features depends on. A r c Epic 3 h Solution features without E i dependency on arch feature. p t i e Epic 4 Architecture features without c c dependency from solution features. s t u Solution feature r Epic 6 Arch feature e Note : No time dimension is illustrated in this picture. 12
- 13. Building Architecture Runway 3. Update 1. Determine initial component-based architecture that will influence the eventual formation of the application teams. Architects / Technical iterate leaders If uncertainty high & risky Feedback 2. Prototyping (Optional) 13
- 14. Extending Architecture Runway 3. Update Spikes that cannot resolved “program” spikes 1. Identify story : design spikes, refactoring within a team into iteration required, evaluations & dependencies. 2. Determine what features the system iterate may require in upcoming release plan that are not presently supported by architecture. Architects / Technical iterate leaders 14
- 15. State Machine for Architectural Epic Kanban Model 2 Portfolio Disruptive Backlog Roadmap technology Technology Roadmap criteria met, not ready slot avail. further value/effort>X, 3 review 1 rejected slot avail. Funnel Analysis Trash rejected rejected 4 business case approved & Implementation resource available Solution Common problem usage model 15
- 16. One of the more insidious and persistent myths of agile development is that up-front architecture and design are bad; that you should never spend time up front making architectural decisions. That instead you should evolve your architecture and design from nothing, one test- case at a time. Pardon me, but that’s Horse Shit. (...) Don’t feel that TDD is the only way to design. On the other hand, don’t let yourself get too vested in your designs. Allow TDD to change your plans if it leads you in a different direction. Robert C. Martin, ObjectMentor blog, „The Scatalogy of Agile Architecture”, 25.04.2009 17