The missing response
A member of staff accepts an offered case transfer. The case service records the transfer, but the response never reaches the screen. The person sees a timeout and tries again. Can the service recognise the same request? Can the person find out who now owns the case?
Integration design assigns responsibilities to applications and services, then defines how they exchange information and request work. An interface is the agreed way to make that exchange. Its contract describes what the information means, who may act, what result is accepted and what happens when the exchange fails.
The organisation example establishes accepted ownership. Here a possible later software increment carries that rule through requests, updates and notifications.
The useful questions
| Concern | Question for the cancellation service |
|---|---|
| Responsibility | Which system holds the accepted case assignment, and which confirms the booking? |
| Meaning | Does “accepted” mean a message arrived, a transfer took effect or the learner’s problem was resolved? |
| Authority | Who may request a change, and which service checks that permission? |
| Contract | What inputs, results, versions and failure responses must both parties understand? |
| Timing | Must the caller wait, or can the work complete later? How is its progress found? |
| Recovery | What happens after a timeout, duplicate request, conflicting update or unavailable supplier? |
| Change | Which consumers must adapt when a field, rule, supplier or service changes? |
A diagram can show logical responsibilities without deciding how many programs, servers or deployments are needed. A case service and booking service might be separate applications or parts of a larger application. Their responsibilities still need to be clear.
Requests and facts
A command requests a change, such as accepting a transfer. A query asks for information, such as the current owner. An event reports a fact, such as a transfer that has taken effect. Name each interaction according to what it does.
A delivery receipt says the message arrived at a particular point. Business acceptance says the requested change passed its rules and took effect. Completion of the learner’s whole case is a further result. Record these separately so that a successful technical exchange is not mistaken for a completed service.
This distinction matters across working channels. A mobile client may save an action while offline, then submit it when connected. Show whether the action is still local, awaiting acceptance or accepted by the responsible service. A conflicting update needs an agreed resolution rule.
The existing landscape
Map the business capabilities and processes to the applications that support them. Record who owns each application, the information it controls, its consumers and its support history. A missing responsibility, duplicated function or costly dependency may justify reusing, changing or retiring an application.
Compare these options with adding a new service. The smallest useful change may be a clearer contract on an existing system. Include migration, continuing support and eventual replacement in the decision.
Before replacing a supplier, agree how records remain accessible, which behaviour must stay compatible, and how work moves to the replacement. Record the transition and exit arrangements.
Meaning and authority
An interface must preserve meaning across its participants. Components written in different languages need compatible interpretations of identifiers, amounts, dates, missing values and errors, as well as a message format they can read.
An interface to a prompt or artificial intelligence (AI) tool needs to specify its inputs, expected outputs and permitted actions. Define how the receiving component checks the result. An output with the required structure may still be incorrect or uncertain. Keep the source context and relevant prompt and model versions available for investigation, within the agreed access and retention rules. The service’s controls determine who may change a case.
Levels of detail
A conceptual view assigns responsibilities and identifies outside parties. A logical view describes operations, information, rules and failure behaviour. A physical view chooses protocols, message formats, products and deployment.
For a handover, the logical contract can require acceptance of the current case version. A later implementation might carry that version in an HTTP request or a message. Preserve the rule when choosing the mechanism. The comparison examines useful notations and interaction choices.
Operation and change
Agree response times, availability, capacity, recovery and support for each participant. A managed cloud service brings supplier guarantees, quotas and regional dependencies into that agreement. Name who handles failed work and how service can resume when a dependency is unavailable.
Reports and other derived views also need agreed timing and recovery. Record how accepted facts and corrections reach each consumer, and how people can recognise a delayed or incomplete result. The data section develops those choices.
The worked example connects these conditions to case ownership. To examine a replacement channel, language or supplier, identify which contracts still hold and which assumptions need review. Changed business obligations may require a changed contract too.
Speed and quality
Observe time to agree an interface, connect another consumer, investigate a failed exchange and recover a case. Record duplicate effects, unresolved outcomes, stale reports and effort spent coordinating changes. Include the cost of support and replacement when comparing a quick initial integration with a more explicit contract.
Assessing long-term usefulness requires a record of actual use and change. These questions help collect that record when a design is put into practice.
Security develops identity, authority and protected interactions across the services, including the Zero Trust view.
Methodology configuration
Your method may describe applications, components, services, actors or integration points. Map each term to the responsibility it carries. Link an interface definition to the relevant business rule, data definition, support procedure and review step.
Use Methodology configuration to map the terms and steps, then the cycles and templates to review an existing approach.