I soon discovered that automation is a very broad topic. There are many services to automate, many different ways to do it and each vendor believes they hold the ultimate truth. Choosing the right tools, the right vendor and the right tasks to automate is quite a daunting task, and it’s easy to bite off more than you can chew.
Even though each vendor promised to automate the world for me, I approached automation in a different way. I wanted to maximize my returns on any investment in automation; however, I also wanted to minimize my risk and learn more about the technology.
I wanted this to be a metrics-driven exercise, as well as a learning experience, so I could intelligently invest time and resources as appropriate. I created a new concept called “Automation Portfolio Management.” An automation portfolio is a set of one or more automated processes to provide a lights-out service. As your portfolio returns on your investment, you measure its effectiveness and gain insight into how automation works, how best to implement it within your own organization, and what types of returns to expect. Automated Portfolio Management is the science of evaluating your automation portfolio and choosing the best areas to pad your portfolio for the greatest returns.
I started my automation portfolio about a year ago, with an investment in a server and database automation platform. The two projects I was most interested in at the time was a server build process that took, on average, 45 days to complete, and a database patching process that required several resources and thousands of hours per quarter to execute. Both of these processes were selected because they occurred commonly, were riddled with missed SLAs and commonly caused problems. I also knew these processes were standardized and were a good starting point for my portfolio, as they were prime candidates for ROI.
The first thing I learned was that automation like this is a new concept for most administrators, and requires some education and training. The automated database patch that the vendor delivered during POC required a few tweaks to manage our full environment because of the nuances between disparate operating environments and our custom applications. However, as the administrators experienced these nuances, they were updating the process to fit each new environment as if they were simply modifying another one of our scripts. This isn’t the most favorable approach when investing in automation because it means I either have to manage multiple, different versions of the same automation, or my team updates the automation to fit each environment before running it. Either way, it sounded like too much maintenance to me.
I spoke with my current vendor, Stratavia, about this problem. They suggested some education and sent an engineer onsite to lead some training on what they called “decision automation.” Decision automation is aware of the configuration and business policies of the environment it’s running on, and uses that information to make process decisions. We worked with Stratavia’s Data Palette solution to automate our critical IT processes such as server provisioning and database administration.
The moral to the story is that good automation should not be treated like scripts which are modified to fit each environment they run on. Good automation should evolve to handle more environments using decision automation through environmental awareness. Lesson learned: investments in decision automation yield easy returns.
The server build process offered lessons as well. A server build process requires several administrators and spans multiple responsibilities. For example, the process we automated included steps to image an operating system, install and configure a database, and secure the system per our compliance standards. Each one of these tasks is owned by a separate group in my organization. For this type of automation which spans groups, there needs to be a leader in charge of the entire process. I created an automation task force to handle this problem, which is comprised of several administrators who meet periodically and are considered our automation engineers. These groups are expensive; however, the savings in the process far outweigh the investment (i.e., the 45-day process now takes just a few hours).
I measured my returns, as well as quality metrics, and took my lessons learned to reinvest into new automation opportunities and tools. I plan to diversify my automation portfolio across new areas like network and storage, while continuing to build more automation in the server and database realm. The savings I’ve realized provide more than enough budget for these new investments.
Automation portfolio management is a pragmatic way to implement automation while staying within budget and resource constraints. Each time a new process is automated, be sure to measure the effectiveness of that automation and reinvest your savings into new automation and automation tools.
He received a PhD in Computer Engineering from the University of Rhode Island, an M.S. in Digital Signal Processing from Indian Institute of Technology, Madras, and a Bachelor of Engineering in Electronics & Telecommunications from Osmania University. Anupindi was the recipient of the 2006 Thomas Edison Award and the 2005 CIO Excellence Award. He can be reached at Nagesh@nagesh.com.
