Evolution Of Architecture, Pawel Lipinski
5 likes1,063 views
This document discusses the evolution of architecture in agile projects. It begins by defining architecture as the highest-level breakdown of a system into parts and decisions that are hard to change. In agile development, a good architecture is responsive to change while a poor architecture resists change. Principles of agile architecture include choosing the simplest design that works, using code to validate architectural decisions, having the development team own the architecture, and allowing architecture to evolve through iterations. The document advocates for architectural decisions to emerge from development rather than being fully pre-planned.
Evolution Of Architecture, Pawel Lipinski
- 1. Evolution of Architecture (I obviously mean „in agile projects”) Paweł Lipiński
- 2. pawel@agileee:/etc$whoami • based in Warsaw / Poland • then >10 years in Java ‣ SCJP, SCWCD, SCBCD, SCEA • i did: development, consulting, trainings, audits, architecture • software and system architect for the last 4 years • worked with: cowboy, quasi-RUP, FDD, Scrum (CSP), XP • currently: ‣ developer & owner @ Pragmatists, doing a merge of Scrum&XP • professional interests: (A)OO, agile, software quality assurance, languages
- 3. What’s this gonna be about • baseline - what’s architecture in general and how do I see it in agile projects • some principles of agile architecture what I think is important what helps what not to do • how we try to implement it
- 4. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. The best architectures, requirements, and designs emerge from self-organising teams. agile manifesto, principles #2 & #11
- 5. Architecture „Architecture” is a term that lots of people try to define, with little agreement. There are two common elements: One is the highest-level breakdown of a system into its parts; the other, decisions that are hard to change. Martin Fowler, PoEAA From the perspective of change, the role of architecture in agile development becomes quite clear: a good architecture is responsive and will support agility; a poor architecture will resist it and reduce it. Kevlin Henney, The role of architecture in agile development
- 6. so how should the architecture be? should encourage change - so it must be extensible and modifiable should promote quality - care for / ensure testability, readability, feeling of safety promote creating value - make adding functionality simple, enable regular demos / reviews of new features enable research and verification - developers should always be able to check different approaches, verify their ideas be self-documenting - architecture lies in the code, the more readable it is at a high level, the less one needs to describe (often just the package names are enough to give high level description of architecture)
- 7. (some) principles of Agile Architecture influenced by Dean Leffingwell, scalingsoftwareagility.wordpress.com
- 8. a team which codes the system, designs the system conscious decisions need data - which appears / emerges during development decisions should be made by the team - it increases responsibility and engagement / commitment making decisions by several people increases probability of making better ones for the architecture to evolve, the architect (as a role) must be aware of costs and consequences of changes - and these are known to the team only
- 9. choose the simplest architecture that can possibly work if we suppose that architecture can evolve together with the development of the system, we can also suppose that it’s enough that it supports only what’s necessary NOW and what we’re absolutely sure is required (vs. YAGNI) the simpler the architecture, the easier it is to control and grasp by the team the bigger the team, the more true it is
- 10. if unsure, check it with code evolution of architecture, design, code means constant refactoring, permanent trials and tests leading to the right solution sometimes you need to check several things up to empirically verify which one is better that’s the best way to gain knowledge and architectural experience
- 11. the one to build is the one to test performance and stability tests verify correctness of architecture (eligibility in respect to nonfunctional requirements) in order to find these kinds of issues, tests must be performed often (CI) tests can lead architecture similarly as they do with design
- 12. if you know it, don’t pretend you don’t some things can be safely assumed / decided on very early, so that big changes are not needed later some things lie in experience and there’s not much sense in verifying them sometimes the last responsible moment is just the very beginning of a project if a decision is to be made, and we have complete data do make it, there’s no sense to pretend we don’t know what to do
- 13. architecture is a collaborative work sometimes it just means a work done commonly within the development team for big systems, with big/many teams it’s a subset of people team members can change - it’s good to have developers there as well - they’re the ones that need to commit! Nokia Test - it’s not agile if any part of a project is done by a single person
- 14. how’s that done in practice? evaluation software initial concept and development changes architecture team: development teams systems architect architect + developers the concept is just a vision, not a BAUF
- 15. Architecture as a part of each iteration Analysis Architecture Design Coding Testing Integration
- 16. Number: As a Manager I want to Estimate: see statistics of progress 13 8 of my projects Notes: A statistic should contain: - project name and description - budget in € and %-tage of overall budget - progress as %-tage 2 15 Pragmatists Release: _____ Priority: _____ Inspect & Adapt architecture is just one aspect of a project, and just like any other is governed by the same forces and principles iterativeness, communication, feedback, balance between decisions and risk enhance reactiveness to change
- 17. Architecture is not a document or some prescriptions, but an effect of a long-lasting process, which starts with initial concept, and then, during system’s development reacts to new-coming data and adapts to them. It’s a message about current system state, a shared team’s knowledge being under constant evolution. Architecture as such is a waste. It’s of no value to a client, but is an element of lowering costs of creating the actual value.
- 18. 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
- 19. Thank You (Q&A) pawel.lipinski@pragmatists.pl http://www.pragmatists.pl