A simple analogy.
Let’s first imagine a real orchestra. What would it sound like without a conductor — just a lot of annoying noise? By adding a conductor, what was annoying can quickly become very enjoyable. Now we get a bit more techy, but remember the role the conductor plays as we go along.
At a very high level, a crucial aspect of service oriented architecture (SOA) is service orchestration. Enterprise systems and integration projects designed according to SOA principles depend on successful service orchestration. Finding a platform with enhanced service orchestration capabilities, then, is a high priority for enterprises looking to build their systems according to SOA. Before going on, let’s make sure we are on the same page when it comes to SOA.
SOA is an approach to developing enterprise systems by loosely coupling interoperable services — small units of software that perform discrete tasks when called upon — from separate systems across different business domains. SOA emerged in the early 2000s, offering IT departments a way to develop new business services by reusing components from existing programs within the enterprise, rather than writing functionally redundant code from scratch and developing new infrastructures to support them. With SOA, functionalities are expressed as a collection of services rather than a single application, marking a fundamental shift in how developers approach enterprise architecture design.
Example: A Bank Loan
To get a better understanding of service orchestration, let’s take a look at a bank loan, for example. A loan broker wants to make a loan request on behalf of a customer and uses an automated Loan Request Service. The broker accesses the Loan Request Service in the enterprise system to make the initial loan request, which is sent to an orchestrator (conductor) that then calls and invokes other services in the enterprise, partner systems and/or the cloud to process that request.
The individual sub-services involved in the loan request include
- a service to obtain credit scores from a credit agency,
- a service to retrieve a list of lenders,
- a service to request quotes from a bank service, and
- a service to process quotes with the data from the other services.
Together, the orchestrated services comprise the Loan Request Service, which then returns a list of quotes from potential lenders to the broker who made the original request.
As the above example illustrates, service orchestration is a fundamental aspect of successfully implementing SOA. In a truly service-oriented architecture, new applications are created by new orchestrations of existing services — not by writing new code.
If it were only that simple
On the surface, service orchestration and SOA are relatively simple concepts. For enterprises faced with integration challenges, skyrocketing IT budgets and increasingly complex infrastructures, building new applications with granular and reusable software components is an understandably attractive approach to creating more agile and competitive systems and reducing time to market.
Service orchestration and SOA, however, can be difficult to achieve without the right set of tools. In its early days, CTOs of large companies eagerly adopted SOA and went about implementing it with a rip-and-replace model. Such an approach resulted in high financial costs as well as major time investments, since it often required developers to orchestrate services programmatically (i.e., write new code), defeating the ultimate purpose of adopting SOA.
What was needed was a simpler and more flexible way to perform service orchestrations and implement SOA. The enterprise service bus (ESB) emerged as the go-to mechanism for service orchestration and SOA. Now there are a number of ESB platforms in the market today, but if you buy in to the fact that embracing SOA eliminates writing code and allows for extensive reuse of components in existing programs, why stop there? We would suggest an ESB platform that could do all that has been mentioned so far, plus let your business stakeholders, IT stakeholders and IT operations stakeholders all be on the same page. This would eliminate false starts and figure pointing.