Agile Grows Up: The Role of Software Architecture in the Agile Tween Years (Rebecca Wirfs-Brock)

This is a guest post by Rebecca Wirfs-Brock, who will be an IEEE-featured speaker at SATURN 2011, which is being presented by the SEI in collaboration with IEEE Software magazine.

Here is the abstract for Rebecca Wirfs-Brock’s SATURN 2011 plenary talk. She is also giving a tutorial at SATURN 2011 with Joe Yoder of The Refractory, Inc., titled Ultimate Agility: Let Your Users Do the Work.

Agile development has been around for over a decade. These days it isn’t edgy to adopt agile practices, merely prudent. Agile development practices bring real value to organizations that want to improve their business flexibility: the discipline of incremental delivery of well-tested software, more transparency in understanding the actual cost of developing product features, and the ability to change requirements late in the development cycle.

But yet, what if you are building software that takes years to unfold? Can you build a complex system without determining some of its architecture first? How should you tackle thorny architecture problems? What exactly is the role of software architecture for agile projects? There are two popular views on this.

The first is to simply let your software architecture emerge. This belief is founded on the practice of conscientiously evolving your design as you go. You won’t end up with a sound architecture unless you rework your design as you incrementally develop and deliver software.

The second view is that some critical investigations should be performed ahead of time. However, these explorations should be grounded, practical, and bounded in scope, and should deliver timely results that support mainstream development. Just as with any requirement, any architectural decision can grow stale if it isn’t applied.

It is tempting to say that the first approach is “more agile” than the second. But that view is overly simplistic. Both approaches avoid lengthy speculation. One supports decision making as a consequence of short experiments; the other encourages on-the-fly architectural decisions during the normal course of work. Both have uncertainty and risk: experimental results may be improperly vetted; on-the-fly decisions may be faulty.

The approach you find more appealing is partly a matter of how you react to uncertainty and how you like to mitigate risk. Do you think it prudent (or wasteful) to consciously invest in making an anticipatory decision? Do you find it rash (or empowering) to make architectural decisions in real time?

Those who divisively argue for one approach are acting like tweens who are more comfortable with concrete, black-and-white decisions than nuanced ones. But life and software development and architecture are often nuanced. It’s time to grow up. The role of software architecture activities in agile development is to support change, not guarantee that it will be painless.

And so, in these tween years of agile development, we need to recognize our options. Both approaches can work and have spectacular results. You don’t have to pick one and exclude the other. Sometimes investigations won’t pan out and sometimes on-the-spot decisions will be rushed and faulty. When we learn more, regardless of what approach we took, we may need to change our minds and our software’s architecture. Designs do evolve. Not every decision will hold up. But we’ll get better at making software when we acknowledge shades of gray, choices and change.

- Rebecca Wirfs-Brock, Wirfs-Brock Associates

 

About these ads

2 responses to “Agile Grows Up: The Role of Software Architecture in the Agile Tween Years (Rebecca Wirfs-Brock)

  1. GheeKeong KANG

    Agile applied to solutions architecting must be marketed to management with supporting evidence that it works. In an environment where the business requirements may change constantly (almost everywhere in the world!), an Agile mindset is ever more important.

    It has been suggested that to start, one may try applying it in little ways, stealthily, and when there are results, shout loudly, demonstrating that Agile delivers.

    The best way to implement Agile will then be the way that delivers results. And in a resource tight environment, being on time, on target and within budget is the best demonstration that the choosing the methodology is prudent.

    Hope to hear more from everyone about how Agile is applied in their context successfully, and some negative examples for me to avoid will be helpful too. With more and more case studies and real applications, Agile will take root, and that is something to look forward to.

  2. Pingback: Roles and Architects | Agile Project Manager

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