Home > Blogs > VMware Operations Transformation Services > Tag Archives: david crane

Tag Archives: david crane

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.

Transforming Operations and Perception of the IT Organization

By David Crane

dcrane-cropA recent engagement with a long-established telecommunications firm presented a huge challenge—the solution for which is a great example of how operations transformation can drive technical transformation. The firm’s customer base spans various global regions, each of which presented a different customer experience. The IT organization functioned in extremely siloed environments, having grown organically over 25 years to support an aging, fragmented infrastructure.

A frustrated but motivated CIO laid down the following requirements for the VMware consulting services team, to be met over an aggressive six-month timeline:

  • Reduce operational costs
  • Improve agility
  • Provide more service offerings
  • Help IT become a service broker and eliminate shadow IT
  • Build a flexible architecture to meet the needs of the business
  • Reduce total number of physical data centers
  • Gain more control and compliance of IT infrastructure environments

The internal IT team lacked the expertise and resources required to implement a software-defined data center (SDDC) solution. Their service request process was time-consuming, manual, and inconsistent. Add to that an average provisioning time for a full end-to-end server of eight weeks, and it’s no surprise that internal customers were seeking out external solution providers for their IT needs.

The VMware team set out to remedy all of this with the following solution:

  • Implement a production SDDC platform
  • Make self-service automated provisioning the first available service
  • Assess the customers’ operating processes
  • Introduce an optimized organizational structure
  • Integrate operations transformation and technical implementation
  • Take a phased approach to the project with clearly defined milestones to deliver immediate results
  • Ensure the VMware team team worked closely with internal groups

Transforming the Operating Model
Breaking down the siloed IT organization, and introducing horizontal, cross-departmental communications was the first step to allow the customer to become service-focused.

The team did have the business analyst concept, but the analysts sat outside the IT organization. They didn’t understand IT and weren’t incentivized to do so. As a result, rogue users were going out and doing things themselves, leading to compliance and governance issues.

We introduced the concept of infrastructure operations and tenant operations. These were cross-functional teams that talk to each other—a virtual center of excellence within the IT organization. As part of this organizational change, we brought in new roles, the two most important being the customer relationship manager and the service owner. We brought customer relationship management back into IT, so the person in the role started to understand IT and what they could deliver (and how) against customer requirements.

One of these requirements was the revelation that customers did not really have an interest in availability.  This was not because they didn’t care, but simply because IT over the years has become robust enough that availability is expected.  What their customers really cared about was the speed, and standardization, of the service provisioning lifecycle, as it was this that allowed them to quickly respond to market demands, and support the business objective to be the first to market with new products.

This led to a technical requirement as the IT organization’s customers requested to see this information in a dashboard format, so that proactive monitoring of the provisioning process could take place.

Transforming Infrastructure Operations
The service owners played a key role in saying VMware vRealize Operations only looks at infrastructure—this resulted in a demand to change things within VMware vRealize Automation.

However, the dashboards needed to be delivered through vRealize Operations. To meet the technical requirement, we focused on the self-service provisioning portal and allowed consumers to monitor the status of their ordered services via that portal. To do that, we needed a dashboard in VMware vRealize Operations to monitor the KPIs involved in service provisioning. In order to build the dashboard to monitor provisioning time, we had to create a custom solution using vRealize Automation. The technical solution was necessary to enable the operating framework architecture and organizational model to support it.

Dashboard Solution
We ended up with a provisioned resources dashboard as shown in figure 1 below that lists each virtual machine (VM) and the number of minutes it took to be provisioned. Less than 30 minutes shows green, less than two hours shows yellow, and over two hours is red. It also shows the average, minimum, and maximum times to provision.

Time to Provision

Figure 1:  Provisioned resources dashboard

The dashboard also enabled the customer to use data to feed back into the service life cycle process. For example, they started to understand service demand. Service owners—who were expected to forecast demand for services—could now do so with more accuracy. Now that the team was forecasting capacity demand more accurately, they were able to increase credibility by sharing this information with the infrastructure team. And ultimately they saved money by having a better handle on demand.

The dashboard also allowed IT to develop proactive operational processes.  On several occasions the service owners started to see a degradation in performance of the provisioning process, while the infrastructure monitoring dashboards were still showing a healthy ecosystem.

On further analysis, changes to the underlying infrastructure, whilst keeping in tolerance and SLA for the IT infrastructure teams, were having an accumulative impact further down the chain to the service provisioning process.

The provisioning dashboard and further integration with the customers’ service desk platform and event, incident, and problem management processes allowed the IT infrastructure teams to tune the change management process so that service provisioning would not be affected.

In the end, IT became service-oriented because of the dashboard. Because internal customers could use that tool to see the incredible accuracy with which the IT team was meeting its 30-minutes-or-less goal, it had a huge impact on the way the IT was perceived within business. IT’s credibility skyrocketed, and suddenly it became easier to drive things like the “cloud first” policy within the organization.

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

7 Key Steps to Migrate Your Provisioning Processes to the Cloud

By David Crane

dcrane-cropIn an earlier blog, my colleague Andy Troup shared an experience where his customer wanted to embark on a process automation project, which could have had disastrous (and consequently frustrating and costly) results, as the process itself was inherently unsuitable for automation.

Automating processes is one of the first projects that organizations embark on once a cloud infrastructure is in place, but why? The answer lies in legacy IT organizations structures that have typically operated in silos.

Many of the IT organizations that I work with have a number of groups such as service development, sales engineering, infrastructure engineering, and IT security that face similar challenges that can include (among many others):

  • Applications provisioned across multiple environments such as development, QA, UAT, sales demonstrations, and production
  • Managing deployments of application workloads in a safe and consistent manner
  • Balancing the speed and agility of deploying the services required to deliver and improve business results while meeting compliance, security, and resource constraints

With the agility that cloud computing offers, organizations look to the benefits that automating the provisioning processes may bring to overcome the above challenges such as:

  • Reduced cycle time and operating costs
  • Improved security, compliance, and risk management
  • Reduced capital and operating expenditures
  • Reduced need for management/human intervention
  • Improved deployment/provisioning time
  • Consistent quality in delivery of services

The IT organizations I work with are often sold these benefits without consideration of the operational transformation required to achieve them. Consequently, when the IT team kicks off a project to automate business processes, especially service provisioning, their focus is on the potential benefits that may be achieved. The result of this focus is that automation becomes a panacea, and not something that should underpin the IT organization’s overall operational transformation project.

As IT leaders, when considering migrating your provisioning processes to your cloud environment, you need to realize that automation alone will not necessarily provide the cure to problems that exist within a process.

You should not consider the benefits of automation in isolation. For example, too much focus on cost reduction can frequently lead to compromise in other areas leading to objections and resistance from business stakeholders. You should consider other benefits that have non-tangible (or direct) metrics, such as improved staff satisfaction. Automation frees your technical staff from repetitive (and uninteresting) activities, which results in both improved staff retention and indirect cost benefit.

As you select processes to migrate from a physical (or virtual) environment to the cloud, the subsequent automation of those processes should not be an arbitrary decision. Frequently my clients choose processes as candidates for automation for reasons based on personal preferences, internal political pressures, or because some process owners shout louder than others!

Instead the desired business benefits the organization wishes to achieve should be considered in conjunction with the characteristics, attributes, and measurable metrics of a process characteristics and a formal assessment made of its suitability for automation.

Your automation project should also be implemented in conjunction with an organization structure assessment, which may require transformation and the introduction of new roles and responsibilities required to support the delivery of automated and self-optimizing processes.

Important Steps to Your Successful Process Assessment
Based on my experience assisting customers in this exercise, I recommend taking these steps before you embark on a process assessment:

  1. Understand automation and what it actually means and requires. Many organizations embark on automation without actually understanding what this means and the context of automated processes and their capabilities. Subsequent delivery then either leads to disappointment as automation does not meet expectations, or the process is not truly automated but instead has some automated features that do not deliver all the expected benefits.
  2. Identify and document the expected business benefits to be achieved through introduction of process automation. This is an important task. Without understanding the benefits automation is expected to achieve, you cannot identify which processes are the correct choices to help you do just that.
  3. Understand cloud infrastructure system management capabilities required to support process automation (e.g., ability to detect environmental changes, process throughput monitoring capability) and implement if required.
  4. Identify ALL processes required to support automated provisioning (e.g., instantiation, governance, approval) to create a process portfolio.
  5. Identify the common process automation characteristics that exist across the process portfolio (e.g., self configuration, self healing, self audit and metric analysis). Note that process characteristics are unique, high-level identifiers of automation across the portfolio.
  6. Identify the common attributes that the process characteristics share. These are more granular than process characteristics and thus may be common to more than one characteristic in the same process.
  7. Identify the metrics available for each process in the portfolio, and apply a maturity assessment based on their ability to be measured and utilized. Metric maturity is an essential part of the assessment process as it determines not just the suitability of the process for automation, but also its capability to perform self optimization.

Process Assessment Weighting and Scoring
When undertaking a process assessment program, an organization needs to understand what is important and prioritize accordingly. For example, if we consider the business benefits of automation, a managed service provider would probably prioritize business benefits differently to a motor trade retail customer.

Once you’ve prioritized your processes, they can be assessed more accurately and weighted based on each identified business benefit. Prioritization and weighting is essential, and you need to carefully consider the outcomes of this exercise in order for your process assessment to reflect accurately whether processes are suitable for automation or not.

And remember, as previously mentioned avoid considering each assessment criteria in isolation. Each process characteristic and associated attribute can have a direct impact on the desired business benefit, however if its metric maturity is insufficient to support it, then the business benefit will not be fully achieved.

For example, let’s say that you have identified that a business process you wish to automate has a self-healing characteristic. One of the attributes the characteristic possesses is the ability to perform dynamic adjustment based on real-time process metrics. The characteristic and attribute would lead you to expect the realize benefits such as reduced cycle time, reduced OpEx, consistent quality of service, and improved staff retention.

However, although you’ve identified the metrics required to meet the characteristic and attribute needs, they are neither measured or acted upon. Consequently, because the metric maturity level is low, then the expected business benefit realization capability is also lowered.

Figure 1 below shows a small sample of the assessment of a process in relation to a single process characteristic, common attributes, anticipated business benefits and their weighting and the impact that a poor metric maturity has on their capability to deliver the anticipated business benefit.

Figure 1. Assessment displaying impact of low metric maturity

Contrast this to Figure 2 below, which assesses a process with exactly the same characteristics, attributes, business benefits, but has supporting management capabilities and consequently much improved metric maturity:

Figure 2. Assessment displaying impact of high metric maturity

Based on this small data sample, the process in Figure 2 is a more likely candidate for process automation. The assessment process also then identifies, and allows the IT organization to focus on, areas of remediation needed to optimize processes to enable them to be suitable automation candidates.

The result is the IT organization is able to realize not just the business benefits that have been promised by automation more effectively, but they are also able to set realistic expectations with the business, which brings benefits all of its own.

In summary, automation is not the “silver bullet” for broken or inefficient processes. IT leaders need to consider expected business benefits in conjunction with process characteristics, attributes, and metrics and in the context of what is important to the business. By assessing the suitability of a process for automation, you can save the cost of a failed project and disappointed stakeholders. Finally, you should not undertake any provisioning process project in isolation to other operations transformation projects, such as organization structure and implementation of cloud service management capabilities.

I will discuss the steps to success mentioned above in more detail in my next blog.

===

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

 

The People and Process Behind the Service Portal

By David Crane

dcrane-cropAs more IT organizations move away from the traditional, siloed model of IT and toward becoming a service provider, new questions arise. Running a smooth, cost-effective, efficient service portal can ease a number of the issues that IT faces, but only if done correctly.

The portal serves as the interface that helps consumers navigate through available service options and select them as needed. Behind the scenes, IT is serving as a contractor, comparing service requirements to different capabilities that may be internal, on premise, or from other providers. The user doesn’t care, so long as they are getting what they need.

So you have a portal, and you have a cloud. Now what?

Consistently Capture Service Requirements
With the right foundation, managing the service portal can be a smooth process,. The first step is to understand the unique requirements that your users have, and deliver the resources that are going to meet their needs. The best way to understand that is to step outside the traditional organizational silos and engage directly with the lines of business.

Once you understand the various service needs, create service charts, such as the example below:

Service chartThese will serve to identify all the different components required in each service. Most of these components will be common across different services, and can then be built out separately. Take a “cookie cutter” approach to these components, so that when mixed and matched they will create the services needed. Part of correctly understanding these components will involve a deeper understanding of the service definition process. What tasks will need to happen across all operational levels? Who will be responsible for those tasks?

Right People, Right Services
Oftentimes, IT organizations feel anxiety about the level of automation that stands behind a portal. It’s challenging to think of users that have previously been carefully walked through specialized processes suddenly having the ability to requisition services through an automated process. Creating clearly defined roles and restricting access to the catalog based on those roles can alleviate these fears.

Once you have the roles defined, deploy provisioning groups to different IT resources consumers. Allow these provisioning groups to handle the issue of deployment capabilities and instead focus on using policies to govern how those deployments will take place. Use the defined roles for the portal to determine which users can perform which actions within their environment. The policies will dictate which components will be required in each context.

When Is a Service Ready to Go in the Catalog?
Some IT organizations, once their portal is set up, try to lump the service portfolio process in with the service catalog management responsibilities. This can lead to frustration and inefficiency down the line, and can undermine the cost savings and automation value that the cloud provides. Instead, use your senior technical resources to create the service definitions and components. This will be the best use of their skills, and is also the work that they are going to find challenging and interesting.

Once that is done, more junior resources can combine and deploy those components into the catalog. It becomes a simple process of handing the service configuration document to the person responsible for deployment.

Integrated Transition to Catalog
The transition process — getting services out of the catalog and into the portfolio — can be difficult and technical. Avoid a lot of the messiness by getting operational input early in the process so that all the requirements are understood up front. Here, again, is where it’s important to keep your senior resources working on high level issues: getting components aligned to the corporate enterprise structure, security, and any other issues that require IT’s attention. If the components are aligned to the business needs, the services that are composed of those components will also align by default.

Once the business and IT agree that there is a need for a service, the service owner and service architect should ensure that the required components exist. For any component, security, access policies and provisioning processes should already be determined — no need for testing, change process or QA. From there the service architect can take the components out to create the service configuration. Keep this streamlined and simple.

New Roles
Making all this work smoothly requires some new roles within the organization. A customer relationship manager (CRM) will act as the interface between the tech teams and the consumer. The CRM captures the requirements, keeps the consumer happy, and keeps IT aligned and communicating with the business. Unlike a managed service provider, the CRM should operate within the cloud tenants team to ensure and understanding of internal IT. The service owner, discussed above, is responsible for taking the requirements gathered and doing something with them, including negotiating contracts with the cloud providers.

The service portfolio manager will know the portfolio inside and out, and create a standardized environment. The service architects will combine components and author a configuration document whenever a new service is required. The service QA will test the created services. The service admin will be responsible for taking the configuration requirements and deploying into the catalog.

The service portal should serve as a powerful tool that connects consumers, both internal and external, with the services they need. By building strong component foundations, creating well-defined roles, and assigning resources where they will be most effective, IT organizations can ensure that their portal process runs smoothly and efficiently.


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