Vendors are focusing on orchestration and automation of their infrastructure to extract pounds instead of pennies from their customers.
If you decide that’s it time to try automation, let's consider what options, tips and plans you could make for a successful deployment.
It's true that the operational management road is littered with failed attempts. HP OpenView, BMC Patrol, Microsoft SCVMM--all have been over-complicated, consultant-rich and expensive failures for all but the rich few. Dozens of other failed companies have had varying levels of success at attempting to automate a single process, much less orchestrating them into a single whole.
I believe that the failure factors can be reduced to a basic set of points: technical limitations , people problems and management will.
In a competitive market, vendors have always attempted to use their existing customers as cows to be milked of cash. Once you purchased a vendor's products, then the vendor aimed to lock the customer into its own ecosystem. As an example, Cisco makes its own network management platforms that are universally reviled by customers for poor functionality, slow performance and lack of features. While claiming that CiscoWorks had better access to developers and would be first to market with feature support and the best integration, it never really delivered on the promise.
The other side of this picture is that supporting third-party management platforms for your products is difficult. Consider Microsoft's SMS/SCVMM management tool set, which promised support for server hardware for automatic detection of drivers and patches, yet remained years behind the release cycles. In the end, SCVMM is used only to manage Microsoft products and still lags months behind the release cycle of any new products. Another example, Cisco CS-MARS, supported third-party firewalls on acquisition but ditched support later because vendors couldn't, or wouldn't, co-operate and integrate their security products.
A lot of equipment doesn't have the resources to run extra software. Many vendors struggle to have stable products at all, and the very idea of adding more functions that would increase costs (and reduce profits) and might introduce more bugs is not good business. Therefore, vendors focus on getting their core functions working and nothing else.
Finally, the other limit is the constant development of new technologies. As new operating systems, switching silicon and storage functions arrive, it means that management tools are quickly obsolete or holding back adoption.
Although orchestration is a technology challenge, ultimately the people involved affect the decision making process. The lack of multiple disciplined people means that resources to build and maintain the orchestration are very limited in supply For example, storage networking was so complex that only a focused resource could comprehend it. Moreover, the people with the vision to lead such deployments are even harder to find. That said, the use of hypervisor virtualization has led to convergence among the network, server, storage and OS teams that provides some hope for the future.
And, finally, job security. Some people will feel threatened rather than embrace the challenge to learn new skills. Their role will move from routine tasks to routine analysis and strategy review. This can be hard to perceive.
The practical reality of modern IT is that the demand for uptime means that deep change to an existing infrastructure is impossible to achieve. The process of ongoing incremental change (as espoused by ITIL and PRINCE2) means there is no opportunity to orchestrate the entire data center process and take deep risks with live services. Even the opportunity to save large amounts of money and time is never going to be enough to satisfy the ITIL change prevention processes on systemic risk.
And while it's tempting to consider implementing automation for smaller areas, in practice, orchestration is an all-or-nothing business. That's why cloud computing is likely to be popular: Someone has already implemented the orchestration, and you can just "move in" with your software. This is perceived as incremental risk, not as systemic risk.