Author Archives: thedoctor

True Orchestration Platforms Are A Lot Rarer Than You Think. How do you find one?

In our last article we told you that you need a modern orchestration platform in order to deal with the application sprawl not just in an average organization but in your own department. However, the majority of today’s platforms are not orchestration platforms but ORCestration platforms, integrating your applications in a manner that is forceful, ugly, and impure, to say the least.

So how do you find a real platform? Well, for starters you can use the checklists in our first two part where Part I gave you the red flags to look out for and Part II gives you key features to identify.

But if you’re techie enough, or savvy enough, here’s a starting list of technical requirements that you look for. (There are more, especially if you’re looking ahead to 2035 and beyond, but let’s face it, you’re lucky if you’re running 2015 technology anywhere in your organization. So if you make it to 2025, that would be a quantum leap for you.)

Technical Requirements

  • Micro-Service Building Blocks that can be assembled together to support all existing and emerging internet an communication protocols
  • Transactional Blocks that encompass standard data-centric operations in the business back office around the information and finance supply chains
  • Blockchain Support for immutable records that capture data, ownership, and processing that has transpired
  • Context Aware as it’s not just data, it’s metadata of what it represents, who’s data it is, where it was obtained, when it was obtained created, and how it was accessed, why it was valid (and who validated it) in a secure, immutable, block
  • Policy Definition Support that can recognize the security and compliance policies of the integrated applications and ensure they are checked and adhered to before processing any request
  • Dynamic Routing that can ensure messages are re-routed when issues are detected to maintain (guaranteed) response times
  • Resiliency via decentralization and multiple service instances to ensure that one failure doesn’t prevent critical functions and processes from being completed
  • Adaptive when human intervention is required, it is recorded and new rules, and workflows, are generated to prevent a human from having to intervene again for the same problem
  • Secure as modern security protocols and requirements are built in at the core, not around the edges as an afterthought
  • Trustworthy full support immutable data objects, policies, and security independent of what systems are connected to the orchestration platform

Savvy Requirements

The whole point of Procurement is supposed to support the business, a business which must buy and sell to survive, and do so profitably. (That’s why Procurement is so focussed on cost, to keep expenses down, and supply assurance, to keep sales flowing.) This means that the business also requires Sales (who sells) and Supply Chain (who ultimately supplies) and that all of these units must work in harmony. However, fundamentally, without inputs, which depend on suppliers, there are no outputs, which means that the Supply Chain, and the support for the Supply Chain Ecosystem, is fundamental.

This means that the best orchestration solution will be one that is built to support the supply chain department’s integration requirements within the organization and with external partners, not just Procurement. After all, if you read the series Bob and I authored on Legacy Sourcing and Planning Solutions, you can’t divorce Direct Sourcing from Supply Chain and expect success.

So if you want a great orchestration solution, find one that was originally built for supply chain where the vendor has layered on out-of-the-box support for Procurement. This maximizes your chance for success as you will already know supply chain integration support has been taken care of.

Wondering where to start? Maybe start by taking a look at something like HubX12 built as a decentralized distributed network for next-gen supply chains. With its built-in support for modern and emerging internet and communication protocols, advanced chains of custody, and compliance, it could serve as the transaction backbone that you need to integrate existing systems and build custom capabilities both within your organization and your supply chain.

Stop Buying ORCestration. You need Orchestration!

In our last article we told you that the majority of today’s platforms attempting to unify the Procurement application space for you are not Orchestration platforms but ORCestration platforms, integrating your applications in a manner that is forceful, ugly, and impure, to say the least. Definitely not what you need in a modern orchestration platform.

A real Orchestration platform is:

–> Light

They aren’t adding another bulky SaaS platform with its own deep stack requirements, vendor maintenance requirements, data store requirements, and rules engine which must not only be maintained separately, but replicate data and rules across the apps it connects. It’s a truly next gen platform, built up from only the (micro) services necessary to connect the apps and accomplish the tasks. It’s a composable container community, not a 100 room palace with no option in between.

–> Cheap

Next generation platforms, built on modern distributed architectures, and built to work behind the scenes (not in front) to allow the users to access the ecosystems they need to access through the applications they are comfortable with, won’t be million dollar applications. They’ll be a fraction of that as the organizations will be buying just a configurable framework, that they can configure themselves as needed, and not a full, heavy, SaaS application with all of the required support infrastructure just to keep it operational (regardless of whether it integrates any applications or not).

–> Flexible

Workflow can be built up, torn down, and put back together on the fly, as required to support evolving processes. Intake, UI, and integration can all be defined, and redefined, as processes evolve, new applications enter the landscape, and old applications leave. The organization is not restricted to a fixed intake screens with limited configuration, predefined workflows, or limited data formats.

–> Open

Built on composable micro-services, that are fully documented and compatible with modern stacks, they allow anyone to build the necessary integrations, workflows, and data manipulations necessary for true process orchestration. They also support the definition of contexts that allow them to be natively compatible with the data structures of the applications they are integrating. And one definitional mistake won’t bring down the whole platform because it’s not a monolithic megalith built on a house of data cards.

–> Real-Time

Not only are data pushes and pulls accomplished in real time, but the orchestration platform will automatically propagate data updates to all apps that maintain a copy of the data. Moreover, when an input the orchestration platform is an initiator of a process, the entire process will be executed without explicit instructions as each output will trigger the next step and serve as the input for that step.

–> Execution

Real orchestration platforms don’t connect apps in workflows, they execute workflows, and they do so dynamically based upon the inputs and outputs of each step. They adapt, and when transactions occur that cause exceptions that require human intervention, they learn from those interventions and dynamically construct new exception workflows on the fly, ensuring that no specific exception ever has to be manually dealt with twice.

–> Blockchain

It will support blockchain at the core, allowing not only for the integration and processing of arbitrary data records, but for immutable data objects to be input, created, and output — with a full history of what app did which change when. That’s a lot more than you can say about today’s ORCestration platforms.

–> Multi-Protocol

Not only will the orchestration platform be composable from the core up, but the building blocks will be designed in such a way that they can be composed to support all of the standard, obscure, and emerging protocols that might need to be supported. As a result, the platform will be able to integrate not only current apps, but emerging apps as well.

–> Organizational

A true orchestration platform is designed to support organizational processes and applications, not just Procurement, allowing the input (signal) data to come from any organizational system and be pushed to any other organizational system, bridging the gap between sales orders, POS demand signals, and demand planning and supply chain (re)order and logistics systems. True orchestration finally tears down the technology walls holding Procurement back, vs. today’s ORCestration platforms which just strengthen their foundations.

–> Secure

Not only are these platforms built on security at the core, recognizing both security standards AND security policies, including the security policy of each application that is orchestrated by the platform. This means that when a user initiates an action, it only executes if they have the appropriate (data) access in all of the applications on the orchestration platform that are needed to complete the action. No hoping, or praying, that the ORCestration platform encoded the right security checks in its native workflow.

–> Policy (Aware)

As per our last point, modern orchestration platforms will understand the concept of policy at the core, and not just for security — for compliance as well! The orchestration platform will integrate with all of the applications that contain encodings of the organizational compliance requirements, understand those compliance requirements in their native contexts, and ensure that all processes are completed in a compliant process.

–> Collaborative

The core of the orchestration backbone is designed to not only support application collaboration, but user collaboration across the organization, and even with connected parties in the supply chain, through the native support of internet communication protocols as well as all standard application messaging protocols. Collaboration will never be easier than with a true orchestration platform.

–> Resilient

Since it’s not just another megalithic SaaS app, but instead a (micro-)service platform built up from building blocks, one failed integration and even one failed block will not bring down the whole platform, the rest of the platform and apps will still work.

–> Process (Focussed)

Modern orchestration platforms are designed to support organizational enterprise processes end-to-end, not departmental functions end-to-end. They can integrate and orchestrate any application in the organization’s software ecosystem (all 1,000+ in a large enterprise) as well as any partner systems the organization has access to.

–> Exception (Orientation)

Modern orchestration is designed to quickly identify exceptions, invoke exception processes, and ensure humans are only involved for a here-to-forth unforeseen exception. Moreover, it will allow for the human instructions and guided process to be automatically captured and encoded to make sure that humans never have to teach the system twice.

Unlike yesterday’s ORCestration platforms, today’s (and tomorrow’s) true orchestration platforms are built on modern technology stacks, and future-proofed for tomorrow’s applications, not just yesterday’s.

It’s Orchestration, NOT ORCestration!

In fiction, Orcs are generally described as a brutish, aggressive, ugly, filthy, repulsive malevolent race of corrupted monsters, embodying the “hell-devil” (orc-néas) of Old English literature. Ever since Tolkien popularized them in his Middle Earth as the servants of Mordor, pretty much every work of fiction has described them the same way. Even though Tolkien himself said they understood morality, they tended to only apply it to themselves as they saw fit in their constant state of corruption, a theme that is echoed to this day even in Dungeons and Dragons and Warcraft (which are the fictional works most of today’s generation will associate Ocs with). While some may strive to be moral and better than others of their kind, they still remain warlike and barbaric by our civilized measurements.

As a result, to be ORCish is to be brutish, aggressive, and even repulsive in one’s actions and to be ORCestrative is to organize things in a way that is forceful, ugly, and impure.

Which precisely describes the majority of today’s platforms attempting to unify the Procurement application space for you.

Today’s ORCestration platforms are:

–> Heavy vs. Light
They add yet another bulky system to your stack that takes months to implement, must be constantly maintained, comes with its own data store and rules engine, requires its own user licenses and management, and exacerbates the app proliferation problem you’re trying to solve with yet another app.

–> Costly vs. Cheap
Many of these platforms charge on a per user basis, with fees that can easily be $250/user/year or more JUST for basic intake. If everyone in a large organization needs their own user license, which is, FYI, the only way to achieve true intake and enterprise wide orchestration, an average large organization will be spending 1.25 Million a year for what is essentially Middleware 3.0 with Intake! It might be saving you a few Procurement or ERP licenses, but, as all the fake Christians like to say, you’re just taking money from Peter to pay Paul. Good job!

–> Rigid vs. Flexible
Most of these platforms are very rigid in terms of workflow, configuration, intake process, UI configuration, integration options, etc. Most of them only permit certain actions (intake, process reporting, etc.) to be initiated through the platform. Instead of increasing organizational flexibility, you limit it.

–> Closed vs. Open
Some of these platforms are so rigid (and inflexible) that they won’t even allow partners to do new application integrations because if it’s not done just right, it could all crumble like a house of cards. Classically, middleware was supposed to open up opportunities, not close them down!

–> Batch vs. Real-Time
In most of these platforms, data transfers between the platform and the apps are typically done on a batch schedule and if you need data in an app right away, you have to a manual push-pull. Heck, even classical RPA works better!

–> Routing vs. Execution
All the majority of these platforms do is route requests and data packets from one application to another, requiring a (moderate to large) number of third party applications to do anything at all. You could replace their core function with a last generation workflow engine at a fraction of the cost without sacrificing that much actual functionality!

–> EDI/API vs. BlockChain
Not only is most data shared in batch after being routed using traditional workflow, but it can only be accepted, processed, and routed if it is shared in a classical data exchange format. Forget about integrating it with any modern systems that use blockchain for traceability or e-payments. Just Fuhgeddaboudit.

–> Single vs. Multi-Protocol
Not only are the majority of these platforms limited to classic EDI/APIs for data interchange, but they tend to run off of a single protocol for network and stack integration. This not only limits them to one stack, but prevents them from being forward-compatible with next generation technology that will need to support multiple stacks (LAMP, MEAN, MERN, Django, etc.), multiple classic protocols (including HTTPS, DHCP, ICMP, SNMP, etc.); specialized protocols like BGP and OSPF; and emerging protocols like MCP.

–> Departmental vs. Organizational
Today’s platforms are being sold as the answer to your Procurement needs by providing you with an interface to all of your Procurement systems — that have already been integrated. But here’s the problem — just integrating your Procurement systems doesn’t meet all your needs! The inventory is in the inventory management system, the lead time in the logistics system, and the forecast in the demand planning system, and these are all part of the supply chain systems. All today’s platforms do is force your existing best of breed applications into a hodge-podge frankensuite. You might as well stick with a mega source-to-pay suite and buy a license for everyone in the organization, especially since some of them were built with intake in-mind (as long as you buy a license for every organizational user).

–> Insecure vs. Security-Aware
Of course the platform comes with its own security, on its SOC2 certified servers, with a secure log-in for every user, but that’s the only security it recognizes. It doesn’t recognize the security of any of the applications that are integrated, beyond the API access key. This means that all of the data available to the platform through the key is available to all of the users of the platform, whether or not they should have access to that data, unless the security policies are replicated in the platform.

–> Rule-Based vs. Policy Aware
Not only do each of the connected applications have their own security protocols for data access, but their own policies for compliance. With regards to some data, such as third party personnel profiles or employee communications, not only is the data restricted to certain people, but they must have reasonable cause to view it, assert that cause, and possibly log the proof of that reasonable cause. Also, some pricing data must be restricted to authorized parties to prevent unauthorized disclosure to competitors, etc. The majority of these platforms can’t even implement basic policies yet alone enforce (compliance) policies in the apps they integrate.

–> Autonomous vs. Collaborative
While all of the applications are integrated to the fancy middleware, they still all function autonomous, usually unaware what other platforms are connected, who needs to use and is using the data and outputs of the platform, and where the inputs come from. All they know is that some piece of mysterious middleware shoves data in, executes API calls, and pulls data out. They don’t know where it’s going, how many copies are being made, and how, and even if, those copies are being maintained. The autonomous aspect of each connected application amplifies the data nightmare of the Procurement organization as well as the readiness for next generation Procurement.

–> Brittle vs. Resilient
Most of these platforms are constructed like traditional SaaS apps and have al the same weaknesses. When they go down, they go down, and so do all their connections. Like the One Ring, they are invincible until the One Ping overloads the stack and they come crashing down.

–> Function vs. Process (Focus)
Business run on processes, but these ORCestration platforms still focus on pushing data into, executing through API, and pulling data from functions. The better platforms support end to end Procurement functions, but they are still only functions, because the whole point of Procurement is to support the organization, which means that the process goes beyond the four walls of Procurement. They need to elevate the functions in the apps they connect into process flows, but they’re not doing that.

–> Task vs. Exception (Orientation)
The whole point of software is automation and freeing the user from tactical data processing and thunking that computers are great at so they can do the more strategic and relational work that computers are poor at and can’t do at all! Considering automation in these platforms requires users to manually define workflows, including workflows for exceptions, one by one, they don’t do a very good job of empowering the user.

Today’s ORCestration platforms are the engineering equivalent of trying to fix a break in a line with spit, glue, and duct tape. It might work for a bit, but it’s not going to take much force for the “fix” to fall apart!

Free Vendor Coverage Comes To An End on Sourcing Innovation!

Posted December 3, 2025

And all relevant free coverage to date has been taken down as of today.

This was a painful decision to make, the most painful decision the doctor has ever had to make regarding SI, but one where he has no choice but to make it (as the only alternative is to shut SI down, which might still happen, but at least not today).

Additional details are below, but for those who just want a quick summary, here are the five key points that summarize what led to this:

  1. SI has dealt with too many vendors in the past year that do not adhere to its policies of openness, honesty, and mutual respect.
  2. A significant number of these vendors have wasted a lot of the doctor‘s time and left both him, and you, with nothing for it.
  3. The behaviour of some of these vendors is so concerning that the doctor cannot recommend them with a clear conscience or even leave any existing coverage up on SI, as coverage on SI is an implicit recommendation of the vendor (as per the FAQ) as a provider of a solid solution that the doctor believes will honestly try to serve its customers.
  4. the doctor does not give bad product/platform reviews or call out bad actors (and only calls out marketing/public statements that are misleading, deceitful, or outright false — i.e. he will only attack their public claims) — it could just be one or two bad apples at the vendor who will be gone within a year or two (as most move on to their next job before their lies and bad actions catch up with them) — and taking down just a handful of posts would be calling them out.
  5. The bad actions * of about 1/5 of the vendors SI has dealt with over the past year have collectively cost SI significantly. It is critical to remember that:
    1. the doctor DOES NOT make any money off of SI# (as he does not charge readers, did not charge vendors for coverage, and no longer takes sponsorship)
    2. the doctor has been essentially DONATING 40% of a normal working week to SI for the past two years (as that was the time required to do an average of 3 vendor reviews and 18 other articles a month)
    3. this donation time does not include the eight-plus (8+) weeks of time lost when vendors don’t schedule necessary follow up demos, return fact checks, or believe the doctor when he says the demo is free and then insist upon customized reprint right/services contracts for their consideration before follow-up demos or fact-checks are returned — so when that adds up to months of time, there’s not enough hours left to make a living (when he has to scramble to write more articles, do more research, or cover other vendors to fill gaps in the daily publication schedule).

Quick Summary Ends Here

Up until 2016 (when the doctor joined Spend Matters as Lead Consulting Analyst until 2023), maybe 1 vendor interaction a year would lead to wasted time and a piece that couldn’t be published and the success rate was 98 or 99 out of 100. This year, the success rate was 4/5. In other words, 1/5 vendors (significantly) wasted my time. Vendors have collectively wasted at least eight (8) weeks of time from bad actions*. Add that to the thirteen (13) standard work weeks that were effectively donated to you to provide free education and insight and to vendors (who might not have another avenue) to get their message out, and that’s twenty-one (21) standard work weeks without revenue. Moreover, from the remaining twenty-nine (29) weeks (leaving only two weeks vacation), you still have to dedicate 30% to business development and overhead, and that leaves twenty weeks that might see revenue (and might is the operative word since non-compete requirements from bad actors not only cost that revenue, but other opportunities as well). It’s well beyond unsustainable!

(the doctor can sustain himself on 39 weeks, which means that he can afford to dedicate up to 13 weeks on SI for free market education as the doctor works an average of fifty-plus [50+] hours a week, and those ten-plus (10+) extra hours are for the business development and overhead so that the one week a month on SI can be maintained.)

* The bad actions range from:

  • refusal to schedule follow up demos/answer additional questions (after an initial demo and coverage outline are completed) that results in a few hours of loss
  • refusal to return/verify fact checks after a complete write up, and corresponding reprint/advisory contract at the vendor’s request [that was never asked for and not required for coverage], that results in two days of loss (and right now the doctor is sitting on 7 unpublished mostly complete write-ups just from this year — two weeks of waste right here!)
  • asking for multiple revisions on a contract/project plan over weeks, and then completely ghosting SI (when the vendor obviously had zero intention of pursuing and should have just said not interested now after the first proposal and discussion) (well over a week of waste right here, only counting revisions because initial asks are standard business development effort)
  • cancelling (multi-stage) projects just before the delivery date/initial presentation of the first phase (and then, because they cancelled/refused it, refusing to pay for the first stage) (two projects alone add up to over a month)
  • not even bothering to give proper notice of intent to cancel a contract at the end of the first phase (and simply not paying) (no lost time, but lost income due to failure to make a guaranteed payment without proper notice AND non-compete requirements until that date)

So at this point it should be clear that:

  • SI is in the situation that it can’t continue offering vendors a free service if 20% of them are going to waste time that SI does not have (and refuse to show any respect for the generous offer of time that was made)
  • SI is also in the situation where it can’t recommend a number of these vendors with a clear conscience (and if they had prior coverage, which is an implicit recommendation, leave that coverage up), but
  • SI can’t remove just some postings and essentially target just some vendors as that not only violates its impartiality policy, but punishes the vendor as a whole when it might just be a few bad people that will either leave when their bad actions catch up with them or be forced out when their (lack of) business ethics come(s) to light
  • SI can’t charge new vendors for coverage if it leaves up relevant free coverage of existing vendors, because why should some vendors pay and not others?

Hence another tough decision had to be made, and since it seems the only thing that these bad apples understand is money^, then that’s the decision, and policy, SI is forced to make. This means that not only all must all free coverage come to an end, but any relevant coverage in the last few years must be taken down as well. (The majority of coverage from the doctor‘s pre-Spend Matters days will stay up as most of those vendors are gone, and most of the remaining coverage is too outdated to be of any use beyond a point in time assessment to determine how far the vendor has come, provided you have recent coverage.)

But since SI still wants to help the 4/5 vendors who are open, honest, respectful, and coming to SI with a desire to help companies and clients succeeds, it’s not going to charge Big Analyst Firm rates. It’s setting the fees at an amount that is just enough to cover the time the effort requires. And will endeavour to maintain the fees at this rate, adjusted for inflation/operational cost increases, for as long as SI has already been in existence.

Moreover, unlike the big analyst firms that only grant one year, these fees will grant two year reprint rights and ensure the coverage can be found on SI for two years as well! The goal is that a startup can get what it needs to get started for 1/10 of a Big Analyst Firm quote and some dedicated analyst time for 1/5 of what the Big Analyst Firm will charge. Enough so that the vendors understand that time is valuable and you should respect whatever time you are getting, but not so much that they can’t afford it (even if the time is worth much more). (Prices are quite low and can be found on the public pricing page.)

Finally, DEMOS WILL REMAIN FREE as they always have been. It’s just that, from now on, there is no write-up without the up-front purchase of a reprint. the doctor will spend the hour he needs to get the insight he needs to properly position you on recommendation lists when people ask who does X well and would be suited for me, but that will be the only free time you get as a vendor from now on.

# If you have the time, ask yourself how many of the influencers you follow every single day are truly doing it for free and, more importantly, will continue doing it if some of you don’t give them your money. When you sign up for a newsletter, how long before you get a “Special offer: act now and get my entire archive of templates for 50% off” or “My online training course for you, as a subscriber, is only $99.99!“. Seriously. the doctor follows a lot of the modern Linked-In content generators … and he can tell you that not a month, if not a week, goes by where, if you are paying attention, they are asking you to buy something from them and it’s a guarantee that if not enough of you do, they’ll go away and take all their content with them.

Now ask yourself the last time the doctor asked you to buy his course, his training archive, or pay for the private articles, or donate to his site. While doing that, go back through the entire 19.5 years of public history (which is now about 6,500 articles). Try to find one instance he asked you, dear reader, to pay. And then, when you get exhausted, give up. Because you won’t find one. the doctor has been intent on helping you understand what you need and, professionally, on helping companies do better — usually vendors who want to build better solutions, but occasionally buying organizations who want to find the right fit technology for them!.

! the doctor must admit that given the current state of the vendor ecosystem, this may be his main focus professionally going forward. Specifically, educating buying organizations on not only how to assess technology, but assess the vendor from a partnership perspective, and working with them to make sure they get it right. Failure rates have reached 88% across the board, and 94% for AI projects. Not only are too many companies selecting the wrong technology, but too many companies selecting the right technology are selecting the wrong vendor. He’s heard directly from, and indirectly about, too many companies where, after the invoice was paid and the system turned on, they were essentially abandoned by the vendor who wouldn’t help them unless they found, and verified, an actual bug in a system they didn’t know how to use! (And then, sometimes, the vendor would demand a mandatory cost increase on the annual license renewal despite not fulfilling their initial promises.) And given his experience with vendors over the past year, he’s inclined to believe every single story! And he finds it both sad and disgusting! If the doctor gets short-changed by a vendor, he loses thousands, maybe tens of thousands. But if you, as a buying organization, get shortchanged, you lose millions. Utterly disgusting!

^Too many vendors still ask the doctor how to get on the radar of a Big Analyst Firm where the sales person says you don’t even get analyst time at 10K+ a day unless you commit to a research package of 30K to 50K or more, 75K or more if you want a guaranteed write-up with a limited one-year re-print right with no renewal included, and over 100K if you want to be sure to get on the map. It’s the wrong question because the vendor can’t afford it, and even if they can somehow scrape together an amount for a minimal engagement, they’re not going to be included in the maps or recommended anyway as the analyst firms have to maintain those high six figure relationships by only recommending the vendors who are on the maps. (The right question is “why do the maps even matter” and the right follow up is “how do we explain to potential customers the maps are leading them down the wrong, dark, rabbit hole they will never escape from“.)