The Architecture Committee: The Secret Organization Behind Enterprise Architecture Governance

What is an Architecture Committee?

Many have heard the term but not know its meaning. In short, an Architecture Committee is the mysterious internal group responsible for architecture governance.

It can be a formal committee with charter and regular meetings, an informal loose group of architects meeting periodically, or a virtual team communicating via Slack/DingTalk.

Why is an Architecture Committee needed?

Problems without a committee

Problem 1: Technology stack chaos

Team A uses MySQL, Team B uses PostgreSQL, Team C uses MongoDB, Team D uses Oracle → maintenance cost doubles, hiring becomes difficult

Problem 2: Duplicate effort

Team A builds a task‑scheduling framework, Team B builds another, Team C builds another… → resource waste, code duplication

Problem 3: Architecture decay

System 1: clean architecture, excellent design
System 2: decent architecture
System N: spaghetti code, legacy system nobody dares to touch → technical debt accumulates

The value of a committee

Unified technical standards – avoid stack chaos

Shared technical assets – prevent duplicate effort

Architecture governance – control decay

Technical direction – guide technology evolution

Talent development – cultivate architects

Composition of the committee

Typical structure

┌─────────────────────────────────┐
│ Architecture Committee           │
├─────────────────────────────────┤
│                                 │
│   ┌─────────────────────────┐   │
│   │ Chair (Chief Architect) │   │
│   │ Responsible for overall │   │
│   │ direction and decisions │   │
│   └─────────────────────────┘   │
│                                 │
│   ┌───────────┴───────────┐       │
│   │                       │       │
│   ▼                       ▼       │
│ ┌─────────┐   ┌─────────┐       │
│ │Domain   │   │Platform │       │
│ │Architect│   │Architect│       │
│ └─────────┘   └─────────┘       │
│   - User domain   - Infrastructure│
│   - Order domain  - Middleware    │
│   - Product domain- Security     │
│                                 │
└─────────────────────────────────┘

Roles and responsibilities

Chair – overall direction, final decisions (1 person)

Domain architects – architecture for each business domain (3‑5 people)

Platform architects – public platform architecture (2‑3 people)

Executive secretary – organize meetings, record minutes (1 person)

Member selection

Selection criteria : technical depth, architecture experience, communication ability, influence, business understanding.

Selection methods : nomination, election, appointment.

Committee responsibilities

Core duties

1. Architecture review

New system architecture review
Major change review
Technology selection review

2. Standard definition

Technical standards
Design guidelines
Coding conventions

3. Architecture governance

Architecture decay monitoring
Technical debt management
Architecture evolution planning

4. Shared platform construction

Public components
Technology middle‑platform
Infrastructure

5. Technical direction

New technology evaluation
Technology roadmap
Technical pre‑research

Daily work

Regular meetings (weekly or bi‑weekly) – review, discussion, decision

Review meetings (on demand) – new architecture reviews

Inspections (monthly) – system architecture checks

Sharing sessions (monthly) – technical sharing

Planning meetings (quarterly) – technology planning

Decision process

Decision types

Advisory – suggestions, not mandatory (architects)

Approval – must be approved to execute (committee)

Mandatory – enforced execution (senior leadership + committee)

Decision workflow

Proposal → Initial review → Discussion → Vote → Decision → Execution → Retrospect

Example meeting agenda

# Architecture Committee Meeting Agenda
## Time: Every Wednesday 14:00
## Duration: 1.5 h
## Participants: All members
## Agenda
### 1. Follow‑up of last week’s actions (15 min)
- [ ] Action 1 – Owner – Status
- [ ] Action 2 – Owner – Status
### 2. Review session (45 min)
- Review: XXX system architecture
- Review: YYY technology selection
### 3. Discussion (20 min)
- Discuss: Technical debt mitigation
- Discuss: Q2 technology plan
### 4. Sharing (10 min)
- Share: Micro‑service governance experience
### 5. Others (5 min)
- Next week’s schedule
- Adjourn

Architecture review workflow

┌─────────────────────────────────────────┐
│ Architecture review request               │
│ (initiator submits materials)            │
└───────────────────────┬─────────────────┘
                        ▼
┌─────────────────────────────────────────┐
│ Formality check                         │
│ (secretary verifies completeness)       │
└───────────────────────┬─────────────────┘
                        ▼
┌─────────────────────────────────────────┐
│ Pre‑review                              │
│ (assign review experts)                  │
└───────────────────────┬─────────────────┘
                        ▼
┌─────────────────────────────────────────┐
│ Formal review                           │
│ (committee review meeting)               │
└───────────────────────┬─────────────────┘
                        ▼
               ┌─────────┴─────────┐
               │                 │
          ┌────▼────┐       ┌────▼────┐
          │ Approved│       │ Rejected│
          └────┬────┘       └────┬────┘
               │                 │
          ┌────▼────┐       ┌────▼────┐
          │ Supplement│     │ Resubmit │
          └────┬────┘       └────┬────┘
               │                 │
               └──────→ Re‑review ←───┘

Common problems and mitigations

Typical issues

Bureaucracy – cumbersome processes slow business; solution: categorize decisions, fast‑track lanes

Tokenism – reviews become perfunctory; solution: clarify responsibilities, focus on value

Over‑centralized power – stifles innovation; solution: define boundaries, prioritize service

Detached from reality – standards not applicable; solution: pilot, align with frontline needs

Success factors

Executive support – CTO/VP backing, clear positioning, resources

Clear responsibilities – what to do, what not to do, decision authority

Service orientation – help solve problems, provide technical support, share knowledge

Continuous improvement – regular retrospectives, feedback collection, process optimization

Summary

The Architecture Committee’s purpose is to unify technical standards, share assets, and govern architecture. Its core members are the chair, domain architects, and platform architects. Core duties include reviews, standards, governance, shared platforms, and technical direction. Effective operation relies on regular meetings, a clear decision mechanism, and strong executive backing.