A collection of connections is not yet an architecture.
Integrations often accumulate one request at a time. A connector serves a new channel, a scheduled export feeds a report and a custom script fills an urgent gap. Eventually, teams struggle to explain where a value originates or what will break when a system changes.
We connect the technical inventory with the people who depend on it. A nightly export may look obsolete until finance explains the reconciliation it supplies. Each proposed change needs that context, a transition path and a team able to operate the replacement.
The business boundary, data owner and support model.
| Architecture decision | What it determines |
|---|---|
| Business boundaries | Define the outcome each flow supports and the point at which responsibility moves between teams. A system boundary should not leave a business decision without an owner. |
| Data authority | Specify which application owns each important record and field. Where ownership changes during a lifecycle, document the event and the rules for later corrections. |
| Operating model | Decide who monitors, supports and changes the connections. Consider the skills, tooling, documentation and escalation the organization can sustain. |
Turn the landscape into a sequenced roadmap.
- 01
Inventory
List systems, interfaces, schedules and known dependencies. Capture existing documentation and validate it with people who operate the process.
- 02
Prioritize outcomes
Identify where disconnected information creates the greatest consequence. Separate required business continuity work from optional convenience and longer-term improvement.
- 03
Compare patterns
Evaluate native capabilities, packaged connectors, integration platforms, files and custom APIs against each flow. Explain trade-offs in control, effort, cost and maintainability.
- 04
Sequence delivery
Group related flows into operationally complete releases. Define prerequisites, transition states, acceptance evidence and the owner of each decision.
Make nonfunctional requirements specific.
Security, reliability and performance need more detail than a heading in a requirements document. Identify the data classification, authorized users, expected volume, acceptable delay and recovery needs for each flow. These requirements influence authentication, error handling, monitoring and the choice of platform.
The business should also understand its dependencies on third-party providers and licenses. Include the cost and responsibility of running the solution, not only the initial build. A design that cannot be supported by the organization is incomplete even if the technical proof works.
Decide what can safely stay as it is.
A stable connection with clear ownership may be worth retaining even if it uses a different pattern from the rest of the estate. Replacement becomes more compelling when support is ending, recovery is unreliable or the business process has changed.
The roadmap should show those reasons alongside the transition cost. Moving a flow to a shared platform can simplify support, but only if the required behaviour and exceptions survive the move. A small proof of the difficult transaction can settle that choice before the migration is estimated.
The output of a strategy review
- What does a useful strategy deliverable contain?
Agree the specific scope, but useful outputs can include a system and flow inventory, ownership map, architecture options, key risks and a phased roadmap. Each priority should have a business purpose and a decision owner. The document should support delivery choices, not only describe technology.