Perfect Integration 11 - Orchestration

I've compared the diversity of an IT application landscape and managing its information exchange in a uniform way to translation, with the European Parliament as a perfect example of translating dozens of languages via three intermediate languages. In IT, we only need one, as languages (syntaxes) there are far less complex than in the linguistic world

I've used a similar metaphor to explain how different transport protocols can be handled, by referring to James Bond's opening scenes, where he takes all kinds of transportation in order to escape death. He simply manages by getting off one kind of transportation, and getting on another one. Clever hey?

In the previous post, I've explained the no. 10 of Integration: the envelope. I explained that mechanism that needn't be explained by pointing out how the everyday mailman handles letters, by wrapping and unwrapping envelopes over envelopes

Together with the hub-and-spoke architecture, it is evident that an Integrated Enterprise needs a single point of entry for all this to make real sense. An airport has one control tower, a house has one front door, a lock has one keyhole, a labyrinth has one centre, a process has one starting point, everything has a beginning and an end...

And an orchestra has one orchestrator

With all interfaces and services passing through the same Enterprise Integration front door, they can be perfectly orchestrated. There will be many points of physical transport entry, and these will have to guarantee delivery to the single Orchestration point of entry. Every single message can then be received, transformed and routed to its destination point. There, business logic will be applied, and something will be sent back in return: a technical confirmation receipt, a functional acknowledgment, a reply to a request, an error: all that is up to the agreements made between the sender of the message and its recipient.
They will make it past the Orchestrator again, completing the transaction, who then has to guarantee delivery by the many points of physical exit


This way, everything going on externally and needing your business process touch, will be handled by one single person - well it'll of course be a machine, but stick with me please. Will that effectively give you the ability to manage those externally offered business processes? Yes. Maybe manage is a big word, but it will give you full traceability over them: you'll know who did what when, what and when the outcome to that was - it will all pass the Orchestrator and you can decide to keep the record of that forever

What if you'd also send and receive your internal service requests through the Orchestrator? Don't mention the O-word nor the P-word (Overhead and Performance), just think about it from a logical, conceptual point of view.
Would it be possible? I think so, why not? Would it be helpful? I think so, why not?
Would it give you Enterprise-scale BPM via a small-step approach, where you can take one application or system at a time? Yes

Tick of the BPM box right there then, no need for massive million dollar devouring seemingly endless big bang projects

If you don't do the BPM, but just stay there, with all externally-used and internally used service requests routing through one and the same Orchestrator, wouldn't that be a nimble yet full-blown SOA?
Wouldn't it? Yes

Tick of the SOA box right there then, no need for massive million dollar devouring seemingly endless big bang projects

Two more posts to finish this series: do's and dont's. I'll leave the dont's for last, assigning that an appropriate no. 13