Steering Group, not ARB: IT Architecture for a SaaS-centric tech stack

The wrong question

Most architecture debates are about structure. Centralized or federated. Hub or spoke. Where the architects sit and who they report to.

Those debates assume the problem is the org chart. It isn't. You can move every architect in the company and still not know whether your tech stack can deliver what the business is asking for.

The better question: can the tech stack drive business goals, and how sure are we? That's effective IT management. IT Architecture exists to answer it.

You don't own the runtime

In most enterprises, SaaS and COTS make up the lion's share of the tech stack. That changes what architecture can control.

You don't write the code. You don't set the release schedule. You inherit dozens of vendor data models, each with its own idea of what a customer, an account, or an order is. Most of them aren't clearly understood by anyone inside the company.

Architecture practices built for custom code focused on templates, patterns, and design standards for what you build. That work still matters at the edges. But in a SaaS-centric tech stack, the risk isn't in the code. It's in the seams between systems, and in what the data actually means as it moves across them.

Govern meaning and interfaces, not code

When you don't own the runtime, you govern the seams. Vendors own their schemas. The enterprise owns the meaning. Mapping one to the other is the real work of architecture now.

Three primitives do most of that work, and none of them is a meeting:

Data contracts. Machine-readable definitions of what shared business data means. Every SaaS app is mapped to them before its data crosses domains.
Governed integration templates. Pre-built workflows that make the compliant path the easiest path.
Automated guardrails. Continuous checks on APIs, data flows, tokens, and SaaS configuration at the edge of every tool.

If a standard can't be checked automatically, it's a suggestion.

Why there's no ARB

An ARB reviews designs. Its origins linger in a world where you write the code.

In that world, a board reviewing solution designs made sense. Designs were expensive to change once built. In a SaaS-centric tech stack, design compliance belongs in the guardrails, templates, and contracts above. When it lives in a meeting instead, you get a queue, a backlog, and teams that route around both.

Design review doesn't disappear. It moves into the assessment. Before anything reaches a group of leaders, an architect writes up the as-is and the proposed change: the tech stack involved, the data it holds, the workflows it touches, and how well it actually works for the request. Simple requests get approved right there.

If a design question still shows up in front of leadership, a guardrail is missing. Fix the guardrail, not the meeting.

What's left is steering

With design review handled in the assessment, the leadership meeting has a different job. It steers. We call it a Steering Group.

It tests every business goal against two things:

How well the tech stack supports it. Strong, partial, or a gap.
How confident that judgment is. Based on how well the systems involved are actually understood.

Confidence comes from three questions about each part of the tech stack. Do we know what it is and who owns it? Are its business concepts defined? Is its data mapped to what those concepts mean? The weakest link sets the score. A well-documented app with unmapped data is still poorly understood.

The combination tells leadership what to do:

Strong support, high confidence: fund it and move.
Strong support, low confidence: it looks fine but it's unproven. Verify before betting on it.
A gap, high confidence: the gap is real. Buy, build, or change the goal.
A gap, low confidence: you don't know yet. Map it first, decide second.

That last case matters most. Most portfolio models assume you know what you have. In a SaaS-centric tech stack, you often don't, and the honest answer is to say so before deciding.

No inventory project

The usual first step is a big inventory: catalog every application, score it, and only then start making better decisions. Most of those projects stall before they pay off.

There's a better order. Start with the next request. The architect's assessment captures the parts of the tech stack that request touches and how well they're understood. The next request adds more. Shared services, like identity, integration, and collaboration platforms, show up again and again, so they get understood first.

Understanding grows where the business is actually asking for change. Coverage rises every month, and nobody had to stop work to build a catalog.

Who owns what

The model only works if ownership is clear:

Domains own the meaning. The business defines what its terms mean.
IT Architecture owns the contract and the standard. It turns meaning into something enforceable and runs the assessments.
Goal owners own the result. They bring goals to the Steering Group and live with the call.

And IT holds it together. Vendors keep shipping their own models. Domains keep defining their own terms. Someone has to make it one tech stack the business can steer.

Centralized or federated stops mattering when the work is this clear.

Vendors own the schema. Domains own the meaning. IT owns the cohesion.

This is the model behind Decision Governance for IT™.