Enterprise Application Integration & iPaaS Guide

What enterprise application integration actually means

Enterprise application integration (EAI) is the practice of connecting business software so that data flows between systems automatically, without human intervention. That's it. Strip away the jargon and EAI is just plumbing — making sure System A and System B share the right data at the right time.

The problem it solves is straightforward. A mid-market company running NetSuite for ERP, Shopify for ecommerce, Salesforce for CRM, Avalara for tax, ShipStation for fulfillment, and HubSpot for marketing has six systems that each contain valuable business data. Without integration, that data sits in silos.

Here's what that looks like on a Tuesday morning: A customer places an order on Shopify at 9:14 AM. The warehouse team doesn't see it in NetSuite until someone manually enters it — maybe by lunch, maybe by end of day. Meanwhile, the customer calls your sales team asking about their order status. The sales rep checks Salesforce, sees nothing, checks Shopify, finds the order, but can't tell if it's been picked or shipped because that information lives in ShipStation. The customer gets a vague "we're working on it" and hangs up annoyed.

That scenario plays out thousands of times per day at companies that haven't invested in integration. Every manual data transfer introduces delay, and every delay introduces error.

EAI eliminates this by creating automated data flows between your applications. The Shopify order appears in NetSuite within minutes. The fulfillment status flows back to Salesforce. Inventory updates propagate to all sales channels simultaneously. Nobody rekeyed anything.

---

The evolution of integration approaches

Integration technology has gone through distinct phases. Each solved real problems and created new ones.

Point-to-point (2000s)

The first approach most companies try: build a direct API connection between two systems. Shopify talks to NetSuite via a custom script. NetSuite talks to Salesforce via another script. Each pair of systems gets its own connection.

This works fine when you have two or three integrations. The math breaks down at scale. Connecting N systems point-to-point requires N*(N-1)/2 connections. Five systems need 10 connections. Ten systems need 45. Twenty systems need 190. Each connection is a separate codebase to maintain, monitor, and update when either system changes its API.

We still see companies running point-to-point integrations built in 2018 that nobody on the current team understands. The developer who wrote the SuiteScript left two years ago. The integration mostly works, except when it doesn't, and debugging it requires reading uncommented code that makes assumptions about NetSuite's data model that are no longer accurate.

Point-to-point isn't inherently bad. For a simple, stable integration between two systems that rarely change, a direct API connection can be the most efficient approach. The problem is that companies rarely stop at two.

ESB / SOA (2005-2015)

Enterprise Service Bus architecture addressed the spaghetti problem by introducing a centralized message broker. Instead of each system connecting directly to every other system, all systems connect to the bus. The bus handles routing, transformation, and orchestration.

Products like MuleSoft Anypoint, TIBCO BusinessWorks, and IBM Integration Bus dominated this era. They're powerful platforms — capable of handling complex routing logic, message transformation, protocol conversion, and high-volume throughput.

The trade-off was cost and complexity. An ESB implementation at a mid-market company typically ran $200K-$1M+ for the initial build, plus $50-150K/year in maintenance and developer salaries. You needed specialists — integration architects who understood SOAP, WSDL, message queuing, and the specific ESB platform's tooling. These weren't skills your existing NetSuite admin or Shopify developer had.

ESB architecture still makes sense for large enterprises processing millions of transactions across dozens of systems. Banks, airlines, and telecom companies run ESBs for good reason. But for a company doing $20M-$200M in revenue with 5-15 integrated applications, ESB was always overkill.

iPaaS (2015-present)

Integration Platform as a Service moved the integration layer to the cloud and made it accessible to a much broader set of users. Celigo, Boomi, Workato, and similar platforms provide pre-built connectors, visual flow builders, managed infrastructure, and error-handling frameworks out of the box.

The shift was significant. An integration that would take a developer 4-6 weeks to build custom could be configured in Celigo in 3-5 days using pre-built connectors with pre-mapped fields. The infrastructure — servers, monitoring, scaling, failover — is handled by the platform provider. Error handling comes built-in, with retry queues and alerting.

iPaaS democratized integration for mid-market companies. A $50M manufacturer can now run 8-10 integrations through Celigo for $3,000-6,000/month, managed by a combination of their NetSuite admin and a consulting partner. That same setup would have required a full-time integration developer and an ESB license a decade ago.

The trade-off is flexibility. iPaaS platforms handle 80-90% of integration scenarios well, but highly complex transformation logic, unusual API patterns, or systems without pre-built connectors can push you to the platform's limits. You're also locked into the platform's pricing model and roadmap.

Composable / event-driven (emerging)

The newest layer isn't replacing iPaaS — it's extending it. API-first architectures, webhook-driven workflows, and event streaming (Kafka, Amazon EventBridge) let systems react to events in real time rather than polling for changes on a schedule.

In practice, most mid-market companies use iPaaS as their primary integration layer and layer in event-driven patterns for specific high-frequency or low-latency requirements. A Celigo flow handles your nightly inventory sync; a webhook triggers immediate stock updates when a large order depletes a popular SKU.

Don't rip out your iPaaS to go fully event-driven. That's a solution looking for a problem for most companies under $500M in revenue.

---

When you need EAI (and when you don't)

Not every company needs an integration platform. Here's a practical framework.

Under 3 integrated systems: Point-to-point is fine. If you're connecting Shopify to NetSuite and that's your only integration, a direct connector or Celigo integration app handles it cleanly. Adding a platform layer for one or two integrations adds cost without proportional benefit.

3-7 integrated systems: This is where iPaaS earns its keep. You have enough integrations that managing them individually becomes a burden, but not so many that you need enterprise-grade infrastructure. Celigo, Boomi, or Workato will cover you.

8+ integrated systems or complex orchestration: You need a deliberate integration strategy and probably a platform with robust orchestration capabilities. This might still be iPaaS (Celigo and Boomi both handle this range), but you need to think about data governance, error escalation workflows, and potentially a dedicated integration resource on your team.

Signs you've outgrown your current approach:

• Your team spends more than 5 hours per week on manual data entry between systems
• You regularly discover data discrepancies during month-end close
• Customer-facing teams can't get accurate real-time information without checking multiple systems
• Failed integrations go unnoticed for hours or days
• You're afraid to update one system because it might break an integration with another

For most mid-market companies running NetSuite, the ERP becomes the integration hub. NetSuite is the system of record for financials, inventory, and orders. Other systems — ecommerce, CRM, 3PL, payment processing — feed into and pull from NetSuite. Building your integration architecture with NetSuite at the center simplifies data governance because ownership is clear: NetSuite owns the master record, other systems sync to it.

---

EAI patterns that matter

Four integration patterns cover the vast majority of business needs. Understanding which pattern applies to your scenario determines how you design the integration.

Data synchronization

Keeping master data consistent across systems. Customer records, product catalogs, vendor information, pricing — data that exists in multiple systems and needs to match.

NetSuite example: A new customer is created in Salesforce by the sales team. The integration syncs that customer record to NetSuite (where it becomes a customer record for invoicing and order management) and to Shopify (where it creates a customer account for online ordering). When the customer's address changes in Salesforce, the update propagates to both systems.

The key design decision is ownership. Which system is the master for each data object? If Salesforce owns customer data, updates should flow from Salesforce outward. If someone edits the customer record directly in NetSuite, that edit either gets overwritten on the next sync (risky) or creates a conflict that needs resolution rules.

Process orchestration

Multi-step business processes that span multiple systems. Order-to-cash is the classic example: an order enters through ecommerce, gets fulfilled through the warehouse, gets invoiced through the ERP, and gets recognized as revenue in the GL.

NetSuite example: A Shopify order triggers a sales order in NetSuite. NetSuite sends the order to a 3PL via ShipStation. When the 3PL confirms shipment, the tracking number flows back to NetSuite (updating the item fulfillment) and to Shopify (updating the customer's order status). NetSuite generates the invoice and recognizes revenue. The payment from Shopify Payments reconciles against the invoice in NetSuite.

Orchestration flows are harder than data syncs because sequence matters. You can't generate a shipment notification before the 3PL confirms the pick. Error handling is critical — what happens when the 3PL rejects an order due to an invalid address? The orchestration needs exception paths, not just happy paths.

Data migration

One-time (or infrequent) bulk transfers of data between systems. Typically happens during system implementations, upgrades, or platform switches.

NetSuite example: A company migrating from QuickBooks to NetSuite needs to move 5 years of customer records, vendor records, open transactions, and chart of accounts. This isn't a recurring integration — it runs once, gets validated, and gets decommissioned.

Migration uses different tools than ongoing integration. CSV imports, NetSuite's SuiteCloud Data Loader, and scripted bulk imports are common approaches. iPaaS platforms can handle migrations but aren't always the most efficient tool for a one-time job.

Event-driven messaging

Real-time notifications between systems triggered by specific events. Unlike scheduled syncs (which poll for changes every 5-15 minutes), event-driven integrations fire immediately when something happens.

NetSuite example: A customer's credit hold status changes in NetSuite. An event-driven message immediately notifies Shopify to disable that customer's account and alerts the sales team in Salesforce. There's no 15-minute polling delay — the action is instant.

Webhooks are the most common implementation. NetSuite's SuiteScript supports webhook-like functionality through User Event scripts that fire on record save. Modern iPaaS platforms support both webhook triggers and scheduled polling, so you can mix patterns based on the urgency of each data flow.

---

Building an integration strategy

A strategy sounds corporate, but it saves real money. Companies that build integrations reactively — adding one whenever someone asks — end up with a tangled mess by year three. Thirty minutes of planning per integration prevents hours of debugging later.

Step 1: Inventory your systems and data flows. Write down every system your company uses and what data moves between them. Include the manual processes — the spreadsheet your ops team downloads from System A and uploads to System B every morning counts as a data flow. We do this exercise with every new client and it consistently uncovers 2-3 data flows that nobody on the leadership team knew existed.

Step 2: Identify the hub. For most NetSuite customers, NetSuite is the hub. Financial transactions, inventory, and order management live there. Every other system either feeds data into NetSuite or consumes data from it. If you're running Salesforce as your primary system and NetSuite as a financial back-end, Salesforce might be the hub. Pick one. Two hubs means two sources of truth, which means zero sources of truth.

Step 3: Map data objects and ownership. For each data object (customers, products, orders, invoices), define which system owns it. The owner is where the record gets created and updated. Other systems receive a copy. This prevents the nightmare scenario where two systems both think they own the customer record and keep overwriting each other's updates.

Step 4: Choose your integration approach. Match the pattern to the complexity:

• Low complexity, 1-2 integrations: Point-to-point or single iPaaS connector
• Medium complexity, 3-7 integrations: iPaaS platform (Celigo for NetSuite-centric, Boomi for multi-system)
• High complexity, 8+ integrations or real-time requirements: iPaaS with event-driven components, possibly custom middleware for edge cases

Step 5: Plan for monitoring and error handling. This is the part every company skips and every company regrets skipping. Integrations fail. APIs time out. Data validation rules reject records. Rate limits get hit. You need:

• Automated alerting when an integration fails (not just a log entry nobody reads)
• Retry logic for transient failures (network timeouts, temporary API errors)
• Error queues for records that need manual review (bad data, business rule violations)
• Dashboards showing integration health and throughput
• Runbooks for common failure scenarios so your team can resolve issues without calling a consultant every time

Celigo handles much of this natively. Custom integrations need all of it built from scratch, which is one of the strongest arguments for using an iPaaS platform even when you have the development skill to build custom.

---

The cost conversation

Integration costs are opaque, and vendors don't make comparison easy. Here's what we see in practice across our client base.

ESB implementations: $200K-$1M+ for the initial build, plus $50-150K/year in platform licensing and maintenance. Requires specialized integration developers at $140-180K/year salary. Reserved for enterprises doing $500M+ in revenue with 20+ integrated systems.

iPaaS platforms: $20K-100K/year depending on the platform and number of connectors. Celigo runs $7K-72K/year for most mid-market NetSuite customers. Boomi is similar. Workato's task-based pricing can swing widely — $10K/year for low volume, $75K+ for high volume. Implementation costs for each integration flow run $5K-25K with a consulting partner.

Custom development: $50-200/hour for API developers, depending on location and expertise. A single integration (e.g., custom Shopify-to-NetSuite order sync) runs $15K-50K to build. Multiply by the number of integrations.

The hidden cost: maintenance. Custom integrations cost 20-30% of the initial build per year to maintain. API changes, business logic updates, error handling improvements, monitoring — it adds up. A $40K custom integration costs $8-12K/year to keep running. Over 5 years, you've spent $80-100K on what started as a $40K project.

iPaaS platforms absorb most maintenance costs into their subscription. When Shopify updates their API, Celigo updates their connector. When NetSuite releases a new version, the platform adapts. You're trading a variable, unpredictable maintenance cost for a fixed subscription fee. For most companies, that trade-off is worth it.

---

These projects demonstrate enterprise application integration patterns with NetSuite at the hub.

Frequently Asked Questions

Frequently Asked Questions

What's the difference between EAI and iPaaS?expand_more

How long does it take to implement an integration platform?expand_more

Can I integrate NetSuite with legacy on-premise systems?expand_more

Should we hire an integration developer or use a consulting partner?expand_more

What happens to our integrations if we switch iPaaS platforms?expand_more