What’s the real future of Procurement Tech?

Twenty (20) Years Ago, we asked What about BoB? when the debate in ProcureTech between BOB (Best-of-Breed) vs. POE (Platform Oriented Enterprise) was getting drowned out by the emerging suite players.

Did you go out and assemble your own suite of best-of-breed modules to suit your needs, and then pay the consultancy integrators big bucks to integrate them, or simplify your life, settle for a 60% to 80% solution and buy a suite that gave you an all-in-one solution (and bypassed difficult and expensive integration requirements) that was hopefully strongest where your core needs were?

It was a valid hot debate because most suites were centred on one (or two) strong modules that the firm was founded on, with the other modules either hastily built to what the firm considered an MVP so that they could sell a (mini) suite or acquired (and partially integrated) so they could have a suite, even though some of the modules were loosely connected (and sometimes even built on entirely different UX philosophies with noticeably different user interfaces).

Furthermore, twenty years ago, the bigger the suite was, the worse or more disconnected part of the suite was. In the beginning, most vendors started as e-Sourcing or e-Procurement and mini S2C and P2P suites were built up around those modules, respectively. S2P suites were usually built by one mini-suite vendor acquiring another (or, in rare cases, a CLM or SXM vendor realizing they needed both and getting the help of an investment firm). You had frankensuites built from three (3) primary solutions (and, in some cases, fattened up by additional acquisitions over time), which felt as disconnected as they were to use. However, the one-vendor-throat-to-choke and one-implementation-team comforted the C-suite and those purchases were easier than trying to get permission to acquire a bunch of best-of-breed solutions and then write a big cheque to an integration consultancy that you hope can get the solutions to all work together, at least until major solution upgrades, in which case the consultancy will have to come back and upgrade the integration.

Then orchestration came along and SOFIA (Solution Orchestration Framework Integration Architecture) was supposed to settle the debate once and for all. With modern orchestration solutions, you were supposed to be able to bring your own best-of-breeds, integrate them all with modern orchestration, and either use their native intake, or bring your own, to open up their solutions to everyone who needs access. That was the theory. The practical reality is different.

I’m not sure if it’s still the case, but for years, neither you nor your consulting and integration partners could integrate your own solutions with Zip — Zip had to do it internally because it was too complicated and needed to be done a specific way. Oro, first designed to make Ariba usable and then to make other major last-generation suite solutions usable, provided you with a similar situation — partner solutions are pre-integrated and easy to onboard, other solutions took time. Then there’s Tonkean, now part of Coupa, that could integrate anything if they did it and you gave them the time to do it. Time being the key word. (They were essentially assembling an application for you … no quick out-of-the-box configuration!)

None work(ed) out of the box, and there’s two reasons for that.

The first is that you can’t quickly MVP generic orchestration solutions that are flexible, powerful, easy to use and work with today’s SaaS — the Enterprise has to be carefully thought out and designed and the coding talent needed is not the script-kiddie drop out talent that many (AI-first) firms are employing.

The second is that most platforms, frankly, weren’t even built for integration, which means that they definitely weren’t built for orchestration. Modern orchestration requires more than the ability to push some data in, and pull some data out. First of all, it requires the ability to push all data in and pull all data out. Secondly, it requires the ability to programmatically trigger and execute functions and workflows from external sources. Most platforms don’t support that (well). As a result, orchestration platforms don’t work. If the platform doesn’t have, and completely expose, its API (through secure channels to apps with appropriate security credentials), orchestration is not truly possible.

As a result, most of the big orchestration providers are trying to use AI-first tools (and vibe coding, which, as we’ve made clear many times, only produces vibes that are please to the smug sniffing coders who use it, not good code) to quickly code their own S2P apps and modules, and essentially reverting to a POE (2.0) solution — internalizing their orchestration solution as a platform oriented enterprise to build a next-gen classical suite solution. (Oxymoron intended!)

But is that the future? (Hopefully not!)