Old School vs New School IT Management: The Politics of Automation and Orchestration

An IT debate has been brewing for years now: the old school IT management, the one built on experience and practice versus the new school IT management, the one built on policy based management and analytic engines that leverage vendor knowledge base and learning algorithms.

This debate is reminiscent of politics. IT is viewed as slow and inefficient bureaucracy by developers and end-users; and yet, IT needs to perform due diligence and impart rigor and processes for compliance, governance, and security. Policies are derived from best practices of well-understood problem-solutions, while experience hardens IT pros toward resolving issues quickly. Oh how IT weaves a twisted tale, since best practices come from IT experience and form the foundation of the policy and analytic engines. In the as-a-Service IT world, strategies are being built around automation and orchestration, which facilitates auto scaling and self-healing. And automation and orchestration implies heavy doses of policy based management actions.

Disruptive innovation is one of the primary drivers for the adoption of new school IT management. As the hardware stack converge towards the commodity limit, businesses view the software application as the layer where differentiation will be realized. This differentiation will come in the form of:

  1. Optimal data center utility;
  2. Optimal availability and scalability for applications;
  3. Maximize utility of IT professionals while minimizing human errors;
  4. Minimize app development and release times.

The real value of an IT pro is during the times of needwhen things break and systems misbehave, and how quickly the IT pro can perform root-cause analysis and bring things back to working order. The counterbalance to this is that there are specific breaks that always follow specific, well-known steps to remediate. These are the opportunities to automate and self-heal. There are also many tasks that may appear repetitive and that self-identify as automation candidates; but requires connected context of the stack and application. Otherwise, it’s a whole lot of wasted actions and time.

Where are you on this spectrum? Is your organization looking at fully automating IT management, hybridizing IT management between some automation & orchestration with some manual intervention, or completely manual? And are you being represented in the policy based IT management world?

Thwack - Symbolize TM, R, and C