Tiered Oversight

Right scrutiny for right risk.

What This Component Does

Not everything needs the same level of architectural scrutiny. A new integration pattern touching core customer systems needs more oversight than a team implementing a standard pattern they've used before.

Traditional architecture governance often applies the same process to everything - same review board, same documentation requirements, same approval gates. The result? Either everything gets bogged down in heavyweight process, or teams learn to route around governance entirely because it's not worth the hassle.

Tiered oversight solves this by scaling governance to actual risk. High-risk decisions get active architecture involvement. Low-risk decisions within established patterns get self-certification. The middle ground gets lightweight checkpoints.

The goal isn't less governance - it's appropriate governance that teams actually follow because it makes sense.

The Three Tiers

Tier 1 - High Risk

Tier 2 - Medium Risk

Tier 3 - Low Risk

Assessing Which Tier Applies

Use these factors to determine the appropriate tier. If any factor suggests a higher tier, default to the higher tier.

Risk Factor Matrix

Decision Tree

When in Doubt

If you're genuinely uncertain which tier applies:

1. Default up, not down - Better to have oversight you don't need than miss oversight you do
2. Ask architecture - A quick conversation can classify appropriately
3. Start at Tier 2 - Reasonable middle ground while you assess further
4. Document your reasoning - If the tier is later questioned, your rationale is on record

Tiered Oversight as Risk Management

Here's the insight that makes tiered oversight click: architecture decisions are risk decisions.

Every guardrail embodies a risk appetite decision. Every deviation is a risk acceptance. Every piece of technical debt is deferred risk. The tier model maps directly to how risk is managed.

Risk Treatment by Tier

Escalation to Enterprise Risk

Some situations escalate beyond architecture governance to enterprise risk management:

• Deviation impacts compliance posture (Essential Eight, PSPF, privacy legislation)
• Technical debt remediation exceeds defined thresholds
• Deviation affects core or critical systems
• Pattern of multiple deviations creating systemic risk
• Security control gap being accepted
• Significant vendor risk being introduced

Architecture doesn't own these decisions - but architecture does own surfacing them to people who do.

Decision Authority by Tier

Clear decision rights prevent bottlenecks and confusion. Everyone knows their lane.

Authority Matrix

Escalation Triggers

Escalate to the next level when:

Escalation Path

Solution Architect
        │
        ▼
Architecture Working Group / CoE
      (peer review)
        │
        ▼
Domain Architect
        │
        ▼
Enterprise Architect
        │
        ▼
Business Sponsor / Architecture Authority

Implementing Tiered Oversight

At Project Initiation

Every initiative gets classified at initiation:

1. Identify the scope - What systems, data, integrations are involved?
2. Assess risk factors - Walk through the factor matrix
3. Assign initial tier - Use decision tree or factor assessment
4. Identify relevant guardrails - What boundaries apply?
5. Confirm oversight approach - Who's involved, what checkpoints?
6. Document in passport - Record tier and rationale

During Delivery

Tier determines ongoing engagement:

Tier 1:

• Architect attends key ceremonies (sprint planning, design sessions)
• Architecture review at each major milestone
• Decision records maintained throughout
• Regular check-ins with EA for strategic alignment

Tier 2:

• Architect available on-demand
• Checkpoint at design completion
• Async review of decision records
• Flag any tier reassessment needs

Tier 3:

• Team proceeds autonomously
• Self-certification at completion
• Architecture available if questions arise

Tier Reassessment

Tiers can change as understanding evolves:

Document tier changes in the passport with rationale.

Setting Your Thresholds

The tier boundaries in this document are examples. Set thresholds appropriate to your organisation.

Investment Thresholds

Consider:

• Your organisation's risk appetite
• Typical project sizes
• Where you want architecture involvement

System Criticality

Define what "core" and "critical" mean for your organisation:

• Core: Systems that directly deliver primary business value
• Critical: Systems where outage causes significant business impact
• Supporting: Systems that enable but don't directly deliver value
• Peripheral: Systems with limited business impact if unavailable

Data Sensitivity

Align with your data classification scheme:

• Protected/Classified: Regulatory protection, significant harm if disclosed
• Internal/Sensitive: Business sensitive, moderate harm if disclosed
• Public: No sensitivity, minimal harm if disclosed

Anti-Patterns to Avoid

Making It Work

Tiered oversight only works if:

1. Tiers are honestly assigned - Gaming defeats the purpose
2. Tier 3 is genuinely self-service - If teams still need approval, it's not Tier 3
3. Thresholds are clear and communicated - No ambiguity about what triggers each tier
4. Architecture is helpful, not just oversight - Teams should want involvement at higher tiers
5. Sampling validates self-certification - Trust but verify

The goal is architecture engagement that scales to value and risk - not bureaucracy for its own sake.

Tiered oversight promise section · MD Copy

The Tiered Oversight Promise

Not everything matters equally. Tiered oversight makes that explicit.

• If you're Tier 3: Standard patterns, low risk, well-understood territory. Self-certify against guardrails and get on with it. Architecture trusts you to colour inside the lines.
• If you're Tier 2: More complexity, more integration, more at stake. A lightweight checkpoint — someone reviews your approach, asks a few questions, confirms you've thought it through. Then you proceed.
• If you're Tier 1: Core systems, significant investment, new territory, real risk. Active architecture involvement at decision points. Not blocking — enabling. Making sure the big choices get the attention they deserve.

The promise is proportionality. Governance scaled to stakes. Architecture attention concentrated where consequences are highest.

Teams doing routine work shouldn't wait for review. Teams doing critical work shouldn't go it alone.

Know your tier. Get the governance that fits.

XAF Connected Architecture | Developed by InnovateX Solutions