Best of Breed vs ERP: The Integration Cost Nobody Prices In.
The debate is older than the cloud and it is always argued the same way. The best-of-breed side says each application in the stack is better at its job than the matching module in a suite, which is usually true. The suite side says one vendor, one login, one data model, which is also true. Then both sides produce a licence comparison and the decision is made on it.
The licence comparison leaves off the line that decides the five-year cost. A stack of applications has to be connected for the business to run, and the connections are a product the company builds and maintains itself, forever. Nobody prices them, because they do not appear on any vendor's quote. This post is how to count them, so the comparison is honest.
A stack is applications plus connections.
Take a plausible mid-market stack: a sales system, an accounting system, an inventory or project tool, a help desk, a storefront, a marketing tool. Six applications, each chosen because it was the best at its job. For the business to run, at least five connections have to exist: sales to accounting for the customer and the invoice, inventory to accounting for cost and stock, storefront to inventory for orders, help desk to sales for the customer record, marketing to sales for leads. Six applications, five connections, and that is the minimum.
Each connection is not a setting. It is a small product with four costs.
A decision. Which system is the record for the thing being connected, and which direction the data moves. The customer is issued by the sales system and received by the accounting system, or the reverse, and every connection carries one of these. We wrote about the three decisions that come before any connector; multiply them by the number of connections.
A build. Through an integration platform, a native connector, or custom code. A week to a month each, depending on how far the two data models are from each other.
A watch. Connections fail silently: a field is renamed on one side, an API version is retired, a record arrives in a shape the mapping did not expect. Somebody has to notice, which means monitoring and a person who reads it.
A change cost. Every time either application updates its data model, or the business changes what a customer or an order means, the connection has to change. Five connections mean five places to change, and they change on the vendors' schedules, not yours.
A suite has the same connections. It has them inside, built and maintained by the vendor, which is the only structural advantage a suite has and the one its sales people least often explain.
Counting the line.
The method is a table, and it takes an afternoon.
List the applications in the proposed stack. Draw the connections that must exist on day one for an order to be taken, fulfilled, invoiced and supported. Then, for each connection, write four numbers: the build estimate, the monitoring hours per month, the expected changes per year, and the cost of one change. Sum across five years.
For a six-application stack built by a competent integrator, the line is rarely under a fifth of the five-year licence cost and is often closer to half. The companies that skip the table discover the number in year two, when they notice they employ a person whose job is re-keying between two systems that were supposed to be connected, and that person is the integration budget, paid monthly, forever.
Take the sales-to-accounting connection as the worked row. The decision is that the sales system issues the customer and the accounting system receives it, with the invoice flowing back. The build maps two customer models, two address formats and a tax field that exists on one side only. The watch is a weekly check that every account created in sales exists in accounting under the same id. The change cost arrives the first time finance adds a required field to the customer record, which the sales side does not have, and every new customer fails to sync until someone notices. None of these is large on its own. Five of them, for five years, is the line.
Put the same stack's figure beside the suite's. The suite's licence is higher; its connection line is near zero for the modules inside it, and non-zero for the systems that stay outside it, which every company has. Now the comparison is between two complete numbers, and it usually surprises whoever built the licence spreadsheet.
Where the decision actually lands.
Run the table honestly and most operationally complex mid-market companies land in the same place: a suite for the core, where the connections are densest, and best of breed at the edges, where a single application does something the suite cannot and connects to the core through one well-built link.
The core is the record-keeping loop: customer, order, invoice, payment, and the inventory or project that sits between order and invoice. That loop has the most connections per application and the most frequent changes, so it is where the suite's internal connections save the most. Zoho's suite covers it for most operators, with limits worth knowing, and the connections between its applications are the vendor's problem.
The edges are the specialist functions: the storefront platform, the warehouse scanner, the clinical or field-service tool, the industry-specific billing engine. Here best of breed earns its keep, because the suite's module genuinely is weaker, and the cost is one connection each, which the table has priced.
The pure best-of-breed stack is right for a company with strong internal engineering that treats integration as a competence. The pure suite is right for a company whose operations fit the suite's defaults. Most mid-market operators are neither, which is why the answer is a core and edges, decided by counting.
The question for the integrator.
If an integrator proposes a best-of-breed stack, ask for the connection table with the five-year figure. If it is not in the proposal, the line is coming anyway, in month six, as change orders. If an integrator proposes the suite, ask which of your systems stay outside it and how each connects, and for the same figure on those. Either way the question is the same, and the answer should be a number.
We built the five-year frame for the suite side in the piece on ERP total cost of ownership. The connection line is the matching frame for the stack side, and the decision is only sound when both are on the page.
Why this is the product.
A company does not run on its applications. It runs on the fact that an order taken in one place becomes an invoice in another and a shipment in a third without anyone re-keying it. That fact is the connections. Whether they live inside a suite or between a stack, they are the thing the company is actually buying, and the thing that fails when it was never priced.
Discovery is no-risk: we build the connection table for your proposed stack or suite, with the five-year figure, and you pay only if you go ahead.
Know whether your business is ready for an ERP before you sign for one.
The ERP Readiness Review is a 90-minute working session plus a written scorecard across master data quality, documented exceptions, integration scope and data ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Comments