The Architecture Owner Role: How Architects Fit in on Agile Teams

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 simply 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.This article is organized into the following topics:

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 initiative 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”) 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. This person would need to have both the skills of an AO as well as a team lead to be successful doing so.

What Architecture Owners Do

People in the role of architecture owner will focus on:

Facilitate creation of the architecture, not enforce 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.
Coach other team members in architecture skills and thinking. Architecture owners typically have critical, senior skills, the type of skills which less senior 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 education and training sessions such as formal classes or brown-bag lunch sessions.
Advise the product owner in technical priorities. Disciplined agile teams recognize that the people who will evolve and maintain the solution over time (and that may be them) are important stakeholders whose needs must be taken into account. As a result, architecture owners will work closely with whomever is responsible for prioritizing the work, which on Scrum-based teams is the product owner, to ensure that long-term architectural concerns are taken into account when the work is being prioritized. Figure 1 depicts the relationship between the “leadership triumvirate” on an agile team.
Build 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. Architecture owners will often pair with someone else, or “mob” with several people, to do the spike so as to transfer skills on knowledge between people (including themselves).
Mentor team members in organizational architectural guidance and roadmaps. Architecture owners are aware of, and often authors of, organizational guidance around coding guidelines, database guidelines, security guidelines, and so on. They should also be familiar with any architectural roadmaps produced by your organization’s enterprise architects. They will help to bring this valuable knowledge to the team, mentoring them in its appropriate application.

Figure 1. Agile team leadership.

Agile Team Leadership

Secondary priorities of architecture owners include:

Break 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.
Review 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

As the way of working (WoW) tailoring factors advises, there is more to agility at scale than just large agile teams. Table 1 summarizes the potential affect of various tailoring factors on your approach to agile architecture. Given that any team will face all of these tailoring factors to some extent, the implication is that architecture owners need to be capable of tailoring their work approach to the sitaution that they face.

Table 1. Agile architecture at scale.

Tailoring Factor	Issue	Potential Impact on Your Architecture Way of Working (WoW)
Team Size	Agile teams may be as small as two people or may grow into the hundreds. Note that teams will grow in size due to other tailoring factors, in particular domain complexity, solution complexity, geographic distribution, and organizational distribution.	As a team grows in size, the collaboration strategies required to make them work will grow in complexity. For example, within a small team conversations will often suffice. Within a large program, each subteam may have their own architecture owner (or an AO will be split across several teams). The AOs within the program will need to adopt collaboration strategies between then so as to evolve the architecture.
Geographic Distribution	Agile teams may be co-located throughout the world or distributed around the globe.	As a team becomes more geographically dispersed: It will need to adopt increasingly sophisticated tooling to support collaboration. For example, in a co-located team the architecture can be captured via inclusive modeling tools such as whiteboards and sticky notes. As geographic distribution increases the team will need to adopt digital collaboration tools such as Miro or Mural to capture their architecture models. Communication will become more and more asynchronous, motivating the need to capture the architectural strategy as documentation will increase.
Domain Complexity	Agile teams take on straightforward to very complex problems.	Straightforward domain problems can typically be addressed using simple requirements artifacts, such as user stories and epics. Quality of service (QoS) requirements will also need to be captured in some manner, and domain complexity will often increase as the result of more challenging QoS requirements. To support increasing complexity you are likely to create various agile requirements diagrams to explore the complexity.
Solution Complexity	Agile teams may work on greenfield, single-platform solutions to multi-platform legacy technologies.	Let’s consider common levels of solution complexity to understand the impact on your WoW: New stand-alone solution. All of your architectural challenges will be contained within your team, enabling you to adopt straightforward strategies for dealing with them. You will likely be able to work with relatively simple agile architecture models. New integrated solution. Your solution needs to integrate with other systems, either accessing functionality and data from them or providing functionality and data for them. You may need to produce some form of agile application programming interface (API) documentation. Legacy solution. Many teams find that they need to either extend or replace an existing legacy solution. The simplest form of this challenge is a single-platform system, such as a stand-alone application. You may need to perform legacy system analysis to understand the system before you are able to safely evolve it. Multi-environment legacy solution. This is a solution that is built using multiple technologies, often over many years by many different people. Analysis of these legacy systems will potentially be challenging, particularly if you don’t have access to the people involved with building and maintaining them in the past. You are likely to require sophisticated architecture models and skilled architecture owners to succeed in this environment.
Skill Availability	Agile team members with the required skills and knowledge may be readily available or may be very difficult to obtain.	A few important considerations: You rarely have immediate access to all the people that you need who together have sufficient skills and experience in all of the architectural issues that you will face. If you choose wait for those people to be available then your team will need to put off any work that requires people with a specific background. If you choose to train and educate existing staff, or hire new staff, to gain the missing skills and knowledge that will take investment and will impact your schedule. Architecture owners don’t need to have every single skill, or deep knowledge of every technology or technique. They should have at least a general knowledge and be willing to work with, and learn from, people with deeper knowledge about various topics.
Compliance	Agile teams may work in non-compliance situations to life-critical compliance situations.	Let’s consider common levels of compliance to understand the impact on your WoW: Informal. This is the simplest form of compliance in that your team basically agrees to follow common guidance and roadmaps produced by other areas of your organization (such as your enterprise architecture team). Internal oversight. With this approach there are one or more governance/audit groups within your organization that you must collaborate with to ensure that your team is following internally developed guidance and roadmaps. This may range from simple collaboration with these groups to informal reviews by these groups and even to formal reviews. Your team will need to identify what architecture artifacts are required to support this oversight. My advice is to create such artifacts only if they add value to your initiative, otherwise question their validity. External WoWs. Your organization may have willingly chosen to adopt industry standards, guidelines, or process frameworks such as CMMI or ITIL. This is often done in the hope of improving your WoW or for marketing purposes (your customers may expect such compliance). As a result your internal oversight may require compliance to these adopted WoWs and this in turn may affect the types of architecture artifacts that your team creates. Regulatory oversight. Your organization is in a regulated industry where various forms of regulation around financial, privacy, security compliance and so is applicable. You will have both internal oversight to ensure compliance as well as the potential of an external audit. This will likely require you to create auditable architecture artifacts (very likely including sophisticated change control processes). Existential (life-critical). Examples of life-critical regulations include the FDA regulations around drug and medical device development and the ISO standards for automotive development. Your WoW will be focused on ensuring quality and safety and proving that you’re doing so. It is possible, and highly desirable, to apply agile WoW in such situations.
Organizational Distribution	Agile team members may come from a single group within your organization or from multiple organizations (contractors, consultants, and service partners).	Let’s consider common levels of organization distribution to understand the impact on your WoW: Startup. Startup teams, including teams starting to develop new solutions in existing organizations, tend to work in a highly collaborative manner. Single organization. When everyone works for the same organization you may face difficulties working together due to political or organizational issues (such as silo groups). Hopefully everyone is focused on the long-term success of the organization and are eager to see an appropriate architecture strategy followed. Paid partners. In this situation you have contractors or consultants from external organizations involved. The way that you work with them will be determined by the contract(s) under which they are working. Ideally these people will bring skills and experiences to the team that you would not have otherwise found within your organization. Coalition partners. In this situation several organizations are working together to produce a shared solution to bring to market. Once again, the contracts will affect how you work together. Architecture work will likely involve people from each organization and any artifacts will need to be shared across the organizations.

Architecture Owners In Programs

In 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 programs, 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 initiative 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.

Architecture Owners and Enterprise Architecture

In addition to geographic distribution, domain complexity, regulatory compliance, technical complexity, and several other WoW tailoring factors there are also enterprise disciplines such as agile 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.