Many agile teams find that they need someone in the role of "architecture owner", often the most technically experienced person on the team, who is responsible for facilitating the architectural modeling and evolution efforts.  Just like the product owner is responsible for the team's requirements, the architecture owner is responsible for the team's architecture.  Architecture owners are the agile version of the traditional role of solution/software architect -- in fact the best solution architects are very close to architecture owners in practice anyway.  In many ways an architecture owner is simple a solution architect who focuses on facilitating the evolution of the solution architecture over time instead of trying to formulate the detailed architecture early in the lifecycle then dictate it to the rest of the team.  Architecture owners take an approach which is collaborative and evolutionary, not command-and-control and certainly not serial.

What Architecture Owners Do

People in the role of architecture owner will focus on:

1. Facilitating creation of the architecture, not enforcing it.  In the past the architect would often be the primary creator of the architecture and would be one of the few people who worked on it.  They would often develop the architecture and then "present it" to, or more accurately force it upon, the development team.  An architecture owner collaboratively works with the team to develop and evolve the architecture. 
2. Transitioning architectural skills to other team members. Architecture owners typically have critical, "senior IT" skills, the type of skills which less senior IT people would like to gain.  So, good architecture owners will focus part of their time on mentoring others, finding opportunities to pair with others, and even running IT education and training sessions such as formal classes or brown-bag lunch sessions. 
3. Architectural spikes.  An architectural spike is a technical risk-reduction technique popularized by Extreme Programming (XP) where you write just enough code to explore the use of a technology or technique that you're unfamiliar with.  For complicated spikes architecture owners will often pair with someone else to do the spike.
4. Mentoring team members in organizational technical guidance.  Architecture owners are aware of, and often authors of, organizational technical guidance around coding guidelines, database guidelines, security guidelines, and so on.  They will help to bring this valuable knowledge to the team, mentoring them in its appropriate application. 

Secondary priorities of architecture owners include: Breaking decision "deadlocks".  Although architecture owners work collaboratively with other team members, and many times the team will come to consensus regarding an architectural decision, sometimes the team doesn't come to an agreement.  In these cases the architecture owner should break the deadlock so that the team can move forward. Reviewing architectural work from other teams.  Although reviews are arguably process smells, the reality is that many organizations still hold architecture/technical reviews.  The implication is that someone on your team may need to invest time being involved with the such reviews, and this task often falls to the architecture owner.

Architecture Owners at Scale

Figure 1 depicts a typical organization structure for a large agile team.  The subteams will be organized either around the architecture of the system (a component team approach), around the requirements (a feature team approach), an internal open source strategy, or combinations there of.  Regardless, each of the subteams will need to have access to a product owner (although any given product owner could work with more than one subteam).  In such situations architecture owners will collaborate with the architecture owners on other subteams to help evolve the overall architecture of the system of systems.  Large agile teams, often referred to as programmes, will often have an architecture owner team, comprised of the architecture owners of the various subteam.  This team will be responsible for the initial architecture envisioning at the beginning of the project and for coordinating significant architectural decisions within the overall team.  This coordination is typically performed as collaboration between the architecture owners on the appropriate subteams with the assistance of others from the subteams as appropriate.  The architecture owner team will often be lead by a "chief architecture owner" who is responsible for coordinating the architecture efforts of the overall program.

Figure 1. Organization structure of a large agile team.

As the Agile Scaling Model (ASM) advises, there is more to agility at scale than just large agile teams.  In addition to geographic distribution, domain complexity, regulatory compliance, technical complexity, and several other agile scaling factors there are also enterprise disciplines such as enterprise architecture to consider.  As a result architecture owners will often participate with program or enterprise-level architecture efforts.  To do this architecture owners will work closely with enterprise architects (EAs), and may even be part of the enterprise architecture team, to ensure that their team leverages enterprise assets and strategies appropriately. Figure 2 depicts an agile enterprise architecture strategy where the EAs interact with the application teams which they support.  The EAs may often take on the role of architecture owner on the application teams (or chief architecture owner on large teams).

Figure 2. Agile Model Driven Development (AMDD) at the enterprise level.

Why Architecture Owners?

For any reasonably complex system you're going to need to invest some time architecting it.  First you'll do some up front architecture envisioning to get you going in the right direction and then you'll need to evolve the architecture over time as your project progresses.  Although it's convenient to believe that a Disciplined Agile Delivery (DAD) team will always be in agreement as to the architecture of the solution, the reality is that many agile developers are smart, strong-willed people and teams of such don't always come to agreement.  Someone needs to lead/facilitate the team with regards to the evolution of the architecture.

Speaking about leadership, the person in the role of team lead (what Scrum refers to as a "Scrum Master", see Translating Scrum Terminology for what I think about this inane term) will often also be in the role of architecture owner.  This isn't always the case, particularly at scale, but it is very common for smaller agile teams.

Recommended Resources

		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Let Us Help

We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer.  A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.