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.