Walk into most procurement organizations and you will find the same quiet contradiction. They spent twelve to eighteen months and seven figures rolling out a source-to-pay suite that promised to put everything in one place. And their best analysts still begin every serious piece of work by exporting to a spreadsheet.

The suite was supposed to be the end of silos. For a lot of companies it became one more. The data is technically in one system and practically out of reach: locked in a schema the analysts can't query, inside a tool the suppliers won't log into, behind a workflow an AI model can't touch.

I sell against these suites for a living, so take the next few thousand words with that grain of salt. But the argument here isn't really about my product or anyone else's. It is about a thirty-year pattern in enterprise software that just hit an inflection point, and what that means for how you should buy.

Two ways to make money

In 1995, on the Netscape IPO roadshow, an investor asked Jim Barksdale how his company would survive Microsoft bundling a browser into Windows. Barksdale's answer became one of the most quoted lines in technology: "Gentlemen, there's only two ways I know of to make money: bundling and unbundling."

He was describing a cycle, not a punchline. Industries pull specialized products together into bundles, then break them apart again as focused challengers attack the bundle's weak spots, then re-bundle once the sprawl gets painful. Cable bundles unbundled into streaming apps, and now re-bundle into Disney-Hulu-ESPN packages. It happens because the thing that makes a bundle worth buying changes over time, and most buyers notice the change a few years late.

Enterprise software has run this loop for decades. In the 1990s and 2000s the bundlers won: Oracle bought PeopleSoft and JD Edwards in 2005, and SAP and Oracle stitched broad capabilities into ERP. Procurement followed a beat later. SAP bought Ariba in 2012 for $4.3 billion. Coupa ran an aggressive roll-up into what it branded "business spend management," acquiring Trade Extensions for sourcing optimization in 2017, LLamasoft for supply-chain design in 2020 for $1.5 billion, and roughly two dozen companies in all. Jaggaer was assembled from SciQuest and BravoSolution. The pitch was always the same: one vendor, one system, one throat to choke. We were squarely in a bundling phase, and the bundle made sense.

The suite solved a problem you no longer have

It is worth being honest about why the suite won, because the reason is not the one its critics usually give. The suite did not win because its modules were excellent. It won because integration was miserable.

In 2010, wiring separate tools together was a serious capital project. Each system had its own data model, and connecting them meant custom code, middleware, brittle nightly jobs, and a standing IT team to keep the whole thing from falling over. By one widely cited estimate, integration and implementation services eat up roughly three-quarters of an enterprise software project's budget, dwarfing the license cost. MuleSoft's connectivity research has for years pegged the average large enterprise at around a thousand applications with under a third of them actually integrated. Against that backdrop, paying a single vendor to pre-integrate the modules for you was not lazy. It was rational. You traded depth in any one area for the promise that the pieces would at least talk to each other.

The bill for that trade came due elsewhere. A full SAP Ariba rollout runs twelve to eighteen months and starts around a quarter-million dollars a year for large deployments, with something like twenty hours of training per user before anyone is productive. Coupa is lighter but still a six-to-twelve-month project that usually needs outside consultants. More than 40 percent of ERP implementations fail to meet their objectives, by Computer Weekly's count, and practitioners who track procurement technology specifically put the share of digital-procurement initiatives that disappoint at 70 to 80 percent. The suites were also built for indirect spend: laptops, travel, office services. They were never strong at direct materials, where sourcing is entangled with bills of materials, engineering changes, and supplier collaboration. Coupa effectively conceded the gap when it bought LLamasoft to, in its own words, "bring together spending and supply chain data."

And here is the part that matters most in 2026: the suites locked your data in a proprietary schema and were built years before anyone needed to point an AI model at it. They achieved integration inside their own walls and became, from the outside, exactly the silo they were sold to eliminate. They are integrated, but not intelligent. Which leads to the uncomfortable reframe: when you bought a suite, you were not really buying procurement excellence. You were buying integration. The suite was a workaround for a problem that lived one layer down.

A full source-to-pay suite rollout runs 12 to 18 months; an AI-native specialist can be live in about a month. Implementation estimates from industry reports.

The integration tax is real

Before declaring best-of-breed the obvious answer, it is worth admitting why "just buy the best tool for each job" failed the last time people tried it. Because they did try it, in data.

From roughly 2015 to 2022, the modern data stack was the standard-bearer for best-of-breed: Snowflake for storage, Fivetran for ingestion, dbt for modeling, a separate specialist for every layer. It was elegant, and it worked beautifully right up until teams had fifteen tools instead of five. Then the engineers who were supposed to be building data products spent their days writing glue code, reconciling schemas, and chasing version conflicts. Data lakes turned into data swamps. The market responded the way the cycle predicts: in October 2025, Fivetran and dbt Labs announced a merger into a roughly $600-million-revenue company, collapsing layers that best-of-breed had split apart. The data world started re-bundling.

That is the honest counterweight to this entire argument. Integration is not free, and it never becomes free. The pendulum does not swing because integration stops mattering; it swings because the cost of integration changes. So the real question was never "suite or best-of-breed." It was always: who pays the integration tax, how much, and where does the work live?

What AI actually changes

What is different now is that two technologies have driven the cost of integration down by an order of magnitude, and they attack it from opposite directions.

The first is the unified data layer. The same Snowflake-style cloud platform that unbundled the data warehouse can serve as a single home for operational data: spend from your purchasing tool, awards from your sourcing tool, terms from your contract system, inventory from your ERP, all piped into one place and joined on common keys. The crucial move is that integration shifts from the application layer to the data layer. You stop wiring every tool to every other tool in a point-to-point mess and instead have each tool publish to one hub. Swap a tool out, and you re-point one pipe instead of rebuilding a dozen connections. This is what kills the suite's oldest argument. "If we buy best-of-breed, our data will be siloed" was true when the data lived inside each application. It is false when a single data cloud holds the unified copy regardless of how many applications feed it. Gartner has a name for the resulting architecture, "composable," built from packaged business capabilities that snap onto a shared backbone, and its analysts are blunt that no single suite vendor is the best at everything.

The second is agentic orchestration. For decades, a workflow that crossed two systems required an engineer to hard-code the bridge. An AI agent does not need the bridge pre-built; given access to each application's interface, it can call them in sequence to satisfy an intent, the way a person clicking through two systems would, but at software speed. The connective tissue that suites sold is becoming something an agent generates on demand. Open standards are accelerating this: Anthropic's Model Context Protocol, released in late 2024, aims to "replace fragmented integrations with a single protocol," a kind of USB-C for software that lets any compliant tool expose itself to any agent. Andreessen Horowitz captured the consequence in a 2026 essay arguing AI will eat application software: when agents can do the migration and integration work that used to trap you, switching costs fall, customers stop being hostages, and vendors have to win on the merits of the product itself.

Put those two shifts together and you get the framing Greylock's Jerry Chen called in 2017. Value is moving from the system of record, the database that holds the transactions, to the system of intelligence, the layer that reasons and acts across many records. It matters less which suite stores your purchase orders when an intelligence layer can read all of them, plus your market data and risk signals, and take action. McKinsey, which now publishes on agentic procurement directly, estimates agentic AI could open a $200-billion market just for orchestration, agent engineering, security, and governance. It also reports that while 62 percent of organizations are experimenting with agents, fewer than 10 percent have scaled them to real value, and the thing that separates the two groups is almost always a data foundation. Which is the whole point.

Most organizations are experimenting with AI agents; very few have scaled them to value. The thing separating the two groups is almost always a data foundation. Source: McKinsey, The State of AI, 2025.

Consolidate your data, not your software

Here is the synthesis. The suite only ever had two structural advantages: it put your data in one place, and it spared you the integration work. AI moves both of those out of the application layer. Data unity now lives in the data cloud. Integration now lives in the orchestration layer. Strip those away and ask what a monolithic suite is uniquely good at, and the honest answer is: nothing that justifies mediocre modules and an eighteen-month install.

So you no longer have to choose. You can have specialist depth and suite-grade cohesion at the same time, because the cohesion comes from your data layer and your agents, not from buying everything from one vendor. You compose your own suite from the best available parts.

The pattern is not new; only the enabling technology is. It is the Unix philosophy applied to the enterprise: small tools that each do one thing well, composed through a common pipe, with the AI agent playing the role of the engineer writing the script. It is also the lesson of microservices, which unbundled the monolith and created orchestration chaos until Kubernetes and API gateways made the modular model manageable; AI agents and the data platform are becoming that orchestration layer for business applications. And it is the iPhone, where a strong platform plus an open market of third-party apps beat the closed, do-everything devices that came before. In each case, modularity won once the cost of connecting the modules fell far enough. That is the threshold we just crossed.

Where this bites first: direct materials

This shift lands hardest in the part of spend the suites always handled worst. Indirect procurement buys what a company uses: laptops, travel, services. Direct materials are what it sells, and that data lives almost entirely outside a traditional source-to-pay suite. A single direct-materials sourcing decision pulls on the bill of materials in PLM, drawings and engineering change orders from CAD, approved manufacturer lists, supplier quality history, should-cost inputs, tooling constraints, and the production schedule. A generic sourcing-event record cannot hold that context, which is exactly why indirect-first suites struggled here, and why Coupa paid $1.5 billion for a supply-chain company to try to close the gap.

The suites understand that their integration advantage is the one AI is commoditizing, which is why SAP and Coupa have spent two years adding generative AI to guided buying and contract review, and why Coupa keeps buying specialists like the invoice-automation vendor Rossum. They are trying to best-of-breed themselves from the inside, and the strong ones will adapt; the future "suite" may be a curated network of good components under one brand, which is a fine outcome for buyers. A suite is still the right answer for standardized indirect buying, broad purchase controls, and compliance across a distributed workforce.

But the structural advantage now belongs to the AI-native specialist that is open by design: deep in one domain, fast to deploy, built to pipe its data into your cloud and expose its actions to your agents. That is the bet we are making at LightSource. We built an operating system for direct-materials sourcing that connects engineering, procurement, and suppliers around the BOM and goes live in about 30 days instead of a year and a half. The point is not that a specialist wins a feature checklist against a suite. It is that the architecture finally rewards tools that are excellent at one job and easy to compose with everything else, and stops rewarding the ones whose main feature is that they own the data.

A buying framework for the next cycle

If you accept the architecture argument, the practical question is how to buy without recreating the sprawl that sent everyone back to suites in the first place. The next few years of procurement technology decisions should start with architecture, before the vendor demos. Five questions do most of the work.

Decide which systems of record stay authoritative. ERP still owns financial transactions; PLM still owns engineering data; contract management still owns executed agreements. The goal is not to blur accountability but to make those records readable by the intelligence layer above them.

Define the governed data layer first. Supplier IDs, part numbers, BOM structure, commodity taxonomy, payment terms, risk signals, quote history, and quality metrics need common definitions before anything else. This is unglamorous work, and it is the difference between an agent that helps and an agent that hallucinates into a live workflow. A data layer without governance is a swamp, not a single source of truth.

Separate the tightly coupled from the modular. Some processes need real-time consistency and should stay close to the transaction system; a purchase-order approval flow may belong in the suite. Others can be modular if events sync reliably; a direct-materials RFQ with engineering in the loop does not need to live where your invoices do.

Make open interop a buying requirement. Ask vendors how data leaves the product, not just how it enters. Are the APIs complete, are events available, is there support for a protocol like MCP and for a buyer-owned data cloud? A tool that only answers "how does data get in" is a silo with a sales deck.

Price the switching cost up front. If a tool turns painful, can you replace it without losing historical data and supplier context? Design that answer before you sign, not during the renewal.

The shape of the result is a deliberate split between what you consolidate and what you let specialize.

None of this is a return to unmanaged point solutions, and it is not a claim that suites are dead. It is a move from consolidating applications to consolidating data, with orchestration on top. Plenty of companies will still buy a suite where a suite fits, and the ones that won't invest in a data foundation are probably better off with one for now. But they should stop treating "one vendor" as a substitute for good architecture, and stop paying the bundle premium out of an integration fear that was valid in 2010 and is not in 2026.

Barksdale was right that there are only two ways to make money, and that the trick is knowing which way the cycle is turning. The data world is already starting to re-bundle, so this will not be the last word. But right now the force that pushed procurement into monolithic suites, the brutal cost of making software talk to other software, is collapsing. The move that follows is not to bundle harder. It is to consolidate the one thing that compounds in value, your data, and let the software above it compete on merit. Bundle what matters. Unbundle what doesn't.

Sources

• The New New Moats -- Jerry Chen, Greylock. The system-of-record versus system-of-intelligence thesis (originally "The New Moats," 2017).

• Good News: AI Will Eat Application Software -- Andreessen Horowitz, 2026, on AI collapsing switching costs and forcing vendors to win on merit.

• Introducing the Model Context Protocol -- Anthropic, November 2024. The open standard to "replace fragmented integrations with a single protocol."

• Redefining procurement performance in the era of agentic AI and The State of AI -- McKinsey, on agentic procurement, the orchestration market, the experimentation-to-value gap, and the data foundation agents require.

• Coupa Software snags LLamasoft for $1.5B -- TechCrunch, on the suite roll-up and the direct-materials gap.

• The Modern Data Stack's Final Act -- on the Fivetran/dbt consolidation and the re-bundling of the data stack.

• How to Succeed in Business by Bundling -- and Unbundling -- Harvard Business Review, on the recurring bundle/unbundle cycle.

• Packaged Business Capabilities -- Gartner, on composable architecture and PBCs.

Frequently Asked Questions

What is the difference between best-of-breed and a suite?

A suite is a single vendor's integrated set of modules covering many functions, such as a source-to-pay suite that handles sourcing, contracts, purchasing, and payments. Best-of-breed means choosing the strongest specialized tool for each function, from different vendors. Suites trade depth for pre-integration; best-of-breed trades integration work for deeper capability in each area.

Why did source-to-pay suites become dominant?

Because integrating separate tools used to be slow, expensive, and fragile. Integration and implementation services can consume roughly three-quarters of an enterprise software project's budget, so buying one vendor's pre-integrated suite was a rational way to avoid that cost and have a single accountable vendor. The tradeoff was accepting modules that were rarely the best in their category and rollouts that often ran 12 to 18 months.

How does a single data layer remove the siloed-data problem?

A cloud data platform like Snowflake holds a unified copy of data piped in from every application and joined on common keys. Integration shifts from wiring applications to each other to having each application publish to one shared hub. That keeps data unified no matter how many specialized tools you run, which removes the suite's traditional argument that best-of-breed inevitably creates silos.

What is agentic orchestration, and why does it matter here?

Agentic orchestration is AI agents executing workflows across multiple systems by calling each tool's interface to satisfy an intent, rather than relying on hard-coded integrations. It matters because it turns integration from a capital project into something an agent can generate on demand, especially as open standards like the Model Context Protocol let any tool expose itself to any agent. That collapses the cost that pushed buyers toward suites in the first place.

Is best-of-breed always the right answer now?

No. The integration tax is real, as the data world's own re-bundling shows, and a data layer without governance becomes a swamp rather than a single source of truth. Best-of-breed wins when you invest in a unified data foundation and orchestration layer; without that, a suite may still be the safer choice. The point is that the integration fear that made suites the automatic default has weakened, so the decision should turn on capability, not avoidance.

How do you avoid data silos with best-of-breed procurement tools?

Decide data ownership before you buy the tool. Each application should feed a governed data platform through APIs, connectors, or event streams, using common IDs and definitions for suppliers, parts, contracts, and transactions. The data platform becomes the shared source of truth while the applications stay specialized execution layers, which is the opposite of letting each tool become its own island.