In the last post (What is Intentional Architecture?) we provided the motivation and a description of the role of Intentional Architecture in agile, enterprise-class application development. I suspect that most enterprise agilists would agree that there are substantive benefits when Intentional Architecture is effectively applied (so long as we don’t slow down development or use the need for up-front architecture as a capitulation to the waterfall design phases of the past!).
Historically, Intentional Architecture was a primary function of the system architect. But the most common agile methods don’t define (or necessarily even support) such a role, so a serious agile paradigm mismatch is likely to occur. These system architects (who, by the way, often hold director-level, VP, or CTO positions!) likely have decades of experience in the technology and the domain and have strong views about the intended architecture. However, the bulk of their implementation experience has happened outside an agile context, so they may not understand the practice of building refactorable code. Indeed, refactoring (mostly good) may all look like unnecessary rework (mostly bad) to them so they may not be initially supportive of our model, which depends on refactoring as a primary technique. They may also be concerned about the potential architectural entropy of all those newly empowered and energized agile teams. In addition, they may have equally strong opinions about the software development practices teams employ. If we fail to bring these key stakeholders on board to our agile development paradigm, they could kill the initiative as quickly as a routine sixty-hour work week. In some cases, we have witnessed the Battle for agile architecture: the agile teams vs. the system architects, and there can be no winner in that battle.
Fortunately, enterprise agility is not a zero sum game and there is room for all who can contribute to the best possible technical solutions. As we are continuously raising the bar to build systems of increasing complexity the likes of which have never been built before, it only makes sense to leverage the skills of all who have the experience to match the challenges the teams face! So include them we will and we described our support for this role in Principle #6 – System Architecture is a Role Collaboration.