What you are actually choosing between
The suite decision is a decision about where complexity lives. An integrated suite pushes complexity into the vendor's product: one data model, one upgrade cycle, one commercial relationship, and processes that bend to fit the software. A best-of-breed stack pushes complexity into your own architecture: each function gets the system that fits it best, and your team owns the joins. Both are legitimate. The mistake is choosing on philosophy ("we believe in integration") rather than on the specific processes, team and constraints in play.
The honest case for a single suite
A suite gives you a single version of the operational truth. Order-to-cash, procure-to-pay and record-to-report run on one data model, so a customer, a cost centre or a stock movement means the same thing everywhere. Month-end consolidation gets simpler. Accountability gets simpler too: one vendor owns the roadmap, and there is no argument between suppliers about whose interface broke. For organisations with a thin IT function, the suite is often the only architecture they can realistically operate, because the vendor is doing the integration work they cannot.
The honest case for best-of-breed
Specialist systems exist because suites are built for the average of their customer base. If your warehouse operation, planning process or pricing engine is genuinely a source of advantage, forcing it into a suite's standard module can flatten the very thing that differentiates you. Best-of-breed also changes the pace of improvement: each function can upgrade, replace or renegotiate its system independently, without waiting for a suite-wide programme. And it caps vendor dependency. No single supplier holds your entire operating capability, which matters at renewal time.
Side by side
| Dimension |
Integrated suite |
Best-of-breed stack |
| Data model |
One shared model across functions |
Multiple models reconciled through integration |
| Fit to specialist processes |
Standardised; deep customisation is costly |
Strong where the specialist tool leads its category |
| Integration burden |
Carried mostly by the vendor |
Carried by your team or an integrator |
| Vendor dependency |
Concentrated in one supplier |
Spread across several, none decisive alone |
| Pace of change |
Suite-wide release cycles |
Each system evolves independently |
| Commercial posture |
One large negotiation, high switching cost |
Several smaller negotiations, credible exit per system |
| Typical failure mode |
Processes distorted to fit the software |
Integration debt and disputed data ownership |
When each option clearly wins
The suite wins when your processes are close to industry standard, when finance consolidation across entities is the dominant requirement, or when the organisation lacks the architecture capability to own integrations for a decade. Best-of-breed wins when one or two functions carry your competitive edge and need depth a suite module cannot offer, when different business units genuinely run different operating models, or when you are deliberately avoiding concentration in a single vendor ahead of a carve-out, acquisition or major renegotiation.
The hybrid routes people forget
- Suite core, specialist edge: run finance and core operations on the suite, and keep the two or three differentiating functions on specialist systems with disciplined interfaces.
- A two-tier design: the group runs a single suite for consolidation while subsidiaries keep lighter local systems that feed it.
- Time-boxed coexistence: adopt the suite module by default, but agree in advance the evidence that would justify a specialist exception, so the debate happens once rather than at every renewal.
- Buy the suite, defer the modules: license the core now and hold the optional modules until each one beats its specialist rival on your requirements, not on the bundle discount.
The questions that decide it for your situation
- Which of our processes would we genuinely refuse to standardise, and what is the evidence they create advantage?
- Who, by name, will own integration architecture for the next ten years, and do they exist on the payroll today?
- What does the suite vendor's pricing look like at first renewal, once switching costs are sunk?
- If we choose the stack, which system is the master for customer, product and financial data, and has every supplier accepted that in writing?
- Is this decision being shaped by the systems we have, or by the operating model we want in five years?
