Architecture in an Agile World: OOPSLA Workshop Report

OOPSLA 2009, Orlando
October 25, 2009

Workshop conclusions

Architecture and agile are two important ideas in software engineering that ought to be used together to make software development more effective.

1. A "mixed model" of agile and architecture-driven development

The obvious conclusion in the workshop was that "pure agile" and "pure architecture-driven" approaches are not the way to go.

We believe that some early attention to architecture planning will contribute to better communication within a development team. Even in a one-person project, architecture planning helps by giving the developer a good way to think through important development issues, instead of merely implementing his or her first idea.

The combination of agile and architecture-driven approaches is a good thing -- it creates some opportunities for discovering potential problems early in the development cycle.

So agile and architecture-driven will complement each other to aid in the discovery of project problems early in the development cycle.

2. The architect can't be an isolated outsider in the software development process

In an agile world, an architect (or any development team member who is involved with software architecture or high-level design) has to be connected with development teams.

The workshop participants have seen organizations two models of interactions between architects and developers:

In either case, an architect needs to overcome the perception of being an "outsider" to the development work. One "agile" way to reduce the distance between architects and developers is to include architects as members of a development team, with specific development and testing tasks assigned to them in each development iteration. One benefit of this model: it makes the architects into users of their own documents and models, so they aren't just off in an "ivory tower". Also, as a member of an agile team, they will have frequent discussions with other development team members, which should improve communication about the architecture.

On the other hand, the idea of "making an architect a member of a development team" is not perfect. Some architects have poor development skills. The distractions of the development process may limit the amount of time they can spend on architecture planning. In some large systems, it is necessary for architects to spend time thinking about larger issues -- not just the development tasks of a single development team.

3. Good architects and good agilists

Another important conclusion of the workshop -- there are many skills in common between "good architects" and "good agilists". The full workshop report has a list of key "patterns and anti-patterns" for architects and agilists.

Two key "patterns" for architects:

There are some important patterns that are similar for agilists:

The architect patterns and the agilist patterns are definitely linked together.

4. Problems across the divide

Agile development teams have many complaints about architects. The top two problems:

These are valid complaints. Architects really do try to control things too much -- and an agile viewpoint could really help architects do their job better.

Architects often complain about agile teams -- some issues related to lack of forward vision and feedback:

Summary of conclusions on the post-workshop poster

In this workshop, the workshop participants explored questions related to the use of agile development techniques, the value of architecture planning, and how architecture-driven and agile approaches can coexist.

The top questions addressed in the workshop were:

Initial thoughts

Architects play many roles in a software development organization:

Architecture should not always be labeled as "big bad design up front". Some early architecture planning is usually important -- even when the requirements are changing.

Risks and opportunities of blending agile and architecture-driven

There should be some alteratives to these two extremes:

We think that a "blended model" is better -- using architecture-driven practices in combination with some agile practices. We think in terms of "opportunities" because agile and architecture-driven can work together to address some important issues in an agile world.

There are some important risks:

Establishing credibility for architects and architectures

In some cases, an architect has real authority -- the power to mandate design decisions, or direct control over development resources and money. In other cases, an architect is considered just a "technical expert" -- and his/her authority comes from the perceived quality of technical advice and the breadth of the organizational contacts in the architect's internal network.

In the agile development world, an "architect" is often viewed as an outsider:

One approach for project organization to improve this "outsider" problem: instead of the "architect role" being an outside expert, the architect is one of the team members, with some direct design and coding responsibility.

One important discussion question: Should there be a "single person" who is responsible for the architecture? No consensus on this question.

Good architects and good agilists

In this section of the workshop, we did some brainstorming about the "patterns" and "anti-patterns" of architects and agilists.

Architect patterns

What are some of the characteristics of an effective architect?

Architect anti-patterns

What can make an architect really awful?

Agilist patterns

What are some of the characteristics of an effective agilist?

Agilist anti-patterns

What can make an agilist really awful?

One important idea for "being a good architect":

One useful reflection on "being agile":

Agile groups problems with architecture-driven; architects problems with agile organizations

We started this discussion with checking version 2 of Kent Beck's XP book -- what does it say about the role of architects in an XP team?

An interesting question from the discussion: "Do we need to create an architecture roadmap for a product (or series of products)?"

Agile groups problems with architecture-driven

Architects problems with agile organizations

What other questions do we have?

In the workshop's initial brainstorming session, we came up with a number of other good topics to discuss. Unfortunately, because of the lack of time, we put these questions off until another future workshop:

Questions and issues on innovation for future discussion:

Last modified: November 3, 2009