Business Provides Clarity. Product Writes Contracts. Engineering Implements Them. Infrastructure Makes It Real
Relative Architecture works in practice when four distinct roles are fulfilled. They may be inhabited by one person or many, by existing teams or new ones. What matters is that the responsibilities each role carries are clearly owned.
The four roles are Business, Product, Engineering, and Infrastructure. Business, Product, and Engineering work in parallel once the contract exists. Infrastructure works beneath the contract — making the promises the contract contains honourable in production.
Business — the irreplaceable source of domain knowledge
Business provides the domain knowledge that cannot be invented. The rules, the edge cases, the vocabulary, the meaning behind every outcome.
Business does not need to think in terms of contracts or events — that is Product's job. Business thinks in terms of what we do and how we do it. That is exactly as it should be.
Every domain carries accumulated knowledge that rarely makes it into documentation. Rules developed over decades. Exceptions that exist because of things that happened long before current systems were built. Judgment calls that experienced practitioners make automatically without being able to articulate why.
This knowledge has been passed down through generations of practitioners — through training, through habit, through institutional memory. It predates any of the current systems and will outlast them. The first job of the Product role is to harvest it.
Product — the essential middle role
Product is the role most often missing or miscast in technology organisations.
Not feature prioritisation. Not requirements translation. Domain modeling.
The ability to sit with a business expert, extract precise domain knowledge, and express it as a contract that Engineering can act on without interpretation. Named intents, explicit outcomes, declared events, trust levels, vocabulary definitions.
Product's primary deliverable is the contract — not the feature.
The people who can fulfil this role are already in most organisations. They are close to the domain. They understand the rules and the exceptions. They have developed an instinct for when a system is modeling the domain correctly and when it is subtly wrong. They are often living through the frustration of integrations that require heroic custom work and rules buried in code nobody in the business can read.
That frustration is diagnostic. Give them the language — contracts, responsibilities, events, ecosystem participation — and they recognise it immediately as a precise description of what the domain has always needed. They do not need to learn the domain. They need to learn the expression.
Engineering — full technical sovereignty
Engineering implements with full technical sovereignty.
Given a precise contract, every decision about framework, language, data model, and infrastructure belongs to Engineering. No domain decisions. No interpretation. Realization of what the contract specifies.
Engineering's deliverable to the business is the OpenAPI specification — nothing more complex than that. It is the contract expressed precisely. Business confirms that the capability names, inputs, outcomes, and events match what was agreed. Product mediates the review where notation feels unfamiliar. But the confirmation is the business's call. If the spec reflects the contract the business defined, Engineering has delivered.
This closes a loop that today rarely closes. Business knowledge travels through analysts into requirements documents into engineering and disappears into code that the business has no path back to. The capability contract is the shared artifact both sides worked from — and the OpenAPI spec is its living record. Business defined it. Engineering realised it. The spec connects both and belongs to both.
Infrastructure — the constraints beneath the contract
Infrastructure makes the contract's promises honourable in production.
A contract that specifies ordered event delivery is only as good as the broker that can guarantee it. A capability that promises sub-second response times is only as good as the deployment topology that supports them. A trust model that requires token validation at every boundary is only as good as the identity infrastructure behind it.
Infrastructure does not define what the system does. It defines what the system can promise. Broker selection determines what ordering guarantees are available to the contract. Deployment topology determines what latency commitments are realistic. Observability determines how quickly a broken promise is detected and diagnosed.
This means Infrastructure decisions are design constraints that flow upward — they bound what Product can specify and what Engineering can implement. A contract written without knowledge of the infrastructure beneath it may promise things the system cannot keep.
Infrastructure is not a support function. It is the foundation on which every contract either holds or does not.
The Clean Separation
| Role | Contributes | Delivers | Validates |
|---|---|---|---|
| Business | Domain knowledge | Clarity | Contract reflects reality |
| Product | Domain modeling | Contract | Implementation honours contract |
| Engineering | Realization | Working capability | Everything behind the boundary |
| Infrastructure | Operational foundation | Running system | Promises are honourable in production |
The boundary between them matters. The contract is the business's instrument. The spec is Engineering's confirmation. The running system is Infrastructure's delivery. Changes always flow through the contract first — Product sharpens it, Engineering produces a new spec, Infrastructure validates that the new behaviour is supportable.
Why This Works
The most important thing this separation does is make parallel work possible.
Once the contract exists, Business continues refining domain knowledge, Product evolves the model, Engineering builds against the contract, and Infrastructure provisions and validates the foundation — simultaneously. The contract is the coordination mechanism, replacing the constant back and forth of traditional development with a clean shared artifact each role can work against independently.
Each role will be explored in depth in its own post. This is the map. The territory follows.
Business owns the domain knowledge. Product owns the contracts. Engineering owns the implementation. Infrastructure owns the foundation. None of them crosses the other's line.