Orchestration from an IT perspective is not a new topic but with the drive towards a DevOps focused world, it has become a hot topic.

Wikipedia describes orchestration (computing) as “the automated arrangement, coordination, and management of complex computer systems, middleware, and services.”

In the last three years, we have seen an increasing amount of attention on orchestration with vendors such as Serena, IBM, Microsoft, HP and Oracle beginning to deliver orchestrated software suites and best practices. Many of these products have their roots in earlier tools such as system, product and configuration management. With multiple starting points, it should come as no surprise that there is a fair amount of confusion as to what orchestration really means for customers.

The Wikipedia description above, sets a very wide scope for orchestration. It allows that any tool that can project manage the delivery of software in a distributed environment, has a claim to be an orchestrated solution. It also means that there are a lot of very poor orchestration solutions out there which are little more than a bunch of scripts that do a marginal job or orchestrating certain tasks.

For Orchestrated IT to mean anything, what is needed is a proper framework. This might be vendor driven or, in a perfect world, standards based or based on a standard. The solution also needs to be more than just random scripts. There must be a clear hierarchy of tasks that have a common reporting engine through which they can be monitored and audited.

More importantly, any solution must be inclusive and able to interoperate with solutions from multiple vendors. Too many practitioners today complain about having to use multiple orchestration products because those that they have deployed cannot manage the complexity of their environment.

The problem isn’t just confined to the management of current datacentre based solutions. As companies look to incorporate cloud into their deployment platform choices and buy access to third-party cloud solutions, there is a requirement for orchestrated IT solutions to address all platforms.

All this raises a serious point. If vendors are shipping orchestration solutions that cannot manage complex environment then can they really claim to be a valid orchestration solution? If we take the Wikipedia definition, the answer is no.

DevOps may well act as the catalyst and framework for many vendors to sort out their orchestration. This is because DevOps requires common processes across the entire IT function. Creating those common processes will enable orchestration vendors to use them as a foundation for a multi-platform, software agnostic solution.

The onus is now on vendors to prove that they are capable of managing more than small, discrete solutions. Those vendors who deliver a solution that manages the complexity of multiple platforms, supporting heterogeneous solution and do so in an open manner will win. Those who continue with limited engagement across the IT infrastructure will eventually be seen as white noise and either find a discrete niche or disappear.