Service Request vs. Automation

I was recently a part of an interesting discussion where individuals were asking why use cloud automation instead of an IT Service Management (ITSM) tool?  This is a very real and valid question.  I personally believe that both are valid business delivery tools.  However, they are not duplicative even though they both may help with delivery of services.  To view either as being able to replace the other is unwise as they deal with two very separate user perspectives; customer service and customer experience.


ITSM and Customer Service

At it’s core an ITSM leverages policy to deliver a structured and consistent customer service experience.  You can leverage the service request process to ensure standard information is gathered each time and follow a defined workflow through delivery.  This can help any organization as it deals primarily with a business process and allows the flexibility of ad-hoc technology solutions to complete each step.  When properly designed the service request process in an ITSM can provide a very pleasing customer service that delivers consistent outcomes.  While a structured process can assist with speed of delivery as it guarantees proper requirements gathering for the request and, much like a checklist, guarantees workflow steps are completed.  But it does not guarantee speed since this is, as previously stated, primarily operates at the process layer.


Cloud Automation and Customer Experience

In comparison cloud automation also leverages policy but then adds technical automation to deliver a structured and consistent customer service experience.  Since it also adds a technical automation layer it lends itself very well to self-service which is provides an improved customer experience.  The drawback to many cloud automation tools is they deliver a service independent of an organization’s ITSM tool.  This forces many organizations into choosing their ITSM process OR self-service cloud automation services.  Luckily most cloud automation solutions provide an accessible API that lends itself very well towards integrating both processes.  But be warned, an API does not guarantee complete and total integration.


My Conclusion

There’s no such thing as a free puppy.  While integrating an ITSM and Cloud Automation brings tremendous business value by delivering on customer service and customer experience, it also brings with it technical debt.  Technical debt such as a structured SDLC, requiring new skills, and increased complexity added to an off the shelf solution.  This typically puts the blending of ITSM and cloud automation out of reach for small or midsized organizations.  However, for those organizations willing to take on the challenge will be greatly rewarded.

ITaaS Guiding Principles

I wanted to share some guiding principles I follow that assist me on maturing an organization towards ITaaS.  Each particular step has it’s own challenges and unique tools to assist in implementation.

My current team hears these principles nearly every day.  I actually have a standing challenge with them involving these principles.  I will buy their lunch if they can provide an example of a situation that is not resolved by use of the principles.  So far I’ve not paid out any lunches.  I’m rather confident in them as I have sat through numerous presentations demonstrating various cloud automation techniques, overcame my own daily challenges, and seen various long term strategies implemented .  In each situation the principles applied even if the individuals were not aware of them.

Each principle serves as a foundation component for the next to build upon.  As with any foundation item, if not soundly implemented can cause issues once built upon.  This is key to understand as it assists with future troubleshooting.


This is the first and oddly enough a very difficult principle to implement.  The standard can be anything; provisioning a server, a policy, a configuration standard, a process for applying a patch, etc..  Let’s take an example of provisioning a Windows 2012 R2 server.  Defining the provisioning process is something I would guess most organizations have defined.  With the implementation of virtualization it’s become a necessity and typically results in a golden image that most engineers create and maintain.  However, cloning an image is not server provisioning.  There are many other items to include such as IPAM, domain memberships, VLAN assignments, support tools, change control adherence, updating record repositories such as the CMDB, implementing firewall rules, DNS updates, and integration into various programs such as patch management, configuration management, compliance management, and vulnerability management to name a few.  When you start looking bigger picture the difficulty increases but it must be done to ensure the next step occurs.  To help keep things organized I find it best to use your documentation tool of choice such as a wiki, a word doc, or a KB repository.


This is a desire for any organization yet it is what is often at times eroded by the organization’s culture.  I find it’s eroded due to the fact that it’s not been achieved.  Everyone knows that one “go to” person they contact directly when they need something because they do it to your expectations when compared to the random person we get when we use the service desk queue.  Let’s continuing with our example and take the server provisioning standard and train a team to leverage it for each service request.  What if that team was 5 people, or 10, or 15, or 20…therein lies the challenge.  I find most managers struggle with a desire to not be dependent on a single person yet overwhelmed with frustrations when trying to train a large group to be consistent.  When working in the consistency principle, do not focus on how long the task takes.  Just ensure it is completed the same way every time. This is where a good set of tools can assist a team.  In this example a workflow orchestration tool is a game changer.  Something like vRealize Orchestrator can be extremely helpful.  I’ve heard someone refer to vRO as their perfect employee and they are right.  No matter who on your team of 20 is running the process, vRO will ensure each step is completed for them and not forgotten.


Do not confuse consistency with efficiency.  Remember, the consistency principle is simply ensuring something is completed the same way every time.  Efficiency is where you apply automation to your process.  To build on our example, you should now have some excellent data at your disposal.  If done well, you can now identify how long each step of the provisioning process takes.  Use that business intelligence to determine what should be automated.  While you can automate practically anything some things really shouldn’t.  Automation is a technical investment and as with any investment understand the ROI.  This is where you can build upon vRO’s API integration.  As you become more adept at using the tool you can integrate with other tool’s API such as your service desk software, hypervisor, IPAM device, firewalls, network devices, etc.. You can also use various scripts to assist in the automation and have vRO execute them for you.


This is really the nirvana of ITaaS that we are chasing.  This is where we truly find out if we are ITaaS or not.  Staying with our server provision example and let’s say the organization now wants you to add Red Hat Enterprise Linux 7 to the service catalog.  Or maybe you were just informed that a new firewall platform is being implemented.  Did your team just freak out?  Did they tell you that it will take months to deliver?  Or worse yet, did they tell you that it can’t be done without purchasing a new set of tools?  If the answer was “no problem” then congratulations, you are living the dream.  You see, this is really a validation of the preceding principles.  If each is sound then the impact on your service is minimized.  All you are doing is changing a standard, changing a workflow, or changing an API/script.  Not to minimize those efforts but this is why you go through normal development, testing, and QA cycles before you hit production.  If you are finding you have to completely start over there is a problem somewhere in the earlier phases.

Think about these four principles and how they can be used.  While used server provisioning as an example think about how they would apply in other programs such as monitoring, configuration management, patch management, or compliance management.