API, ESB and event integration: choosing the right interaction pattern

The core decision

For “API, ESB and event integration: choosing the right interaction pattern”, define the outcome as a change in management practice. The central object is infrastructure and security controls; it needs an agreed source, decision owner and observable state after the action “record interfaces and owners”.

The first evidence is not a solution presentation but a reproducible example of “integrations have no owners”. It allows the team to set the process boundary, inspect baseline data and select the fact that will confirm completion.

When to use APIs, an ESB and events

An API defines a governed contract for requesting a function or data. An ESB centralises routing, transformation and orchestration when many systems must be connected. Event integration publishes a change, allowing subscribers to react independently and asynchronously.

The choice depends on temporal coupling, volume, latency, number of consumers, redelivery requirements and contract ownership. One architecture often combines them: APIs for commands, events for notification, and a platform for observability and policies.

Objects under management

Describe the boundary through object records rather than system names. For integrations and data flows, record meaning, identifier, source, quality owner and update event; for infrastructure and security controls, also document the relationship rule.

Test the link between integrations and data flows and infrastructure and security controls using an end-to-end example. The team performs “design target transitions”, traces transformations and identifies where a discrepancy arises, who corrects it and which dependent outputs are recalculated.

• Object 1: Business services and criticality. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: Dependencies are known only to individual specialists.
• Subject area 2: Applications and components. Verification basis: system of record, owner authority and the signal “a component cannot be replaced in isolation”.
• Record 3. Object: Integrations and data flows. Required details: identifier, lineage, quality rule and update event. Signal: There is no criticality classification.

Integration contract

An integration design begins not with arrows between applications but with events and accountability. It defines who creates a record, where it becomes authoritative, which checks run before transfer, how duplicates are handled and which action is blocked when records disagree. The reference object here is infrastructure and security controls.

Every exchange has a business owner, technical owner and observable control point. API, messaging, file transfer or another technology is selected after frequency, volume, resilience and error behaviour are known. For the signal “integrations have no owners”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Boundary 5. Object: Versions, migrations and operations. Define the source, frequency, permitted transformations and response to “migration has no rollback scenario”.
• Control record 4. Object: Infrastructure and security controls. Observable signal: Integrations have no owners. Accountability: semantic owner and quality owner.
• Record 3. Object: Integrations and data flows. Required details: identifier, lineage, quality rule and update event. Signal: There is no criticality classification.

Services and critical dependencies

For infrastructure and security controls, the sequence begins with “record interfaces and owners”. The owner of the next step reviews its output; an incomplete result is returned with a specific issue concerning data, a rule, authority or an architecture dependency.

Maintain an assumptions log for infrastructure and security controls. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• Step 1. Describe business services. Output: business services and criticality.
• Map applications and data is the action at stage 2. The output documents applications and components.
• At position 3, the action is “record interfaces and owners”; its result is integrations and data flows.
• Stage 4: identify critical dependencies. The working artefact describes infrastructure and security controls.

From signal to decision

The article addresses “API, ESB and event integration: choosing the right interaction pattern”. The adjacent management issue is choosing the right interaction pattern. The two may share data or participants while differing in decision horizon, role authority and architecture boundary, so they are documented as separate entries in the decision map.

A signal–risk–action chain defines the subject-specific focus. Here the signal is “dependencies are known only to individual specialists”, the material risk is “treating trust as a marketing label”, and the testable action is “design target transitions”. This chain turns a broad term into a concrete decision.

• Decision 1: object — business services and criticality; signal — there is no criticality classification; action — record interfaces and owners.
• Decision 2: object — applications and components; signal — integrations have no owners; action — identify critical dependencies.
• Decision 3: object — integrations and data flows; signal — migration has no rollback scenario; action — design target transitions.

Diagnosis before solution selection

Diagnosis examines a concrete episode involving integrations and data flows. Its record states the time, participants, data used, decision made and consequence; recurrence is checked against a second sample.

Review the signal “dependencies are known only to individual specialists” with the process owner. If its cause lies outside the selected boundary, record the dependency separately and do not expand scope without a new decision on timing, resources and acceptance.

• Signal: Dependencies are known only to individual specialists. Evidence includes an example, frequency and consequence for business services and criticality.
• Event to test: a component cannot be replaced in isolation. Evidence shows timing, frequency and consequence for applications and components.
• Indicator: There is no criticality classification. Analysis needs an actual example and the resulting change in integrations and data flows.

Authority and escalation

Build the authority matrix around decisions concerning versions, migrations and operations. Assign the right to change a rule, duty to prepare data, authority to approve an exception and accountability for confirming the outcome separately.

Define the escalation path for “record interfaces and owners” concerning versions, migrations and operations in advance. The business owner is accountable for decision meaning, the data owner for evidence fitness, the architect for dependency integrity and the project manager for the agreed work sequence.

• Business owner: decision area — business services and criticality; control action — map applications and data.
• Architect is accountable for applications and components and confirms the action “record interfaces and owners”.
• Role: Data owner. Decision object: integrations and data flows; verified step: identify critical dependencies.
• Project manager decides within infrastructure and security controls; the basis is prepared through “design target transitions”.

End-to-end outcome test

The acceptance criterion for versions, migrations and operations includes a baseline sample, calculation rule, expected change and source of the actual outcome. The interpretation owner confirms that comparison conditions have not changed.

The end-to-end test starts with “dependencies are known only to individual specialists”, passes through an authorised decision and “design target transitions”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Criterion 1: Business services and criticality; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: There is no criticality classification.
• Criterion 2. Object: Applications and components. Test fields: baseline, target change, source and owner. Signal: Integrations have no owners.
• 3. Acceptance object: integrations and data flows; compare the baseline sample, expected change and confirmed actuals. Test signal: Migration has no rollback scenario.
• Evidence item 4 describes infrastructure and security controls, comparable test conditions and the person accountable for interpretation. Signal: Dependencies are known only to individual specialists.

Constraints and risk control

The risk map starts with two conditions: “treating trust as a marketing label” and “claiming compatibility without testing”. Each receives an observable event, decision owner, control and outcome that requires a stop or rollback.

A regulated environment maintains a register of applicable requirements: official source, version, interpretation owner, affected process and confirmation method. The risk “claiming compatibility without testing” is reviewed whenever affected data, integrations, roles or control scenarios change.

• Risk: Selecting a platform without a dependency map. Control: describe business services. Evidence: integrations and data flows.
• Risk condition 2: Claiming compatibility without testing. Response: Map applications and data. Testable evidence: Infrastructure and security controls.
• The risk scenario “a shared component becoming a new failure point” is addressed through “record interfaces and owners” and confirmed using versions, migrations and operations.
• Controlled constraint: transition without operational criteria. The owner performs “identify critical dependencies” and provides business services and criticality.

First working session

The first session examines one real case involving integrations and data flows. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “integrations have no owners”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “record interfaces and owners”; assign an additional test or stop condition to the risk “claiming compatibility without testing”.

• Step 1. Describe business services. Output: business services and criticality.
• Map applications and data is the action at stage 2. The output documents applications and components.
• Evidence item 4 describes infrastructure and security controls, comparable test conditions and the person accountable for interpretation. Signal: Dependencies are known only to individual specialists.
• Test 5 concerns versions, migrations and operations. The method, interpretation owner and outcome source are documented. Signal: A component cannot be replaced in isolation.