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.

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.