Arqua in TOGAF-Aligned Enterprises
How enterprise architecture governance extends to the T=0 execution boundary.
TOGAF-aligned enterprise architecture helps organisations structure, govern, and communicate architecture change.
Arqua adds the execution-admissibility lens: where architecture becomes consequence-bearing execution, and where authority, evidence, context, constraints, and state must be resolved at T=0.
This page is a translation and alignment note. It is not an official TOGAF extension, certification, endorsement, or formal representation of The Open Group or the TOGAF Standard.
Core thesis
TOGAF-aligned architecture governance remains necessary.
But enterprise architecture artefacts do not, by themselves, prove whether a consequential action is admissible at the moment it binds the institution.
Arqua extends architecture governance to the execution boundary:
Is this action allowed to execute now?
What TOGAF already gives enterprise architects
TOGAF-aligned EA concern | Typical enterprise value |
Architecture development method | Repeatable approach for developing and governing architecture. |
Architecture governance | Structured oversight of architecture decisions, standards, and conformance. |
Architecture content | Common artefacts, viewpoints, building blocks, and roadmaps. |
Business / data / application / technology architecture | Multi-domain representation of enterprise change. |
Transformation planning | Roadmaps, migration planning, and capability evolution. |
Architecture repository | Reusable architecture assets and governance records. |
The execution-admissibility gap
TOGAF-aligned architecture can show what the enterprise intends to design, change, govern, and transition.
Arqua asks a narrower execution question:
When a workflow, system, model, agent, integration, or operational process is about to bind consequence, is the action admissible at T=0?
Most EA artefacts can show:
- target state,
- capabilities,
- processes,
- systems,
- data,
- standards,
- roadmaps,
- controls.
Arqua adds:
- execution surfaces,
- consequence systems,
- commit boundaries,
- authority states,
- evidence-at-execution,
- admissibility outcomes,
- non-action, hold, and escalation as valid outcomes.
How Arqua extends TOGAF-aligned architecture work
TOGAF-aligned practice | Arqua extension |
Architecture governance | Adds governance of consequence-binding execution at T=0. |
Architecture repository | Adds Architecture of Record for execution surfaces and commit boundaries. |
Architecture principles | Adds admissibility principles such as “Explanation is not authority” and “Non-action is a valid outcome.” |
Architecture viewpoints | Adds execution topology, authority lifecycle, commit boundary, and evidence-at-execution views. |
Building blocks | Adds admissibility control points and execution-surface patterns. |
Migration planning | Adds staged movement from assumed authority to mapped, controlled, and evidenced execution. |
Conformance review | Adds pressure testing of high-consequence workflows before execution control is trusted. |
ADM-to-EAA alignment
TOGAF ADM-aligned activity | Execution-admissibility question | Arqua artefact |
Preliminary / architecture governance | What execution-governance principles must apply? | Arqua principles, boundary language, EAA policy lens. |
Architecture vision | Which consequences matter? | Consequence statement, workflow candidate list. |
Business architecture | Who has authority to bind consequence? | Authority lifecycle view. |
Information systems architecture | Which systems propose, decide, or execute? | Execution topology and system role map. |
Technology architecture | Where can controls be enforced? | Commit-boundary and control-surface map. |
Opportunities and solutions | Which workflows should be pressure tested first? | Pressure Test candidate list. |
Migration planning | How does the enterprise mature execution control? | EAA maturity roadmap. |
Implementation governance | Are controls preserved through delivery? | AoR-to-delivery handoff. |
Architecture change management | Has context, authority, or execution topology drifted? | Drift register and AoR update cycle. |
Architecture artefact mapping
Existing EA artefact | Execution-admissibility addition |
Capability map | Consequence-bearing capabilities. |
Process map | Execution surfaces and commit boundaries. |
Application map | Proposal systems, decision systems, and consequence systems. |
Data lineage | Evidence-at-execution lineage. |
Control catalogue | Admissibility control points. |
Role / RACI model | Authority state and delegation boundary. |
Roadmap | Progression from assumed authority to T=0 control. |
Architecture decision record | Whether the decision remains non-binding until execution is admissible. |
Common failure signals
- Architecture governance approves a target state, but no one knows where consequence actually binds.
- Processes are mapped, but execution surfaces are not.
- Systems are classified by application domain, but not by whether they propose, decide, or execute.
- Controls exist in design documents, but not at the commit boundary.
- Authority is assumed from workflow state rather than re-resolved at execution.
- AI or automation outputs are treated as executable actions.
- Architecture review happens before delivery, but no admissibility evidence exists at runtime.
- Audit reconstructs authority after execution has already occurred.
Diagnostic questions
- Which enterprise workflows bind financial, legal, operational, regulatory, or customer consequence?
- Where are the execution surfaces in the architecture?
- Which systems propose actions, which systems decide, and which systems execute?
- Where is the T=0 commit boundary?
- Is authority resolved at execution or inherited from an earlier approval?
- What evidence must exist before execution is permitted?
- What makes hold, refusal, or escalation a valid governed outcome?
- Can the Architecture of Record show where control must exist?
- Does implementation governance preserve the admissibility boundary?
- How is authority, context, or execution drift detected?
Example workflow
A payment workflow appears in the enterprise architecture as a process, application integration, data flow, and control path.
TOGAF-aligned artefacts can describe the target state and governance model.
Arqua asks:
- Where does the payment become consequence-binding?
- Which system executes the payment?
- Is authority still valid at that moment?
- What evidence is required before release?
- What prevents release if authority, evidence, context, constraints, or state has changed?
The architecture is not complete until the execution boundary is visible.
Engagement pathway
- Run an Enterprise Bridge Workshop.
- Select one high-consequence workflow.
- Map the execution topology.
- Identify execution surfaces and consequence systems.
- Locate T=0 commit boundaries.
- Define authority, evidence, context, constraints, and state requirements.
- Produce an Architecture of Record baseline.
- Hand off architecture guardrails to delivery partners.
Key links
- Enterprise Bridges
- Request a Briefing
- Pre-Execution Pressure Test
- Architecture of Record (AoR)
- SCIA Runtime Reference Architecture
Source basis
This bridge note is informed by Arqua’s Execution Admissibility Architecture materials and the public TOGAF Standard materials from The Open Group.
- Enterprise Bridges
- Architecture of Record (AoR)
- Pre-Execution Pressure Test
- SCIA Runtime Reference Architecture
- TOGAF Standard — The Open Group
This page is a translation and alignment note. It does not assert endorsement, certification, affiliation, or official extension of TOGAF or The Open Group.
Boundary note
“This page describes architectural alignment patterns. It does not assert certification, endorsement, partnership, affiliation, official framework extension, legal assurance, regulatory compliance, system operation, or implementation. Arqua operates at the architecture and governance layer. Runtime behaviour, system execution, regulatory compliance, and operational responsibility remain with the deploying organisation and its chosen delivery partners.”
CTA
Primary: Run an Enterprise Bridge Workshop
Use the workshop to translate TOGAF-aligned architecture governance into execution-admissibility questions, artefacts, and first workflow candidates.
Secondary: Build an Architecture of Record Baseline
Map execution surfaces, consequence systems, authority boundaries, and admissibility control points for one high-consequence workflow.
© Arqua Pty Ltd. All rights reserved.