Best-of-Breed or Suite Is the Wrong Question

The strategic choice is who orchestrates the work – and how expensive it will be to change later

Altivate | Published 10 May 2026 | Updated 26 July 2026

1. The debate everyone is still having is a decade out of date

Best-of-breed versus suite has been argued in the same terms since Gartner popularised “postmodern ERP” in 2013: a single vendor gives you coherence and a slower pace; assembling specialists gives you capability and an integration bill. Pick your side.

The terms of that argument were set when integration meant point-to-point interfaces and nightly reconciliation. It survives in vendor blogs because it is easy to restate and it flatters whichever side is paying.

The reason to stop restating it is not that either side was wrong. It is that the thing being traded has moved twice, and the decision now turns on a question that did not exist when the framing was invented.

The analysts arguing it at the time were already circling this. Forrester’s George Lawrie located the risk not in features but in “data integrity… because it’s hard to do the integration.” Constellation’s Ray Wang was similarly sceptical of assembling specialists. Gartner’s Denise Ganly, on the other side, described organisations as “getting their heads around” postmodern ERP’s advantages. All three were arguing about where the integration cost sits and who absorbs it, which is the right question. It is the answer that has changed.

Move one, roughly 2015-2022. Cloud and APIs relocated the cost from bespoke point-to-point interfaces to iPaaS subscriptions and vendor connectors. This is widely described as integration getting “solved.” It did not get solved; it got repriced and moved onto a line item. Anyone who has renewed an integration platform contract knows the bill did not go away.

Move two, happening now. An agentic layer is relocating it again – to orchestration. When software agents execute multi-step work across systems, the binding question stops being “can these two systems exchange a record” and becomes “whose agent is in charge of this process, and what does it cost to change that later.”

That is not a feature comparison. It is an architectural commitment, and it is considerably harder to reverse than a connector.

The version of this debate we published earlier: best-of-breed vs best-of-suite.

2. Gartner’s own successor concept already concedes the point

The framing that replaced postmodern ERP is composable ERP, which Gartner defines as “an adaptive technology strategy that enables the foundational administrative and operational digital capabilities for an enterprise to keep up with the pace of business change.”

Read that definition carefully and notice what it does not contain: any number of vendors. It is not a recommendation to buy one suite or many specialists. It describes a strategy – an ongoing capacity to recompose – which is a statement about architecture and ownership, not about counting logos on a slide.

The industry adopted the word and kept having the old argument. This paper takes the definition at face value: if the strategy is adaptive recomposition, then the thing to evaluate is what it costs to recompose, capability by capability. That cost now lives at the orchestration layer.

3. Interoperability direction is the new lock-in

The distinction is testable. SAP is the worked example because its primary material exposes both directions clearly enough to audit. The same test should be applied to every platform under consideration: can it orchestrate external capability, and can an external orchestrator invoke its native capability on equal terms?

Finding: agent interoperability is real, and it is currently one-directional.

• Outbound – Joule calling an external agent – works today. SAP’s own reference architecture (last updated 6 May 2026) states that the current architecture “supports unidirectional (outbound) communication only.” SAP community documentation from February 2026 walks through Joule invoking an externally hosted agent at runtime via an A2A Agent Card. So an agent your team built on LangGraph, running on your own infrastructure, can be called by Joule as part of a process.
• Inbound – an external orchestrator calling Joule agents as peers – is not generally available. The Agent Gateway that would enable it is explicitly pre-GA. SAP’s Sapphire 2026 Innovation News Guide (12 May 2026) states that “bi-directional A2A capabilities in Joule will be enhanced to enable third-party agents to securely call on Joule Agents and act within enterprise processes”
• future tense – and puts general availability for Joule Work and Joule A2A capabilities in Q4 2026.

In one line: Joule can call out; it cannot yet be called into.

We want to be scrupulous about what that does and does not mean, because there is a lazy version of this finding that we are not making. It is not “SAP is closed.” The outbound path is documented and working, and the inbound path has a published date. At the build layer SAP has genuinely opened up: its own Joule Studio announcement names LangChain, Pydantic AI, LlamaIndex, an embedded n8n environment, and partnerships with Vercel and Cursor/VS Code. That is real, verified openness.

It is also a different question from whether Joule can be called into as a peer by another vendor’s orchestrator, which is what this section is about. Anyone conflating “open at build time” with “open at run time as a peer” is either confused or selling something – and the two are presented interchangeably in almost every vendor deck we have seen.

What we could not establish, stated plainly: we found no named example of Joule orchestrating a specific rival’s branded agent product as a peer. Not a counter-example – an absence.

There is a second distinction worth carrying into any vendor demonstration, and we flag it as a conceptual point rather than a documented finding, because we did not verify a specific instance of it. An agent reaching into a third-party system to call its APIs as tools – broadly the role MCP plays – is not the same as orchestrating that vendor’s own agent as a peer. The first is integration wearing new clothes; the second is the thing this paper is about. They look almost identical in a demo. Ask which one you are being shown.

4. Why direction is the question, not openness

Openness is a yes/no that every vendor answers yes to. Direction is a design fact you can verify, and it determines something concrete: which platform is the caller and which is the called.

The surrounding orchestrator owns the end-to-end process: sequence, cross-system retry, compensation, context and the audit trail of what happened and why. A called agent can still own its internal plan and tool path; the boundary between those two control loops must be explicit.

That distinction is where switching cost accumulates now. Two consequences follow, and neither is about SAP specifically:

A platform that can only call out is trying to be your orchestrator. That is not a criticism; something has to be – but it means a capability you place behind it becomes a step in someone else’s process, and a second orchestrator elsewhere in your landscape is a genuine architectural conflict rather than a redundancy.

A native agent that cannot yet be invoked as an A2A peer cannot occupy that peer position in someone else’s process. API or tool-level composition may still be available, but it is a different contract with different context, identity and audit semantics. If the intended design has a non-SAP orchestrator invoking SAP-side agents as peers, validate the current inbound A2A path in the proposed tenant and release rather than treating a roadmap date as delivered capability.

Run both questions against every vendor on your shortlist. Our finding is about SAP because SAP publishes a reference architecture precise enough to check. A vendor that will not answer these two questions in writing has answered them.

Product detail: SAP Joule agents.

5. The gate that overrides the entire framework

Before any of the above matters, one class of requirement removes the choice altogether, and it is the one most commonly discovered late in this region.

Where a regulator certifies a path, architecture is decided for you.

Saudi e-invoicing is the cleanest example. ZATCA’s Phase Two is an integration phase, not a generation phase: the invoicing solution integrates with Fatoora. Standard tax invoices follow clearance before issue; simplified tax invoices follow the reporting path and must be reported within 24 hours. Onboarding also follows a prescribed sequence for the solution unit or device.

This is not a scoring criterion. It is a gate. A best-of-breed billing engine that cannot hold a Fatoora-onboarded cryptographic identity is not a lower-scoring option; it is not an option.

And the population inside the gate keeps growing. ZATCA announced Wave 25 on 24 July 2026, covering businesses with VAT-taxable revenue above SAR 187,500 in 2022, 2023, 2024 or 2025, who must integrate with Fatoora by no later than 1 February 2027. The threshold has halved from Wave 24’s SAR 375,000. ZATCA runs this as a standing programme with roughly six months’ notice per wave, which means if you are below today’s threshold you are not exempt, you are early.

The general rule: enumerate the certified paths in every country you operate in before you score a single vendor. They do not appear in feature matrices, and they cannot be integrated around.

Practical detail: preparing for the ZATCA e-invoicing mandate.

6. The framework: six questions, asked per capability

The central practical claim of this paper is that “are we best-of-breed or suite?” is asked at the wrong altitude. It is a landscape-level question, and the decision is a capability-level one. Payroll, field service, treasury and CRM can each land differently in the same organisation, and an organisation that answers once, globally, has guaranteed itself the wrong answer somewhere.

For each business capability, in this order:

1. Is this a system of record or a system of differentiation? Records pull toward the suite – they need one authoritative version and they change slowly. Differentiators tolerate and often reward a specialist. If you cannot say which one a capability is, that is the finding: you do not yet know what it is for.

2. Does a certified statutory path exist? If yes, stop scoring – this gates the choice (§5). Answer this second, before anyone builds a weighted matrix, because it invalidates matrices.

3. Who owns the orchestration layer for this process, and what does leaving cost? The §3/§4 question. Establish direction – can it call out, can it be called into – and get it in writing. This is where the switching cost of the next decade accumulates.

4. Does the point tool survive the suite’s release cadence, and who absorbs regression cost? A specialist integrated against a platform that ships quarterly inherits a permanent testing obligation. Somebody pays for it. Name them during selection, not after.

5. Does this require one authoritative master, or tolerate eventual consistency? Customer, employee and material master. If a process genuinely requires a single authoritative version in real time, the integration cost of a specialist is structurally higher and no amount of API quality changes that.

6. Can the extension you need live outside the core? If the capability can be built on a platform alongside the core, it is durable across upgrades. If it requires modifying the core, it is fragile – and in this region it is also restore-fragile, because it is exactly what a vendor-initiated restore or a major upgrade silently reverts.

Notice that only question 1 resembles the traditional debate. Questions 2 through 6 are about coupling, ownership and cost-to-change. That is the actual decision.

Worked example: payroll across a Gulf and India footprint

Abstract frameworks are easy to agree with and hard to use, so here is the whole thing run against one capability. The evidence behind questions 2 and 6 is our own: we read SAP’s and Oracle’s payroll documentation in full, and the findings and their limits are set out below and in the sources.

Five of six answers point at the suite. And the decision is still not “buy the suite” – because question 2 is gated, and here is the finding that makes this worth working through:

Current SAP and Oracle documentation both describe UAE WPS output generation. That changes the decision: the suite may satisfy the native country output, but a buyer still needs evidence for the specific release, bank/SIF validation, submission responsibility, rejection handling, segregation of duties and the operating support path. Nationalisation tracking likewise needs a demonstrated data source, calculation owner and evidence trail.

So the honest answer is suite first, extension only for a demonstrated gap. Questions 1, 3, 4 and 5 support a suite core; question 2 turns statutory proof into a gate; and question 6 decides where any remaining gap belongs. Do not buy a parallel statutory layer merely because a high-level feature matrix is silent, and do not accept a feature name as proof of the end-to-end operating chain.

That answer is not expressible in the either/or framing. The correct architecture can be a suite core, a native statutory output, and a deliberately owned extension for a separately evidenced gap. The capability-level evidence, not the portfolio label, determines the boundary.

7. When the point solution is simply correct

A paper from an SAP partner that concluded “buy the suite” would deserve the scepticism it got, and the framework above genuinely does select specialists in identifiable situations:

• The capability is a differentiator and the suite’s version is generic. If it is how you compete, a competent specialist usually beats a checkbox – and question 1 says so.
• No certified statutory path is involved. Question 2 is silent, so nothing is gated.
• The process tolerates eventual consistency. Question 5 passes, so the integration burden stays proportionate.
• You are willing to own the orchestration layer yourself. This is the honest version of best-of-breed in 2026: it is a decision to be the orchestrator, with the staffing that implies. Chosen deliberately, it works. Arrived at by accident – which is what happens when nobody asks question 3 – it produces a landscape where every vendor assumes it is in charge.

The failure mode is not choosing a specialist. It is choosing several, each of which assumes it owns the process, and discovering the conflict after all of them are in production.

8. What this framework deliberately leaves open

• The orchestration-direction finding is dated and will move. Inbound A2A is targeted for Q4 2026. Re-check §3 before relying on it after that; the whole point of stating the date is that you should.
• We found no named rival-branded-agent integration in either direction. That is an absence, not a proof of impossibility, and we say so in §3.
• We verified direction for SAP only. We did not run the same audit against Workday, Oracle, Microsoft or ServiceNow. The two questions in §4 are the ones to ask them; we are not reporting their answers because we did not check them.
• The framework is a decision aid, not a scoring model. It deliberately produces no weighted total. A weighted average would hide the statutory and run-time gates.
• It produces no universal vendor recommendation. The answer belongs to each capability and operating chain, not to the landscape as a whole.

9. The executive agenda

1. Name the enterprise orchestrator for each end-to-end process; “the integration layer” is not an accountable owner.
2. Ask every shortlisted platform whether it can call external agents and whether external orchestrators can call its agents as peers.
3. Run the six-question framework per contested capability, beginning with statutory gates.
4. Price the seam – identity, observability, reconciliation, change and exit – not merely the connector.
5. Record who will own orchestration if the answer is “the enterprise.”

Altivate provides SAP advisory and implementation services and therefore has a commercial interest in this market. Section 7 sets out when the specialist is the correct decision. A useful framework must be capable of choosing against its author’s commercial interest.

Apply the framework to enterprise resource planning, or return to White Papers.

Sources and verification status

Checked 26 July 2026.

SAP primary – [read]

• SAP reference architecture, architecture.learning.sap.com (last updated 6 May 2026) – the source for “supports unidirectional (outbound) communication only” and for the Agent Gateway being pre-GA. This is the document that establishes A2A’s direction.
• SAP Sapphire 2026 Innovation News Guide (12 May 2026) – the bi-directional A2A enhancement quoted in §3 and the Q4 2026 GA target for Joule Work and Joule A2A.
• SAP News Center, Joule Studio announcement (May 2026) – the build-layer openness quoted in §3: LangChain, Pydantic AI, LlamaIndex, an embedded n8n environment, and Vercel and Cursor/VS Code partnerships. Cited to make the point that SAP’s openness at build time is real and verified – and is a different question from run-time peer interoperability.
• SAP News Center, reporting Gartner’s definition of composable ERP (§2), quoted verbatim.

SAP community – [read], and labelled as such

• “Joule A2A: Connect Code-Based Agents into Joule” (16 February 2026) – the runtime walkthrough of Joule invoking an externally hosted agent via an A2A Agent Card. Community-authored, not SAP product documentation. Cited for the existence of a documented outbound path, which SAP’s own reference architecture independently confirms.

Regulatory primary – [read]

• ZATCA, E-Invoicing Detailed Guideline – the Phase One/Phase Two distinction, real-time clearance, and the three-step Fatoora onboarding sequence in §5. Fetched and read directly.
• ZATCA, Wave 25 criteria announcement, 24 July 2026 – the SAR 187,500 threshold across 2022-2025 and the 1 February 2027 integration deadline.

Vendor payroll documentation – [read in full]

• SAP, Automatic Generation of the WPS File and Oracle, Wage Protection System Report for UAE – current primary documentation for the native UAE outputs used in §6.

Analyst positions – [read]

• TechTarget (SearchERP) – the named-analyst positions in §1: Gartner’s Denise Ganly, Forrester’s George Lawrie (“data integrity… because it’s hard to do the integration”) and Constellation’s Ray Wang. Cited as positions held in the pre-AI debate, not as current guidance.

The framework excludes claims that could not be confirmed from a readable primary or named secondary source. The sixth question is framed as a general architectural test rather than as SAP’s published framework.