Point-to-point integration versus a hub

What is point-to-point integration versus a hub?

These are the two shapes the connections between your systems can take, and you end up with one of them whether you decided or not.

Point to point means every system talks directly to every other system it needs. The webshop writes orders into the accounting package. A nightly script copies new customers from CRM into the ERP. Each link is built on its own, lives on its own, and breaks on its own.

A hub is the other shape. Every system connects once to a central place, and that place routes the traffic, converts the formats and records what happened. Microsoft describes the switch in its BizTalk documentation as replacing point-to-point communications with a flexible hub-spoke arrangement. In practice the hub can be a message broker, an integration platform, an iPaaS, or, for reporting traffic, your warehouse.

You build both shapes with the same connectors and the same APIs, so the choice is not about tooling. It is about where the knowledge of who talks to whom ends up: spread across every link, or written down in one place.

The arithmetic behind the whole argument

Take n systems that could each need to reach each other. Point to point, that is up to n(n-1)/2 links. Through a hub, it is n. Four systems: up to 6 links against 4. Six systems: 15 against 6. Ten systems: 45 against 10, and nobody has a mental model of 45 links.

The total is not the number that decides it, though. What decides it is the price of one extra system. Going from six systems to seven adds up to 6 new possible links point to point, and exactly 1 to a hub. Point to point grows by however many systems you already have. A hub grows by one, every time.

Two caveats before you take that curve too seriously. Almost nobody builds every pair, so your real number is a fraction of the theoretical one. And the curve says nothing when you have two systems and one link: a hub there buys you a licence, an extra moving part and a new skill in the team in exchange for nothing. Point to point is the right way to start, and it stays right for longer than platform vendors tend to suggest.

Six systems, counted properly

A technical wholesaler near Hasselt, about forty people. Six systems: the webshop, the accounting package, the CRM, the warehouse system, the mail platform and Power BI. Ask the office and you get an answer of four or five links, because those are the ones people talk about. Sit down and count, and the list runs to eleven.

Orders go from the shop to accounting overnight and stock comes back hourly. Customers go from CRM to accounting through a Power Automate flow, and outstanding invoices come back through a script on a laptop under a desk. Opt-ins go from the shop to CRM through Zapier, and both the shop and CRM feed the mail platform. Accounting sends picking orders to the warehouse system, which reports shipments back. Power BI reads accounting through a gateway, and the warehouse system through a monthly Excel export a colleague makes by hand.

Eleven links across eight of the fifteen possible pairs, because the formula counts pairs and real life builds each direction separately. Six years, four people, four different tools, and none of it on the diagram somebody drew in year two. The costs that surface later are not in that diagram either. Nobody knows how many links exist, and the count above took an afternoon and two people who have been there a while. Adding one field means finding every link that carries it: sales wants a delivery instruction on the customer record, and the customer record travels over three of those eleven links, in Power Automate, in Zapier and in the mail platform's own sync. Three changes, three tools, three people. Credentials sit wherever the link was built, in a script, in a flow, in somebody's personal Zapier connection. There is no shared logging, so a link that fails at two in the morning fails silently unless whoever built it added an alert.

Then there is the departure, and that one is not only about lost knowledge. Microsoft documents it as a mechanism: when the account that created a connection is removed or disabled in the directory, the connection becomes invalid and affects all users who share it. People leaving breaks integrations on its own.

If you want one signal instead of a rule, take this one. Write down your interfaces, with source, target, what moves and who owns it. If you cannot produce that list in an afternoon, you have outgrown point to point, whatever the count says.

What a hub buys you, and what it costs

What you get is operational rather than architectural: one place to see runs and failures, one place for credentials and retries, and transformations you write once and call everywhere.

The first of those is the big one. Microsoft's guidance on flow failures says a per-run alert email only goes out when the system recognises a known, fixable cause, and even then a 28-day cooldown follows before the same flow can alert again. The complete picture lives in the Monitor experience in the Power Platform admin center, which shows every failed run with no exclusions and lets you see failures across all flows in an environment in one place. Scattered links have no equivalent of that screen. For secrets, Microsoft's basic enterprise integration architecture on Azure gives Key Vault the role of centralised secret storage for Logic Apps and API Management, so rotating a password becomes one change instead of a hunt.

The bill has three lines. A licence, usually priced per run or per task, which gets uncomfortable at volume. A skill your team does not have yet, because somebody has to own the platform. And a component that takes everything down when it stops, which is worth writing out before you sign: what halts when the hub halts for a day, and who gets told.

You do not have to guess at the risk of centralising, because the industry already ran the experiment. IBM's account of why the enterprise service bus faded is blunt: a change to one integration could destabilise other teams that relied on that same integration, updates to the middleware often hit existing integrations so any update needed significant testing, and because the bus was centrally managed, application teams soon found themselves waiting in line. Martin Fowler and James Lewis drew the design lesson in 2014, arguing for smart endpoints and dumb pipes against products that put significant smarts into the communication mechanism itself. So a hub should route, retry and log, and should not become the place where your pricing rules live. Microsoft says the same in its Power Platform integration guidance: rigid, centralised logic reduces flexibility and increases maintenance overhead.

The middle options an SME actually uses

Between eleven hand-built links and a licensed integration platform there are three positions that work, and most Belgian SMEs end up in one of them.

1. A shared automation platform as the operational hub. Power Automate, Make or Zapier, with the rule that every new link gets built there and nowhere else. You gain the run history and the credential store without an architecture project. Holding on to the rule is the hard part, because these tools make it easy to add a twelfth flow off to the side.

2. The warehouse as the hub for reporting traffic. Each system loads into the warehouse once, and every report and export reads from there. That turns a spreading web of reporting links into one load per system, and it is often the cheapest real win available. It only moves data one way, so it does nothing for flows that write back.

3. A small internal API layer. One service owns the customer, and everything asks it rather than asking each other. The strongest option, and the one that assumes a developer on the payroll. Without that person it becomes another link nobody maintains, with the added disadvantage that you built it yourself.

Whichever you pick, move the links that break most often first and leave the stable ones alone. Rebuilding eleven links in one project is how these efforts die.

What a hub does not fix

A hub moves messages between systems. It has no opinion on whether those messages mean the same thing. If the same customer is Van Damme BVBA in your CRM, Van Damme B.V.B.A. in accounting and VANDAMME in the warehouse system, a central platform gets three spellings to arrive faster. Deciding which one is right and keeping them tied together is master data management, separate work with a separate owner. What the hub gives you is one sensible place to keep the mapping between those three identities, instead of a lookup table copied into four scripts. That is worth something. It just does not fill itself in.