Most businesses don’t have an “integration strategy”, they have a pile of one-off connections that mostly work until they suddenly don’t. A calm integration architecture starts with a clear system of record (usually your ERP), a small set of repeatable integration patterns, and boundaries that keep each app in its lane. The result: fewer surprises, cleaner data, and a stack you can actually evolve instead of fear touching.
The Real Problem Isn’t “No Integration”, It’s “Accidental Integration”
If you’ve been in business more than a few years, your tech stack probably looks something like this:
- An ERP or accounting system (Business Central, NAV, QuickBooks, etc.)
- A website on WordPress (with forms, quotes, maybe a portal)
- A CRM or sales tool
- A handful of point solutions (email marketing, help desk, scheduling, payments, etc.)
- A bunch of spreadsheets filling in the gaps
Individually, none of these tools are bad decisions. The pain comes from how they’ve been connected over time:
- A custom API integration someone’s cousin wrote five years ago
- A Zap that only one person remembers creating
- A nightly export/import that “just runs on that old server”
- Three different systems all claiming to be the “source of truth” for customer data
This isn’t architecture. It’s archaeology.
A proper integration architecture is about stepping back and designing how data should move through your business, on purpose.
What Integration Architecture Actually Is (and Isn’t)
Integration architecture is not:
- “We have an API, we’re good.”
- “Zapier will handle it.”
- “IT can just connect those two systems real quick.”
Instead, it answers questions like:
- What system is the source of truth for each type of data? (customers, inventory, contracts, pricing, etc.)
- How does data move between systems? (real-time vs. batch, push vs. pull)
- What patterns do we standardize on? (webhooks, staging tables, message queues, ETL jobs, and so on)
- How do we evolve this in 3–5 years without ripping everything apart?
For many companies, the most pragmatic answer is:
“We’ll design our integrations around a central system of record, most often the ERP.”
That doesn’t mean the ERP does everything. It means everything that matters eventually flows through it in a structured, predictable way.
Anchor Everything Around Your System of Record
Let’s assume your ERP (for example, Microsoft Dynamics 365 Business Central) is your core.
A simple, calm integration architecture might look like this:
- ERP as the “brain”
Owns contracts, orders, inventory, billing, and financials, and exposes clean APIs or OData endpoints for other systems. - Website (WordPress) as the “front door”
Captures quotes, requests, applications, inspections, and more. Validates data and pushes clean records into the ERP via a controlled integration plugin, and pulls back selected ERP data for portals or dashboards. - CRM as the “sales memory”
Owns leads, opportunities, and some customer engagement history. Syncs key account and deal data with the ERP (no more manual export/import). - Marketing & service tools as specialists
Email platforms subscribe to events (new customer, contract renewal, overdue balance). Help desk tools sync key ticket and asset info with the ERP so operations sees the full story.
The key idea:
Each system has a clear job and a clear contract for how it talks to the others.
No system is trying to be everything. No random one-off feeds. No mystery overlaps.
Common Integration Patterns That Keep Things Sane
You don’t need 20 different integration patterns. You need a small handful that you repeat consistently.
1. API + Staging Tables (ERP-Centric Pattern)
In this pattern:
- WordPress or other web apps submit data to the ERP via an API.
- Data lands in staging tables first, not directly into your live transactional tables.
- Validation and business rules run inside the ERP where you already have governance.
- Approved records get promoted to live (for example, a “Quote Intake” record becomes a real quote).
Why it’s good:
- Reduces risk from bad or partial data.
- Keeps business rules in one place (the ERP), not scattered across multiple apps.
2. Event-Driven Push (Webhooks)
Instead of every system polling every other system (“Anything new yet?”), use events:
- “New quote created”
- “Contract activated”
- “Inventory level changed”
- “Customer updated”
Each event can trigger downstream actions:
- Update your CRM.
- Send onboarding sequences.
- Recalculate capacity planning.
- Notify operations in an internal portal.
This scales better than a mess of scheduled jobs that all run at 2 a.m. and sometimes step on each other.
3. Batch Sync for Non-Critical Data
Not everything needs to be real-time. For reference data (such as product lists and non-urgent statuses), a nightly or hourly sync is:
- Cheaper
- Simpler
- More predictable
The trick is to decide upfront what needs real-time vs. batch, instead of having it decided by whoever shouted loudest first.
How This Shows Up in a Real Stack (WordPress + ERP + CRM)
Here’s a simple example scenario:
Use Case: Online Quote Request → ERP → CRM → Operations
- Customer submits a quote form on WordPress.
Front-end validation ensures required fields are present and formatted. A custom integration plugin structures the payload and sends it to the ERP intake endpoint. - ERP receives the data into a “Quote Intake” staging area.
Business rules check customer accounts, pricing, availability, and credit flags. If valid, the system creates an official quote and assigns a quote number. - ERP publishes an event: “Quote Created.”
The CRM receives the event and either creates a new lead/opportunity or updates an existing one. An internal operations portal shows the new quote in the queue. - Marketing subscribes selectively.
If permitted, an email is triggered with next steps or a follow-up sequence.
From the outside, it looks like “our website integrates with our ERP and CRM.”
Under the hood, it’s actually:
- One well-structured intake pattern.
- One staging and validation pattern.
- One event publishing pattern.
…reused over and over for different forms and workflows.
Signs You’re Living in “Integration Spaghetti”
If any of these sound familiar, you don’t just need another integration, you need integration architecture:
- You maintain multiple spreadsheets purely to reconcile systems that “should already match.”
- Nobody is certain which system holds the “real” customer record.
- You’re afraid to upgrade or replace tools because “we’re not sure what else that touches.”
- Integrations were built by different vendors with different assumptions and zero documentation.
- Fixing one data issue often breaks something somewhere else.
This is normal. But it’s not inevitable.
A Practical Way to Start Cleaning It Up
You don’t have to redesign everything at once. Here’s a phased approach that fits real-world constraints.
Step 1: Inventory the Systems and Flows (No Tools Yet)
- List every major system: ERP, website, CRM, marketing, service, file storage, and so on.
- For each, write:
- What data it creates or owns.
- What data it consumes.
- How integrations currently work (API, file, Zap, manual, etc.).
Even a messy spreadsheet is a huge step forward.
Step 2: Declare Your System of Record Per Data Type
For each data domain (customers, contracts, inventory, invoices, quotes, assets):
- Choose one source of truth.
- Note where that data is copied for convenience (and how it’s kept in sync).
This alone cuts down on whole categories of arguments and confusion.
Step 3: Standardize 3–5 Integration Patterns
Decide which patterns you’re going to use going forward:
- API + staging tables into the ERP.
- Webhooks / event notifications out of the ERP.
- Scheduled batch sync for reference data.
- Possibly a thin middleware layer where necessary (but not for everything).
Then stop approving one-off “snowflake” integrations that don’t fit those patterns.
Step 4: Tackle the Highest-Friction Flow First
Pick one high-impact, high-friction scenario:
- Quote intake.
- New customer onboarding.
- Inventory availability.
- Service ticket visibility for operations.
Redesign that flow using your new patterns. Prove the value, then repeat for the next one.
Where Elephas Fits In
This is the kind of work that lives in the uncomfortable middle between “IT project” and “operations cleanup.” It’s rarely anyone’s full-time job, but it touches everyone.
Elephas can help with:
- Integration architecture design around your ERP and website.
- Patterns and governance so future integrations don’t degrade into spaghetti again.
- Hands-on builds: custom WordPress plugins, Business Central integrations, and portals.
- Documentation and knowledge transfer so your team can maintain and extend things safely.
The goal isn’t to make your stack “fancy.” The goal is to make it calm, predictable, and upgradeable.
FAQs
Do I really need an ERP as the center of my architecture?
Not always. But having a clear “home base” for operational and financial truth (often an ERP) makes integration decisions much cleaner. When no system is clearly in charge, every integration turns into a negotiation.
Can’t we just use a no-code integration platform and skip all this?
Tools like Zapier, Make, or full iPaaS platforms are great, as long as they’re used inside a deliberate architecture. Without that, they just become a faster way to build more spaghetti.
What if our systems don’t have great APIs?
You can still design good architecture. You might need staging tables, file-based imports, or an intermediate database. The important part is that the patterns are intentional, documented, and consistently applied.
How long does an “integration cleanup” usually take?
It depends on how tangled things are, but even a 2–4 week architecture and discovery phase can give you a clear roadmap, reduce risk, and prevent expensive rework later.
Want a Calm Integration Story Instead of a Heroic One?
If you’re tired of living in “who built this and why?” territory every time you touch your systems, it might be time to step back and design your integration architecture properly.
Elephas can help you:
- Map your current integrations.
- Define a sane, ERP-centered architecture.
- Implement the highest-impact flows first.
You shouldn’t need a hero every time you want two systems to talk. You should have a system for that.
