I’m stealing work from my bot.

I just asked Google Gemini to conceive an illustration of the benefits of orchestration. You can see my original prompt and the resulting illustration, credited to Bredebot, in the blog post “Orchestration: Harmonizing the Tech Universe.” (Not “Harmonzing.” Oh well.)

Note the second of the two benefits listed in Bredebot’s AI-generated illustration: “Reduced Complexity.”

On the surface, this sounds like generative AI getting the answer wrong…again.

• After all, the reason that software companies offer a single-vendor solution is because when everything comes from the same source, it’s easier to get everything to work together.
• When you have an orchestrated solution incorporating elements from multiple vendors, common sense tells you that the resulting solution is MORE complex, not less complex.

When I reviewed the image, I was initially tempted to ask Bredebot to write a response explaining how orchestrated solution reduce complexity. But then I decided that I should write this myself.

Because I had an idea.

The discipline from orchestration

When you orchestrate solutions from multiple vendors, it’s extremely important that the vendor solutions have ways to talk to each other. This is the essence of orchestration, after all.

Because of this need, you HAVE to create rules that govern how the software packages talk to each other.

Let me cite an example from one of my former employers, Incode. As part of its identity verification process, Incode is capable of interfacing to selected government systems and processing government validations. After all, I may have something that looks like a Mexican ID, but is it really a Mexican ID?

Mexico – INE Validation. When government face validation is enabled this method compares the user’s selfie against the image in the INE database. The method should be called after add-face is over and one of (process-id or document-id) is over.

So Incode needs a standard way to interface with Mexico’s electoral registry database for this whole thing to work. Once that’s defined, you just follow the rules and everything should work.

The lack of discipline from single-vendor solutions

Contrast this with a situation in which all the data comes from a single vendor.

Now ideally interfaces between single-vendor systems should be defined in the same way as interfaces between multi-vendor systems. That way everything is nicely neatly organized and future adaptations are easy.

Sounds great…until you have a deadline to meet and you need to do it quick and dirty.

In the same way that computer hardware server rooms can become a tangle of spaghetti cables, computer software can become a tangle of spaghetti interfaces. All because you have to get it done NOW. Someone else can deal with the problems later.

So that’s my idea on how orchestration reduces complexity. But what about those who really know what they’re talking about?

Chris White on orchestration

In a 2024 article, Chris White of Prefect explains how orchestration can be done wrong, and how it can be done correctly.

“I’ve seen teams struggle to justify the adoption of a first-class orchestrator, often falling back on the age-old engineer’s temptation: “We’ll just build it ourselves.” It’s a siren song I know well, having been lured by it myself many times. The idea seems simple enough – string together a few scripts, add some error handling, and voilà! An orchestrator is born. But here’s the rub: those homegrown solutions have a habit of growing into unwieldy systems of their own, transforming the nature of one’s role from getting something done to maintaining a grab bag of glue code.

“Orchestration is about bringing order to this complexity.”

So how do you implement ordered orchestration? By following this high-level statement of purpose:

“Think of orchestration as a self-documenting expert system designed to accomplish well-defined objectives (which in my world are often data-centric objectives). It knows the goal, understands the path to achieve it, and – crucially – keeps a detailed log of its journey.”

Read White’s article for a deeper dive into these three items.

Now think of a layer

The concept of a layer permeates information technology. There are all sorts of models that describe layers and how they work with each other.

Enter the concept of an orchestration layer:

“In modern IT systems, an orchestration layer is a software layer that links the different components of a software system and assists with data transformation, server management, authentication, and integration. The orchestration layer acts as a sophisticated mediator between various components of a system, enabling them to work together harmoniously. In technical terms, the orchestration layer is responsible for automating complex workflows, managing communication, and coordinating tasks between diverse services, applications, and infrastructure components.”

Here’s an example from NIST:

Once you visualize an orchestration layer, and how this layer interacts with the other layers, things become…simple.

So maybe Bredebot does know what he’s talking about.