The Architecture Owner Role: How Architects Fit in on Agile Teams
- Why architecture owners?
- What architecture owners do
- Architecture owners at scale
- Architecture owners in programs
- Architecture owners and enterprise architecture
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.
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.
|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:
|Domain Complexity||Agile teams take on straightforward to very complex problems.||
|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:
|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:
|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:
|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:
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.