Ever since the introduction of “Agile” around the turn of the century, people have wondered how to combine agility with architecture. The difficulty of this combination is due in part to a fundamental difference in goals between the agile and architecture approaches: architects look for stability and future-proof-ness, while agilists want to embrace change, looking for a kind of future-“loose”-ness.

Some say architecture and agility are conflicting approaches. The agile proponents’ attitude towards Big Up-Front Design (BUFD) certainly seems to directly oppose the idea of architecture-driven development. This perception of conflict is increased by the agile movements’ tendency to behave like a religion, complete with dogmas and heretics, as wittily described by Philippe Kruchten. On blogs, agilists sometimes post rants against any suggestion towards up-front thinking about a solution’s architecture, or any hint that not all key (quality) requirements can be addressed afterwards by magically refactoring an IT solution. Fortunately, not all agilists scorn architecture, as witnessed by Scott Ambler’s essay on agile architecture.

Looking more closely, one sees that architecture and agility represent two ends on a spectrum.  Where in this spectrum is the optimal place for your project to live depends on the project context. As noted in an earlier blog post, Barry Boehm suggests that the ideal place on this spectrum depends on three factors that together determine the amount of architecture needed beforehand: the size of the project, the volatility of the environment and the business criticality of the solution.

Agilists can become more successful if they take the project context into account when assessing the usefulness of architecture, but what can architects do to cross the divide between agility and architecture? Judging by TOGAF, the Open Group’s popular architecture framework, the principles in the Agile Manifesto have long been neglected by the architecture community. ADM, the TOGAF architecture development method, still requires rather bulky documentation, produced by often heavy processes like Business Architecture, Information Systems Architecture and Technology Architecture. This type of enterprise architecture approach is not suitable for an agile environment. In the software architecture world, lighter architecture approaches like George Fairbanks’s “Just Enough Architecture” are gradually gaining ground. These more agile approaches no longer view architecting as mainly a design discipline, but also as a way to control risk and deal with uncertainty.

Risk- and Cost Driven Architecture (RCDA) is a relatively new approach in this arena. This approach was developed to close the gap between enterprise and software architecture. Existing software architecture practices are often too limited in scope for the solutions that need to be architected, but the enterprise architecture practices are too heavy for the agility required by time pressure and frequently occurring changes and uncertainty. The RCDA approach incorporates a number of aspects from agile software development practices, such as the use of a backlog of architectural concerns, to be frequently reprioritized based on economic factors like risk and cost.

The secret of making architecting agile is to change your view of the main deliverable of the work, just like with agile software development methods. An agile software development team does not deliver a “big-bang system”, but a continuous stream of improvements to a system. In the same way, an agile architect does not deliver a “big up-front design”, but a continuous stream of architectural decisions, step by step gaining control of the uncertainties and risks surrounding complex IT solutions. How much architecture to build in is determined not by agile dogmas like “You Ain’t Gonna Need It” (YAGNI), but by economic trade-offs taking into account the real value of architecture in context.

Architects can do much to cross the divide towards agility – in fact, they not only can, but must. If they don’t make this effort, architecture departments will lose touch with their IT development departments, where agile methods have become mainstream, and with their business stakeholders, who continually ask for faster and better responses to changing market requirements. The key change architects need to make is to no longer view architecture as a design document to be delivered to projects up-front, but as a continuous decision making process in order to gain control over cost, risks and uncertainty. Only then can architects deliver the added value and flexibility required from them by their business stakeholders.

Listen to Bett and Russ of architecturecast.net interviewing me about these ideas and RCDA.