The architect is responsible for defining and maintaining the structure of the solution, and ensuring that it will meet the requirements. An agile architect must also help the team to work together in an agile fashion, to jointly own the solution, and to interface well with other parts of the organisation.

There are five main parts to this:

• Understanding the requirements - identifying the stakeholders, helping to analyse the requirements and extracting those of architectural significance
• Formulating the design - creating a solution structure which will meet the various requirements, balancing the goals and constraints on the solution,
• Communicating the architecture - making sure that everyone understands the architecture. Different people have different viewpoints, so the architect has to present various views of the system appropriate to different audiences,
• Supporting the developers – making sure that the developers are able to realise the architecture, by a combination of mentoring and direct involvement,
• Verifying the implementation – ensuring the delivered system is consistent with the agreed architecture, and will meet the requirements.

The architect defines the structure and organisation of the system. The architecture describes the system’s components, their responsibilities and interactions. A complex system is more than the sum of its parts. It must have a unifying, coherent structure. Therefore the architect must also define and describe:

• Metaphors, design principles and patterns on which the architecture is based,
• The technology, tools and standards which will be used,
• Key mechanisms, such as data access and error handling,
• Specifications and interfaces of components to be bought or built.

In an agile development team many people will contribute to these things. The agile architect will help all team members to contribute to the architecture, taking good ideas from everyone and making them part of a coherent whole. The architect may also adapt ideas originating elsewhere, but without losing the team’s ownership of the solution.

The architect will lead choosing the technology, and confirm that the choices are viable. He or she must therefore be aware of the alternatives, and factors that choose between them, and understand what technical issues are key to the project’s success.

The architect is frequently an evangelist for new or different technologies, processes or solutions. However, he also has a responsibility to help manage change, which may mean reining in his enthusiasm where risks and costs would outweigh the benefits.

The solution must meet the users’ needs, but not necessarily every wish and constraint. The architect should help to identify and resolve conflicting requirements, helping to say “No”, or “What do you really need?” if the requirements clash. The architect's objective is working solutions, and the best solution for the enterprise may not even need new software to solve the users'  problems.

One of the architect’s main jobs is communicating the architecture. He or she must become the solution’s “champion”, selling the vision and keeping it alive in the face of challenges. Each group of stakeholders needs to understand how the architecture meets their requirements. This requires multiple representations of the architecture directed at different parties. Any architect must model to communicate, but an agile architect will follow the principles of agile modelling, and help the project to "travel light".

An expert visualiser, good at abstracting and modeling solutions, the architect sees the “big picture”, and views a system and its context as a set of interacting components. However, the architect must also be able to understand and discuss the system in terms of functionality, hardware, project or financial considerations.

The architect helps the developers to understand the architecture, its value and the reasons behind it. He may act as a mentor or consultant, assisting, training and providing leadership to the developers. He may even work within the development team, focussing on implementation issues of particular architectural significance.

Not all architects are agile, and only special agile developers can become architects. A good agile architect is defined by his attitudes: understanding all the stakeholders, current and future, a "big picture" view,  willingness to accept and adapt ideas from various sources, and acknowledging that people are more important than processes or tools. In other words, an Agile Architect is someone who follows the principles of agile architecture.

A good architect will be insightful, pragmatic, and able to negotiate between conflicting forces. He may act as a bridge between developers, managers and other communities, and spends much of his time translating and mediating between them. A true architect must not be parochial, and this means gaining experience in different roles and fields. Having and using experience is more about attitude than years.

The architect must recognise the wide range of stakeholders, and their needs and concerns. The architecture has to serve well all the “build” and “use” processes (both in their widest possible sense), not just a single phase such as coding or deployment.

An architect models and documents: to understand, to create solutions and to communicate. An agile architect will use informal methods and and promote agile documentation: good enough, but not excessive.

In an agile development the architect has the main responsibility to consider change and complexity while the other developers focus on the next delivery. In any system of real-world complexity you can't allow anybody to change anything at any time, any more than any member of a family can take down a wall of the house. There are three dangers if "embrace change" is taken too literally:

• "Thrashing" as things change rapidly backwards and forwards where the requirements are unstable, or not understood, or not agreed by different stakeholders,
• Loss of stability for the system as a whole, and "the house falls down",
• Development of complexity, where changes lead are made without abstracting their common aspects or refactoring the design.

The architecture must support change but control complexity. The architect may have to take the viewpoint of future users, developers and maintainers, extrapolating the requirements from the short term into the future. The architect may also have to identify which aspects of the design can be freely changed, and which need control and planning.

An agile project will work in a different way, and at a different speed to less agile parts of the enterprise. This is not necessarily a bad thing, just the reality of different objectives and realities. In engineering terms, there may be an "impedance mismatch" between the agile developers and the others. The architect may act as the "transformer" between the different "impedances", more than just "keeping people happy" or "blocking", the architect should help each party understand the others' needs. The architect may make an important contribution to the agility of the project, by protecting the agile developers from unnecessary bureaucracy.

Many enterprise IT organisations are very bound by formal processes and fail to recognise the importance of people and a flexible approach to solving problems. In other words, they are "fragile" rather than "agile". By following and promoting the principles of agile architecture, the agile architect can both deliver more value himself and herself, but will often over time develop similar approaches in others.

The architect takes on many different roles over time. On a single project, the focus will change as the system's architectural detail matures. The same person may undertake different roles, changing his or her focus, or different people may take on different architectural roles. The latter is typical if there's a large architectural team, or responsibilities are split between architectural, development and technology support groups.

For a portfolio of projects, the focus may be different for different projects at the same time, simply because each project is at a different point in the life cycle. Again, a single person can change focus and role, or different people fill the different roles.

Finally, people change over time. As a person's interests and skills develop, he or she may feel happier concentrating on different parts of a system's life-cycle. If an architect has particular skill explaining concepts to business people, he will naturally focus at the strategic end. Another with deep technical skills will focus at greater levels of detail.

In fact, the picture is even more complicated, because as the system matures a team of people become involved, each with a different role and focus. so at the right-hand end of the picture we should show several overlapping roles. The total breadth of architectural knowledge increases so no one person can hold it all, and architectural responsibility is typically split, at least between hardware, software and data.

Each architect has a different "range of vision", and that may change depending on his role within the project. The "gaps" between the different ranges of vision may also be important, because these represent potential areas for failure in communication, where one person cannot "get down to the level" of another and vice-versa. 

There's no "progession", "seniority" or natural reporting hierarchy between different architecture roles. These things do exist, but they are independent of the varying roles that architects naturally have.

The architect may be any combination of client, project overseer, inspector, trouble-shooter and builder as well as some combination of visionary, designer, problem solver and mentor. No single body of knowledge or expertise defines the architect. There is no single role: some architects spend time getting their hands dirty, and others spend most of their time drawing “big picture” views of an enterprise’s whole IT portfolio.

“Architecture” is certainly not defined by job title. Some organisations or projects have no named architects but a good architecture, others have many people called "architects", but few with the right attitude and mindset.

The architect may deal with either “architecture” or “design”. Architectural attitudes and approach are equally important inside a component’s interface as outside it – this is just a different stage in the same process.

Ask a building user or owner about architecture, and they are interested in two main things: the "grand design" (i.e. the big ideas, the overall form of the solution), and the "visible design" (how it looks, and how it actually works in day to day interaction with its users and the environment). The architect's primary concern is to deliver a solution on these two levels which firstly meets the objectives of the various stakeholders, and secondly provides sufficient guidance so that it can be built in line with "the architecture".

It's not actually the architect's job to know about plumbing, except to understand how plumbing contributes to the overall set of requirements and constraints. Likewise IT architecture is about a lot more than "plumbing". It has three major aspects:

• The "grand design" and how it (the solution) meets the various stakeholder objectives,
• The structure which underlies the "grand design", and how it will meet the quality requirements (adaptability, performance etc.),
• The "visible design", and how its users will understand it. Different aspects of "visible design" matter to different people. For an end user, it's the user interface. For programmers, it's the design patterns and overall class structure. For both the architect delivers a vision, and a clear set of consistent metaphors and guidelines.

All architects, and especially agile ones, must embrace this visionary role, focusing on how the solution delivers real value to the users, and how the system's structure meets the needs of all the stakeholders.