Architecture in an Agile World: SPLASH Workshop Report

SPLASH 2010, Reno, NV
October 18, 2010

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
  2. Architects lead and communicate (they have stronger interpersonal skills than the average team member)
  3. Set up the architecture infrastructure
  4. Work across multiple levels of abstraction
  5. Communicate with customers and stakeholders (such as the project sponsor)
  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)
  8. "Combat the forces of evil"

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?

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.

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:

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.

Another interesting practice to try: Pageboxing.


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:

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:

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
  4. Abstractions that are hard to understand or communicate
  5. Missing -ility stories / tests / strategies
  6. Untestable code
  7. Unbalanced test suite (too many unit tests, not enough functional tests)
  8. Test churn
  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
  11. General violations of architecture standards
  12. Missing boundary stories
  13. Duplication without reason
  14. A mumber of incidents in operations

Discussion

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

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

Thanks to everyone for a great discussion!


Last modified: Oct. 26, 2010