Managing Enterprise IT Automation
Automation is trending in IT and everyone including CIO and IT administrators’ performance is measured by the quantum of automation achieved in an organization. While there may be differences in measuring the effectiveness and efficiency of IT automation, there is no second guessing on a few key principles that need to be followed while organizations embrace automation in a big way. These principles bring a programmatic structure to IT automation just like the principles help improve the SDLC process. Let’s look at some of the benefits that can accrue to an organization by way of principles of automation.
The key principles are:
- Automation code/run books maintained in a Configuration Management System
- Separation of data and logic
- Compliance driven: trackability and auditability
- Integrated automation
Automation code/run books maintained in a Configuration Management System
In a traditional IT organization, it is not that automation has not been attempted or is not prevalent. There have been scripts, codes and snippets that help achieve automation and drive efficiencies, small or large. However, most of this automation is unstructured and unorganized and the entire process of automation faces the danger of dying a slow death in case the initiating team member is replaced or decides to leave the organization. Additionally, if the automata (any script or entity or engine that does automation) suffer any bug or stop functioning one fine day, it is extremely challenging for the IT team to troubleshoot and make that work again. Fixes that are made again may remain undocumented, potentially, paving way for the same situation to repeat in future. This is where maintaining the code in a Configuration Management System is of value. Such a measure helps maintain a central repository, possibly well-documented, providing access to authorized users and as an added benefit, improving the reusability of the automata across the organization, thereby improving the overall automation efficiency.
Separation of data and logic
One of the best practice that is followed in software development is to segment data and logic so that there is no hard coding of any data and there is no data exposure through the code thereby maintaining data privacy. However, in a traditional IT automation model, this practice is perhaps given a go by, thereby leading to security threats, data exposure, code malfunctioning due to environment change etc. For instance, hard coding a SQL access username and password in automata for performing database automation will make the automata fail whenever the access credentials are changed in the database. Suggested measure is to maintain data that are required for automata to function, in a separate YAML / JSON / XML file (preferably in an encrypted format for sensitive data) and the automation logic is maintained on a separate code. This will lead naturally to parameterisation of code which will in turn enhance the reusability of the automata progressively.
Compliance driven: track-ability and audit-ability
All automata may not always be successful, so there must be room for reversing automata at the time of failures or undesirable results. Hence, it is recommended to maintain a track of the actions that are taken through automata thereby giving room for reversing the changes at a later stage. Tracking can be in the form of a simple syslog entry or Windows event log entry or maintaining a separate log file. Another key factor is to maintain an audit log such that compliance requirements are addressed. IT auditors can scan/read the audit log, gain an understanding of the automated activity and make observations on the level of compliance that activity has adhered to. It is possible to combine these two functionalities and maintain one central log repository addressing these two requirements simultaneously.
IT automation activities usually tend to have an impact on the end-user of IT services, be it a simple task like password reset or service health check. To ensure that the end-user experience is positive, in most organizations, end-user requirements are interfaced via a Service Desk tool. Given this, it is therefore suggested that a tight integration is maintained between such a tool and the automation engine. This integration will continue to maintain the end-user experience while improving the overall back-end operational efficiency. Taking the password reset scenario again as an example, imagine an end user’s interface not changing for password reset while backend gets changed from manual effort to automated execution via tight integration with automata. Turnaround time that used to be a few hours will be cut down to a few minutes (if not seconds) while not impacting the end user’s front end interface and experience.