SATURN 2010: IEEE Software Speaker Philippe Kruchten, Architecture and Agile: An Oymoron?

Agility: ability to both create and respond to change in order to profit in a turbulent business environment (Jim Highsmith).

We define agility not by what we do, but by what we want to achieve.

Because software development is a knowledge activity, it deals with things that machines don’t deal with–uncertainty, unknowns, fear, distrust.

Architecture is part of design. It comprises choices about structure, behavior, style, tools, and language. Infrastructure and much more; part of system architecture.

Tensions between agility and architecture: Impression by Agilists that architecture is big design up front (BDUF), that it creates massive documentation. There is perception that value of architecture is low or has negligible visible value. Architects perceive lack of rigor in Agile, excessive focus on details. Architects also believe that non-functional requirements or quality attributes are not reducible to stories.

Summary of tension: adaptation vs. anticipation.

Seven issues of architecture vs. Agile:

  1. semantics – architecture is about design decisions, architectural decisions, and requirements constraints; it is a choice that is binding in the final product.
  2. scope – amount of architecture stuff that is needed depends on context (e.g., environment conditions; context attributes affecting practice: size, criticality, age of system, rate of change, business model, stable architecture, team distribution, governance)
  3. lifecycle – when must architectural activities take place, and when are Agile methods most appropriate, across inception, elaboration, construction, and transition stages?
  4. role – much confusion about role of architect, and many variations (e.g., system architect, enterprise architect, solution architect)
  5. description – fuzzy semantics, diverging interpretation, multiple views and viewpoints. What should an architecture description be? Again, this depends on the context: size, criticality, age of system, rate of change, business model, stable architecture, team distribution, governance.
  6. methods – Agile developers don’t know much about architectural design and have no explicit guidance for architecture; do not appreciate that it is sometimes necessary to get above the code level
  7. 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 worthy of attention. But cost of development is not identical to value.

Planning: derive architectural and functional requirements from requirements; establish dependencies and cost; plan interleaving functional and architectural increments. Weaving functional and architectural chunks (image of a zipper).

Benefits: gradual emergence of architecture, as in Agile, but deliberately, not accidentally. Architecture validated with actual functionality. Do this early enough in development to support development, with adequate time spacing.

There are significant cultural differences between architecture and Agile cultures. We need to move from ethnocentrism to ethnorelativism – acceptance and integration. Learn from the other culture.

Agilists should exploit architecture to scale up, partition work, communicate.

Architects can exploit iterations to experiment, functionality to assess architectures, and the growing system to prune (keeping it simple) and keep it lean.

Understand your context. Define architecture for you: meaning, boundaries, responsibility, tactics (methods), representations.

Recommendations

  • get out of ivory tower
  • build early an evolutionary architecture prototype
  • weave functional aspects with archtectural (technical) aspects – zipper image
  • Don’t jump on a labeled set of Agile practices – understand the essence – why and how
  • select Agile practices for their own value
  • don’t throw away the good stuff you have
About these ads

One response to “SATURN 2010: IEEE Software Speaker Philippe Kruchten, Architecture and Agile: An Oymoron?

  1. Pingback: Answering questions from the User Stories Webinar « Software Education Trainers' Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s