Architecture Governance Across Delivery Partners

Q: What is architecture governance across multiple delivery partners?

It is the function of reviewing, challenging, approving and continuously conforming solution architectures produced by teams you influence but do not manage — multiple system integrators, several internal squads, and staff-augmentation vendors, each with its own house style, preferred stack and commercial incentive. It is a distinct discipline from designing a system yourself, because when many teams design in parallel, coherence is not a byproduct of one mind but something a specific function has to manufacture against the grain of everyone's local incentives. Each partner's proposal is individually defensible and collectively a mess: five vector stores, three gateways, two definitions of "evaluated," and a technical-debt bill that lands on the enterprise long after the integrator has invoiced and left. The function has seven parts: reviewing proposed architectures against a standard, assessing alignment with enterprise reference architectures, identifying inconsistency and duplication and proliferation and debt, challenging designs that fail on scalability or reuse or security or performance or cost, providing Go/No-Go recommendations, influencing partners without a reporting line, and establishing mechanisms for ongoing conformance. The unifying idea is that governance here runs on published standards and earned influence rather than instruction, because you have no authority to simply tell an external partner what to build.

Q: How do you govern partners you have no authority over?

By making the aligned path the path of least resistance and, uniquely in a multi-partner program, by writing conformance into the contract. Influence without authority is earned the same way everywhere: be clear, be consistent, and be right often enough that teams consult you before they build rather than after. Golden-path templates that a partner would choose anyway — because they are genuinely the fastest way to ship — do more than any mandate, which is the internal-developer-platform logic applied to outsiders. But multi-partner governance has one lever that purely internal governance lacks: the statement of work. Platform usage and architecture conformance can be written into the SOW as acceptance criteria tied to milestone sign-off, which converts "please align" from a favour into a term the partner is paid against. Used well this is not a cudgel; it is what lets a partner justify to their own management the time spent conforming rather than cutting a faster, more billable corner. The combination matters: the contract creates the obligation, and the paved road makes meeting the obligation cheap, so a partner both must align and finds aligning easy. Governance that relies on pleas without the contractual term is ignored the moment alignment costs margin, and governance that relies on the contract without paved roads breeds resentment and malicious compliance.

Q: What five lenses should you challenge an AI solution design on?

Scalability, reuse, security, performance, and cost efficiency, each with a concrete failing-question, applied identically to every partner so a challenge reads as a standard being applied rather than one team being singled out. Scalability: does unit cost fall or rise as volume grows? A design can pass a technical autoscaling demo and still fail economically if cost per interaction climbs with load. Reuse: which shared platform service does this bypass, and why? This is the lens that most often exposes a weak design, because bypassing the platform is how duplication and proliferation enter, and partners bypass it precisely because reusing your gateway is less billable than rebuilding one. Security: where is the new attack surface, and who authorised it? A partner who cannot say where their new attack surface is has not finished the design. Performance: what is p95 under real load, not the demo? A measured budget, not a hope. Cost efficiency: what is the cost per interaction, token and retrieval? A unit-economics model, not a bill discovered later. Beneath the five lenses sits the distinction that keeps "scalable" honest: it means three things at once — technical scale (handling load), organisational scale (many teams building without a bottleneck), and economic scale (unit cost falling, not rising, with volume) — and a design can ace one while failing the others.

Q: What is the difference between a design that deviates and one that violates?

It is the single most important distinction in architecture review, because confusing the two turns governance into either bureaucracy or negligence. A design deviates when it departs from the reference architecture for a reason — a genuine domain difference, a constraint the reference did not anticipate, a better approach the reference has not yet absorbed. Deviation is sometimes exactly right, and a governance function that treats every deviation as a failure becomes architecture-as-bureaucracy: a review board that says no to everything unfamiliar and gets routed around. A design violates when it breaks a load-bearing principle — direct database access instead of a governed interface, an unauthorised model for sensitive data, a bypassed gateway, no evaluation baseline before production. Violation is an automatic no regardless of how good the rest of the design is, because principles exist precisely to constrain the decisions you are not willing to re-litigate case by case. The practical test is whether the departure can be defended on its merits (deviation, hear it out, possibly capture it as a new pattern) or whether it simply ignores a rule that protects the enterprise (violation, block it). Getting this distinction right is what lets a governance function be simultaneously firm on the things that matter and flexible on the things that do not, which is the only posture that earns lasting influence over partners who do not report to you.

Q: What does a good Go/No-Go decision look like?

A decision made against published criteria, whose most common and most useful outcome is neither a flat yes nor a flat no but a conditional yes — approve with mandated changes — and whose every no ships with a supported yes. Go/No-Go loses its sting and gains its authority when the criteria are published in advance, because a partner who fails then knows exactly which criterion they failed and how to pass, rather than experiencing the decision as an arbitrary veto. The conditional yes is the workhorse outcome because most designs are roughly eighty percent right: approving with specific conditions moves faster than a hard no while still enforcing the standard, and it keeps the partner moving. A flat no with no path forward is what makes architecture governance hated and quietly bypassed; a no that arrives with "here is the supported design that gets you to yes" is what makes the function consulted early instead of worked around. Every decision is captured as an Architecture Decision Record so that the reasoning survives the partner rotation that is guaranteed in a multi-vendor program — the integrator who made the call may be gone in six months, and without the record the next partner reopens a settled question. In short: published criteria, conditional-yes as the default, a supported path attached to every rejection, and durable decision records so nothing is silently re-litigated.

Q: How do you stop technology proliferation across multiple partners?

With a published sanctioned-technology radar and a cross-partner duplication map, so that "we already have one of those" is a visible, enforceable fact rather than knowledge that lives only in the architect's head. Left ungoverned, N partners produce N stacks and the enterprise inherits the union: every licence, every skill set, every on-call rotation, multiplied — a standing cost the proposing partner rarely includes in their estimate. The counter is a radar with adopt, trial, assess and hold rings that tells a partner which technologies are already sanctioned before they propose a new one, applying the boring-technology discipline that keeps a stack from churning. The judgement call is distinguishing healthy variation from debt: two teams using different embedding models because their domains genuinely differ is variation, while two teams standing up different vector databases because neither checked what already existed is debt. The governance move is not to ban all variation — that is its own failure mode, standardising away real domain differences — but to make proliferation a decision that someone explicitly owns rather than an accident nobody noticed, and to price it, so that any unsanctioned technology has to justify its standing cost in licences, hiring and operational surface. Proliferation is rarely defeated by prohibition; it is defeated by visibility plus ownership, which is what the radar and the duplication map provide.

Q: What are architectural fitness functions and why do they matter for conformance?

Architectural fitness functions are automated checks that assert the architectural properties you care about — no direct data access, every model call routed through the gateway, no unsanctioned dependency, an evaluation baseline present — and fail the build when a partner violates them, turning conformance from a periodic review into a continuous signal that runs in CI on every commit. They matter because a one-time approval is worthless in a multi-partner program: the thing that ships is rarely the thing that was reviewed, since schedules slip, corners get cut under delivery pressure, and a conformant design quietly becomes a non-conformant system between the design review and go-live. Without an automated check, that drift is discovered in an incident — the data leak, the runaway cost, the outage — rather than in a pipeline run. Fitness functions make conformance conformance-as-code, running in the same CI/CD pipeline as the delivery itself, and they embody the same producer-owns-the-contract discipline that data contracts bring to data: the partner owns keeping their own stream conformant, and a lightweight per-partner conformance scorecard makes drift visible before it compounds. The goal is not to police every commit with a human reviewer, which does not scale across many independent teams; it is to make the compliant path the automated default, so a partner stays aligned as a side effect of a green build rather than as a favour to the architecture function.

Q: How is this different from the enterprise AI architecture authority in general?

The general authority-layer function is the whole operating system of enterprise AI architecture — six responsibilities spanning target architecture, principles, patterns, the technical domains, and enterprise alignment — and it argues why a senior architecture authority needs to exist at all. Multi-partner delivery governance is a deep, specific slice of that function: it takes one of the six responsibilities, acting as the architecture authority, and works out its mechanics for the hardest version of the problem, which is coherence across many external partners and internal teams who do not report to you and are not incentivised to align. The general treatment establishes that the authority earns influence rather than commanding it, that decisions become ADRs, and that Go/No-Go should feel like a standard applied; the multi-partner treatment goes deeper on exactly how — the standard submission template, the five-lens challenge rubric, the deviate-versus-violate test, the technology radar, the SOW conformance clause, and fitness functions in CI. In practice you read the general authority-layer article to understand the shape of the function and this one to actually run architecture reviews across a portfolio of delivery partners. They are reciprocal: the hub points down to this deep-dive for the multi-partner mechanics, and this deep-dive points up to the hub for the broader operating model it sits inside.