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.

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!