Software Architecture and Agile Software Development â€”An

Architecture and Agility June 8, 2009 @ USC

Philippe Kruchten 1

T H E U N I V E R S I T Y O F B R I T I S H C O L U M B I A

Software Architecture and Agile Software Development

—An Oxymoron?

1 Copyright © 2004-2009 by Philippe Kruchten

Philippe KruchtenUSC, June 8th 2009

Philippe Kruchten, Ph.D., P.Eng., CSDP

Professor of Software EngineeringDepartment of Electrical and Computer EngineeringUniversity of British Columbia

@[email protected]+1 604 827-5654

Founder and presidentKruchten Engineering Services [email protected]+1 604 418-2006

Kruchten - 2009

Cofounder and secretary of IFIP WG2.10 onSoftware architecture

Cofounder of Agile VancouverAssociate Editor of IEEE Software for

architecture and design


Philippe Kruchten 2

Agile & Architecture? Oil & Water?

ParadoxOOxymoronConflictIncompatibility

Kruchten - 2009

Agility

A definition• Agility is the ability to both create and respond to

h i d t fit i t b l t b ichange in order to profit in a turbulent business environment.

Characteristics• Iterative and incremental

S ll l

Jim Highsmith (2002)

Kruchten - 2009

• Small release• Collocation• Release plan/ feature backlog• Iteration plan/task backlog

Sanjiv Augustine (2004)


Philippe Kruchten 3

Agile Values: the Agile Manifesto

We have come to value:Individuals and interactions over process and tools,Working software over comprehensive documents,Customer collaboration over contract negotiation,

Kruchten - 2009

Responding to change over following a plan.That is, while there is value in the items on the right, we value the items on the left more

Source: http://www.agilemanifesto.org/

Software Architecture: A Definition

Software architecture encompasses the significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those

Kruchten - 2009

gelements, the composition of these elements into progressively larger subsystems,

Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational, circa 1995(derived from Mary Shaw)


Philippe Kruchten 4

Software Architecture (cont.)

the architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition. Software architecture is not only concerned with structure and behavior, but also with usage functionality performance

Kruchten - 2009

usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and tradeoffs, and aesthetics.

Perceived Tensions Agility- Architecture

Architecture = Big Up-Front DesignArchitecture = massive documentationArchitecture massive documentationRole of architect(s)Low perceived or visible value of architecture

Kruchten - 2009

Adaptation versus Anticipation


Philippe Kruchten 5

Story of a failure

Large re-engineering ofa complex distributed world-wide system; y ;2 millions LOC in C, C++, Cobol and VBMultiple sites, dozens of data repositories, hundreds of users, 24 hours operation, mission-critical ($billions)xP+Scrum, 1-week iterations, 30 then up to 50 d l

Kruchten - 2009

developersRapid progress, early success, features are demo-ableDirect access to “customer”, etc.A poster project for scalable agile development

Hitting the wall

After 4 ½ months, difficulties to keep with the 1-week iterationsRefactoring takes longer than one iterationScrap and rework ratio increases dramaticallyNo externally visible progress anymoreIterations stretched to 3 weeks

Kruchten - 2009

Staff turn-over increases; Project comes to a haltLots of code, no clear architecture, no obvious way forward


Philippe Kruchten 6

Issues

1. Semantics2 Scope2. Scope3. Lifecycle4. Role 5. Description

Kruchten - 2009

6. Methods7. Value & cost

Issues


Kruchten - 2009



Philippe Kruchten 7

Semantics

What do we mean by “architecture”?

Kruchten - 2009

Software Architecture: A Definition

Software architecture encompasses the significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed together with their behavior as specified in the collaboration among those

Kruchten - 2009

gelements, the composition of these elements into progressively larger subsystems,

Grady Booch, Philippe Kruchten, Rich Reitman, Kurt Bittner; Rational, circa 1995(derived from Mary Shaw)


Philippe Kruchten 8

Software Architecture (cont.)

the architectural style that guides this organization, these elements and their interfaces, their collaborations, and their composition. Software architecture is not only concerned with structure and behavior, but also with usage functionality performance

Kruchten - 2009

usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and tradeoffs, and aesthetics.

Architecture = design decisions

Decisions

Software design

Software Architecture

Decisions“Design” decisionsArchitectural decisions“Requirements constraints”

Requ

men

Kruchten - 2009

A choice that is binding in the final product

Code etc.

uirents


Philippe Kruchten 9

Architecture = Design? Not

“Do not dilute the meaning of the term architecture by applying it to everything in sight.”

Mary Shaw

Kruchten - 2009

Issues


Kruchten - 2009



Philippe Kruchten 10

Scope

How much architecture stuff do you really need?

It depends…

It depends on your context

Kruchten - 2009

p y

Environment Context Practice

Environment Conditions (organization)

Drive/constrain

Context Attributes (software project)

Kruchten - 2009

Drive

Practices (actual process)



Context attributes affecting practices

1. SizeAge of

Size

2. Criticality3. Age of system4. Rate of change5. Business model6. Stable architecture

Age ofSystem

Rate of change

Business model

Criticality

Context

Kruchten - 2009

6. Stable architecture7. Team distribution8. Governance

Governance

TeamDistribution

StableArchitecture

Issues


Kruchten - 2009




Lifecycle

When does architectural activities take place?The evil of “BUFD” = Big Up-Front Design

“Defer decisions to the last responsible moment”

Kruchten - 2009

Refactor!

Architectural Effort During the Lifecycle

time

Inception Elaboration Construction Transition

Kruchten - 2009

Majority of architectural design activities



Little dedicated architectural effort

time

Inception Construction Transition

Kruchten - 2009

Minimal pureArchitectural

Activities

Ideal realm of agilepractices

P li i A hit t A hit t D l D l D l T iti T iti


Iterations and Phases

PreliminaryIteration

Architect.Iteration

Architect.Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

TransitionIteration

TransitionIteration

Internal Releases with f hit t

Releases with main f f t

Kruchten - 2009

An architectural iteration focuses in putting in place major architectural elements, resulting in a baseline architectural prototype at the end of elaboration.

focus on architecture focus on features



Team Structure over Time (Very Large)

Construction and TransitionElaborationInception

Initial teamArchitecture

team

Architecture team

Feature team 2

Feature team 1

Management team Management team

Kruchten - 2009 integration team

Feature team 3Infrastructureteam A

Infrastructureteam B

Prototyping team

Teams using agile development practices



team

Architecture team

Feature team 2

Feature team 1





Prototyping team



Issues


Kruchten - 2009


Inflation?

Kruchten - 2009



Role – Agile Architect

A. Johnston defines the agile architect, but it does not seems to be any different from a

ft hit t b f il th d isoftware architect before agile methods came in.Combination of• Visionary - Shaper• Designer – making choices• Communicator – between multiple parties

Kruchten - 2009

• Troubleshooter• Herald – window of the project • Janitor – cleaning up behind the PM and the

developers

Two styles of software/system architects

Maker and Keeper of Big decisions

Mentor, Troubleshooter, and Prototyper

• Bring in technological changes

• External collaboration• More requirements-facing• Gatekeeper• Fowler: Architectus

• Implements and try architecture

• Intense internal collaboration

• More code-facing• Fowler: Architectus aryzus

Kruchten - 2009

• Fowler: Architectus reloadus

Fowler: Architectus aryzus

Only big new projects need both or separate people



Team Structure over Time (Very Large)



team

Architecture team

Feature team 2

Feature team 1





Prototyping team

A. Reloadus and A. Aryzus ecological niches



team

Architecture team

Feature team 2

Feature team 1


A. Reloadus




Prototyping team

A. Aryzus



Issues


Kruchten - 2009


Architectural description

MetaphorPrototype

Logical View ImplementationView

ProcessView

DeploymentView

Use CaseView

PrototypeSoftware architecture documentUse of UML?UML-based tools?Code?

Kruchten - 2009

Code?



It will depend on context (not agile issue)

1. SizeAge of

Size

2. Criticality3. Age of system4. Rate of change5. Business model6. Stable architecture

Age ofSystem

Rate of change

Business model

Criticality

Context

Kruchten - 2009

6. Stable architecture7. Team distribution8. Governance

Governance

TeamDistribution

StableArchitecture

Issues


Kruchten - 2009




Architectural design methods

Many agile developers do not know (much) about architectural designAgile methods have no explicit guidance for architecture• Metaphor in XP• Technical activities in scrum

Kruchten - 2009

Relate this to Semantics and Scope issue

May have to get above the code level

Issues


Kruchten - 2009




Value and cost

Architecture has no (or little) externally visible “customer value”Iteration planning (backlog) is driven by “customer value”Ergo: architectural activities are not given attention

Kruchten - 2009

“Last responsible moment!” & Refactor!

Value and cost

Cost of development is not identical to valueTrying to assess value and cost in monetary terms is hard and often leads to vain arguments

Kruchten - 2009

Use points (“utils”)



Planning

From requirements derive: • Architectural requirementsq• Functional requirements

Establish • Dependencies• Cost

Kruchten - 2009

Plan interleaving:• Functional increments• Architectural increments

Weaving functional and architectural bits

Kruchten - 2009



Benefits

Gradual emergence of architectureValidation of architecture with actualValidation of architecture with actual functionalityEarly enough to support development

Not just BUFD

Kruchten - 2009

jNo YAGNI effect

P li i A hit t A hit t D l D l D l T iti T iti


Iterations and Phases

PreliminaryIteration

Architect.Iteration

Architect.Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

TransitionIteration

TransitionIteration

Internal Releases with f hit t

Releases with main f f t

Kruchten - 2009

An architectural iteration focuses in putting in place major architectural elements, resulting in a baseline architectural prototype at the end of elaboration.

focus on architecture focus on features



Agility as a Culture

CultureCultureBeliefs, Norms

Values Behaviours

RitualsJargon

Kruchten - 2009 R. Thomsett 2007

ValuesReflect beliefs

BehavioursReflect values

Manifesto!

Agility and Architecture as Cultures

CultureCultureCultureBeliefs, Norms

Values Behaviours

CultureBeliefs, Norms

Values B h i

RitualsJargon

Kruchten - 2009 R. Thomsett 2007







Stages

Ethnocentrism• Denial• Defense

Ethnorelativism• Acceptance

Kruchten - 2009

• Integration

Learn from the “other” culture

Agilists• Exploit architecture to scale up• Exploit architecture to partition the work• Exploit architecture to communicate• …

Architects• Exploit iterations to experiment

Kruchten - 2009

• Exploit functionality to assess architecture• Exploit growing system to prune (KISS), keep it lean• …



Recommendations

Understand your context• How much architecture?

1. Semantics2 S

Define architecture• Meaning• Boundaries

2. Scope3. Lifecycle4. Role 5. Description6. Methods

Kruchten - 2009

• Responsibility• Tactics (methods)• Representation

7. Value & cost

Recommendations

No ivory tower• Architect is one of us

“Architecture owner” (Product owner)• Architecture owner (Product owner)• Make architecture visible, at all time

Build early an evolutionary architectural prototype• Constantly watch for architecturally significant

requirements• Use iterations to evolve, refine

Kruchten - 2009

• Understand when to freeze this architecture (architectural stability)

Weave functional aspects with architectural (technical) aspects (“zipper”)



Evolutionary Design

“In order to work, evolutionary design needs a force that drives it to converge. This force can only come from people –somebody on the team has to have the determination to ensure that the design quality stays high.”

Kruchten - 2009

Martin Fowler 2002

Kruchten - 2009

The first matrix I designed was quite naturally perfect….



… a triumph equaled only by its monumentalonly by its monumental failure.

I have since come to understand that the

Kruchten - 2009

… I have since come to understand that the answer eluded me because it required a lesser mind, or perhaps a mind less bound by the parameters of perfection.

Kruchten - 2009

Questions?



ReferencesAmbler, S. W. (2006). Scaling Agile Development Via Architecture [Electronic Version]. Agile Journal, from http://www.agilejournal.com/content/view/146/Clements, P., Ivers, J., Little, R., Nord, R., & Stafford, J. (2003). Documenting Software Architectures in an Agile World (Report CMU/SEI-2003-TN-023). Pittsburgh: Software Engineering Institute.Software Engineering Institute.Fowler, M. (2004) Is design dead? At http://martinfowler.com/articles/designDead.htmlJohnston, A., The Agile Architect, http://www.agilearchitect.org/Kruchten, P. (1995). The 4+1 View Model of Architecture. IEEE Software, 12(6), 45-50.Kruchten, P. (1999). The Software Architect, and the Software Architecture Team. In P. Donohue (Ed.), Software Architecture (pp. 565-583). Boston: Kluwer Academic Publishers.Kruchten, P. (2003). The Rational Unified Process: An Introduction (3rd ed.). Boston: Addison-Wesley.Kruchten, P. (2004). Scaling down projects to meet the Agile sweet spot. The Rational

Kruchten - 2009

( ) g p j g pEdge. http://www-106.ibm.com/developerworks/ rational/library/content/RationalEdge/aug04/5558.htmlMills, J. A. (1985). A Pragmatic View of the System Architect. Comm. ACM, 28(7), 708-717.Nord, R. L., & Tomayko, J. E. (2006). Software Architecture-Centric Methods and Agile Development. IEEE Software, 23(2), 47-53.Parsons, R. (2008). Architecture and Agile Methodologies—How to Get Along.Tutorial At WICSA 2008, Vancouver, BC.

Software Architecture and Agile Software Development â€”An

Documents

Transcript of Software Architecture and Agile Software Development â€”An