Most contributions to the world of agile development define a set of key principles, and we are no exception. The following build on principles from the Agile Manifesto, eXtreme Programming and, in particular, Agile Modeling. However, they have been re-structured, and some revised, to better meet the needs of Agile Architects.

These are separated into "objectives" (what you are trying to achieve), and "principles" (how to get there). All architects share similar objectives. Only Agile Architects follow most of the principles, most of the time. The practices needed by Agile Enterprise Architects making existing processes more agile will be different from those needed by Agile Software Architects trying to improve the architecture of an agile development. So over time these principles should be supplemented by several sets of practices to help implement them.

The key objectives for an Agile Architect are:

1. Deliver working solutions
2. Maximise stakeholder value
3. Find solutions which meet the goals of all stakeholders
4. Enable the next effort
5. Manage change and complexity

The Architect's primary objective is a working solution. The best solution may not need significant software development: extending a package solution or rationalising legacy data sources, for example. This is a different focus to most other agile methods, which assume that the solution is to develop or change software. However, like other agile developers the Agile Architect focuses on the solution, not on documents and management deliverables which don't contribute to the solution.

The solution must be seen as part of a whole, which includes other systems and projects. It must be robust enough to be changed and extended over time. You must support further work, whether it is to change the solution or simply to operate it efficiently.

Requirements change as technology changes, as the business changes, as stakeholders' jobs change and as understanding of the requirements evolves. The solution must support change. The Agile Architect must manage change. Don't fight it, embrace it, but plan for it  - this is a key architectural responsibility.

The cost of change is significant in any major real-world system, so the Agile Architect must balance planning for change against other goals. The Agile Architect must also seek to manage and minimise complexity, which helps to maximise stakeholder value. The aim is a solution which is neither simplistic and brittle, nor over-complicated by over-building for flexibility.

You must recognise the value and importance of people. It's people who build success in IT, not machines, money, tools, technology or processes.

Motivated individuals are your greatest asset. Guide them gently, with support and understanding. Remember, and remind others, that they are not interchangeable resource units. Instead trust people, give them the tools and resources to get the job done, and work hard to minimise the things which get in their way.

Aim for sustainable development, with a pace which can be maintained indefinitely by business people, developers, users and others. Help the project team to avoid panics, and discourage any tendency to a culture of overwork.

Work with and learn from others. Understand that you don't know everything, and that everyone has their own area of expertise and value to add to a project. Treat everyone with respect, and promote every opportunity to learn from each other.

Focus on your audience. Use appropriate communications for each audience, matched to their skills, goals and needs. Write every document, and build every maintained model, with a defined purpose for a defined audience. Recognise that different stakeholders need different views, and support them with appropriate information. Viewpoints include (among many others):

• A development, managerial or operational focus,
• Static and dynamic views, and those that represent the system(s) changing over time,
• Those that focus on the data, processes, or application elements.

Keep the content and style of communications as simple and brief as possible. Keep documents short and models simple. Focus on content, not representation or "polish". Models may have many physical forms, and not every model becomes a document.

Encourage comments and suggestions. Try not to be protective or defensive of your ideas. Anyone may have a good idea or valuable insight. Open and honest communication helps people to make better decisions based on better information. Share appropriate materials with all stakeholders. Where possible display models publicly, open to comment from everyone.

Travel light, and update only when it hurts. Everything you create, document, model, code, test or any other artefact has a cost. If you decide to keep it, each will need to be maintained over time, increasing the cost of change, and what people must know and understand. The less you keep and maintain, the more agile you are.

Don't be afraid to throw things away when they have served their purpose, but you may sometimes consciously trade off agility for the convenience of having information available to enhance communication.

Minimise complexity. Simplicity reduces the amount of work to do. The simplest solution is usually the best solution. More complex and detailed artefacts will be more difficult and expensive to change. Plan for change realistically, but don't overload your models or the system with features that you don't need.

Minimise complexity to deliver stakeholder value. One of the key causes of eroded value is the overhead and extra costs from complexity. Do not create lots of separate little systems or data sources, which increase complexity and overheads at an enterprise level.

Use models to simplify both software and the software process. It’s much easier to explore an idea, and improve upon it as your understanding increases, by drawing a diagram or two instead of writing tens or even hundreds of lines of code.

Some agile methods imply that the cost of change is very small. They "embrace change" by waiting until the customer says "Jump!", and then asking "How High?" The Agile Architect knows this knee-jerk approach is wrong.

The cost of change in a real-world enterprise system is never that small. You must plan for change, and understand its costs. You must deliver an architecture which can accommodate likely change in the best way for the enterprise, not just any way. However "agile" your process, if your architecture cannot handle change then it is fragile, not agile. True agility is the ability to undergo change quickly and easily without degrading the architecture, and with as small as possible an impact elsewhere.

Plan for change. Understand the likely directions of change, by looking forwards using techniques such as "scenario analysis" and "change cases", and looking backwards at previous changes. If a particular change is repeated, or contradicts another, or contradicts your common sense, then try to find a way in which you can make and undo that sort of change more easily, without having to change artefacts like documents, source code or data structures. (See Strategies for Flexibility for more details.)

Consider the design in terms of its behaviour over time, not solely in terms of an “instantaneous” characteristic such as performance or current functionality. To provide resilience to change and control complexity you must abstract out common elements and encapsulate those which may change behind stable interfaces.

Manage change. Make changes in a controlled way. Don't accept any change regardless of its cost and impact. Know when to say "no". If a proposed change creates a problem, then look for alternatives whose impact is smaller. Common sense and a consideration for other stakeholders are key tools. Balance the goals, but have the courage to make decisions when they are needed.

Travel light, so the cost of necessary change is minimised, and communicate so that everyone understands what is changing, why, and how it will affect them. Use agile models to explore change - it's much cheaper than cutting code. You must still keep an eye on the future, and remember to support the next effort - again the Agile Architect must balance different goals.

Manage and plan for change, but don't resist it. You won't get it right first time, and there's nothing agile about being paralysed by analysis, or overburdening your models or your design with features you don't need. Accept that things grow and evolve, but give that evolution structure, and support, and room. 

You must balance the various goals and constraints, actively trying to find the best balance for the overall situation. The best solution for the enterprise might not be exactly what a particular stakeholder wants, but you should strive to meet his business needs, if not his desires.

Have courage in your decisions. Don't be defensive, but be prepared to sell them. Listen to the arguments, but avoid letting one stakeholder or concern dominate the decision making process.

Being agile in your choice of what to model, document and build is not the same as reducing quality. Poor quality serves no-one: neither you, your current stakeholders nor future ones. Focus on quality work, but measure quality by the strength and usefulness of the deliverables, not adherence to a document-heavy process.

Plan and design for testing. Some agile processes (eXtreme Programming in particular) put testing first, before coding - this is a good practice to emulate. If you can not write the actual test scripts, you should still verify your understanding of any requirement by defining how it can be tested. Design the architecture to support testing: ensure the system is controllable, so that tests can be performed easily, and observable, so you can verify the test, or find out what has gone wrong.

Test your ideas. In some cases the best way is to write the code, to develop a prototype. If this is not practical, think of other ways in which you can "test" the architecture, without committing a lot of effort to detailed work around an unproven design.

Trust your instincts, and those of other people. If something "feels" inconsistent, or unworkable, then there may be a good reason. Use your instincts to guide your modelling and testing efforts, and challenge requirements which don't pass common-sense checks. If two alternatives cannot easily be rationally separated, but one "feels" better, go with that choice.

Adapt your process to fit your organisation, tools and standards. Don't try to shoe-horn tools or ways of working in where they don't easily fit. Help each team to regularly review how it can become more effective, and to adjust its methods and behaviour as required.

Deliver your products both regularly and, if possible, frequently. A regular delivery cycle makes it easier for the users and other IT people to plan to accept and adopt each release. Frequent deliveries progressively increase the value to the users, and prove that the project is working. However, you must be pragmatic, and balance the advantages of frequent delivery against the cost of processing each release.

Make sure your interfaces to other areas are clear and well defined. This applies to both physical interfaces to other systems, and human interfaces to other areas. Define physical interfaces using models which you formally control and maintain - these form a contract with the developers and users of other systems. You may not need to be so formal about human interfaces, but make sure you understand who is responsible for what - you may need to write this down and get agreement, especially in more difficult situations.

Being agile in your approach to modelling and documentation is key to being an agile architect. Some of the techniques to achieve this are described above.

The work on Agile Modeling and Agile Data led by Scott Ambler details a set of further principles and practices which you should also follow. The following particular principles and practices are described further on the Agile Modeling web site:

• Model with a purpose
• Multiple models
• Know your models
• Know your tools
• Apply the right artefacts
• Model in small increments
• Model with others
• Use the simplest tools
• Apply modelling standards
• Discard temporary models

Philippe Kruchten of Rational has taken the Tao of Lao-Tsu, and created a modern translation focussed on the values and attitudes which an architect should adopt. He says many things I have been trying to, but much more beautifully:

The Tao of the Software Architect: Lao-Tsu revisited