Think (about ITSM) before undertaking IT automation

Automation isn’t a silver bullet. Before undertaking automation, an organization must look at their service management maturity level. 

I’ve been in vendor sessions listening to the value of abstracting your application from the hardware layer. Reduction of total cost of ownership (TCO) is the primary business driver. Reducing friction in provisioning IT services reduces overall cost. Automation is a great way to reduce friction. However, one critical prerequisite in the drive for automation is proper service management. 
High TCO is sometimes a symptom of an overly complex or non-existent IT service management practice.

Everything’s a snowflake

The IT service catalog is a good place to start. If a request for a new system requires a bunch of analog inputs, then there’s opportunity for unknown challenges in the deployment process. An example is a server build. If application owners have to define all the file systems, middleware configuration and security settings then the build team has to craft each server build. 

For most organizations, there’s no business driver for such customization. I don’t look to AWS as an example for best practices for enterprise IT operations. However, standard sizing of instances is an example of a practice an organization should borrow from AWS. Offering too much choice can slow implementation. Crafted deployments don’t scale across a wide range of customers and add an unnecessary level of complexity. Offering a static set of options is commonly referred to t-shirt sizes. 

Request process

Another area to consider is the process for requesting services. Users will default to the path of least resistance. I’ll pick on the server build process again. It’s much easier for a developer if given the option of consuming an API to provision ten X-Larger database servers vs. feeling out the same form ten times, a developer will select the API. The service management tool must have the flexibility to take these types of requests. 

Configuration management

And the last area is multifaceted. For this short post, I’ll label it configuration management (CM). CM includes configuration management, inventory, test and quality assurance. These processes can easily trip up any manual service management architecture. Organizations should clearly define the processes for how they request, identify, approve and implement system changes. 

This small heading does a disservice to this area of service management. Just taking a look at the area of implementation is a large challenge. For example, during implementation a good deal of data needs to be collected and validated. 

Going back to our snowflake analogy, how does a QA engineer ensure that a built system matches the original request? Also, how does Audit ensure the requested system falls in the enterprise standards? What’s the artifact that validates the configuration? And just to be mean, how do you measure historical performance of the builds for quality and compliance? 

Conclusion

I’ve just scratched the service of service management. But, these are all basic concerns that need addressing before any consideration of automation. A successful automation project would continue to reduce the friction of a well-defined IT Service Management program. Organizations may find in the process of maturing their IT Management program they realize most of the desired benefits of automation without undertaking the technology project.