Successful Enterprise Architecture uses an Architecture Guidance Team (AGT) and Architecture Review Board (ARB) Together

As you begin to develop your enterprise architecture capability you will find yourself in a sea of complexity of different approach. Often times the question comes up early around how much should an ARB really do?

Blending the decision making authority with the rules and policy authority introduces a great deal of conflict of interest. When combining these functions the group loses focus and mixes standards setting with the job of an ARB composed of senior leaders and decision makers.

The Architecture Guidance Team (AGT) is chartered to provide direction and advisory support on architectural practices, patterns, and standards. While an Architecture Review Board (ARB) might be the final decision-maker on whether a given solution conforms to enterprise standards, the AGT’s upstream role is to ensure that solution teams and architects have clear, actionable guidance long before formal reviews occur.

Below, I have outlined a model that shows how to execute an architecture governance structure that I have used in my past EA organizations and plan to continue to use on a going forward basis with my EA organization.

Architecture Review Board Governance Relationships — The three main governance functions with each one with a very specific purpose.

In many organizations, the AGT is the thought leadership hub for emerging technologies, industry trends, and best practices. It provides a research and advisory function by evaluating market shifts, experimental approaches, and new frameworks, then distilling them into policies and guidelines that align with business strategy.

Three Important Governance Constructs

Enterprise Architecture Goverenance Functions

Architecture Review Board – Validates and approves solutions based on their alignment to the strategic imperatives of the organization.
Architecture Guidance Team (AGT) – This team defines the principles, policies, standards, frameworks and solution guidance that is published to an architecture repository for consumption by the architecture community and ARB.
The Office of Enterprise Architecture or Architecture Engagement Services – The enterprise architecture organization facilitates and drives many of the governance functions. While Enterprise, Domain and Solution Architects are not the sole decision makers, given the distributed domain model, they are the thought leaders in the organization to be the agents of change.

An Analogy

To further explain this concept I use an analogy that I have used for the past 5 years that really resonates with folks is using the US government as a parallel to this governance model. See below:

Enterprise Architecture Analogy to US Government — Architecture Review Board as the Judicial Branch, Architecture Guidance Team (AGT) as the Legislative Branch, and The Office of Enterprise Architecture or Architecture Engagement Services = Executive Branch

You can see a ton of similarities here. I break these three forms of government into the following activities of the EA function:

Judge It - This area goes into the governance activates of an Architecture Review Board (ARB). Ideally ARB's should have limited power and only have the ability to review architectures not to create the laws (i.e., standards).
Standardize It - When we talk about standardization this is the activity that forms virtual teams of domain stakeholders to build what is commonly referred to as Principles, Policies and Standards.
Execute On It - The executive branch in reality is the "commander chief" that is the official spokesman and stimulates action in time of need. Likewise with EA's on strategic projects and management of future strategies.

Like with all analogies it's not 100% accurate but it can be a power tool to convey a message. However, the point of the analogy is not for communicating with people whom already understand EA but rather others such as developers, business representing or senior IT decision makers.

So what's the point here for EA's? Being able to articulate your function and purpose to your audience in terms they understand will greatly help you in your endeavors. This allows your audience to understand what you do and how you can help them. On the flip side, if they do not fully understand your role there is a good possibility that they will not engage. This isn't because they want to, but because they do not know that they should.

What this model provides us with is a clear separation of duties but also ensures that the right people are in the right governance function. When we look at the ARB, we want to have senior IT decision makers in the room evaluating and validating designs to ensure alignment. If we had subject matter experts in the ARB, the room could be filled with a lot of people and a lot more opinions. The ARB should be a tight group of leaders of no more than 10 –12 voting members.

The AGT on the other hand, should be filled with SME’s as they best know the technology sets and most likely will be accountable for them as well. The reverse is true for the ARB members. We wouldn’t want senior decision makers driving a platform or protocol standard.

In a future post I will detail out these members, how it all fits together and their roles and responsibilities.

Engagement with Other Governance Bodies

Collaboration with the ARB

Pre-ARB Pipeline: The AGT can act as a first line of defense, ensuring project teams are well-prepared for formal reviews.
Issue Escalation: If a project’s needs fall outside current standards, the AGT may escalate the exception request to the ARB, providing context and recommendations.
Feedback Loops: When the ARB notices recurring issues, it can feed those insights back to the AGT. The AGT, in turn, updates reference architectures or design patterns accordingly.

Relationship to a Center of Excellence (CoE)

In many enterprises, an Architecture CoE and the AGT are either synonymous or closely linked. The CoE tends to focus on long-term strategic capabilities and community-building, while the AGT offers more hands-on, solution-level guidance. However, roles can overlap—collaboration ensures consistent messaging and the avoidance of duplicated effort.

Alignment with Security / Data Governance Councils

Security or Data Councils may define deep vertical standards (e.g., data classification models, encryption protocols). The AGT takes those specialized standards and packages them into practical, easily consumable guidance for solution teams, ensuring broad compliance.

Critical Success Factors

Clear Charter and Mandate

An AGT needs executive sponsorship and a clearly defined purpose:

Are they primarily consultative, or can they enforce standards?
Do they own reference architectures, or only contribute to them?
How do they measure success (e.g., reduced ARB escalations, faster project ramp-ups)?

Continuous Communication

Frequent communication channels (Slack, Teams, or a dedicated knowledge portal) help maintain open lines for questions, feedback, and collaborative design. The AGT should be seen as a friendly ally to project teams, not an isolated ivory tower.

Broad Influence, Minimal Bureaucracy

Effective AGTs strike a balance between influence and agility:

They have enough authority (via leadership endorsement) to shape the direction of solution teams
They don’t create overly burdensome processes that slow project delivery
They rapidly evolve their guidance as new technologies and requirements emerge

Tangible Outcomes and Metrics

Tracking metrics can prove the AGT’s impact:

Adoption rate of published reference architectures or design patterns
Number of exceptions that get escalated to the ARB
Cycle time from project inception to initial architectural sign-off
Stakeholder satisfaction through surveys or feedback loops

Keeping it all in Sync

As you can see from the first model of how all of these functions interact there is somewhat of a lifecycle we are defining with regards to the technology life cycle of the technology portfolio and the architecture repository of knowledge. Since the AGT and the ARB are tightly connected and have integrated processes and transparency the knowledge gathered by both bodies is integrated as well. This in turn keeps this information base always up to date without a separate function in charge to constantly chase people down for information.

Key Responsibilities

Developing and Maintaining Reference Architectures

The AGT is typically responsible for documenting and evolving reference architectures—the high-level structural guidelines that solution teams can follow to ensure consistency.

These reference architectures cover but not limited to :

Technology platforms
AI Libraries
Integration patterns (e.g., microservices, API gateways, event-driven)
Security baseline (e.g., identity management, encryption)
Data architecture principles (e.g., data lakes, data governance models)

Providing “Pre-Review” Guidance

A well-functioning AGT helps projects avoid surprises at the ARB by engaging early:

Offering design clinics or “office hours” where teams can ask questions about architecture decisions
Conducting informal reviews or solution workshops to catch potential misalignments in advance
Sharing templates, checklists, and design patterns that streamline compliance and speed time-to-market

This approach reduces friction and cycle time later in the governance process.

Training and Community Building

Another significant role of the AGT is architectural enablement:

Training sessions, webinars, or lunch-and-learns on new architectural concepts
Maintaining a knowledge repository of best practices and “lessons learned” from previous projects
Fostering a community of practice (CoP) among solution architects, domain architects, and engineering leads to promote ongoing knowledge-sharing

Innovation Incubation

In some organizations, the AGT also pilots emerging technologies or patterns to validate feasibility, performance, and business value. By doing so, the AGT can provide data-driven recommendations to the broader enterprise on whether (and how) to adopt new approaches.

Maintaining all the AGT Artifacts

You will need a librarian, an ownership model and stewardship thought through but these activities should be light since we are updating this base as an output and/or input to our enterprise processes.

An added benefit to this model as well is the traceability aspects. When using an Architecture Repository (like defined by TOGAF) as your main way to validate projects tracing back to business capabilities, goals and objectives is very achievable.

Final Thoughts

The Architecture Guidance Team can be a powerful enabler for consistent, high-quality architectural decisions across an organization. By setting clear roles, focusing on practical and timely guidance, and collaborating closely with other governance bodies (especially the ARB), the AGT ensures that project teams benefit from deep expertise before they reach formal review gates.

When empowered with the right authority, staffed with skilled architects, and embedded in the organization’s project lifecycle, the AGT bridges the gap between enterprise strategy and day-to-day project execution. Through this function, enterprises can reduce technical debt, accelerate time to market, and align technology investments with strategic business outcomes.