The Six Best Automation Questions from HPE Discover

I’ve just returned from HPE’s  customer and partner event, HPE Discover London, where I took part in a panel session about Automation and the Cloud.  

It’s always enjoyable to meet old friends, discover new ones, and share experiences of travelling the path to improve the delivery of IT services and applications; something which for Automation Logic is at the core of what we do.

There were six great questions that came up in our session which for me, summarise some of the crucial topics that you’ll need to address if you are embarking on an automation and cloud journey. We were at HPE Discover, so HPE customers there were largely based on HPE OO and HPE CSA platforms, but these questions are universal and can be applied whatever technology foundation you are building upon.  Here’s my summary.

1.What are the typical things we should automate?

The driver behind automation is usually to reduce time-to-market (do things faster) and with greater quality.  This reduces rework and ultimately reduces cost.

If you started on this path a few years ago it was all about automating simple infrastructure provisioning (a server or VM).  These days it has progressed into automating IT4IT value chains, and enabling services such as software delivery platforms.

2. How do I not automate for the sake of automating? How do you stop automating bad processes?

Not everything needs to be, nor should be, automated.  Sometimes the cost of automating does not justify the reward.  Other times the existing, often manual, process is flawed (because that’s just the way it’s always been done).  

I have two comments on this:

1. Benefits analysis: A benefits analysis methodology is needed that baselines existing performance and estimates future improvements for a price.  This is a topic for several other blog posts.
2. Leadership style: This concept is broader than just IT.  All too often I see people following the same process (because that’s how it’s always done) as a way of saying they’ve “checked all the boxes, so I’ve done my job”. Meanwhile the reason, or goal, for doing the process is unknown.  In most situations, this is bad.  Leadership is needed to transform the organisation from executing to avoid errors, to decision making for achieving excellence.  

To learn more, read this great book: Turn the Ship Around! by David Marquet .

3. How do I decide what should be kept in my data center and what be put into the public cloud?

There may be regulatory compliance reasons why some data cannot leave your data center, or if the data does then it must stay within a certain jurisdiction.  To best address these risks and issues, information security specialists need to be engaged in the beginning and throughout the process of going to the public cloud.

Another measure of risk is how quickly you can respond to an incident.  To better understand, ask the question, if I need to perform a given change to my system to mitigate risk, what service allows me to do that the quickest?  My internal IT and data center, or a public cloud provider?

4. What’s the best way to set up an automation team?

Historically many organisations had informal pockets of automation distributed around their business.  When automation became an area for investment, many organisations then created a centralised automation team.  In the beginning this is very helpful.  It allows you to better understand the issues and opportunities.  However, this model does not scale.  Very quickly your central automation team will be known as yet another IT group that says NO.

Instead one of the early goals of a central automation team must be to create a governance model that enables others to build their own automation through coaching, promoting standards, facilitating reuse, and always practice continuous improvement.

5. What makes for a successful automation project?

Regardless of the technology, you must have user involvement and executive sponsorship, otherwise your project will likely fail. From a technical perspective, automation is usually an exercise in integration. Therefore, all tools, applications, and services should have an API that is functional, performant, robust, and secure.

6. In your next automation and cloud project, if you could do something different, what would it be?

Inspire a greater appreciation for the commercial budget and KPIs.

Frequently organisations invest in an IT project.  For example, a short term, 9 month, deliverable.  Important aspects such as enhancements, dependent systems, support, and retirement, are easily forgotten.

One alternative that helps you appreciate a more realistic budget, and supports KPIs to make decisions around continued investment, is to run as an agile project.  For example, creating product or service oriented cross-functional teams, start with a minimal viable product (MPV), and using KPIs to determine if the service should receive additional funding or be retired.  

Some useful information:

https://www.agilealliance.org/,

https://hbr.org/2014/12/your-agile-project-needs-a-budget-not-an-estimate

Over the years our consultants have amassed huge experience on what makes an automation project successful based on many different technology platforms – HPE included. Hopefully from my answers here you’ll understand that very often (maybe even always?), the critical success factor for any project lies in the non-technical people and business aspects of the project. Rarely is it enough to just hire a few great engineers – we learned that lesson early on at Automation Logic and hopefully it something that every one of our clients learns from us in turn.