Reference architecture · Azure Integration Services

Integration hub on Azure — reference architecture, explained

How a website, stores, a bank, ERP, CRM and reporting stay in step through one hub on Azure — three layers, each with one job, shown move by move in eight scenarios on fictional data.

Type
Reference architecture, not a client engagement
Data
Fictional and illustrative
Platform
Azure Integration Services
Scope
11 example systems · 8 scenarios

Watch it work

Follow one change through the hub.

Pick a scenario. Each step shows where the data is, what it looks like at that moment, and which Azure service does the work. Every name, amount and volume is fictional.

Focus on a layer:
Data on the moveDeliveredFailed attemptIgnored duplicate
Integration hub on Azure: external systems, the three layers, and internal systems On the left, external systems: website form, payment gateway, bank, e-invoice service, and a slot for a new system. On the right, internal systems: ERP on-premises, CRM, POS, HR and a data lakehouse that feeds Power BI. In the middle, the Azure platform. Each system plugs into its own LoB connector. The connectors translate to and from shared business objects (Customer, Order, Payment, Invoice, Product) published through API Management. At the core, the Business Rules Engine, built from Logic Apps workflows, Azure Functions and a Service Bus queue, decides who receives each change. Security, monitoring and the DTAP release path run underneath. EXTERNALCustomers and partners INTERNALYour business systems AZURE PLATFORMIntegration hub Website form Customers Status Payment gateway Card payments Status Bank Statements Status E-invoice service Official tax invoices Status + Add a system ERP Finance, stock, orders ON-PREM Status CRM Customers, marketing Status POS Store tills Status HR Employees Status Data lakehouse All history, for analysis Status Power BI Reports and dashboards Status LOB CONNECTORSLOB CONNECTORS Web Payments Bank E-invoice ERP CRM POS HR Lakehouse Business Object Connectors Shared business objects, published as APIs (API Management) CustomerOrderPaymentInvoiceProduct Business Rules Engine Decides who gets what, and when WorkflowsCustom codeQueue RULE CHECKS Waiting for data DECISION QUEUE · WAITING LINE 0 WORKERS RUNNING IN PARALLEL 1 SecurityEntra ID · Key VaultMonitoringApp Insights · Log Analytics · MonitorRelease (DTAP)Dev → Test → Acceptance → Prod

Swipe sideways to see the whole diagram.

Step 1 of 6

Create: a new customer signs up

Lan signs up on the website

Lan fills in the sign-up form. The website saves it in its own format and knows nothing about ERP or CRM.

The data at this step

Live monitoring for this demo

Simulated

    What this is, plainly

    This is a reference architecture, not a client system. It shows how I would connect a typical mid-sized business — a website, stores, a payment gateway, a bank, an e-invoice service, ERP, CRM, HR and a reporting lakehouse — through one integration hub on Azure.

    Every customer, order, amount and volume in the scenarios is fictional. The product logos are examples of the kind of system that sits in each slot, not a statement about any organisation’s stack. What is real is the Azure behaviour each step relies on: queues, retries, duplicate detection, rate limits and identity are documented platform features.

    The point is the shape of the design. A hub like this is mostly plumbing, and that is the goal: each system plugs in once, and a change in one place reaches every system that needs it.

    Three layers, one job each

    Without a hub, every system has to know every other system. With one, each system plugs in once, speaks one shared language, and a single set of rules decides where data goes. Use the layer buttons above the diagram to see each one on its own.

    • LoB connectors: one per system, and the only part that knows that system’s format, such as SAP tables, POS exports or bank statement files. Built with Logic Apps connectors, and Azure Functions for unusual formats. Adding a system means building one of these.
    • Business Object Connectors: a small shared dictionary of business objects (Customer, Order, Payment, Invoice, Product) published as APIs through API Management. Systems never call each other; they read and write these objects.
    • Business Rules Engine: decides what happens to each change, whether it is valid, which system owns the data, which version wins, who needs to know, and what to do when a delivery fails. Built from Logic Apps workflows, Azure Functions and Service Bus queues.

    Scale

    Why it stays simple as you grow.

    Drag the slider. Point-to-point links grow much faster than the number of systems. A hub grows by one connector per system.

    HUBPOINT-TO-POINTHUB, THREE LAYERS
    Point-to-point45links to build and maintain, worst case
    Hub, three layers10connectors to build and maintain

    Adding system #11: 10 new links point-to-point, 1 new connector with the hub.

    Worst case assumes every system exchanges data with every other. Real landscapes are lighter, but the curve has the same shape.

    A queue absorbs spikes

    Service Bus holds messages safely when traffic jumps, turning a burst into a steady flow.

    Service Bus

    Workers multiply on demand

    Logic Apps Standard and Azure Functions scale out automatically, up to a ceiling you set for cost.

    Logic AppsAzure Functions

    The slow system sets the pace

    A concurrency limit per connector protects older systems, such as an on-premises ERP, from overload.

    Logic Apps

    Safe to repeat

    Duplicate detection and version checks mean a resent message never creates a second order or overwrites newer data.

    Service Bus

    Run it safely

    Operate it like a product.

    The hub carries business-critical data, so it gets the same care as any production system: you can see inside it, it is locked down, and every change ships through a controlled path.

    Application InsightsLog AnalyticsAzure Monitor

    See every message

    • One tracking ID follows a change from the source to every target (Application Insights).
    • Dashboards in business terms: orders waiting for ERP, payments not matched (Log Analytics workbooks or Power BI).
    • Alerts to Teams or email when a person must act (Azure Monitor).
    • Fix the cause, then replay the failed message. No re-typing.
    Microsoft Entra IDKey VaultVirtual Network

    Locked down by default

    • Every caller signs in with Microsoft Entra ID. No shared passwords.
    • Secrets and certificates live in Key Vault, never in code.
    • Private network paths to on-premises systems (VNet, private endpoints, data gateway).
    • Each connector gets only the access it needs (managed identity).
    Azure DevOpsGitHub Actions

    Change it without breaking it

    • Build once, then promote the same package through every environment.
    • Infrastructure as code (Bicep), so environments are identical by design.
    • Settings per environment come from Key Vault and app settings.
    • Approval gate before Production. Roll back by redeploying the previous version.

    DTAP release path

    Every connector, rule and API change passes four environments before it touches real data.

    1. D · BuildDevelopmentDevelopers build connectors and rules against sample data.
    2. Code review
    3. T · VerifyTestAutomated tests on every change: mappings, rules, failure paths.
    4. All tests pass
    5. A · AcceptAcceptanceBusiness users run real scenarios against test copies of ERP, CRM and POS.
    6. Business sign-off
    7. P · RunProductionReleased after sign-off. Same package as tested; only settings differ.
    • Everything in Git: connectors, rules, API definitions
    • Infrastructure as code (Bicep)
    • Settings per environment in Key Vault
    • Rollback means redeploying the previous version

    By design

    What the shape of the design gives you.

    1 new connector to add a system; the systems already connected do not change
    n connectors for n systems, against up to n(n−1)/2 point-to-point links
    4 environments every change passes: Development, Test, Acceptance, Production

    Here is the catch

    Trade-offs to plan for before you build.

    • Changes arrive in seconds, not at the same instant. That is fine for customers and invoices; for live stock during a flash sale, read ERP directly through an API.
    • The shared objects need an owner. If nobody owns the definition of “Customer”, every team adds its own fields and the shared language drifts.
    • There is more to operate: monitoring, on-call and upgrades. Budget that time, or the hub becomes the new bottleneck.
    • Cost follows volume. You pay per message and per workflow run, and peaks cost more, so set budgets and alerts in Azure Cost Management before go-live.
    • Not every rule belongs in the hub. How ERP calculates tax stays in ERP; the hub holds the rules about moving data between systems.
    • Start small. Ship one object between two systems first, such as Customer between CRM and ERP, and add more once monitoring and the release path work.
    Dat Tran, founder of EthanCorp

    Dat TranEnterprise Data & AI Analytics Architect — the person behind EthanCorp.

    All case studies

    Questions

    Common questions about this architecture.

    Is this a client system?

    No. It is a reference architecture with fictional data. The scenarios show how the design behaves; they do not report results from any organisation.

    Does it have to be Azure?

    No. The three-layer split works on any platform with an API gateway, a workflow engine and a durable queue. This version uses Azure Integration Services because that is where the documented behaviour on this page comes from.

    When is a hub the wrong choice?

    With two or three systems and no plans to add more, a direct, well-tested integration is cheaper to run. A hub pays off as the number of systems, and the cost of a failed sync, grow.

    Can EthanCorp build this for my systems?

    Yes — that is the enterprise data integration service. The work usually starts with a fixed-scope review such as the Integration & Migration Review, because agreeing the shared business objects, and who owns each one, is where real projects spend their time.

    Have a data, analytics or automation problem that should not need another workaround?

    Tell me what is breaking and what you have already tried. If EthanCorp is not the right fit, I will say so and point you somewhere better.

    Discuss a project View case studies
    Response time
    Within two business days
    Based in
    Ho Chi Minh City, Vietnam — working across Asia and remote