Home > Blogs > VMware Operations Transformation Services > Tag Archives: provisioning

Tag Archives: provisioning

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.

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.

Clouds are Like Babies

By: Kurt Milne

While preparing for the Datamation Google+ hangout about hybrid cloud with Andi Mann and David Linthicum that took place last week, I referred to Seema Jethani’s great presentation from DevOps Days in Mountain View.

Her presentation theme, “Clouds are Like Babies,” was brilliant: Each cloud is a little different, does things its own way, speaks its own language and of course, brings joy. Sometimes, however, clouds can also be hard to work with.

Her great examples got me thinking about where we’re at as an industry with respect to adopting hybrid cloud, and the challenges related to interoperability and multi-cloud environments.

My guess is that we will work through security concerns, and that customers with checkbooks will force vendors to address technical interoperability issues. But then we will realize that there are operational interoperability challenges as well. In addition to cloud service provider decisions to use the AWS API set, there are tactical nuances that make having a single runbook for cloud tasks difficult across platforms.

From her presentation:

  • Cloudsigma requires the server to be stopped before making an image
  • Terremark requires the server to be stopped for a volume to be attached
  • CloudCentral requires the volume attached to the server in order to make a snapshot

The availability of various functions common in standard virtualized environment varies widely across cloud service providers – such as pausing a server, creating a snapshot, creating a load balancer, etc.

We don’t even have a common lexicon to describe a “Machine image” in AWS. VMware calls it a “Template vApp,” Openstack calls it an “Image,” and CloudStack call it a “Template.”

So in an Ops meeting, if you use an OpenStack-based public cloud and a private cloud based on CloudStack, and you say “we provision using templates, not images,” and someone from another team agrees that they do that too, how do you know if they know that you are talking about different things? It confuses me even writing the sentence.

I led a panel discussion on “automated provisioning” at DevOps Days. Due to templates/images/blueprint terminology confusion, we ended up using the terms “baked” (as in baked bread) to refer to provisioning from a single monolithic instance, and “fried” (as in stir-fried vegetables) to refer to building a release from multiple smaller components, assembled before provisioning – just to discuss automation!

Bottom line: Why not avoid all the multi-cloud hybrid-cloud interoperability and ops mishmash and use the vCloud Hybrid Service for your public cloud extension of VMware implementation?

Don’t miss my sessions at VMworld this year:

  • “Moving Enterprise Application Dev/Test to VMware’s internal Private Cloud” with Venkat Gopalakrishnan
  • “VMware Customer Journey – Where Are We with ITaaS and Ops Transformation in the Cloud Era?” with Mike Hulme

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