From: http://www.disciplinedagiledelivery.com

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.

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.

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.