April 2010 Theme:
Agility and Architecture
Guest Editor's Introduction by Maurizio Morisio
 

Do you think “agile architecture” is a contradiction in terms? Well, perhaps not. Architecture should be seen not as immutable but as an asset to reevaluate at each iteration, in close collaboration between architects and developers. But in practice, how do you really use agile methods at the level of architecture?

For instance, in the IEEE Software article “Agility and Architecture: Can They Coexist?“, (login required for full text) Pekka Abrahamsson, Muhammad Ali Babar, and Philippe Kruchten explain the role of architects, the importance of architecture as a function of project context, and the need for architecture documentation in agile processes. In the IEEE Software article “Architects as Service Providers,” (login required for full text) Roland Faber says that the architect role is to champion system qualities and stability, while the developer role is to champion the system functions and change. At the start of each scrum, they meet and negotiate the prioritization of tasks relevant for functionality or system properties. The “agile architect” keeps documentation about architecture at a minimum and interacts frequently (and flexibly) with the developers, building a trust relationship with them. The agile architect creates the rules but also helps break them, because “keeping the rules is not the goal; the goal is the overall system’s qualities.”

James Madison, in the IEEE Software article “Agile-Architecture Interactions,” (login required for full text) describes architecture-related activities at each step of a scrum iteration (up-front planning, storyboarding, sprint, working software). The key point in this case is also the communication and collaboration between architects and developers, with the goal of adapting and improving the architecture at each iteration and learning lessons from the working software.

On an application-oriented note, the authors of the IT 2008 conference paper “Presenting a Framework for Agile Enterprise Architecture” (login required for full text) apply agile methods to define an enterprise architecture (IEEE Xplore login is required for this article). Mark Isham’s Agile 2008 conference paper “Agile Architecture IS Possible—You First Have to Believe!” (login required for full text) reports on how a real project went awry, what the product team learned, and how an agile process not only created a scalable, reliable architecture but also improved the team’s ongoing productivity and morale.

Finally, the IEEE Software article “Peaceful Coexistence: Agile Developer Perspectives on Software Architecture” (login required for full text) reports on a survey of 72 IBM software developers. The authors found a supportive, rather than neutral or contrastive, relationship. This bodes well for future efforts to integrate agile and architecture practices. Be sure to check out the Related Resources below as well.

So, to answer my original question, agile architecture is not immutable, imposed architecture. It’s the result of interaction between developers and, as Faber says, the “humble architect.”

Enjoy your reading!


Guest Editor

Maurizio Morisio is an associate professor in the Department of Automation and Computer Science, Politecnico di Torino. He’s IEEE Software‘s associate editor in chief for online initiatives. Please visit him at http://softeng.polito.it/morisio.


Related Resources

Note: Login is required to access the full text of these articles.