Management ≠ Orchestration

As we continue to see a ripple-like effect of agile methodologies washing over the rest of IT (you know, like network and security) we’ve seen the rise of architectures and technologies like SDN and SDDC in addition to the continued expansion of DevOps into adjacent IT concerns.

That’s because the need for (deployment) speed is growing with an appetite nearly as insatiable as that of consumers for apps. Growth of the business today depends on the ability of IT to scale; not just in transaction rates and throughput, but operationally.

Achieving the scale required to support rapid (and often unpredictable demand) means more hardware (whether custom or COTS) and more platforms and more services and more, well, everything. More things that need to be monitored, backed up, configured, and licensed. That’s management.

Achieving the speed required to deploy the apps and delivery services means automation of the deployment process. That’s orchestration.

These two are not the same. It’s dangerous, in fact, to conflate them because doing so tightly couples the one to the other and makes it difficult to rapidly change the processes. That’s often necessary to improve efficiency or add components to the system that are necessary to maintain the performance, speed, and security of the apps on which business relies for both productivity and profit. That can be multiple times a year. Business process management experts tell us from studies that businesses change their core processes 4-7 times a year. They do that based on analyzing all that data IT gathers along with feedback from consumer and corporate users.

Business process orchestration (BPO) became a requirement in the mid 2000s in order to ensure that kind of agility at the business layer.

And now we’re seeing it at the IT layer, too.

Operational process orchestration will be critical to the successful transformation of any organization seeking to enable the scale and speed of deployments necessary for business success.

But that doesn’t mean management isn’t also important.

Management is still required and while certain management tasks may be (and often should be) automated, it’s not orchestration. Automated nightly backups of critical systems, upgrades, license management, patches, and even asset management (inventory) are important means by which IT can ensure it scales operationally, enabling a single administrator to manage increasing numbers of devices, but it is not orchestration.

Conversely, orchestration is not management. While you can certain benefit from using orchestration engines (systems, frameworks, whatever you want to call them) like OpenStack or Cisco ACI or VMware NSX, none of these enable the core management of the actual components for which they provision. They can certainly create and start up a BIG-IP to provide LBaaS, for example, but it isn’t in the business of actually managing that instance. It doesn’t do updates, or apply hot-fixes, or watch alerts or any of the day-to-day responsibilities that still ensure the business keeps running. That’s the task of management, not orchestration.

And while they are not the same, they are both equally important in an application world. Orchestration enables the business to scale by making it possible for IT to scale app deployments, while management ensures the business stays running by taking care of all those tasks we seem to forget (thanks, cloud) still have to be accomplished. 

Management works (collaborates) with orchestration by enabling self-service provisioning and deployments, but they are not the same. Nor should they be.