Home > Blogs > VMware Operations Transformation Services > Tag Archives: cloud automation

Tag Archives: cloud automation

How Demand and Capacity Management can Streamline Service Requests in your Cloud Environment

Eric TisdaleBy Eric Tisdale

What does Request Fulfillment have to do with Demand and Capacity Management in Service Management? Are these process areas still relevant today, as IT concentrates more on delivery of Cloud Services?

As we know, the Demand and Capacity Management processes are closely related, with increases or reductions in demand driving capacity plans and delivery. Service Requests in Request Fulfillment are often thought of simply as wishes for “stuff”. Linking these three process areas and connecting and leveraging of ITSM and virtualization tools at your disposal will be key to supercharging your ability to handle cloud requests.

Leveraging automation will streamline provisioning of requests for both private and public cloud offerings. When your Request Fulfillment process is synergized with the Demand and Capacity processes, you will provide high value to your customers. Why? Because drastically reducing provisioning times and facilitating application and infrastructure teams means IT is much more efficient at providing services.

Do you have these issues?

  • IT tells me they can build a virtual server in a few hours. Why does it take us 90 days to deliver?
  • Why are we just now hearing of this new requirement? I was told this project was approved in last year’s budget, but this is the first the first request I have seen. Why doesn’t the Business communicate with us (IT)?
  • How could this project have doubled in size in a week? What could have changed since our last demand report?

For successful and timely delivery of components for any server, storage, or application request, the below areas should be well thought out and planned:

  • Re-imagine your Request Fulfillment approval process with automation tools by creating application and infrastructure blueprints that facilitate delivery efficiency
  • Don’t be afraid to ESTIMATE! Too many times folks in IT think they have to have every Gigabyte accounted for and each contingency covered to provide an educated guess for future demand. As requests move through their lifecycle, think in terms of:
    • Small, medium, or large request
    • 40%, 60%, 90% confident that the request is accurate
    • Estimates at 120, 90, 60, and 30 days out from delivery
    • Engage all stakeholders (Program Management, Account/Business Relationship Management, Infrastructure and Line of Business Architecture, etc.) in the gathering and input of demand data
    • Enable capacity management to become more agile and adaptable in responding to resource demands by providing comprehensive visibility into current capacity to allow enhanced demand forecasts with virtualization management tools that you may already own
    • Abstract applications from infrastructure, and then infrastructure from resource pools to drive agility in the fulfillment process
    • Utilize predictive analytics in virtualization tools to assists in applying demand and allocation-planning principles for enhanced utilization of resources, leading to shorter fulfillment cycles
    • Break down the silos that inhibit your Request process. Enable linkage of each ingredient of a service request into a single request record and integrate all electronic or paper forms utilized for demand funnels, requirements gathering, etc. into your service request tool.

Future posts will explore the above topics in more detail.

Building key relationships between the Demand and Capacity Management and Request Fulfillment processes and integrating them within your environment will culminate in a greatly enhanced procurement and request delivery experience for your customers. You many find that you have many of the enabling tools necessary and simply need a strategy and plan for implementation.

______________________________________________________________________

Eric Tisdale is a Transformation Consultant based in Louisville, KY.

6 Processes You Should Automate to Provide IT-as-a-Service

kai_holthaus-cropBy Kai Holthaus

IT-as-a-Service (ITaaS) is one of the current paradigm shifts in managing IT organizations and service delivery. It represents an “always-on” approach to services, where IT services are available to customers and users almost instantly, allowing unprecedented flexibility on the business side with regards to using IT services to enable business processes.

This brave new world requires a higher degree of automation and orchestration than is common in today’s IT organizations. This blog post describes some of the new areas of automation IT managers need to think about.

1&2) Event Management and Incident Management

This is the area where automation and orchestration got their start – automated tools and workflow to monitor whether servers, networks, storage—even applications—are still available and performing the way they should be. An analysis should be performed to study whether events, when detected, could be handled in an automated fashion, ideally before the condition causes an actual incident.

If an incident already happened, incident models can be defined and automated, implementing self-healing techniques to resolve the incident. In this case, an incident record must be created and updated as part of executing the incident model. Also, it may be advisable to review the number of incident models executed within a given time period, to determine if a problem investigation should be started.

It is important to note that when a workflow makes these kinds of changes in an automatic fashion, at the very least the configuration management system must be updated per the organization’s policies.

3) Request Fulfillment

Automation and orchestration tools are removing the manual element from request fulfillment. Examples include:

  • Requests for new virtual machines, databases, additional storage space or other infrastructure
  • Requests for end-user devices and accessories
  • Requests for end-user software
  • Request for access to a virtual desktop image (VDI) or delivery of an application to a VDI

Fulfillment workflows can be automated to minimize human interaction. Such human interaction can often be reduced to the approval step, as required.

Again, it is important that the configuration management system gets updated per the organization’s policies since it is part of the workflows.

4&5) Change and Configuration Management

Technology today already allows the automation of IT processes that usually require change requests, as well as approvals, implementation plans, and change reviews. For instance, virtual machine hypervisors and management software such—such as vSphere—can automatically move virtual machines from one physical host to another in a way that is completely transparent to the user.

Besides automating change, the configuration management system should be automatically updated so that support personnel always have accurate information available when incidents need to be resolved.

6) Continuous Deployment

The examples provided so far for automating activities in an IT organization were operations-focused. However, automation should also be considered in other areas, such as DevOps.

Automation and orchestration tools can define, manage, and automate existing release processes, configuring workflow tasks and governance policies used to build, test, and deploy software at each stage of the delivery processes. The automation can also model existing gating rules between the different stages of the process. In addition, automation ensures the correct version of the software is being deployed in the correct environments. This includes integrating with existing code management systems, such as version control, testing, or bug tracking solutions, as well as change management and configuration management procedures.

In an ITaaS model, automation is no longer optional. To fulfill the promise of an always-on IT service provider—and remain the preferred service-provider of your customers—consider automating these and other processes.


Kai Holthaus is a delivery manager with VMware Operations Transformation Services and is based in Oregon.

Key People, Process and Policy Considerations for vRealize Automation Success

Keng-Leong-Choong-cropBy Choong Keng Leong

Organizations implement VMware vRealize Automation (vRA) with the aim of shortening the provisioning of infrastructure services and the release of applications through self-service and automation. To achieve this, there is a need for balance between governance and business agility. Projects are more likely to fail or face significant obstacles if they do not plan adequately and ensure the necessary policies, processes and workflows are in place.

In this blog, we’ll explore some of these key planning and design activities that are often overlooked on the journey to cloud automation.

Key Players

vRealize Automation - Key PlayersThe very first thing we need to do is identify key players. The roles are mapped to actual team members in the organization. Minimally, we need to identify:

  • Service consumers – Authorized users of the self-service portal who can request and manage their cloud services, and which business groups they belong to
  • Approvers – Approves all possible requests
  • Cloud administrators Administers and manages the cloud infrastructure, cloud resources, and the configuration and maintenance of vRA
  • System administrators – Administers, configures and maintains the guest operating systems in the virtual machine
  • Application administrators – Installs, administers, configures and maintains the application software hosted on the virtual machine
  • Cloud security and compliance analyst –Monitors, analyzes and tests the security and compliance of application, guest OS and infrastructure

A common mistake is not identifying all the necessary key players and involving them in the planning and design early, which could have drastic impact to the vRA workflow designs.

Service Models

vRealize Automation - Service ModelsThe next step is to determine what cloud services will be offered through vRA. Many organizations start by offering Infrastructure-as-a-Service (IaaS), provisioning virtual machines leveraging existing vSphere virtual machine templates. For organizations that are heavily virtualized, this is not transformational and has very little incremental impact visible to the business.

To realize the full values of vRA, organizations should look beyond provisioning up to the OS level. The steps that follow after the server with OS is ready usually involve manual or scripted steps and multiple parties (app, middleware, db, security, etc.). Being able to automate these steps, package them and offer the package as a cloud service will result in significant efficiency gains. For example, instead of offering Windows 2012 as a catalog item, why not offer a SQL Server 2012 or a Tier 2 Application consisting of a pair of load-balanced Apache Tomcat Servers and a SQL Server?

Developing service models requires engaging the business to understand their requirements. For example, what is the point in offering a Windows Server 2003 R2 catalog item when no new business applications will be running on it. We also need to understand the service levels and performance requirements so that we can provision the machines in the correct pool of resources that provide these capabilities. We also need to identify which business groups will be entitled to these services.

Request Models

vRealize Automation - Request ModelsOnce the service models are defined, we can identify all the use cases for vRA and the types of requests within the scope of vRA. Request models (i.e. workflows) for the services are mapped out and documented. These may include:

  •  Request for a virtual machine
  • Request for a database server
  • Request to increase the resources of a virtual machine (e.g., add CPU, Memory)
  • Request to extend the lease of a virtual machine
  • Request to reboot a virtual machine
  • Request to decommission virtual machine
  • Request to snapshot a virtual machine
  • Request to back up a virtual machine

It is common to start by mapping out the current workflows and automating some of the steps using vRA and/or vRealize Orchestrator. While this approach may be quick, it has proven inadequate in many customer use cases I have encountered. Requirements to interface with a business system, process and function appear in late stages of the vRA implementation project, jeopardizing the project’s schedule and budget. In order for an organization to automate as much of the process as possible and make significant impact to service provisioning and delivery times, the whole service fulfillment cycle needs to be studied, optimized and transformed. It’s imperative to understand the whole business process through initiation of an IT/business project, budgeting, approval, procurement, installation, building, integration, testing, release, operation, management, support and retirement. Then, you must identify how the vRA will fit and interface with the various stakeholders, functions, processes and systems. Sometimes, it is necessary to have the vRA interface with external workflows already existing in other systems such as an IT service management (ITSM) system.

In addition, each request model needs to be correctly categorized and aligned with the organization’s governance policy and processes. For example, a request for a virtual machine in production vs. a machine for development will require different change management process, approval levels and approvers. These considerations should be incorporated into the design of the workflows and vRA approval policies. The request models can also be re-categorized to reduce governance overhead due to risk reduction with process automation and standardization of blueprints.

Access and Entitlement Management

vRealize Automation - Access & Entitlement ManagementAfter the key players, service models and request models are finalized, the different security access roles for vRA can be defined and mapped to the key players, so that they have adequate permissions and privileges to perform their tasks defined in the request models. Entitlements to the services are also configured and granted to the respective business groups and/or users.

Communication and Awareness

vRealize Automation - Communication & Transition SupportBefore the launch of the vRA, don’t forget to brief all key players on the processes and how to use the vRA based on their roles. Print and distribute reference cards and stickers to remind them of the process steps and how to get support when needed. It is important to cater for more hand-holding and support during the initial transition phase. The project will fail if users start to revert to old ways and stop using vRA.

========
Choong Keng Leong is an operations architect with VMware Professional Services and is based in Singapore. You can connect with him on LinkedIn

The Business Case for Cloud Automation

Automating in the Cloud Pays Off

Approval Policies: It’s All About the People

By David Crane

dcrane-cropTalking with customers, I hear a consistent message that is being asked of IT from the business; that is the ability to deliver IT services more rapidly and efficiently while reducing costs.

Combined with the demand for greater flexibility in delivering infrastructure and application services, my customers are implementing cloud environments, and they’re looking to take advantage of the automation capabilities of those platforms.

Automation, in its simplest guise, offers consumers an “app-store” style experience, where they can browse to a self-service portal for requesting cloud services and select virtual machine templates or blueprints that have been created for them.  As part of the provisioning process, consumers can also make changes to the virtual machine properties such as network, storage, compute, and memory within the ranges for which the blueprint they are using is configured.

Part of the provisioning process can be the approval of that request from that user’s line manager, or a budget holder for that service or line of business.  The traditional way of automating this step is to allow the approver (again via the self-service portal) the ability to authorize the request.

Consider, however, the typical activities that take place during this step, as shown below:

 

Approval Policy-Crane

 

Activity time that is conducted by a toolset is typically a very small percentage of the overall task time, and those customers who try to optimize this time typically get a poor ROI on their efforts.

Instead it is reducing the activity time that is carried out by people—and subsequently reducing the wait time for these activities to be carried out—where the benefits of automation are to be realized.

Many IT organizations attempt to do this through the implementation of approval policies, which are based on a set of rules around tangible parameters such as service cost, sizing, numbers, and so forth.

The focus then becomes configuring automation toolsets (e.g., VMware vRealize Automation), using these rulesets with the expectation that it should be a simple case of rolling out the approval policy to replace the “people approvers” and all will be well in the world.

However, as my customers are discovering, without careful consideration and consultation of the people element of the process, the carte blanche introduction of approval policies frequently meets resistance and pushback from those people approvers whose wait time is causing the benefits of automation to not be realized in the first place.

Reassurances of “trust in technology” or “trust in policy” usually falls on deaf ears, with counter arguments from the people approvers of needing to oversee and meet compliance, governance, and security requirements especially in those sectors (e.g., financial), where fierce regulation exists.

A compromise is then subsequently drawn up, with SLAs or OLAs determining response times from people approvers when requests come in, or approval policies existing for small-value or perceived low-risk requests, which offer minimal benefit.

While such agreements may suit the people approvers and placate the personal and political problems, they are a blunt instrument and still constrain the agile technology platforms that have been put in place, to the detriment of the business, and to the benefit of competitors that have addressed the problem in a different way.

My customers who have been successful in introducing significant approval policies have understood that one of the core reasons for this pushback is that people fear having their responsibilities cut back and the removal of their charter over the approval of the service requests of their line staff and business unit.

Stay tuned for my next blog, coming soon…I will go into more detail, including suggestions on how to successfully allow those approvers to retain their charter, while still introducing significant approval policies, but also achieving further business benefit through the publication of the cost savings, via approval policy-centric dashboards.

====
David Crane is an operations architect with the VMware Operations Transformation global practice and is based in the U.K.

A Click Away—The IT Vending Machine Experience

IT users increasingly expect a more consumer-type of enterprise technology experience. A user friendly, cloud-based experience will increase productivity, efficiency, and customer satisfaction.

This infographic reveals why the consumerization of IT is a key development that organizations can leverage to ensure that IT is successful.

 

140207-VMware-OnDemand-IT-Services-final-LORes

VMware #1 in IDC Worldwide Datacenter Automation Software Vendor Shares

Today’s VMware Company Blog announces that market research firm IDC has named VMware the leading datacenter automation software vendor based on 2013 software revenues.(1)

IDC’s report, “Worldwide Datacenter Automation Software 2013 Vendor Shares,” determined that VMware’s lead in 2013 jumped 65.6 percent over 2012 results and its market share now stands at 24.1 percent, more than 10 percentage points above the second place vendor. Overall, the worldwide market for datacenter automation grew by 22.1 percent to $1.8 billion in 2013. Download full IDC report here.

(1)   IDC, “Worldwide Datacenter Automation Software 2013 Vendor Shares,” by Mary Johnston Turner, May 2014

5 Ways Cloud Automation Drives Greater Cost and Operational Transparency

By Kevin Lees

Kevin_cropThere has always been tension between IT teams and their end customers — not the good kind of tension, but rather the contentious kind that rarely ends well.

It breaks down like this: IT never believes it has enough time, resources, or money; and the line of business (LOB) really doesn’t understand what they want. On the other side, the LOB is rarely happy with IT because response times aren’t fast enough or IT is missing the mark with its capabilities.

This tension leads to inefficient use of resources, both equipment and people. Shadow IT happens when those outside of IT take matters into their own hands and shirk IT policies and procedures. This can mean inefficiencies in the allocation of capital because finance is challenged to track exactly what it costs for IT to deliver. This becomes especially difficult in a shared resource environment, and it will only get more challenging as we move to a fully virtualized stack as defined by the software-defined data center (SDDC).

This can lead to all sorts of problems, fostering mistrust, lost profits, and lost opportunities. You get the idea.

In this post, we’ll explore key ways that cloud automation is critical to fulfilling the promise of cloud and how automation provides opportunities to practice cost and operational transparency as a way to help drive business alignment.

The Promise of Cloud Management
Cloud holds great promise and great responsibility. It provides many advantages to both IT and its stakeholders, but without effective cloud management and automation, the true value will never be realized.

This is true regardless of the type of cloud, whether private enterprise cloud, an external cloud provider, or a hybrid cloud.

As the figure below shows, there are five areas to focus on that not only provide opportunities to drive business alignment, but also provide opportunities to practice the cost and/or operational transparency needed to gain the business stakeholder’s trust:

5 Ways Automation-Lees

  1. Service quality: The business has to know it can count on the service it’s consuming.
  2. Predictability: Of course, the service has to be predictable. Outages are unacceptable.
  3. Agility: The business needs to quickly react to changing business conditions or proactively get to market before the competition, so IT needs to keep up.
  4. Smart economics: It also has to be cost effective. If it’s not, shadow IT rears its ugly head, and any degree of governance as well as economy of scale efficiencies dissipate into the cloud, outside of IT’s control.
  5. Clear communication: Business stakeholders have to truly understand what they’re getting and how much flexibility of choice is available to them.

That said, IT cannot deploy and run an effective and successful cloud in a vacuum. A truly successful cloud, one that adds real business value, requires alignment among IT, LOB, and finance. It requires a lot of interaction, listening, discussing, and agreeing. Yes, there will be trial and error.

Fortunately, one of the big benefits of cloud when done right (namely agility) is the ability to fail fast, fail often, and try something else.

With alignment and the clear communication required to achieve it:

  • IT can provide solutions and services that add value to the business by meeting its needs, because business is involved in the service definition.
  • LOB stakeholders will have a much better idea of what they’re getting and know it will meet their needs.
  • Finance will understand service costs within a business context to make more informed decisions about how to maximize the budgets and ensure a degree of cost predictability.

If all goes well, the end result is trust and business alignment between the parties.

One final note for IT: you desperately need to take a course in Marketing 101. IT needs to get better at advertising its services and demonstrating its value add so everyone knows what an asset the group is. At VMware, this is something we address explicitly when we help IT customers set up their processes for defining, costing, and offering cloud-based services to their LOB market. Taking a technical service to LOB market is no different than the business taking a service to market. Would they do that without proactive marketing? I don’t think so.

If you found this post helpful, stay tuned for future posts on this topic. Next time, I’ll offer my thoughts on ways to turn IT’s “trust debt” into true business alignment through greater transparency, agility, and technical alignment.

===========
Kevin Lees is Global Principal Architect, Operations Transformation Practice. Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.

Understanding Process Automation: Lean Manufacturing Lessons Applied to IT

by: Mike Szafranski

With task automation, it is pretty simple to calculate that it is worth taking 2 hours to automate a 10-minute task if you perform that task more than 12 times. Even considering the fixed and variable costs of the automation solution, the math is pretty straightforward.

But the justification for automating more complex processes composed of dozens of ‘10 minute tasks’ completed by different actors – including the inevitable scheduling and wait time between each task – is a bit more complex. Nonetheless, an approach exists.

You can find it laid out in Kim, Behr, and Spafford’s modern classic of business fiction, The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win [IT Revolution Press, 2013], in which the authors show how the principals of lean manufacturing are directly applicable to IT process automation.

So what lessons do we learn when building a case for process automation by applying lean manufacturing principles to IT Ops? Let’s take a look.

Simple Steps Build the Business Case

First, you need to break the process you’re interested in into its constituent parts.

Step 1 – Document Stages in the Process and Elapsed Time. Through interviews, identify major process stages and then document the clock time elapsed for each. Note, use hard data for elapsed time if possible. People involved in the process rarely have an accurate perception of how long things really take. Look at process artifacts such as emails, time stamps on saved documents, configuration files, provisioning, or testing tool log files to measure real elapsed time.

Step 2 – Document Tasks and Actors. Summarize what gets accomplished at each stage and, most importantly, detail all the tasks and record which teams perform them. If a task involves multiple actors working independently with a handoff, that task should be broken down into sub-tasks.

Step 3 – Document FTE Time. Record the work effort required for each task. We’ll call that the Full Time Equivalent (FTE). This is the time it takes to do the actual task work, assuming no interruptions, irregularities, or rework.

Step 4 – Document Wait Time. Understanding wait time is critical to building a case for process automation. If actors are busy, or if there are handoffs between actors, then elapsed time is often multiple times longer than FTE time. This is because at each handoff, the task must sit in queue until a resource is ready to process the task.

After taking these steps, you can summarize in a chart similar to this.

In Lean Manufacturing, the concept of wait time or queue time has a mathematical formula [see chapter 23 of The Phoenix Project]. The definition is:

The formula, of course, offers hard proof of what you already knew – that the busier you are, the longer it takes to get new work done. With multiple actors on a task, each can contribute to wait time, with the amount they contribute depending on how busy they are.

In the example below, there are five separate teams (security, network, dev, QA and VM) involved in the Validate Firewall step in the flow. Each team is also busy with other tasks. 

Figure 2. In a manually constructed environment, the network settings, firewall rules, and application ports need to be validated. More often than not, they need to be adjusted due to port conflicts or firewall rules. Wait times correlate strongly with % ultilization.

As you can see, the time spent by FTEs is 5.5 hours, which is only around 15% of the clock time. Clearly, with complex tasks, FTE is only a part of the story.

Step 5 – Account for Unplanned Work. Unplanned work occurs when errors are found, requiring a task from an earlier step in the process to be reworked or fixed.

In complex automation, unplanned work is another reality that complicates the process and increases FTE time. It also dramatically impacts clock time – in two ways. First, there’s the direct impact of additional time spent waiting for the handoff back upstream in the process. Second, and even more dramatic, is the opportunity cost. Planned work tasks need to stop while the process actor sets things aside and addresses the unplanned work. Unplanned work can thus have a multiplier effect, causing cascading delays up and down the process flow.

One aim of automation, of course, is to reduce unplanned work – and that reduction that can also be calculated, further adding to the business case for process automation. Indeed, studies have shown that, currently, unplanned work consumes 17% of a typical IT budget.

Process Automation Can Offer More Than Cost Reduction

But there’s potentially even more to the story than a complete picture of IT work and detailed accounting of reduced work effort and timesavings. The full impact of process automation can include:

  • Improved throughput
  • Enabling rapid prototyping
  • Higher quality
  • Improved ability to respond to business needs

The cumulative impact of these can be substantial. Indeed, it can easily exceed the total impact of direct cost reductions.

Step 6 – Estimate total benefit to business functions. If calculating the value of reducing FTE, wait times, and unplanned work is relatively straight forward, figuring the full business impact of reducing overall calendar time for a critical processes (from 4 weeks to 36 hours, say) requires more than a direct cost reduction calculation. It’s worth doing, though, because the value derived from better quality, shorter development times, etc., can substantially exceed the value of FTE hours saved through automation (see figure 3). 

Figure 3. The secondary impacts of automating processes and increasing agility and consistency can be much larger than the value of the FTE hours saved.

You do it by asking IT customers to detail the benefits they see when processes are improved. There are many IT KPIs that can help here, such as the number of help desk tickets received in a specific period, or the number and length of Severity 1 IT issues.

We used this method at VMware when we automated dev/test provisioning and improved the efficiency of 600 developers by 20%. We achieved a direct cost reduction related to time and effort saved. But we found an even bigger impact, even if it was harder to quantify, in improved throughput, in always being able to say, “Yes” to business requests, and in enabling rapid prototyping.

Lessons Learned

With these steps, you can capture major process stages, tasks, actors, calendar time, work effort, and points of unplanned work, quantifying the business value of automating a process end-to-end – and making your case for end-to-end process automation all the stronger.

Key takeaways:

  • It’s possible to make a business case for automating end-to-end IT processes;
  • You can do this by applying concepts from lean manufacturing;
  • The concepts of wait time and unplanned work are central;
  • Efficiency driven cost reduction is only part of the equation, however;
  • To quantify the full value of agility, work with IT customers to gauge improvements in KPIs that reflect improved business outcomes.

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.

Automation – The Scripting, Orchestration, and Technology Love Triangle

By Andy Troup

In speaking with some of my customers, the message comes resoundingly across “WE WANT TO AUTOMATE.” So this is the sweet spot for cloud solutions as they have in-built automation to provide the defined benefits of cloud computing such as On-demand self service, Resource pooling and Rapid elasticity (as defined by NIST here).

However, upon scratching the surface and digging a little deeper, the other thing I’ve found is that when I’m told “yes we’ve got automation,” it typically means that a lot of effort has gone into developing a whole heap of scripts that have been written to solve a very specific problem. This, I would argue, is not the best way for automation to be achieved.

I was in conversation with a customer a few weeks ago where they wanted to automate a particular part of their provisioning process, and my recommendation to them was “DON’T DO IT.” Why did I say this? Well, the process was broken, inefficient, relied on spreadsheets & scripts and meant there was constant rework to have a satisfactorily provisioned system. Their provisioning process took weeks and weeks. There was no point in automating this broken process – what needed to happen was that the process had to be fixed or changed first. I won’t go into anymore detail about this particular problem, but my point is that sometimes you have to take a step back and see if there are other ways of solving a particular problem.

In summary – there’s no point in automating a broken process.

So, why do we want to automate our IT systems and the provisioning of them anyway? Primarily because we want two things:

  1. To take the boring repeatable activities that many IT administrators undertake and get a system to do it instead. This frees up time for the administrator to do the more interesting and difficult things.
  2. Remove the potential for errors. Anything that is done as a manual activity involving people is liable to be inconsistent and error-prone (I say liable, but really we all know that they will be inconsistent and error-prone). Cloud solutions are all based on the premise that everything is standardized, and thus we need to remove any activity that introduces unreliability.

OK, so we’ve now established that automation is a good thing. All we need to do now is work out HOW we’re going to automate, and this may introduce some difficult decisions.

So what are the automation options? Well, in my mind automation comes in three different flavours which should be used together to solve the automation challenge. Here they are with some definitions I found:

  1. Script – programs written for a special runtime environment that can interpret and automate the execution of tasks which could alternatively be executed one-by-one by a human operator. (http://en.wikipedia.org/wiki/Script_(computing))
  2. Orchestration – describes the automated arrangement, coordination, and management of complex computer systems, middleware, and services. (http://en.wikipedia.org/wiki/Orchestration_(computing))
  3. Policy – Policy-based management is an administrative approach that is used to simplify the management of a given endeavor by establishing policies to deal with situations that are likely to occur. (http://whatis.techtarget.com/definition/policy-based-management)

In terms of their use, the image below shows how I believe they should be used and in what quantities. As you can see, we should be aiming for as much policy implementation as possible with as little script as we can achieve.

If you have a process you’d like to automate, to find the solution, you should work up the pyramid from the bottom.

So the first question you should ask yourself is “can I create a policy or several policies to solve the problem?” This will have a dependency on the technology available to utilize the policy, but should be the first port of call. It may even be worth considering investing in the technology to make the policy implementation possible. The overhead of creating and maintaining policies are small and they will provide a robust solution to your problem with reliability and consistency.

If it isn’t possible to create a policy to solve the challenge, next consider orchestrating a solution. This will provide a reusable, standardized capability that has an element of management/maintenance overhead and will be reliable.

Finally, if neither policy nor orchestration will work for you, then utilize scripting as a last resort. Why a last resort? Scripting is a tactical, bespoke solution for a specific requirement and will require managing and maintenance during its entire life, which in turn will incur costs and will be less reliable.

So in summary, when you are considering automating a process:

  • Step back from the automation challenge and consider the options. They may not be what you expected.
  • Work up the “Love Triangle” from the bottom.
  • If you can’t implement a policy, consider orchestration and use scripting as a last resort.

For more great insight on automation, see our previous posts highlighting automation economics and IT automation roles.

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.