Architecture in an Agile World: SPLASH Workshop Report

Workshop conclusions

The role of an architect can be very important in an agile project.

The workshop attendees addressed the following four questions:

1. What is the role of an architect in an agile project?
2. How can an agile project schedule architecture activities?
3. Team and project characteristics: how do they impact the role of the architect?
4. What are some of the "architecture smells" to watch out for?

Role of an architect

1. Balance YAGNI and long-term / business value
   (YAGNI stands for "you aren't going to need it" -- which is the XP idea of only designing and implementing based on the items in the current iteration. The YAGNI principle advises developers to "do the simplest thing" that will complete the user story. An architect can be the person who says "when you do not do the simplest thing."
2. Architects lead and communicate (they have stronger interpersonal skills than the average team member)
3. Set up the architecture infrastructure
   (Architecture infrastructure might be the items the team identifies in "iteration 0", or it might be a series of 3 or 4 exploratory early iterations to stabilize the initial architecture.)
4. Work across multiple levels of abstraction
   (It has been generally observed that not all software professionals are equally capable of working with several levels of abstraction -- many get lost after two or three levels. Architects often need to work with 5 levels of abstraction or more.)
5. Communicate with customers and stakeholders (such as the project sponsor)
   (In agile projects, direct communication between customers and all team members is encouraged. Architects might have a more intense focus on collecting and understanding requirements that go beyond the normal "functional requirements."
6. Set up guide rails -- these may be some decisions that guide future design-level decisions
7. Advise people making priority decisions (so they are more aware of the future)
   (In some agile methods, such as Scrum, the decisions about priorities are made by the Product Owner -- usually with input from customers, stakeholders, and team members. Product Owners often need help to get familiar with architecture issues -- what architecture choices might block future features, how implementing some stories might have positive or negative impact on performance, scalability, reliability, and so on.)

   (Some teams decide to dedicate certain iterations to do refactoring work -- architects might help recommend when a refactoring iteration is necessary.)

8. "Combat the forces of evil"
   (In the workshop discussion, participants noted that certain business organizations -- Human Resources (HR), Information Technology (IT), procurement, marketing, and sales organization -- might sometimes be a drag on the process... through obfuscation, delays, and bad excuses. Architects aren't always able to solve these problems, but they sometimes have more authority to put up a good fight.)

How to schedule architecture activities

There is always a risk that essential architecture activities are delayed because the customers or Product Owner put a higher value on new functionality than infrastructure. What are some ways to increase the visibility of the risk and value of architecture work?

• Identify technical risk for each item in the backlog
  The "technical risk" value might simply be high, medium, or low.
• Identify dependencies on "-ility" stories.
  The term "-ility" refers to a number of "extra-functional requirements" (sometimes called "architectural requirements") that span a large number of customer-facing scenarios. This category of requirements includes:
  • reliability
  • portability
  • usability
  • performance
  • security
  • scalability
• Use more functional and acceptance tests (for some of these -ility requirements) to drive architecture work -- to get more architecture work scheduled in the iterations.
  If there are automated tests for some of the -ility requirements, it is more likely that these items will be given some priority in the planning -- because they become more visible.

Gap: Not enough materials on acceptance testing.

The current training materials and books on automated testing for "functional and acceptance tests" is pretty weak -- so many agile team members don't really learn how to write good tests for these -ility requirements. We need more examples, experience reports, and training for ATDD practices, especially aimed at a wider range of requirements types. (Much of the literature is focused on simple database-centric web applications -- but there are much richer functional testing problems in other domains.)

Architecture-affecting business requirements

One way to approach the process of defining adequate -ility requirements and testing is to narrow the focus on a subset of the business requirements that are collected from the customers.

• Don't just wait for the customers to tell you about -ility requirements -- probe the customers to get more information.
• In other words, if you get a new or changed Business Requirement from the customer -- and the requirement is in this "architecture-affecting" subset -- then the architect (or other team members) can open a dialog with the customers to define some extra -ility tests.

Two smells from -ility requirements

We discussed two smells (which are really "agile process smells" more than "architecture smells") that agile teams should be aware of:

• Smell: Not enough time spent on architecture in iterations
  • Resolution: Get the business people to articulate the missing -ility requirements as user stories, then convert stories into functional/acceptance tests. Use these tests to drive architecture work into each iteration.
• Smell: Unbalanced test suite (the test suite is too heavy on unit tests and TDD, or the test suite is narrowly focused on certain facets of the architecture)
  • Resolution: Get architects and lead developers to elicit more -ility requirements.

Side discussion on avoiding Big Design Up Front

One common fear of agilists -- the architecture documentation might become an undesirable "Big Design".

This is a somewhat rational fear... because standard architecture practices often push architects to try to be complete -- to specify as much as they can.

But... one standard agile practice helps to reduce the risk: Timeboxing.

• Timeboxing in agile methods includes the mandate that each iteration produce some real working code, even in the first iteration. So you can't force the creation a document of hundreds of pages without having at least some code to show that the architecture might really work.

Another interesting practice to try: Pageboxing.

• Pageboxing is deliberately limiting the initial architecture documentation to a very small page limit -- for example, no more than 20 pages in iteration 0. This is a good strategy, because a short and concise document is more likely to be read and understood by the entire team. (Why do you want to write a 100 page document that no one will read? It is just a waste of time and effort.)

Team and project characteristics

Some combinations of team characteristics and project characteristics might increase the importance of architecture and architects.

Team characteristics

New teams

A "new team" is not a team of inexperienced developers, it is just a group of people who have never worked together before.

An architect helps build trust within a new team

An architect helps train and establish a common vocabulary within the team

An architect acts as facilitator / catalyst, to get the team to think about business issues, regulatory constraints, and customer needs

Over time, an architect gains credibility and becomes a technical leader for the team

Established/mature teams

This kind of team has experience working together, so an architect isn't as important

But an architect can help the teamlearn what is new and novel in their new project

Project characteristics

There are some important project characteristics to watch for -- that increase the value of having an architect on the team:

• complexity
• size
• novelty
• constraints (e.g. regulatory constraints)

If you have higher complexity, larger size, and so on, the value of the architect is higher.

Suppose your team is developing yet another web application. The problem domain is very familiar to the team -- there isn't much that is novel. The size of the project is small, complexity is low, and there are no serious constraints. Does the team need an architect? No -- probably not.

On the other hand, suppose this web application is for a medical application -- and there will be some regulatory approval required from the government. Is an architect more valuable here? Yes, absolutely.

In the analysis of these factors, we think these three cases are special:

• Highly-complex projects
• Highly-novel projects
• Significant constraints

For highly-complex projects, we need more architect involvement, especially in "setting the roadmap" for the team. The architect can help the team decide where to schedule the definition, implementation, and testing of key pieces of the architecture.

For highly-novel projects, there is some value in "encapsulating the novelty" -- defining modules or components that make the novelty easier to work with. Again, the architect can contribute to building the roadmap or schedule of architecture-centric features. Finally, an architect can identify which parts of the problem might be addressed later -- with an "emergent architecture".

For projects with significant constraints, the role of the architect is mostly "communication" about the consequences of the constraints plus "governance" -- ensuring that appropriate reviews, tests, and other procedures are in place to ensure the constraints are met.

Architecture smells

The following list of architecture smells came out of many parts of the Architecture in an Agile World discussion. It isn't a complete list, and many of the smells in this list are sometimes caused by problems unrelated to architecture issues. But these smells are a good place to start in looking for architecture gaps in an agile project.

1. Code that nobody wants to change (they are afraid to change it because it is complex or cryptic, and they don't want to break anything)
2. Missing metaphor (the team and customers need a common shared understanding and vocabulary about the problem)
3. Overreliance on "refactoring iterations" to fix technical debt
   (It is generally OK to have some refactoring iterations that are driven by architecture changes and evolution.)
4. Abstractions that are hard to understand or communicate
5. Missing -ility stories / tests / strategies
   (A related issue: If you have many successive failures of -ility tests in a series of iterations, it might be a sign of a lack of progress on making improvements to the architecture.)
6. Untestable code
7. Unbalanced test suite (too many unit tests, not enough functional tests)
8. Test churn
   (Small design changes trigger a number of changes in the automated tests -- could be caused by poor technique in the implementation of tests, but there might be some architecture issues as well.)
9. Problems in design evolution -- the problem is sometimes called "you can't get there from here". You have a design that is too rigid.
10. Inconsistent use of infrastructure
    (For example, there are some modules that use a standard messaging component while other components use some special local messaging code. It isn't really "wrong", but it increases the learning curve for new project members, and it might cause long-term maintenance issues.)
11. General violations of architecture standards
12. Missing boundary stories
    How does your system interact with other systems? What end-to-end stories do you need to write to understand the interface requirements between your system and external systems?
13. Duplication without reason
    (Examples: using two different databases, multiple interface mechanisms.)
14. A mumber of incidents in operations
    (If the system is hard to use, easy to make configuration mistakes, or it is easy to get things into an error state -- this might indicate that you missed some requirements or you might have some other architecture gaps to address.)

Discussion

Some "agile development advocates" reading this report might ask the question:

• "Why are you advocating an architect role in agile projects? We have always found architects and architecture organizations to be a source of many problems for agility. For example, they are always trying to act as a 'central control' of the design -- a kind of design rule dictator. Shouldn't we just get rid of architects completely?"

We discussed this point a year ago: in the 2009 workshop. (See http://mysite.verizon.net/dennis.mancl/oopsla09/agile_arch_report.html for the full report of the 2009 workshop.) We came to the conclusion that although there are many architects and architecture organizations that abuse their powers, there can still be a lot of value from having architects within agile teams.

The 2009 workshop defined a list of characteristics of "good architects" and "bad architects" -- also called "architect patterns and antipatterns." We assume that an overcontrolling architect is really bad. Effective architects work in a more collaborative model: they may be strong advocates for the "architecture", but they must act more as a coach and teacher than as a dictator.

The 2010 workshop started with the recognition that some architecture work needs to be part of any good iterative development process. Most of the established agile methods, such as XP and Scrum, put up some obstacles to getting important architecture planning and implementation into the iteration workflow.

Instead of making architects into outcasts in the agile development process, they really need to be full team members, with responsibilities for real coding as well as planning and documentation.

Workshop attendees

• Henry Baragar (Instantiated Software, Canada)
• Wim Couwenberg (Oce Technologies, Netherlands)
• George Fairbanks (Rhino Research, USA)
• Steven Fraser (Cisco Systems, USA)
• Gail Harris (Instantiated Software, Canada)
• Kenji Hiranabe (Change Vision Inc., Japan)
• Eric Lindberg (Teachscape, USA)
• Sonya Lowry (University of Arizona, USA)
• Dennis Mancl (Alcatel-Lucent, USA)
• Gerard Meszaros (independent consultant, USA)
• Chris O'Connor (Xtrm-Nrg Consulting, USA)
• Bill Opdyke (JP Morgan, USA)
• Barbara Prusiewicz (Verifone, USA)
• Dave Rathnow (Zedi Inc., Canada)
• Thomas Ritter (SAP, Germany)
• Vanessa Santanna (Globo.com, Brazil)
• Martin Buhl Svanum (Saxobank, Denmark)
• Harald Wesenberg (Statoil, Norway)
• Werner Wild (Evolution, Austria)
• Anders Winthereik (BankInvest, Denmark)

Thanks to everyone for a great discussion!