Reference architecture partner
Determine whether a reference design is sufficiently bounded to reuse
When several customers ask for a reusable agent deployment pattern, this area becomes relevant. For the enterprise architecture leader, the concern is specific: a reference architecture is treated as proof that every deployment is secure or suitable. The collaboration qualification starts from that consequence and follows the relevant evidence through the customer workflow. A reference architecture should expose the conditions under which it stops applying. The partner conversation should make customer-owned controls and untested interfaces as visible as the preferred components.
The collaboration responsibilities relationship
- Candidate architecture diagrams
Establish the basis for design assumption.
- Substitution boundary
Show which components may change and what to recheck.
- Annotated reference architecture
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around design assumption
Questions and the evidence they need
- Design assumption
- Inspect candidate architecture diagrams for the relevant constraint or observation.
- Substitution boundary
- Inspect environment assumptions for the relevant constraint or observation.
- Validation owner
- Inspect known implementation constraints for the relevant constraint or observation.
For the enterprise architecture leader, this becomes relevant when several customers ask for a reusable agent deployment pattern. The immediate decision is whether a reference design is sufficiently bounded to reuse. The scope should be narrow enough that the proposed collaborators can identify a meaningful alternative, including continuing the current approach if the available evidence already supports it.
The practical failure to challenge is that a reference architecture is treated as proof that every deployment is secure or suitable. That concern gives the work a concrete direction: establish what the relevant boundary should do, inspect how it behaves or would operate, and identify the owner of any gap. It should not be diluted into a broad transformation exercise before the specific question has been answered.
Mechanism
Reference architectures need explicit applicability limits
Relationships within collaboration responsibilities
- Design assumption
- State the workload and controls the design assumes.
- Substitution boundary
- Show which components may change and what to recheck.
- Validation owner
- Assign evidence needed before reuse.
Assumption visibility
For this scope, assumption visibility should be examined alongside candidate architecture diagrams. Make deployment assumptions visible in the reference design, including customer-owned controls and untested interfaces. The proposed architecture should help readers decide when it applies. A reusable diagram should not imply that every combination of components or customer configuration has been validated.
Component substitution points
For this scope, component substitution points should be examined alongside environment assumptions. Identify substitution points and the evidence each substitution would require. Replacing an identity service, runtime, model, or store can change the surrounding control assumptions. Qualification should test whether the collaborators can explain these consequences rather than merely reproduce a preferred stack.
Validation ownership
For this scope, validation ownership should be examined alongside known implementation constraints. Assign validation responsibility for the reference pattern and each customer adaptation. The proposed collaboration should distinguish documented design reasoning from observed implementation behaviour. A customer’s deployment still needs its own acceptance decision, with gaps and dependencies preserved rather than inherited approval from the reference asset.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for design assumption
Illustrative working format
- Candidate architecture diagrams
- Match this description to the deployed or proposed boundary being examined.
- Environment assumptions
- Separate observed inputs from assumptions and retain the comparison boundary.
- Known implementation constraints
- Name the custodian and the conditions requiring a refreshed version.
The starting material is candidate architecture diagrams, environment assumptions, and known implementation constraints. Review these together rather than assuming one document tells the whole story. A stated rule may differ from a configured behaviour, and a proposed responsibility may not yet have an available owner. Identify those differences before selecting the detailed work.
Participation should include a customer-side sponsor, a technical owner, and the people who would accept delivery and support responsibilities. The customer should define which information and environments may be used. Synthetic or sanitised examples can support preparation when they preserve the relevant behaviour; if they omit a material dependency, record the limitation and agree how the missing evidence would be obtained.
How the work proceeds
Carry design assumption through to an accountable finding
From the scoped material to a decision record
- Candidate architecture diagrams
Qualify the customer need and participation required.
- Substitution boundary
Apply the scoped check to validation owner.
- Annotated reference architecture
Record the evidence, open dependencies, and the owner’s next decision.
Require the reference design to list substitution assumptions. Replacing a model, identity provider, execution runtime, or data store may change the evidence needed even when the high-level diagram looks unchanged. A useful architecture artefact therefore includes decision points and untested combinations alongside its preferred configuration.
A practical first slice would focus on assumption visibility and then follow its consequences into component substitution points. Keep validation ownership visible as a separate review question rather than assuming it is satisfied by the first result. The proposed collaborators should record observations, competing explanations, and changes to the original assumptions. A second reviewer can challenge whether the evidence supports the recommendation and whether an apparently successful example omitted the condition that matters most.
Indicative artefact
Make the annotated reference architecture usable by its owner
Annotated reference architecture
Illustrative working format
- Annotated reference architecture
- Identify the assessed workflow, revision, and decision boundary.
- Applicability checklist
- Distinguish verified conditions from assumptions that require confirmation before use.
- Validation backlog
- Name the missing evidence, responsible owner, and condition for revisiting the decision.
Indicative outputs include annotated reference architecture, applicability checklist, and validation backlog. Their form should follow the decision and the customer’s existing operating records. The first should establish the assessed boundary and relevant observations; the second should make material gaps or dependencies inspectable; the third should identify the action, owner, and evidence needed to revisit the decision.
Acceptance should be tested through use: can the responsible owner explain what was examined, identify an unresolved issue, and act on the next step without reconstructing the whole engagement? Findings should preserve counterevidence and limits. A polished document is insufficient if it does not help resolve the customer’s specific question.
Illustrative scenario
Examine validation owner through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Design assumption
A proposed design combines orchestration, enterprise identity, and a managed runtime.
- Substitution boundary
Replace one assumed component in the proposed reference design.
- Validation owner
Identify the validation work needed before the adapted design is reused.
Consider an illustrative situation in which a proposed design combines agent orchestration, enterprise identity, and a managed execution environment. This is a constructed example, not a client engagement or an observed Softlander outcome.
In the illustrative shared design, customer-owned identity and network controls would be marked separately from platform behaviour. A review exercise would choose one plausible substitution and trace its consequences. The collaboration should advance only if the parties can explain both the reusable pattern and the validation work each customer must still perform.
The useful learning would be the difference between the expected behaviour and the behaviour or responsibility actually demonstrated. If the exercise leaves validation ownership unresolved, that should remain a named next step. A recommendation to narrow the scope, improve a prerequisite, or hold the decision can be appropriate when the example exposes a material dependency.
Scope and next action
Keep the conclusion within the proposed collaboration scope
Confirm fit before the next commitment
- Design assumption
- This review is limited to the proposed collaboration scope.
- Candidate architecture diagrams
- The relevant owner must confirm access and the intended operating conditions.
- Partnership and capacity
- Neither an existing relationship nor available delivery staffing is established here.
A public partnership, certified status, staffing commitment, or response obligation would require separately verified evidence and authorisation. This collaboration model is presented for qualification; it does not announce an existing relationship.