Orchestration is the coordination and management of multiple seemingly unrelated pieces to accomplish a specific goal. What makes these pieces related is the outcome of the orchestration that they work together to influence.
Orchestration logic brings all the different components and pieces together to carry out the actions step-by-step and enables integration and communication between those components.
Let’s have a look at an example, for instance in the finance industry, when a customer applies for a loan there will be steps and procedures in place to ensure this particular prospect is eligible to receive the loan.
As it is illustrated in the above model, this model orchestrates different pieces that are unrelated, but their collaboration ensures specific goals i.e. whether or not an individual is eligible to receive a loan? The objective of this particular process is to find the answer to a business question which is identifying an eligible or ineligible person at the end of the process.
In the above example, this business process is a type of orchestration, but please note in this case, the whole objective of this model is to answer an operational question.
There are different types of orchestration models; transient or long-running models.
When a result of orchestration can go into a dormant stage and can be resumed and continue later in days, weeks, months and sometimes years’ time.
This type of orchestration is appropriate for long-running operational decisions as well as human workflows. They can be fully automated (i.e. Including decision robotics for end-to-end decision automation) or semi-automated. The semi-automated orchestration enables human intervention at any point in time. Therefore, the decision can be reviewed or altered by an expert.
This type of orchestration, once started, will finish (almost immediately) without a need to go into any intermediate dormant stages.
There are different models that are transient orchestration such as:
- Decision and Rules flow
- Decision requirement Diagram (DRD)
- Information Requirement Diagram (IRD)
Some of the transient orchestration models such as Decisions and Rules flow, Information Requirement Diagram (IRD) models are based on sequences of multiple steps that they join, fork and follow each other until they reach the End or Terminate state. And in quite opposite, the Decision Requirement Diagram (DRD) is based on dependencies of different pieces such as Input Data, Business Knowledge, and Decision.
In any business, now more than ever, it has become more critical to ensure processes and operational decisions are adaptable to changing conditions in a state of flux. This means any Orchestration model i.e. Transient or Long-Running will need to be built, modified, deployed and executed based on changing requirements of day-to-day business operation as the requirements for operational decision changes. These changes make orchestration much more needed than before to enable communication and interactions of different parts of operational decisions based on requirements of market dynamics, regulation and policies, as well as data and information.
Last updated April 17th, 2020 at 09:28 am, Published April 16th, 2020 at 09:28 am
CEO and the founder of FlexRule – He is an expert in architecture, design, and implementation of operational decisions, business rules, and process automation. Created Decision-Centric Approach, a methodology that brings People, Data, Rules, and Processes together to automate operational business decisions.
This approach is recognized by Gartner as the missing link to provide business value to organizations.