Successful EA Governance is Collaborative, Empowering, and Accelerates Time to Value

Today we will talk about Enterprise Architecture governance. We want to shift away from a policing function to shift to as much of a self-governing governance strategy. Traditionally, Architecture Review Boards (ARB) were used exclusively for this work. There's an opportunity to be more effective and get the much needed adoption to drive results. I want to break that model with the introduction of an Architecture Guidance Team (AGT) combined with an ARB and Architecture Engagement Services (AES).

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 principles, policies, standards, reference architectures, and architectural guidance. 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. 

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

1. Architecture Review Board – Business Decision Makers (BDM) and Tech Decision Makers (TDM) with the ultimate decision rights approves solutions based on risk mitigation, business need, and strategic value.

2. Architecture Guidance Team (AGT) – This team defines the principles, policies, standards, reference architectures, frameworks, and architecture guidance that is published to an architecture repository for consumption by the architecture community and ARB.

3. Architecture Engagement Services (AES) – EA or SA’s that enables business value creation through architecture definition, embraces AGT resources and expert network, and facilitate ARB approvals.

Using Democracy as the Model for Governance

To further explain this concept I use an analogy that I have used for almost 15 years that really resonates with folks.

Let's dig deeper on why using the US government as a parallel to EA governance model is valuable and how this can be a way of communicating archtiectural governance in terms all of us understand.

Architecture Review Board as the Judicial Branch, Architecture Guidance Team (AGT) as the Legislative Branch, and Architecture Engagement Services (AES) = 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:

1. Judge It - Review and make rulings on problems by analyzing the law or providing interpretation of the law. Ideally ARB's should have limited power that focuses on business outcomes-led decision making, not to create the laws.

2. Standardize It - Senators creates the laws for federal, state, & local based on the current & future needs of the citizens. For EA, Specialists Architects or Domain Architects create the Principles, Policies and Standards for ARB and AES..

3. Execute On It - The executive branch puts laws into motion, challenges laws, and in some circumstances creates executive orders to drive results. AES provides architecture rigor that drives business outcome-led results through defined initiatives.

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)

Often times, an Architecture CoE is part of the AGT or closely linked. The CoE tends to focus skills and competencies, while the AGT offers more more holistic view with an execution arm of architecture specialists. While not the most efficient, these functions roles can overlap—collaboration ensures consistent messaging and the avoidance of duplicated effort.

Alignment with Security / Data Governance Councils

This is another case where these councils are included under the same umbrella as the AGT. Security or Data Councils may define deep vertical standards (e.g., data classification models, encryption protocols). It's critical to make sure the AGT is holistic in nature to have a fully rounded set of principles, policies, and standards that share the same strategic oginizational goals. Tightly weaving in security and risk is foundational to all architecture work.

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

#1 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.