The key word here is changing. The value of leveraging an orchestration layer is not that you can easily define processes that exists between information and services, but the fact that you can easily change those processes later to adapt to changing business needs. Indeed, if it was all about creating processes a single time, you would be better off with a compiler than an orchestration layer, but the ability to place volatility in a single domain, in this case a process/orchestration engine, will payback many times the original investment. That’s why, I believe orchestration defines your SOA, and you won’t have an effective SOA without orchestration.

Orchestration is a necessity of you’re building a SOA, intra- or inter-organization. It’s the layer that creates business solutions from the vast array of services and information flows found in new and existing systems. Orchestration is a godlike control mechanism that’s able to put our SOA to work, as well as provide a point of control. Orchestration layers allow you to change the way your business functions, as needed, to define or redefine any business process on-the-fly. This provides the business with the flexibility and agility needed to compete today.

You approach orchestration as you would approach any other new technology. First, define its value and purpose. Second, define your own problem domain including existing data and services. Third, prototype a small problem to obtain functional experience. Once that occurs, it’s time to create your strategy, select your technology, and roll out our solution. This is one of those technologies that makes a difference in the way the business runs. I