Integration means getting your separate work apps to pass details to each other by themselves, in a way each one understands, so people don’t have to copy the same thing from screen to screen.
Plugs or a knot?
In our short film, four trains are your work apps: shop, stockroom, billing and delivery. The fifth, the partner’s line, is another company’s system. Auntie Saule’s parcel is an order. Mr. Feathers is anyone copying details between screens. The junction is all your apps together, and each line is one link between them. The plug is one agreed way for apps to ask each other for things (an API), the board is where news is announced once (events), and the shelf is where news waits until an app is ready (a message queue).
Wired: every new app needs a track to every other.
As each app joins: every app wired to every other
As each app joins: one agreed plug each, one shared board
Worth knowing: What each plug offers is agreed between the apps that use it, and helps only if both sides keep to it, so we add checks that test each side against the agreement. A new app still needs setting up and testing on its side, and the apps that want to use it still need setting up to ask it.
Worth knowing: A shared board is one more thing to look after. It needs an owner and a plan for when it is busy or down.
Watch · 2 min 3 sec
Auntie Saule turns ninety on Sunday, and her parcel rides five train lines that don’t talk to each other. A short story about one agreed plug and one shared board, so people can stop retyping.
The idea in plain words
Each idea in everyday words first, then the name experts use for it.
Say it once. Everyone who needs it can hear it.
01
Each app gets the same kind of plug: one agreed, written way to ask it for things, saying how to ask and what it answers. The shop can ask the stockroom what’s left and get a reply. A new app gets a plug of its own, so the others aren’t rewired to fit it. In the film, “the same plug” means the same kind of plug: each app gets its own.
Experts call this: APIs and API contracts
Worth knowing: What each plug offers is agreed between the apps that use it, and helps only if both sides keep to it, so we add checks that test each side against the agreement. A new app still needs setting up and testing on its side, and the apps that want to use it still need setting up to ask it.
02
When something happens, like a new order, it is announced once. Every app that needs it reads the board and gets on with its part; the others carry on.
Experts call this: events, publish and subscribe
Worth knowing: Apps that hear the news catch up shortly after, not all at the same moment. Announcements make it easy to add listeners and harder to follow one order from start to end, so we add a way to trace each one. A shared board is one more thing to look after. It needs an owner and a plan for when it is busy or down.
03
If an app is busy, the news waits on its shelf until it’s ready. If the same news turns up twice, the app checks whether it already acted and skips the repeat. Stuck items go to a lost-and-found shelf, not the bin.
Experts call this: message queues, dead-letter queues, safe repeats (idempotency)
Worth knowing: A waiting shelf holds news until an app is ready and keeps stuck items on a lost-and-found shelf instead of dropping them. It can sometimes hand over the same news twice, so each app is set up to spot repeats, and someone still watches the lost-and-found shelf.
04
Every team runs its own app its own way, and so can a partner company. They share the board, and details are written so both sides read them the same way.
Experts call this: federation, interoperability, data mapping
Worth knowing: A converter changes how details are written, not the facts. If details are wrong at the start, they arrive wrong, so we check them at the source too. Each team keeps its own system. A shared view (one screen where teams see the same order) shows only what each side agrees to share, and someone has to keep that agreement current.
Who hears the news?
Pick a piece of news, then switch on a busy day. The left column is Mr. Feathers (anyone copying details between screens) with his forms; the right is the shared board.
A busy day
By the third copy, Blue Lake is Blue Cake.
Mr. Feathers copies the order onto a form for the stockroom, another for billing and another for delivery.
Shop
Fills in a form for Mr. Feathers.
Stockroom
Gets a copy, retyped.
Billing
Gets a copy, retyped.
Delivery
Gets a copy, retyped.
ORDER IN goes up once. The stockroom, billing and delivery read it and get on with their part.
Shop
Says it once.
Stockroom
Hears it and gets on with its part.
Billing
Hears it and gets on with its part.
Delivery
Hears it and gets on with its part.
Worth knowing: Announcements make it easy to add listeners and harder to follow one order from start to end, so we add a way to trace each one.
Worth knowing: Apps that hear the news catch up shortly after, not all at the same moment.
Worth knowing: A waiting shelf holds news until an app is ready and keeps stuck items on a lost-and-found shelf instead of dropping them. It can sometimes hand over the same news twice, so each app is set up to spot repeats, and someone still watches the lost-and-found shelf.
Arrived, read, understood
Your shop sends one detail to the partner’s line. It passes three arches, and arriving is only the first. Pick a detail, then try it with a converter at the border.
Address: Lake House, Pier Street, Blue Lake (town last)
Their system reads the first line as the town, so the van is booked to a town called Lake House.
Every detail, both ways
Worth knowing: A converter changes how details are written, not the facts. If details are wrong at the start, they arrive wrong, so we check them at the source too.
Worth knowing: Each team keeps its own system. A shared view (one screen where teams see the same order) shows only what each side agrees to share, and someone has to keep that agreement current.
Sounds familiar?
If two or more of these ring true, your apps are leaning on people to carry details between them.
Seven plain questions. Answer what you can, and we’ll point to where we’d look first.
Answer any question and the places we’d look first appear here.
Answer “No” or “Not sure” to any question to email the list.
Nothing is stored or sent unless you choose to email it.
What we help with
Eight pieces of work. Start with the one link that hurts most, or join them up one at a time.
See how details really travel today, then agree how they should.
A clear picture of how your apps really pass details, and which links to fix first.
We follow one real journey, such as an order, across every app it touches, and draw every link, hand-off and place where someone retypes.
Experts call this: integration review, system landscape, API and event inventory
Also in this area
Agreed plugs in front of your apps, and one board for news.
Changing one app is less likely to break the others.
Agreed, written ways to ask each app for things. Numbered versions let an old way keep working while apps move to the new one. One front door checks every request before it reaches the app, old apps included.
Experts call this: API design, API contracts, gateways, versioning
New apps can start listening without anyone changing the sender.
Moments that matter, like “order in” or “parcel sent”, announced once, with a written list of who sends what and who reads it (an event catalogue).
Experts call this: event-driven architecture, publish/subscribe messaging, event catalogue
Teams wait less on one central team to make changes.
Teams keep their own apps and plugs, with shared rules at the junction, one screen where teams see the same order, and one sign-in where it helps. Shared sign-in needs both sides to agree whom they trust and to keep that list up to date, and each system still checks what that person is allowed to do.
Experts call this: federation, API and GraphQL federation, single sign-on
Adding a partner follows a known path.
Partner-facing plugs, agreed file exchanges, and a message to the partner’s system when something happens, so a new partner joins along an agreed path instead of a custom one.
Experts call this: partner APIs, B2B and EDI integration, webhooks
Also in this area
Details that mean the same thing on both sides.
Fewer mix-ups when details cross from one app, or company, to another.
One agreed way to write common things, such as customers, orders and dates, and converters between each app’s habits and your industry’s standards. A converter changes how details are written, not the facts. If details are wrong at the start, they arrive wrong, so we check them at the source too.
Experts call this: data mapping, shared data model, standards such as HL7 FHIR, ISO 20022 and EDI
Also in this area
Shelves, repeat checks and a label to follow each journey.
Lost or doubled news is easier to spot and trace.
News that waits when an app is away, gentle retries, a lost-and-found shelf, repeats that are spotted and skipped, and a label to follow each journey. Someone still watches the lost-and-found shelf.
Experts call this: message queues, retries, dead-letter queues, idempotency, tracing
Helpers get only what they are given, and their requests go through the same logged entrance.
Giving AI assistants limited, logged plugs into your apps, through the same entrance, permissions and checks as everything else, including the openly published way many AI assistants use to connect to apps.
Experts call this: agent-ready APIs, tool calling, Model Context Protocol
Also in this area
For your technical team: we work with what you already use, for example REST and OpenAPI, GraphQL and Apollo Federation, gRPC, AsyncAPI and CloudEvents, Apache Kafka, RabbitMQ, NATS, cloud event and queue services, API gateways such as Kong, OpenTelemetry, and standards such as HL7 FHIR, ISO 20022 and EDI.
Ways to start
We follow one real order through every app it touches and draw every hand-off, including the places people retype.
One busy link redesigned as an agreed plug, built with one team.
We follow one failed hand-off end to end, then add a waiting shelf and a watched lost-and-found shelf to that link.
How we work
The film’s last stop in more detail: trace, agree, connect, with listening first and your team running it after.
Listen
We talk to the people who retype, chase and fix mix-ups, and pick one journey that hurts, such as an order from shop to doorstep.
Trace
We draw every app, link and hand-off on that journey, and mark where details are copied, lost or doubled.
Agree
We agree the plugs, the announcements and the shared way of writing details for that journey with you, and who owns each.
Connect
We build that journey end to end with one team, with tracing and the shelves in from the start, then move the next links over one at a time while the old ones keep running.
Your team runs it
Your people own the list of plugs and announcements, the agreements and the check-ups, with templates and training. We can stay on to help with the next line if you prefer.
Where it fits
Illustrative examples, not customer stories: the kind of work this approach suits.
Good to know
Plain answers to what owners and tech leads ask first. Something else on your mind?
Ask us directlyGetting your separate work apps to pass details to each other by themselves, in a way each one understands, so people can stop copying them from screen to screen.
Integration is connecting the systems. Interoperability is them understanding each other once connected: the details arrive, can be read, and mean the same thing on both sides.
An API is an app’s plug: every app gets the same kind, one agreed, written way to ask it for things, and what it answers. Event-driven means an app announces “this happened” once, and every app that cares reacts, instead of all of them asking again and again.
Often not. We can put an agreed plug in front of many of them so they keep working while the rest connect, and move pieces over one at a time if and when that makes sense. Many old systems can be given a proper connection without replacing them; some need changes first, and we say which after we look.
No. We start from the tools you already have and the connections that hurt most. A new platform comes in only where it helps.
It can, and the shared board is a central piece too. The difference is that the board only carries the news: each team keeps its own app and its own decisions, so changes don’t wait on one central team. The board still needs an owner and a plan for when it is busy or down.
News waits when an app is away, failed hand-offs are tried again gently, items that can’t be delivered go to a shelf someone watches, repeats are acted on once, and each journey carries a label you can follow. These catch many problems, not all of them.
We agree a few plain measures with you at the start, for example how many hand-offs are still typed in by hand, how often news lands on the lost-and-found shelf, and how long a change in one app takes to reach the others. You keep the numbers and see how they move, so you can judge for yourself whether it’s helping; we don’t promise targets for them.
Heard it before?
Answer: Someone still decides who announces what, who listens, and what “order” or “paid” means. The tool is the tracks, not the timetable.
Answer: Often not: many old apps can get the same kind of plug and keep running, like the creaky stockroom train in our story. Many old systems can be given a proper connection without replacing them; some need changes first, and we say which after we look.
Answer: Arriving, being read and meaning the same thing are three different checks. A converter changes how details are written, not the facts. If details are wrong at the start, they arrive wrong, so we check them at the source too.
Answer: It can become the new bottleneck: one central team everyone waits on. A shared board is a central piece too, but it only carries the news; each team keeps its own app and its own decisions. The board still needs an owner and a plan for when it is busy or down.
Answer: They make adding a listener simple. Announcements make it easy to add listeners and harder to follow one order from start to end, so we add a way to trace each one.
Answer: Apps, partners and rules change, so plugs need an owner, versions and a regular check-up. We connect one link at a time, starting with the ones that hurt most. It’s steady work, not a switch you flip.
Download the one-page overview or the playbook to share with your team. Or ask us to trace one order: tell us which apps it passes through and where people retype, and we’ll reply with where we’d look first.
Or write to contact@algoshred.com
