Disciplined Agile

Enterprise Architecture Team Structures

There is no one right way to organize an enterprise architecture (EA) team, your approach must be driven by the context of the situation that you find yourself in. We present three strategies that we’ve seen work in practice. Each of them describe a potential starting point from which you can tailor an approach that makes sense for your context. The three strategies are:

  1. Collaborative enterprise architecture team
  2. Enterprise architecture service team
  3. Large enterprise architecture team

Collaborative Enterprise Architecture Team Structure 

This structure is used to collaboratively support Disciplined Agile® Delivery (DAD) solution teams. Every DAD team has someone in the role of architecture owner (AO), sometimes called an agile solution architect or simply an agile architect. This person is responsible for guiding the team through architectural decisions and for mentoring and coaching other team members in architecture and design skills. An AO should have a solid understanding of your organization’s enterprise architecture and be willing to collaborate closely with the enterprise architecture team. With the collaborative EA team structure, AOs are members of the enterprise architecture team. Figure 1 shows how an AO is a member of a delivery team and a member of the enterprise architecture team at the same time.

Team Enterprise Architecture

Figure 1. A collaborative enterprise architecture team. 

A few important observations about this team structure:

  • The team is led by someone in the role of Chief Enterprise Architect. This person may or may be working as a member of a delivery team. They often spend much of their time collaborating with senior stakeholders across your organization.
  • Sometimes a given person performs the role of AO on several teams, often due to lack of staff with agile architecture skills. Note that this is generally believed to be poor practice as the person will quickly become a bottleneck.
  • There may be enterprise architects who are not currently working with solution delivery teams. This occurs in organizations where the architecture work is sufficiently complex to require people focused on that or because there are more architecture-skilled people available than are currently needed by solution delivery teams.
  • Some teams may not have someone in the role of AO, once again due to a shortage of skilled people. 

The AO will spend most of their time (90-95%) working with one or more delivery teams and the remainder working performing enterprise architecture activities. There are several strategies that you can consider for determining who will be on EA team:

  1. Delivery teams nominate their own architecture owners. This person must then become part of the EA team. The primary advantage is that this person will already be a respected member of the delivery team. The potential downside is that they may not yet have the skills required to be an effective enterprise architect.
  2. The enterprise architecture team nominates someone to be an architecture owner. The advantage of this approach is that the person will have enterprise architecture knowledge and experience. The potential disadvantages are that the person may not fit well on the delivery team, the team may already feel that it has someone in this role, and that the enterprise architect may not yet have the skills required to be a productive member of the delivery team. This top-down approach only works well with agile teams when the person being added to the team is both known and respected by them.
  3. Each team nominates someone to work with the other team. With a holocracy-based approach, when there is a need for two teams to collaborate with one another over a period of time each team nominates someone to work with that other team. This helps to ensure that the priorities of both teams are addressed and ensures more effective communication between the teams, although has the drawback of requiring more people split across teams.

This collaborative team structure is typically used by:

  • Architecture-oriented organizations. This strategy is common in organizations willing to make a significant investment in enterprise architecture.
  • Large programs. In this case it ends up being an architecture owner team for the program, or a program architecture team, and not a true enterprise architecture team. 

Enterprise Architecture as a Service Team 

Figure 2 depicts what we call the “EA service team structure.” In this case stakeholders from external teams will submit a request for the EA team to do some work. These are typically requests to review their work or to provide some guidance on an architectural issue. The enterprise architect(s) will address the requests in priority order, often working in a Kanban-style manner. 

Small Team

Figure 2. Enterprise architecture as a service team. 

The EA service team approach is common when EA teams are starting out or when they aren’t adequately funded to fully support the teams they are tasked to serve. Although it is possible to keep this lightweight, and that is often a necessity due to funding constraints, it can sometimes devolve into a review-based, documentation heavy approach. Furthermore, due to understaffing the enterprise architects rarely have the time to coach others in architectural skills. In extreme situations the EA team becomes a bottleneck for the solution delivery teams waiting for help from them.

Large Enterprise Architecture Team Structure

Very large organizations, often those with thousands and sometimes tens of thousands of people in solution delivery teams, need a more sophisticated approach to organizing their EA team. In these situations, they tend to have a multi-level approach. For example, we worked with one organization that is taking a three-level approach to the collaborative team strategy described earlier. The first level is enterprise architecture for the line of business within a specific geographic region (e.g. retail banking in Europe), the second level for the geographic region (e.g. Europe), and the third level for the overall organization.   

With this strategy someone is an AO on a delivery team and a member of the first level EA team. The chief EA of the first level team is a member of the second level team for their geographic region, and the chief EA of that team is a member of the organization-level EA team. In short, this multi-level EA team structure reflects the overall organization’s structure. 

Context Counts 

Each EA team structure described above has advantages and disadvantages. No one approach fits all situations, and as the context of the situation that you face evolves over time so will the structure of your enterprise architecture team.