Deciding not to architect is an architectural decision. Postponing key architectural decisions while focusing on iteration-at-a-time development and customer-visible features negatively affects the success of large-scale projects. On the other hand, indulging in analysis paralysis in search of the best architecture that will sustain the system for its entire lifespan has the same effect. This is a reality that both the agile and architecture communities have accepted, especially in the context of large projects. But given that neither little-to-no-architecture nor big-up-front-architecture delivers the desired results to project stakeholders, what is the solution?
Communicating the value of architecting within agile development is a year-long project that Nanette Brown, Robert Nord, and I have just begun at the SEI with the goal of better understanding and measuring where the sweet spot is for just enough architecting to support agility in the context of large projects. Understanding how architecture-related tasks and features appear in iteration and release planning is an essential aspect of finding the right balance. We observe, as have many others such as Jim Highsmith in the latest edition of Agile Project Management, that foregoing planning in the haste of development does not necessarily equate with agility. Customer-visible features come to be because of the underlying organization of the software. Every system has an architecture, explicitly designed or not. The separation of architecture, code, and features might aid in project management, yet the reality is that they are not clearly separable.
Architecture can focus planning, backlog management, and refactoring. It can help prioritize features that are architecturally significant. However, this requires eliciting architecture-related features, assigning value and cost to them, and having mechanisms that treat customer-visible features simultaneously with architectural features based on their dependencies. Philippe Kruchten describes these concepts and their relationship to each other quite clearly with the metaphor of painting. We are also collaborating with him and his team at the University of British Columbia.
We often get asked at the SEI, “What are you currently working on?” On one hand, I’m glad that people care. On the other hand, I feel responsible that, in the search for solutions, we should not overlook the simple and the obvious. Being overly protective of ideas can lead to overthinking and overanalyzing, common pitfalls in any project, and contrary to agility: open communication, frequent feedback, courage, and simplicity.
In response, we have decided in this project to practice the principles of agility. We will make frequent posts here talking about what we are currently thinking, what we have read that we thought was valuable, what we applied, and what we think will not work as we progress on this project.
Ipek Ozkaya – SEI