Architecture Meets Agility
In June 2009, the Software Architecture Challenges in the 21st Century Workshop sponsored by IEEE Software, University of Southern California, and University of California Irvine attracted quite a bit of interest. Pekka Abrahamsson, Philippe Kruchten, and Grady Booch all addressed the role of sotware architecture and architecting in agile software development. I ended up writing an editorial based on this Kruchten and Booch’s talks for the September/October ‘09 issue of IEEE Software. The editorial is also featured in the August ‘09 edition of Computing Now.
In that editorial I explore the common themes raised by Booch and Kruchten, and also touch upon where the two gurus differ. The common themes I identified are:
- The scope of software architecture
- Architecture-phobia
- Architecture’s omniprescence
- Architecture for self-governance
- Architecting as a continuous activity
-
Just-enough architectural representation
These themes made me reflect on my former views on the topic of how agile and architecture interact. Those views were expressed in a tongue-in-check article that I had written for Agile Times back in 2003 . The article was sarcastically titled “Let’s Scale Agile Up”. In those relatively early days of agile, I used to advocate a purist agilista approach that downplays architecture. I used to object to any attempts to scale up agile software development by augmenting it with explicit architecting. I was wrong. And I felt how wrong I was in a recent project.
The project was small, but I couldn’t crack it with seat-of-the-pants, “let the design emerge” attitude. The project’s success relied on the ability of a complex core technology to solve the problem at hand. We had to nail down technical decisions at the beginning. And these decisions couldn’t be reversed easily later even though the project was small. And my client demanded to know about the main components, how they would interface with each other and be integrated with the core technology, how they would be decoupled from each other for maintainability and extensibility, and what general functionality would they provide. He wanted me to document the underlying decisions. In a nutshell, he demaned that I did some architecting.
I ended up spending a week and a half on these issues, constantly soliciting clarifications from my clients on the requirements, running endless spikes to resolve technical risks pertaining to the core technology, and coming up with a general design in the process. And I am glad my client insisted, because this upfront activity paid off. It turned out that seemingly subtle aspects of the requirements had an impact on how the core technology, a hairy rule engine, would work to solve my client’s problem. Interstingly, I no longer associated all this early activity as I did back in 2003 with the “grit” between the gears: the grit that contaminates the project and brings it to a screeching halt. And that grit did not interfere with planning and running the project as a highly incremental and iterative one. Actually it turned out be a lubricant rather than a contaminant. I grew up, I suppose.
