Welcome to the Agile Architect Website!

Agile development methods attempt to improve the software development process, so that we can deliver useful solutions more often, and more quickly. However, despite some successes larger organisations and projects have been very slow to adopt them. One of the reasons is that many agile methods are perceived as architecturally weak, disconnected from the realities of delivering large systems in complex enterprise environments.

At the same time, many architecture processes are seen as slow, clumsy and bureaucratic. They would benefit from a more agile approach.

This web site looks at ways to confront this dilemma, by bringing agility to architecture and architecture to agility.

Most of the agile methods are based on a set of core principles, focussed on software delivery and collaboration. The Agile Manifesto sums these up, by stating that it values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

These are laudable aims, and we support them in principle. However, the reality for most enterprise architectures challenges them.

Most agile methods make two implicit assumptions: that a software system needs to be developed, and that we have some influence over how it is built. Neither is necessarily valid: the best solution may not be a new system, and any software may not be built under our control. Agile enterprise architecture needs to consider package, legacy and non-software solutions.

Among the architect's key responsibilities are management of change and complexity. Allowing for and managing future change is a fundamental part of well-designed complex systems, but anathema to agile methods such as eXtreme Programming. Neither is it easy to strive for simplicity. Complexity and simplicity are relative terms, and simplicity for one stakeholder means complexity from a different viewpoint, like the frantic activity underwater to power a duck's elegant glide.

This is perhaps the prime responsibility of an architect: to balance the interests of a wide range of stakeholders. In doing so, we must take a much more sophisticated view than simply prioritising the delivery of software to the users.

The agile architect, therefore, learns to balance the needs of multiple stakeholders, to make his own working practices and delivery processes more efficient by using agile techniques, but making sure that neither he nor other agile developers compromise the larger picture.

The Principles of Agile Architecture outline how agile architecture delivers on this complex responsibility.

The Role of the Agile Architect discusses the agile architect's role and responsibilities. There are a great many architectural roles in enterprise IT, but this site focuses on two: the Software Architect who develops the structure of an individual system, and the Enterprise Architect who focuses on how all the different systems, data, processes and strategies in an enterprise fit together.

If you would like to contribute material or links, please contact me.