Architecture Governance for Teams Without a Dedicated EA Function

Nobody on a forty-person engineering team wakes up and decides to run enterprise architecture governance. It isn't in anyone's job title, there's no budget line for it, and the word "governance" itself tends to trigger an eye-roll before the sentence finishes. And yet the same organization, eighteen months and a few reorgs later, has three systems that all claim to own "customer," a service nobody can safely change because the person who understood its downstream callers left, and a Slack thread every quarter titled some version of "does anyone know what talks to the old billing service." That is architecture governance's problem set, arriving on schedule, with no architecture governance function anywhere in sight to catch it.

This is not a story about organizations doing something wrong. It's what happens by default once a system landscape crosses a fairly low threshold of complexity — somewhere around a dozen services, a couple of integrations nobody fully owns, and more than one team touching shared infrastructure. Below that threshold, everything genuinely does fit in people's heads. Above it, gaps start forming quietly, and they don't announce themselves until something breaks or someone asks a question nobody can answer with confidence.

The usual response is to treat this as a headcount problem: governance needs a governance team, a governance team needs budget, budget needs a business case, and the business case needs the kind of incident that makes governance look cheap by comparison. That's a real path, and for organizations that eventually grow into needing a dedicated enterprise architecture function, it's the right one. But it's also a multi-quarter answer to a problem that's costing you real money this quarter. Most of what a dedicated EA function actually does day to day — keeping an accurate picture of what exists, catching obvious inconsistencies before they compound, being able to answer "what breaks if we touch this" — doesn't require a team. It requires a model, some automated checks, and someone whose job includes maintaining both, even if that's ten percent of their job rather than a hundred percent of it.

What the problem actually looks like without a name for it

It helps to be specific about what shows up, because "governance" as a word is vague enough to mean anything and therefore tends to mean nothing. In a team without a dedicated EA function, the same handful of symptoms recur almost everywhere:

• Duplicate capability. Two services independently grew the ability to send customer notifications, because the second team either didn't know the first one existed or didn't trust it enough to depend on it. Nobody decided this was fine; nobody decided anything at all.
• Undocumented dependencies. A batch job reads directly from another team's database because that was the fastest way to ship something two years ago. It has never appeared in any diagram, because nobody thought of a cron job as an architectural fact worth recording.
• Inconsistent naming and ownership. "Auth service," "identity API," and "login backend" turn out to be the same system, referred to differently by three different teams, with an owner field that says three different names depending on who last edited the wiki page.
• Nobody who can answer "what would break." This is the one that costs real money. A retirement, a migration, or a vendor switch gets planned, and the honest answer to "what depends on this" is "we think we know, but nobody's actually checked everything."

None of these require an EA framework to fix. They require somebody to have written the facts down somewhere real, and a way to check them automatically instead of relying on memory. That's a much smaller ask than it sounds, and it's the ask this article is actually about.

Why waiting for a dedicated function is the wrong call

There's a reasonable-sounding argument for waiting: governance done badly is worse than no governance at all, because it creates process overhead without fixing anything, and a small team doesn't have the bandwidth to do it properly. This argument is correct about heavyweight governance and wrong about governance in general. The failure mode it's describing — a review board, a change advisory process, a forty-item compliance checklist applied to every pull request — is a specific and avoidable design choice, not an inherent property of trying to know what your own systems look like.

The lighter-weight version of governance this article describes costs an afternoon to start and a few hours a month to maintain. What it buys back is disproportionate to that cost, because most of the value in EA governance doesn't come from sophisticated analysis — it comes from the unglamorous act of having a single, current, queryable record of what exists, instead of a system landscape that lives across old diagrams, a wiki nobody trusts, and the heads of whoever's been there longest. That record is worth having at ten systems. It's worth having more at fifty. The organizations that regret not having it are, without exception, the ones that waited until the landscape was too tangled to reconstruct cheaply.

Step one: capture what exists as a real model, not a slide deck

The instinct, when someone finally decides the system landscape needs documenting, is to book a workshop, put everyone in a room, and produce a slide with boxes and arrows. This slide will be accurate for approximately as long as it takes to present it. It will be wrong within a quarter, because nothing about a slide deck makes it anyone's job to keep it current, and because a slide is a picture of a system landscape rather than a record of one — there's no underlying structure a second person, or a tool, can query, check, or extend.

The first real step is different in kind, not just in effort: capture what exists as a model — a set of actual systems, actual relationships between them, actual ownership — rather than as a drawing that happens to look like one. This is where a tool like Mooodels earns its keep for a team in exactly this position. It doesn't ask a small team to adopt a formal metamodel before they're allowed to start; the lightweight Generic profile lets you model "this service, that database, this relationship" without first sitting through ArchiMate training or deciding whether something is a Business Process or an Application Function. A relationship is a relationship. You can always adopt more formal notation later, once the modelling habit exists and there's a real reason to want it — a profile switch, not a rebuild.

In practice, this first pass looks less like a workshop and more like triage. Pick the twenty or thirty systems that actually matter — the ones a serious incident would touch, or the ones people already argue about in meetings — and get each one into the model as a real element with a real owner, even if the owner field just says a team name to start. Then add the relationships you're confident about: this calls that, this reads from that database, this depends on that queue. Resist the urge to make it complete before it's useful. A model with thirty systems and their real dependencies, built in an afternoon, beats a slide with sixty boxes that took three meetings and started decaying the moment it was exported to PDF.

The point of doing this as a model instead of a picture isn't aesthetic. It's that a model is the only form of this information a computer can check. A slide can't tell you that "Auth Service" and "Identity API" are two names for a relationship that was never actually confirmed. A model can flag that two elements claim overlapping responsibility, because overlapping responsibility is a structural fact about the model, not a subjective judgment about a picture. Everything that follows in this article — the linting, the rules, the part-time ownership — depends on this first step being a real model rather than documentation theater.

Step two: let automated linting do the first pass

Once a model exists, the temptation is to jump straight to writing rules — "every application must have an owner," "public services must go through the approved gateway," and so on. Resist that for a moment, because there's a cheaper step first that catches a surprising fraction of the real problems without anyone having to decide what a rule should say. Deterministic linting — the checks a tool runs automatically against the structure of the model itself, with no custom rule-writing required — tends to surface exactly the class of problem described at the start of this article: elements with no owner at all, relationships pointing at something that no longer exists, two elements that look suspiciously like duplicates of each other, orphaned pieces nothing else in the model connects to. None of this required anyone to sit down and author a governance policy. It's just what falls out of checking a model's basic structural integrity, the same way a code linter catches an unused import without anyone having written a rule specifically about that import.

This matters for a team without a dedicated EA function for a specific reason: it delivers governance value before anyone has had to make a single policy decision. Policy decisions are where governance efforts stall — someone has to decide what "good" looks like for this organization, and that decision-making tends to require the kind of cross-team authority a small team doesn't have and doesn't want to manufacture. Structural linting sidesteps that entirely. "This relationship points at an element that doesn't exist" isn't a policy opinion. It's a fact, and it's useful to know regardless of what anyone believes governance should look like.

In practice, this first pass on a freshly captured model routinely turns up things like: three systems with no owner recorded at all, one relationship left over from a system that was decommissioned last year and never removed, and two elements that are actually the same system under different names — exactly the naming-inconsistency problem from the opening section, caught automatically instead of discovered the hard way during an incident. Fixing these takes minutes once they're visible. Finding them without a linter takes a room full of people and a lot of goodwill, and even then it's not exhaustive.

Step three: two or three rules that matter here, not forty that matter nowhere

After the structural pass, there's a real temptation to import a governance framework wholesale — take the forty-item rule set some EA methodology publishes, load it in, and call the organization governed. This is close to the single most common way lightweight governance efforts die. A forty-rule framework written for a generic enterprise encodes forty decisions someone else made about problems someone else had. Most of them won't apply. The ones that do apply will be phrased for a context — formal ArchiMate layers, a change advisory board, a security classification scheme — that this organization doesn't have and isn't going to build just to satisfy a rule it imported by default. Within a month, half the rules are permanently red, everyone has learned to ignore the governance dashboard, and the effort is worse than useless: it's now actively training people that the warnings don't mean anything.

The alternative is almost boringly simple: write two or three rules that encode a real, specific, remembered problem this organization has actually had. Not hypothetical risks a framework author imagined for enterprises in general — the ones this team has actually been burned by. A few examples of what that looks like in practice:

The pattern across the right-hand column is that each rule is traceable to a specific, remembered cost. That's what makes a small rule set survivable long-term without dedicated governance staff: everyone involved can explain, in one sentence, why the rule exists, because it exists because of something that actually happened to them. A rule nobody can justify in one sentence is a rule that gets disabled the first time it's inconvenient, and rightly so — an unjustified rule blocking real work is worse than no rule at all.

This is also where deterministic rule checking earns the word "deterministic." A rule like "customer-facing systems must have a named owner" isn't a suggestion reviewed occasionally by whoever remembers to look — it's a check that runs against the model every time it changes, the same way a build fails on a broken test. Nobody has to remember to enforce it. It either holds or it doesn't, and the model tells you which, without needing a governance team to sit in a room and manually inspect every change for compliance. That's the entire mechanism by which two or three rules can deliver real governance value without a dedicated function: the enforcement is automatic, so the ongoing cost is close to zero once the rules are written.

Resist adding a fourth or fifth rule quickly. Live with two or three for a month, watch what they catch, and only add another once there's a second remembered incident that justifies it. A rule set that grows by scar tissue rather than by aspiration stays maintainable indefinitely, because it never grows faster than the organization's actual appetite to care about what it's checking.

Step four: a rotating architecture owner, not a headcount request

The model needs a keeper — someone whose job includes noticing when a new system should be added, when an owner field has gone stale, when a rule is firing so often it's clearly wrong and needs revising rather than ignoring. This is the piece organizations most often assume requires a hire, and it's the piece where that assumption is least justified.

Treat it instead as a role, not a headcount: an "architecture owner" who holds the responsibility for a defined period — a quarter is a reasonable rhythm — as maybe ten percent of an existing job, most naturally a senior engineer or tech lead who already has informal architectural authority whether or not it's ever been named. Their actual workload is small and specific: review the linter output every couple of weeks, add new systems to the model as they show up, adjust or retire a rule that's clearly stopped being useful, and be the person who gets asked "does this exist in the model" when someone starts a project that might duplicate something. None of this is full-time work. All of it goes undone if it's nobody's explicit job, which is exactly the state most organizations without a dedicated EA function are in today — not because no one is capable of it, but because it's everyone's job and therefore no one's.

Rotating the role rather than assigning it permanently solves two problems at once. First, it prevents the model from becoming one person's private knowledge again — the same failure mode as tribal memory, just relocated into a tool instead of a person's head. Second, it spreads the habit of thinking in model terms across more of the team over time, which tends to improve the quality of the model itself: a new owner coming in fresh notices staleness and gaps a long-tenured owner has stopped seeing. A one-quarter or two-quarter rotation, handed off with a short walkthrough of what changed and what's currently flagged, keeps the role light enough that nobody dreads being assigned it.

What makes this practical rather than aspirational is that the tool has to support someone doing this part-time without becoming a specialist. This is where the Generic profile matters again, alongside the fact that Mooodels runs in a browser with no heavyweight install or licensing step standing between a newly rotated owner and actually opening the model on their first Monday. An architecture owner who has to spend their first two weeks learning a modelling notation before they can do anything useful is an architecture owner who quietly stops doing the job by week three. One who can open the model, see what the linter flagged, and fix three things before their next meeting is one who actually keeps doing it.

Where AI fits, and where it deliberately doesn't

A part-time owner covering a model alongside their regular job is exactly the situation where AI assistance earns its keep, and exactly the situation where it needs the right guardrail. An AI assistant that can look at the model and propose "these two elements look like the same system under different names" or "this new service looks like it duplicates the capability tagged on that other one" is doing useful triage work that would otherwise eat into the owner's limited time. What it should never do is apply that change itself. In Mooodels, AI proposes a reviewable ModelPatch — a concrete, inspectable set of changes — rather than editing the model directly, so the part-time owner's actual job becomes reviewing a short list of proposed changes rather than hunting for problems from a blank canvas. That division of labor — AI surfaces candidates, a human with actual context approves or rejects them — is what makes ten percent of a job a realistic amount of time for this role to take, rather than a polite fiction.

What this gets you, honestly measured

Run this for two or three months and the change is noticeable in ordinary conversations, not in a dashboard metric. "What talks to this" gets answered by a query instead of a Slack thread. A new project gets flagged before it quietly rebuilds something that already exists, instead of after. An owner field that used to say "not sure, maybe the platform team" says an actual name. None of this requires anyone to have adopted the word "governance" out loud, and that's fine — the value doesn't depend on the label.

It's also worth being direct about the shape of interoperability here, because a small team's model rarely starts from nothing. If systems are already partially documented in Archi or Sparx EA from an earlier, abandoned attempt at this, that work doesn't have to be thrown away — Mooodels interoperates with both, so an existing repository can seed the new model rather than being quietly discarded in favor of starting over. And because the underlying model is stored in a Git-friendly serialization, the model itself can live in version control next to the code it describes, reviewed the same way a pull request is reviewed, rather than as a separate artifact that lives in a different tool with a different access list and a different sense of what's current.

Where this stops being enough

All of this deserves an honest ceiling, because overselling a lightweight practice is how it earns a bad reputation the moment it's stretched past what it was designed for. This is a lighter-weight version of governance. It is not a substitute for a real EA practice once an organization is large enough to genuinely need one, and pretending otherwise does a disservice to the teams that eventually get there.

A few signals tend to show up in roughly this order as an organization outgrows the lightweight version:

• The two or three rules that used to matter have grown to fifteen or twenty, each justified by its own remembered incident, and a part-time owner can no longer hold the whole rule set and its rationale in their head.
• Architecture decisions increasingly cross team boundaries in ways that need actual authority to resolve — not "should this be flagged" but "which of these two competing designs does the organization commit to" — and a rotating owner with no mandate to say no isn't positioned to make that call.
• Regulatory, audit, or formal compliance obligations start requiring documented governance process, evidence of review, and traceability that a lightweight linting setup was never built to produce.
• The model itself has grown to a scale — many hundreds of systems, multiple business units, layered ownership — where maintaining it is no longer a plausible ten percent of one rotating person's time, whoever that person is.

When two or more of these show up together, that's the signal to make the business case for dedicated headcount, not a sign that the lightweight approach failed. It succeeded at exactly what it was for: getting real governance value during the period when the organization couldn't yet justify — and didn't yet need — a dedicated function. The model, the rules, and the habits built during that period aren't wasted once a real EA team arrives. They're the starting inventory that team inherits, already in a real tool, already reasonably current, instead of a green field and a stack of outdated slide decks to reverse-engineer from scratch.

That's a better handoff than most dedicated EA functions actually get when they're first stood up. Most of them spend their first two quarters just finding out what exists. A team that did the lightweight version first has already answered that question, and answered it as a real, queryable model rather than as institutional memory that leaves when people do.