Skip to content

Integration and connected systems

The order is in one system
and not in the other.

Your process does not stop where an application ends. An order might start on the website and finish in finance, passing through stock, the warehouse and a carrier on the way. The systems do not have to become one. The process does have to work, and somebody has to notice when it does not.

See how it works

Sometimes the right answer is fewer interfaces, not another one.

Sound familiar?

A message that succeeded is not the same as a job that got done.

These are the things operations and finance teams describe when they ring us about connected systems.

  • The order is in one system and not the other

    Somebody notices at the end of the week, usually because a customer rang.

  • Somebody rekeys it every morning

    A spreadsheet and an hour of somebody's day are holding two systems together.

  • It failed quietly

    No alert, no error anyone saw, and no way of knowing how long it had been happening.

  • Two systems disagree about stock

    The website says available, the warehouse says otherwise, and the customer finds out first.

  • Nobody owns the interface

    The person who built it left, there is no documentation, and everybody hopes it keeps working.

  • The same invoice was raised twice

    A retry ran when it should not have, and the correction takes longer than the original job.

How it works

From a broken handover to a process that holds.

Seven steps. The second one occasionally saves people a project they did not need.

  1. Start with the process, not the systems: What has to happen, from the customer placing an order to the money arriving.
  2. Ask whether the connection should exist: Sometimes the honest answer is to change the process or retire a system instead.
  3. Decide who owns each piece of information: If two systems both think they own the customer record, you are managing conflict forever.
  4. Design what happens when it breaks: Because it will. Queue, retry, alert, correct or stop, decided in advance.
  5. Test the awkward paths: Bad data, duplicates, timeouts and the other system being down, not only the happy path.
  6. Go live with someone watching: Monitoring, a named owner and a route for the day something goes wrong.
  7. Keep it working: APIs change, volumes grow and businesses change. An interface is something you own, not something you finish.

Design the failure, or discover it on a Saturday night.

What customers say

People who have been through it.

Around 80% of our business comes from existing customers and referrals. These are their words, not ours.

80%

of our business comes from existing customers and referrals.

All customer stories

The best I’ve ever experienced in over 20 years of collaboration.

Programme Manager, Hill & Smith Plc

Four decisions

What you are approving, and when.

Four points where the connection has to justify itself again, in language you can take to a board.

Should this connection exist?
Gate 1Before any design work

Should this connection exist?

The cheapest place to stop. We check the business event, the value, and whether integration is genuinely the best answer.

Confirmed at this gate

  • The business event and what it is supposed to produce
  • Which systems really belong in the future, and which do not
  • Which system is the trusted source for each piece of information
  • The alternatives, including changing the process or doing nothing

Decision

  • Integrate
  • Replace
  • Consolidate
  • Retire
  • Defer

Swipe, drag or use the arrow keys to move between decisions.

Check the fit

A few questions before integration scope is agreed.

A routing aid rather than a quote. Your answers come with you into the conversation, so nothing has to be repeated.

Question 1 of 6

0 of 6 answered

1. What best describes the current situation?

Select one option.

Common questions

Questions leaders ask about integration.

Part of the InteliSense Delivery System

Integration is part of how we deliver, not a separate craft.

The same delivery system applies: decisions recorded, failure designed, testing against consequence rather than the happy path, and an owner named before anything reaches production. If you want the wider picture, our delivery approach explains how integration sits alongside data migration, testing and go-live.

How we deliver

A conversation, not a pitch

What is not connecting today?

The handover somebody does by hand, the interface nobody owns, or the two systems that never quite agree. Start there and we will tell you what we would look at first.