Business systems engineering glossary
Eighteen practical definitions that connect architecture, data, integration, AI and automation language to business decisions and operating consequences.
01Business system
The connected people, decisions, processes, data, applications, rules and controls that produce a business outcome.
Why it matters to the business
It prevents a technology component from being treated as if it were the whole operating problem.
Example
Order fulfilment includes decisions, inventory meaning, partner exchanges, exceptions and evidence — not only the order application.
02Enterprise architecture
A coherent view of capabilities, information, applications, technology, decisions and transitions used to guide organisational change.
Why it matters to the business
It connects investments and delivery choices to the capabilities and constraints they affect.
Example
A target architecture shows not only future components but ownership, transition states and decision principles.
03Integration
The designed exchange and coordination of data, events or actions between system boundaries.
Why it matters to the business
Reliable integration preserves meaning and status across the points where no single component controls the entire outcome.
Example
A partner order exchange defines identity, validation, response, retry and recovery as well as message transport.
04Interoperability
The ability of independent systems and organisations to exchange information and use it with a shared, operationally meaningful interpretation.
Why it matters to the business
A message received but misunderstood is connected technically, not interoperable in practice.
Example
Both parties interpret accepted, rejected and pending states consistently and know who must act.
05Data governance
The decisions, responsibilities, policies and controls that make data meaning and use accountable.
Why it matters to the business
It connects data quality and access work to material business decisions rather than a standalone compliance exercise.
Example
An owner can define a critical term, approve use and resolve a quality issue against a stated decision risk.
06Data lineage
Traceable knowledge of where data originated, how it changed and where it was used.
Why it matters to the business
Lineage supports explanation, impact analysis, control and challenge when a decision depends on transformed data.
Example
A reported value can be followed from source through validation and aggregation to the decision dashboard.
07Data contract
An explicit, versioned agreement about the structure, meaning, quality, ownership and behaviour of data exchanged across a boundary.
Why it matters to the business
It makes change and failure expectations testable rather than leaving consumers to infer them.
Example
A contract states required fields, semantic definitions, version policy, rejection behaviour and responsible owner.
08Event-driven architecture
An architecture in which significant state changes are expressed as events and consumed asynchronously by interested components.
Why it matters to the business
It can decouple timing and ownership, but only when event meaning, identity, ordering and recovery are designed.
Example
An order-approved event records the business fact and stable identity rather than issuing a vague update notification.
09Idempotency
A processing property that lets the same request or event be applied more than once without creating an unintended additional business effect.
Why it matters to the business
It allows safe retry when a sender cannot know whether the first attempt completed.
Example
Repeating a payment-status update returns the established result rather than creating a second payment.
10Target architecture
The intended future structure, responsibilities and principles that support a defined business capability and direction.
Why it matters to the business
It gives decisions a coherent destination without assuming a single irreversible implementation path.
Example
The target describes domain ownership, interfaces and control boundaries required for dependable partner onboarding.
11Transition architecture
A deliberately operated intermediate state between current and target architectures.
Why it matters to the business
It makes coexistence, temporary controls, risk and exit criteria part of the plan rather than accidental delivery residue.
Example
Old and new order services run together with reconciliation, authority and retirement criteria defined.
12AI readiness
The degree to which a specific AI use has suitable value, data, workflow, architecture, oversight, evaluation and operating ownership.
Why it matters to the business
It prevents model feasibility from being mistaken for production capability.
Example
A use case is ready only when its decision owner, data fitness, human review, monitoring and fallback are explicit.
13Human oversight
A designed set of human responsibilities, information, authority and intervention points around automated or AI-supported action.
Why it matters to the business
A human in the loop is meaningful only if that person can understand, challenge and change the outcome in time.
Example
A reviewer receives relevant context, can reject a recommendation and knows when to suspend automated execution.
14Process automation
The engineered execution of repeatable process steps, rules or exchanges with explicit exception and control behaviour.
Why it matters to the business
It should remove avoidable effort without hiding accountability or accelerating a flawed process.
Example
A workflow routes standard cases automatically while preserving human authority for defined exceptions.
15Operational model
The responsibilities, decision rights, processes, capabilities and measures through which a system is run and improved.
Why it matters to the business
A technical capability without an operational model has no durable owner or response to change and failure.
Example
A data domain model defines who decides meaning, monitors controls and funds remediation.
16Technical debt
A present constraint created by earlier technical decisions that increases the cost, risk or delay of useful change.
Why it matters to the business
Debt becomes actionable when linked to a business decision or change path, not only listed as poor code.
Example
A shared database blocks independent release of two capabilities and raises migration risk.
17System context
The relevant actors, boundaries, dependencies, information, constraints and environment surrounding a system or decision.
Why it matters to the business
Context determines whether a local design remains valid when placed in the real organisation.
Example
An automation design includes the teams, approval authority, source systems and exception routes around the workflow.
18Decision record
A concise, durable account of a consequential decision, its context, options, reasoning, consequences and review trigger.
Why it matters to the business
It preserves why a choice was made so later change can challenge the right assumptions instead of repeating discovery.
Example
A record explains why asynchronous exchange was selected and when volume, latency or control changes require review.
No matching terms
Discuss a system challenge
Build what comes next without losing what must remain true.