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

Source basis

This bridge note is informed by Arqua’s Execution Admissibility Architecture materials and the public TOGAF Standard materials from 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.