Agile Enterprise Architecture Team Structures

We learned in a previous blog posting, The Mindset of a Disciplined Agile Enterprise Architect, that disciplined agile enterprise architecture (EA) teams work in a very collaborative manner, evolving their artifacts over time based on their learnings.  But how do you organize an enterprise architecture team so that it can be agile?  Answering this question is the goal of this posting.

As you would expect, the answer is “it depends”.  There is no one right way to organize an enterprise architecture team, your approach must be driven by the context of the situation that you find yourself in.  We start with the strategy that we call the “hands on” approach because members of the EA team are also members of IT delivery teams.  We then describe a small EA team approach, a common strategy when you are first getting your team in place or when the team doesn’t have the funding required for the hands-on approach.  We end with a discussion of how to go about this in very large organizations.

The “Hands On” Team Structure

Every DAD team has someone in the role of architecture owner (AO), sometimes called an agile solution architect or simply 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 technical and business roadmaps, if they exist, and be willing to collaborate closely with the enterprise architecture team.  With the “hands on” EA team structure, AOs are members of the enterprise architecture team.  The following diagram shows how an AO is a member of a delivery team and a member of the enterprise architecture team at the same time.

Disciplined Agile Enterprise Architecture Team Structure

A few important observations about the “hands on” team structure depicted above:

  • The team is led by someone in the role of Chief Enterprise Architect (we’ve referred to this as Chief Architecture Owner in the past).  This person may or may be working as a member of an IT 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 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 IT delivery teams.
  • Some delivery 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.

The “hands on” 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.

The Small Enterprise Architecture Team Structure

The following diagram depicts what we call the “small EA team structure.”  In this case 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 Enterprise Architecture Team Structure

This small EA team approach is common when EA teams are starting out or when they aren’t adequately funded to have people on every IT delivery team.  Although it is possible to keep this lightweight, and that is often a necessity due to funding constraints, it can sometimes devolve in to 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 IT delivery teams waiting for help from them.

The Multi-Level Enterprise Architecture Team Structure

Very large organizations, often those with thousands and sometimes tens of thousands of people in IT, need a more sophisticated approach to organizing their EA team.  In these situations they tend to have a multi-level approach.  For example, we have one customer who is taking a three-level approach to the hands-on team strategy described earlier.  The first level is enterprise architecture for the line of business within a specific geographic region (i.e. retail banking in Europe), the second level for the geographic region, and the third level for the overall company.  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 in this blog 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.

Related Readings

Have any Question or Comment?

8 comments on “Agile Enterprise Architecture Team Structures

Duane Banks


You mentioned solution architect, but not business, application, or data architect. Are you lumping all architecture roles under the EA umbrella, either of which that can be assigned to a project team as an AO?


Yes, enterprise architects are multi-disciplinary. They need to be able to consider the full range of issues to be effective.

Terry Hamilton

Although EA’s may IDEALLY be multi-disciplinary that isn’t always true. However I would think if you are in an organization where there are separate Architecture domains or one where an individual fulfills multiple or all roles the structures in this article would still apply.

If there are multiple domains then each Architecture domain owner would likely report up 1 more level to the Enterprise level.


I should have said that disciplined agile EAs are multi-disciplinary.

You’re right, there are many people claiming to be enterprise architects whom are focused on a specialty, such as data, security, or networking. But I struggle to consider them enterprise architects. They might be enterprise domain architects as you point out, which is fine, but that’s just one step into becoming a full-fledged enterprise architect.

Duane Banks

Ok, so that’s what you consider the difference between traditional EA and DAD EA (referencing our exchange from another article in the series), that the latter requires a multi-disciplinary EA approach. And you’re saying that DAD EAs are full-fledge enterprise architecture. Correct?


I wouldn’t consider a specialized architect, say someone who calls themselves an enterprise data architect or an enterprise security architect, to be a full-fledged enterprise architect. This is regardless of them working in an agile manner, a traditional manner, or some other way.

It may be that they are on the learning path to become an enterprise architect, but they’re not there yet. An enterprise architect needs to understand the enterprise, and to do that properly they need to consider a range of viewpoints, not just a specialized viewpoint.

Being an enterprise architect is a tough job.

Duane Banks

Allow me to re-phrase…

You’re saying that the sub EA disciplines–solution, business, data, security, etc–doesn’t really have a place in DAD architecture, only full-fledge EAs. Is that correct?


No, not at all.

What I’m saying is that I wouldn’t consider a sub-EA person to be a full-fledged EA. That’s a starting point, but they need to work on gaining a wider range of skills. This will take time and will require them to work closely with others that already have those skills so that they can learn them too.

DAD isn’t prescriptive. It doesn’t say “thou shalt do this” or “thou shalt organize in this way”. DAD does give you options. DAD does motivate you to choose better options. People in the enterprise architecture role who consider a range of viewpoints are generally more effective than those who are narrowly focused on a specialty.

Having said that, you “go to war with the army that you have.” So, if you currently have architects who are specialized then those are the people that you have. As you move to a more disciplined agile manner of working, part of that move will be finding ways to motivate the architects to broaden their horizons. Having them work as active members of agile delivery teams is one way to do that. Having them collaborate regularly with other architects to share their learnings is another way. Making them aware that they should adopt a learning mindset so that they can grow as individuals is another part of the solution.

Leave a Reply

Your email address will not be published. Required fields are marked *