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.

Advertisements

The Importance of Communmicaiton in Strategy Development

I was provided a great example this week on the importance of an effective communication program.  In my current role I am responsible for a large scale private cloud as well the overall service of all centrally managed servers across the enterprise.  I have crafted and implemented what I believe is a comprehensive and well managed strategy for my service.  Yet to my surprise a senior IT leader in my organization caught me in the hallway for a quick talk.  The individual asked me if we could get together to craft and document a cloud strategy.

My initial reaction was surprise and confusion.  I explained the work that has occurred to validate and how we gathered input on the current cloud strategy.  Luckily, I also understood that this encounter was a result of something lacking somewhere.  So I agreed to meet to learn more.  I spent most of the remaining day thinking about why this encounter happened.  My ultimate conclusion is that I had a flawed communication program.  The portion of my communication program  I use to craft and communicate strategy has three channels targeted towards business input, executive vision, and engaging consumers and those that support the service.

Business Input

I meet routinely with executive leadership from each line of business to assess, document, and understand their priorities.  We have clearly defined roles through this channel.  The business is responsible to define “what” they want.  I am responsible to explain “how” my service will meet their want.  I propose “when” we can deliver their want which we must both agree upon.  We meet routinely to share progress of delivery, changes to solutions, and identify if their wants and/or priorities change.

Executive Vision

I meet with my internal executive leadership and my sponsors to review their intended vision and strategies.  I also have them validate my vision and strategies.  This channel ensures we are closely aligned with one another.  It also serves as a check point to ensure my executives and sponsors are aware of information from the other two communication channels and the message I am presenting to the business.

Consumers/Support Engagement

This channel is another routine engagement with two separate groups.  One is the middle management and consumers from each line of business.  The other is the internal teams that support our service.  This is my version of a business relationship management (BRM) channel.  It’s not only important to understand the customer service being delivered but the customer experience and the painful processes the support and engineering teams may be dealing with.  It’s just as important that this group understands the service strategy and roadmaps as it is for the business leadership and executives.

Conclusion

While I am ultimately responsible for my service and the creation of our cloud strategy I am also accountable to ensure said strategy meets the organization’s needs.  Each channel in my communication program is designed to ensure I understand the needs from each level of the organization and provides an opportunity for me to review our strategy and roadmaps.  But then why was this senior leader not aware of our cloud strategy?  The answer was simple, I failed to include them in the executive vision channel.  They had joined our organization after that channel was established.  The result, a lack of awareness by the individual and a lack of understanding of their needs by me.

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.

Standards 

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.

Consistency

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.

Efficiency

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.

Flexibility

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.