There’s a difference between automation and orchestration, and knowing which one you’re really doing is half the battle in achieving a truly dynamic data center.

Randy Heffner on CIO.Com wrote an excellent article on SOA and its value, “SOA: Think Business Transformation, Not Code Reuse.” The problem I had with the article was not in any way related to its advice, conclusions, or suggestions. The problem I had was that I kept thinking about how perfectly much of his article could be applied to data center orchestration, operational transformation, and automation. Simply replace “SOA” with “orchestration”, “software reuse” with “automation”, and “business” with “operational” and you’ve pretty much got what needs to be said. Here, I’ll show you what I mean:

The worst CIO CTO misunderstanding about service-oriented architecture (SOA) orchestration is thinking of it as only another technical initiative for automation software reuse. Although SOA's reuse orchestration’s automation potential is real and good, its business operational impact goes much further: In Forrester surveys, 38 percent of Global 2000 SOA orchestration users say they are using it for strategic business operational transformation. SOA's Orchestration’s true source of power is in its business operational design models, not its technology — and this means that SOA orchestration provides a broad foundation for a much larger shift in business operational technology (BT) architecture that goes far beyond SOA orchestration itself. By correctly understanding orchestration SOA, CIOs CTOs can lead their organizations on a solid and well-managed path toward a strategic technology future and greater business value.

This is true for SOA, and it’s true for cloud computing, where it is the orchestration of the data center infrastructure that brings the value to the table through making more efficient the operational processes codified to automate and integrate systems.

This very short (perhaps too short) post on differentiating between automation and orchestration last year kicked off a very interesting (and also short) discussion on Twitter with the core theme appearing to be “why differentiate in the first place?” Why, indeed. I can answer that question with a question of my own: why differentiate between “software reuse” and “SOA”? After all, aren’t they the same thing?

They are not the same, as Randy very eloquently pointed out above. The biggest difference is that discrete components like services and automation are designed from the top-down; that is, they are not necessarily taking into consideration the business side of the processes.

Automation is akin to expert systems: it is the codification of a set of steps to perform some action. That action may be conditional upon variables extracted or shared by other systems within the environment, but they are environmental and focus on specific properties such as CPU utilization, number of connections, or even the user invoking the automation. Automation can answer the question “how do I do this?”

Orchestration, however, resides on the process level and more specifically on the business process level. Business process in this case relates to the operational IT processes which seek to achieve a specific business goal in its execution. Orchestration can answer the question “why do I do this?”

The subtle but significant difference between automation and orchestration is important if you’re looking to realize the maximum benefits from an implementation. Automation will reduce time spent on tedious tasks, yes, but orchestration can streamline processes by discovering – and one hopes ultimately eliminating – redundancy, and aligning the technical aspects of IT with the business.

Oh how you hate that “align IT with the business” line, don’t you? It’s fluff, you’re thinking; just another buzz phrase. In some cases when it’s used, yes, it’s just a phrase. But in the case of orchestration there isn’t a truer set of buzzwords that have been strung together in quite some time.

That’s because the goal of orchestration is to make operational decisions based on business goals and needs in real time. Instead of thinking about bandwidth in terms of how much an application might need, you start making decisions based on what it uses and what it costs and what the prioritization of the business function the application serves. Yes, you probably do factor those variables in today, but orchestration makes them an integral part of the decision making process and uses automation to make the adjustments required without human intervention. Orchestration is the art of tying together those integrations in such a way as to automatically execute against business logic based on operational and business requirements. In the case of orchestration, the whole is greater than the sum of the parts because the integration and collaboration that happens in an orchestration is enabled by automation, but not made from it.

Just as JBOWS (Just a Bunch of Web Services) don’t make a SOA, neither does a bunch of disconnected scripts automating IT tasks make an orchestration. It is the integration and flow of systems from the top down, with a view from the business layer of the stack, that makes an orchestration valuable to both business and IT folks alike. SOA is an architecture, not an implementation. So, too, is orchestration an architecture and not an implementation.

I think some folks from an EDS (HP) said it best in their vision paper: “Orchestration for the Business-Driven Data Center”

Orchestration technology is not the same as systems management, provisioning, workflow management or “run- book” automation (a type of workflow management). These disciplines seek to automate the tasks required to manage elements of the IT infrastructure, such as servers, network devices, storage or databases. The primary goals of automation are to improve response times, reduce errors, reduce IT staffing needs, avoid redundant manual procedures and improve consistency. These are operational goals specific to the mechanics of managing technology.

Orchestration, by contrast, focuses on business goals such as improving business up-time, improving customer satisfaction and retention levels, reducing order processing and delivery times, and reducing missed business opportunity costs.

Well, no. Not really, unless you’re implementing discrete automation points and calling it orchestration. The reason it matters then is that you may not know that you could be realizing more benefit out of the automation if you really were doing orchestration. If you’re doing orchestration and calling it automation, well, a rose by any other name, right?

What you call it isn’t nearly as important as recognizing that there are differences between the two and then applying that knowledge such that you can achieve the best benefits from what you’re trying to do.

Cause knowing is half the battle, right? The other half requires lasers…and for those, you’re on your own.