Evolution Of Architecture by Pawel Lipinski

Evolution of Architecture (I obviously mean „in agile projects”) Paweł Lipiński

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

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

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

Architecture „Architecture” is a term that lots of people try to deﬁne, 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

so how should the architecture be? should encourage change - so it must be extensible and modiﬁable 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 veriﬁcation - 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)

(some) principles of Agile Architecture influenced by Dean Leffingwell, scalingsoftwareagility.wordpress.com

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

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

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

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 ﬁnd these kinds of issues, tests must be performed often (CI) tests can lead architecture similarly as they do with design

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

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

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

Architecture as a part of each iteration Analysis Architecture Design Coding Testing Integration

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

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.

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

Thank You (Q&A) pawel.lipinski@pragmatists.pl http://www.pragmatists.pl

http://agileee.org	70
http://agileee.com	5
http://www.slideshare.net	2
http://www.agileee.com	1

Evolution Of Architecture by Pawel Lipinski

by Agileee on Sep 21, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 78

Statistics

Evolution Of Architecture by Pawel Lipinski — Presentation Transcript