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.

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