The first domain is established. The political architecture holds. The Tuesday Test passes.
The SAP upgrade does not pause to acknowledge this.
It continues. New integration patterns are proposed every fortnight. New data dependencies are created every week. New cross-system flows are designed by delivery teams who are optimising for speed within their own context, without visibility of what those flows will cost the estate when the next programme arrives and finds three undocumented dependencies where the documented model said there should be one.
This is the condition constraint infrastructure is designed to operate inside. Not a quiet environment where the decision system can be carefully calibrated before it is tested. A live programme environment where every week of delay in building the infrastructure is a week of architectural decisions being made without it.
The Compliant Path, built in the first domain as a proof of concept, now has to become something more durable. Not a single documented answer to a single recurring question. An infrastructure that makes compliance the structural default across every integration the SAP programme touches.
Three Layers of Constraint Infrastructure
Constraint infrastructure operates at three layers simultaneously. The layers are not sequential. They run in parallel. Weakness at any layer propagates to the others.
Layer One — Constraint Definition
The architectural intent is expressed as constraints that are precise enough to guide a delivery decision at the point it is made. Not principles. Not guidelines. Constraints. A principle says "prefer loosely coupled integrations." A constraint says "no direct database-to-database integration between SAP and the data warehouse. All data flows route through the approved integration layer. Exceptions require domain owner sign-off and are recorded with the integration dependency created."
The precision matters because delivery teams make decisions at speed. A vague principle requires interpretation at every decision point. A precise constraint requires only a binary assessment — does this decision comply or not? If not, what is the exception process?
In the non-profit, the first constraint is precisely this. The SAP programme has been making database-to-database integration decisions without the constraint existing. The constraint does not retrospectively invalidate those decisions. It applies from the point it is defined and communicated. The decisions made before the constraint existed are recorded as the baseline. The decisions made after it exists are evaluated against it.
Layer Two — Compliant Path Engineering
The constraint is defined. The Compliant Path is the implementation of the constraint as the easiest available route. Engineering the Compliant Path means making the compliant option faster, cheaper, and lower friction than the non-compliant alternative.
For the SAP programme, the Compliant Path for data integration is the pre-approved integration layer. Compliant Path engineering means the integration layer is documented to the level of precision a delivery team needs to use it without a fresh architectural review. The API contracts are published. The data models are current. The security review is complete. The provisioning process is self-service or close to it. The delivery team that uses the integration layer gets to implementation faster than the delivery team that proposes a direct database connection and triggers the exception process.
The Internal Market Problem is solved when this is true. Before Compliant Path engineering, the non-compliant option was faster because it was undocumented and the documented option required a review. After Compliant Path engineering, the compliant option is faster because the review is pre-done and the non-compliant option requires a deviation process.
Layer Three — The Refinement Cycle
The constraint is defined. The Compliant Path is engineered. The Refinement Cycle is the mechanism that keeps both calibrated to the evolving delivery reality.
Constraints go stale. A constraint that was correctly calibrated to the estate six months ago may be miscalibrated today because the estate has changed, the programme has changed, or the business requirement the constraint was designed to protect has changed. A stale constraint produces two failure modes. It either blocks legitimate delivery — teams route around it because it prevents something genuinely necessary — or it is ignored silently, accumulating exceptions without the pattern being read.
The Refinement Cycle runs on a defined cadence — every fourteen days in active programme environments. It has three inputs. The exception log — every deviation from a constraint in the last fourteen days, with the stated reason. The rework log — every instance where a delivery decision produced unexpected integration cost, dependency creation, or constraint violation that was not an approved exception. The velocity signal — whether the Compliant Path is being used at the rate it was designed for, or whether delivery teams are finding the friction of compliance higher than it should be.
These three inputs produce one output. Constraint adjustments. Not wholesale redesign. Targeted calibration. The constraint that is generating exceptions for legitimate reasons is adjusted to accommodate the legitimate cases explicitly, which removes the ambiguity that was producing unnecessary deviation. The Compliant Path that delivery teams are avoiding because the friction is too high is re-engineered to reduce the friction. The constraint that is being silently ignored is examined to determine whether the delivery behaviour is wrong or the constraint is wrong.
In the non-profit, the Refinement Cycle surfaces something the first constraint definition did not anticipate. Three of the SAP programme's integration patterns touch a legacy system that is not in the documented data model because it predates the capability map. The integration layer does not have an approved pathway for that system. Delivery teams are routing around the constraint not because they are non-compliant but because the Compliant Path does not yet exist for their actual delivery requirement.
The Refinement Cycle identifies this as a Compliant Path gap, not a compliance failure. The domain owner adds the legacy system to the data model. The integration layer is extended. The constraint is updated to cover the new pathway. The delivery teams that had been routing around the constraint now have a Compliant Path. The deviation pattern disappears. The constraint was not wrong. It was incomplete.
The SAP Upgrade as Proving Ground
The SAP upgrade is the most demanding test an estate-wide constraint infrastructure can face because it is not a single programme with a bounded scope. It is a cross-domain event. Every business process that touches SAP is in scope. Every integration is potentially affected. Every data ownership question that was left implicit in the capability map year now has a delivery deadline attached to it.
In the non-profit, the SAP upgrade is running into the constraint infrastructure the practitioner is building simultaneously. This is the honest version of the implementation arc. Not "build the infrastructure, then deploy it against a programme." Build it while the programme is running, under the pressure of the programme's delivery schedule, and demonstrate that the infrastructure can absorb programme load while it is being constructed.
Three specific SAP scenarios demonstrate the infrastructure working.
The first is the financial data feed integration. The delivery team proposes a direct database connection. The Compliant Path is documented. The deviation requires an explanation. The domain owner reviews the explanation, identifies that the direct connection would create three undocumented dependencies, and proposes an alternative using the integration layer that achieves the same outcome with documented dependencies. The delivery team adopts the alternative. The decision is recorded. The Compliant Path holds.
The second is a permissions boundary conflict. The SAP upgrade requires a user provisioning model that conflicts with the existing Active Directory structure. Neither the SAP team nor the infrastructure team has the authority to resolve the conflict at domain level — it crosses the boundary between the data domain and the security domain. The conflict escalates to enterprise level as designed. The enterprise architecture function facilitates the resolution. The decision is documented with a reference to both domain constraints and the modification made to each. The Refinement Cycle updates both domain constraints to reflect the agreed resolution.
The third is a constraint the programme team identifies as blocking a genuine business requirement. The integration layer constraint, as originally written, prevents a real-time data feed that the SAP programme needs for a regulatory reporting obligation. The programme team raises the exception. The domain owner reviews it. The exception is legitimate — the constraint did not anticipate regulatory real-time requirements. The Refinement Cycle updates the constraint to accommodate real-time feeds for regulatory purposes, with specified conditions. The exception becomes a Compliant Path. The programme gets the feed. The constraint is more precise than it was before the exception was raised.
In each of these scenarios, the constraint infrastructure does not obstruct delivery. It routes delivery decisions through a system that produces recorded, attributed, traceable outcomes. The programme is faster for having the infrastructure than it would be without it — not because the infrastructure removes friction, but because it removes the specific friction of undocumented decisions that cost more when they compound than they saved when they were made.
The VMware Thread — What the Infrastructure Should Have Caught
The VMware licensing situation in the non-profit is the most concrete demonstration of what constraint infrastructure prevents when it exists and what it costs when it does not.
Broadcom's acquisition of VMware in late 2023 changed the licensing model fundamentally. Organisations running VMware on perpetual licences needed to make a decision in 2024 — migrate, renegotiate, replace, or absorb the cost increase. That decision required knowing what the VMware estate looked like. Which workloads were running on it. Which were candidates for migration. Which had dependencies that made migration complex. What the cost of the current model versus the alternatives was.
A functioning constraint infrastructure would have surfaced this as a Baseline Integrity question within weeks of the licensing change becoming public. The estate documentation would have been queryable. The VMware dependency map would have been current enough to scope the options. The decision would have been routed to the right Decision Altitude — in this case, a Level Four executive trade-off between the cost of migration and the cost of the new licensing model — and resolved with a recorded rationale.
The non-profit did not have constraint infrastructure. It had a capability map. The capability map described what the organisation did. It did not describe what was running on VMware, what those workloads depended on, or what the migration complexity was. The licensing question arrived. The measurement model did not surface it. The capability map could not answer it. The decision was not made. Two years passed.
Building constraint infrastructure now does not recover those two years. But the VMware situation becomes the most concrete argument for why the infrastructure matters — because every person in the organisation who was affected by the non-decision on VMware licensing can be shown exactly where the structural gap was and what it cost.
The constraint infrastructure, once built, makes this category of non-decision structurally impossible. Not because it forces someone to decide. Because it creates the Baseline Integrity conditions under which the decision is visible at the point it needs to be made rather than two years later when the cost has compounded.
What Constraint Infrastructure Is Not
It is not a governance gate. A governance gate is a checkpoint that a delivery decision must pass before proceeding. Gates produce queues. Queues produce pressure to approve without adequate assessment. Adequate assessment collapses under delivery pressure. The gate becomes a formality. The formality becomes theatre.
It is not a standards library. A standards library describes what good looks like. It does not make good structurally easier than the alternative. It relies on practitioners consulting it, interpreting it, and applying it consistently. Practitioners under delivery pressure do not consistently consult standards libraries. They use what is fastest.
It is not a review board. A review board is a committee that evaluates architectural decisions after they have been proposed. Review boards are slow. They meet on fixed schedules. Delivery teams cannot wait for them. Review boards generate the Upward Altitude Collapse pattern — decisions that should be made at domain level accumulate at enterprise level because the review board is the designated authority regardless of the decision's consequence.
Constraint infrastructure is the structural condition that makes the right architectural decision the fastest available one. Built correctly, it is invisible to delivery teams. They do not experience it as a constraint. They experience it as the available set of pre-approved options — faster, documented, lower risk. The constraint is felt only at the boundary, when a decision approaches the edge of what is pre-approved and the exception process begins.
That is what the Compliant Path, the Refinement Cycle, and the three-layer infrastructure produce together. Not governance. Not standards. Not review. The structural default toward architectural coherence.