Home > Blogs > VMware Operations Transformation Services

3 Analogies for Cloud/DevOps Transformation That Can Turn Your Resisters into Champions

Analogies

By Pierre Moncassin and Peter Stokolosa 

Resistance to change can sideline any project. Customers who embark on the transformation journey towards VMware’s cloud platforms, increasingly often as a stepping stone towards DevOps, inevitably must confront the challenge of resistance to change, which manifests itself in many forms and behaviors.

Fostering a change in mindset towards transformation projects is key to a cloud/DevOps project’s success. No matter how much technical expertise the stakeholders bring to the project success remains elusive until they can be persuaded to adopt not only new tools, but to adapt new ways of working, thinking and participating in the advancement of the project.

We have found that the introduction of meaningful analogies to explain the character  and necessity of change can help to unlock the key to motivational and behavioral changes in project teams.

Resistance to change usually boils down to two main factors:

  • fear of loss – because change involves departing from the known environment (often perceived as a comfort zone);
  • inability to develop a clear vision of the future state and the needed steps to arrive there engenders passive resistance and lack of motivation

Well-crafted analogies can help tackle both factors. Analogies are grounded in known, familiar environments. They are re-assuring because they build a cognitive bridge that begins with the known stage while offering a path to the future.

Next, let us share three frequently-used analogies that have been proven to resonate well with our audiences, when discussing cloud transformation.

Introducing a commercial electric power grid to replace local power generation (as an analogy for switching from physical IT to cloud).

The utility metaphor has been popular since the early days of the cloud – it was actually used well before the cloud era, first appearing in 1961 from John McCarty.

Early in the 20th century, the common approach to generating electricity was to own a private generator.  Switching to the public utility model meant giving up ownership and control of the private power generator.  It implied trusting a third party to provide electricity consistently and reliably, at a reasonable cost

The shift meant a radical change of focus from production to consumption. It meant that consumed resources are now commoditized, pervasive and always available.

It is worth noting that electricity consumption is also associated with simple metering – the ability to monitor consumption and therefore costs in real-time.  This is a useful introduction to the cloud costing models

A retail shop versus a factory (as an analogy for the two teams in a cloud organization: one customer facing and one, infrastructure focused).

One of the tenets of the cloud organization, as recommended by VMware best practices, is to define two teams with complementary objectives.

The first team drives the communication and relationship with the business, we call this the Cloud Service Team. They work closely with business stakeholders and meet customer requirements with innovative solutions. They can be equated to the “retail shop” of the cloud organization – their main task is to provide compelling services (products) that are constantly adapted to customer demand.

The second team manages the overall infrastructure we call this the Cloud Service Infrastructure team.  They can be equated to the “factory” of the cloud organization.  Their objectives include standardization, efficiency and economies of scale in order to deliver cloud services with the best quality/cost ratio.

As with every analogy this one has its limitations.  It understates the agility of the cloud infrastructure services.  As this team progresses towards always-higher levels of automation, their day-to-day activities resemble more the engineering room (focused on design activities) than a traditional production chain (repetitive tasks are automated away).

Cloud Org Model

From Farm to Fork. The modernization journey of agriculture (as an analogy for the evolution of IT roles from managing physical IT to operating a cloud).

(Note – this analogy will resonate best in countries with a strong rural tradition – think of France for example!).

Before the 1930’s, the farm ecosystem was largely run by local family businesses, with small units and limited mechanization.  Farm professions were based close to the place of production: farmer, miller, carter (and many others).  The path from farm to consumers (farm to fork) was relatively short and traceable:  consumers could generally assume that their food was produced locally.  Because production was limited there was a need for more families to farm for a livelihood.

Within a generation farming methods changed while mechanization brought significant increases in productivity, but it also meant that change to the métier of farming was inevitable.  To respond to increasing customer demand, they standardized and consolidated to produce a greater quantity while implementing increased control and norms (quality).

Increases in both automation and market demand lead to sweeping changes in the farming “workplace”.  Many traditional jobs and activities became less relevant or obsolete (eg laborers with horse and carts).  New,  specialized jobs developed , or became significantly more visible: traders, operations managers (for processing factories).  In general, there was a shift from labor-intensive production to sales, marketing, distribution, quality control and standardized, automated production.

It’s worth noting, the path from production to consumers became considerably extended. Consumers have very little awareness of where their food is grown (unless specific labeling shows this sourcing information).  Although the system required to deliver the product became more complex, the consumption aspects of the product were simplified.

Compare this to ‘traditional’ ways of running IT in technical silos.  IT tends to be operated by silos of local expertise with numerous, labor-intensive tasks.   As a correlation of silos (fragmentation of work), there is little standardization and the path from production to consumers tends to be short . IT tends to be “sourced locally,” so consumers may be familiar with the hardware and cabling as well as with the administrators who operate the platform.  We have all heard stories of business users walking over to the IT administrators to resolve their problems (rather than raise a ticket with a remote service desk!).

As cloud automation is introduced, these tasks and roles will evolve along similar trends:

  • Standardization of processes and architectures
  • Leverage automation throughout
  • Increased consumer expectations (measurable, formalized service levels, control over costs, agility)
  • The path from production to consumers is significantly extended. In most instances cloud consumers are not aware of the location of their physical IT. There is a separation of accountabilities so that business lines do not usually communicate with systems operators – they would liaise via the service desk (for routine operations) and via the Cloud Service team (for more complex requests).

The technical transformation leads to new or transformed IT roles:

  • Focus shifts from production (hardware, infrastructure) to consumption (cloud services). The new cloud organization requires increased effort on “marketing” of cloud services and “distribution” (teams focus on finding ways of making the services consumable e.g. publishing them on self-service catalog portal).
  • There is growing demand for automation specialists who can translate the technical knowledge into workflows and scripts.
  • New roles emerge: such as Service Blueprint Manager, a specialist with skills to leverage automation in tools such as VMware’s vRealize Automation.
  • Traditional Computer Operations roles evolve, requiring more coding skills.
  • The mission of IT teams changes from “maintenance” to value creation.
  • Consumption is facilitated and simplified.

All in all – analogies are a powerful tool to help overcome resistance to change. One caveat though: do not over-use them as they risk becoming oversimplified, losing their pertinence and distracting from that main issue of how an organization must adapt to address inevitable change.

Take-aways:

  • Start from the point of view that resistance to change is predictably human and normal. It is part of the change process cycle and it is not a problem. It can turn into one, however, if it is not dealt with correctly
  • Leverage analogies in order bring a concrete dimension to abstract concepts such as cloud services; they can help to advance projects, but adapt your references with sensitivity to the audience’s culture, maturity and environment.
  • Set clear remit for using your analogies. Keep in mind that all analogies have intrinsic limitations. Although they are useful tools to walk across the cognitive bridge, they have a limited shelf-life when it comes to get across a given message to an new audience – so their use should be focused.

=======

Pierre Moncassin is an operations architect with the VMware Operations Transformation global practice and is based in Taiwan.

Peter Stokolosa is an operations architect with the VMware Operations Transformation Services and is based in France.

VMware Honored for Professional Services Innovation and Excellence by the Technology Services Industry Association

Technology Services Industry Association AwardThe Technology Services Industry Association (TSIA) announced the 2016 STAR Award winners at the Technology Services World Conference held in Las Vegas. VMware Professional Services was named the 2016 STAR Award winner for Innovation in Enabling Customer Outcomes.

“VMware is thrilled to be recognized for the progressive advancement of our Professional Services business,” said Bret Connor, Vice President of Professional Services at VMware. “This award reflects our commitment to enabling customers to realize differentiated business value and drive accelerated IT transformation through the adoption and deployment of VMware’s technology vision.”

VMware’s global Professional Services organization has long played an important role in enabling customer successes. Over the past five years, as VMware has evolved from a single product company to a multi-product solutions provider, the maturation, innovation and transformation of its professional services business has driven new and higher levels of business success and customer satisfaction.

According to TSIA, “Many Professional Services organizations are doing some of these things, but very few are doing all of them. The business and customer impacts have been substantial…” The transformative approach to customer success has resulted in a tripling of VMware’s Professional Services NPS score and a 50% decrease in project escalations in the Americas.

Read the full article on the VMware Radius Blog.

Implementing an Operating Model for Agility

Paul WiggettVMworld 2016By Paul Wiggett

At VMworld Europe 2016 next week in Barcelona one of the topics you will be hearing a lot about is digital transformation. How must IT organisations adapt to support the changing business models required to remain competitive in a “liquid” business environment?

There is constant pressure on businesses to introduce innovative products and services rapidly into new and existing marketplaces. IT departments need to enable this by improving their strategy and becoming more tightly aligned with the business than ever before. The core focus needs to shift from keeping the lights on to delivering agility, efficiency, and core business value. One of the primary ways this can be achieved is by embracing a cloud-based services delivery model enabled by a flexible SDDC infrastructure platform.

Cloud-based service delivery introduces significant challenges for traditional IT operating models. For example, traditional IT Service Management (ITSM) operating models have generally focused on delivering services through a centralised set of responsibilities driven by heavy governance to decrease the rate of change and therefore risk. In addition, traditional ITSM services are often highly customized for IT’s line of business customers.

In contrast a cloud-based Service-Driven Operating Model focuses on cross-functional integration, extensive automation, proactive IT operations, and standardized services while applying the appropriate level of governance to control risk but not at the cost of agility and responsiveness.

Now as you can imagine this is not something that can be done overnight and requires a well-defined and achievable transformation roadmap. This transformation can take a time to implement successfully depending on many organisational factors such as maturity, size and the appetite for change.

VMware’s operations transformation services teams are partnering with organisations just like yours on a day to day basis to put the building blocks in place to help them in their transformation journey and make their strategic vision a reality.

If you are interested in our approach to this as well as some of the challenges and lessons we’ve learned in one of our major transformation projects, plan to attend the session SDDC7886 – Implementing an Operating Model for Agility: A Customer Success Story next Thursday the 20th October 2016 at 9AM presented by Kevin Lees (Principal Architect for VMware’s global Operations Transformation practice) and myself, Paul Wiggett.

=======

Paul Wiggett is a Technical Operations Architect for Operations Transformation Services EMEA and is based in the U.K.

VMworld 2016 Barcelona: Breakout Sessions You Shouldn’t Miss

vmworld_ots_aas_eu

Download a handy guide.

Learn from the Experienced VMware Advisory and Operations Transformation Teams at VMworld 2016 Barcelona

VMworld 2016 Barcelona kicks off in less than two weeks on October 17th.  Our Operations Transformation Services and Advisory Services teams will be there to extend their expertise to help customers get the most out of their investments in VMware technology.

View the abstracts for these breakout sessions and add them to your VMworld Barcelona agenda using the links below.  We look forward to seeing you there!

Day Date Time Session Title
Mon 17-Oct 1:00 PM SDDC7609-QT How to Respond to the “Bring Your Own Data Center” Trend
Mon 17-Oct 2:00 PM SDDC7876-QT Service Automation Roadmap:  Approach and Samples
Tue 18-Oct 11:00 AM SDDC7616 Strategizing Cloud Business Management Using vRealize Business
Tues 18-Oct 11:00 AM DEVOP9093 Unpanel: How I Survived the DevOps Transition
Tue 18-Oct 12:30 PM SDDC7692 Tips for Realizing the Full Value of Your SDDC Transformation
Tue 18-Oct 3:30 PM SDDC8824 Thales UK – How Defining a Service Led to Automation Success
Wed 19-Oct 12:30 PM DEVOP8924 Building an Actionable Strategy Around DevOps and Platform as a Service (PaaS)
Wed 19-Oct 2:00 PM DEVOP7788 Industry Perspective: Enterprise Reality of Doing DevOps
Thur 20-Oct 9:00 AM SDDC7886 Implementing an Operating Model for Agility
Thur 20-Oct 12:00 PM SDDC8357 If They Come – Are You Ready?
Thur 20-Oct 1:30 PM SDDC9971 Experience the Business Impact of IT Innovation & Transformation in this Live Interactive Simulation

The Art of Resource Reclamation

Increasing Efficiency with vRealize Operations & Proactive Capacity Management

By Alberto Martinez

“Become more efficient”, “reduce costs” and “sustainable growth” are common drivers in our customers’ strategies, both at a business and IT level. Today, these drivers are more pressing than ever as market competition increases and investment decreases. What are you doing at a virtual infrastructure level within your organization to support them?

This post will focus on a key capability that addresses all three drivers: proactive capacity management.

Proactive capacity management enables IT to reclaim resources that aren’t being used and balance utilization, effectively right-sizing the virtual infrastructure. This increase in efficiency will free up VMs that you can allocate to other projects, reducing costs and supporting growth.

Our experience in the field has proven that to successfully perform this exercise, you must first understand the following 3 key questions: the WHAT, the WHEN and the HOW.

What: Defining your Proactive Capacity Management

To proactively manage the capacity of your virtual infrastructure, you need to look at three areas:

  1. Resource Reclamation (oversized VMs)
    Reclaim CPU & memory that are not being used by VMs
  2. Virtual Machine Recertification (idle & powered off VMs)
    Rectify that the VMs are supporting a service (being used)
  3. Hot Spot Identification (stressed VMs)
    Identify VMs that are undersized and require more CPU or memory

Establishing a proactive capacity management process will efficiently right size your provisioned virtual infrastructure.  I explicitly refer to this as a “process” because right sizing is more about the correct engagement with your business than the technical activities.

When: Implementing proactive capacity at the correct moment

Proactive capacity management is not an activity to be performed during project lifecycle because at that point IT architects and / or Project Managers will provide (and pay for) VM sizing based on vendor recommendations, even though these may seem oversized at the time and will probably include conservative margins. Proactive capacity management should be performed once the VM has been provisioned, the project has been completed and a reasonable amount of time has passed. At that point, the Virtual team will be better placed to analyze the performance and behavior of that VM in your infrastructure.

Resource Reclamation and Proactive Capacity Management

For example, one of my customers determined that VM cost was considered depreciated after 4 years, moving the cost from project CAPEX to the Virtual team OPEX budget.  In that case, VMs whose period of life was greater than 4 years would be the best candidates to focus on when implementing proactive capacity.

How:   A 7 Step Process for Proactive Capacity Management

There is no “one size fits all” process for proactive capacity management, as each organization will have its own particularities, so customizing that process is key to success.  The process I have laid out below highlights the key steps in proactive capacity process which you shouldn’t miss, and what “configurations” should be applied based on your specific environment.

  1. Extract Reports from the vRealize Operations Tool (vROPs)
    Use the information available in vROPs reports about the vSphere environment as an input to the proactive capacity management process and make sure that you ignore those VMs that has gone through already the process (use vSphere tagging to identify them!). Agree on the scope of the analysis (environment, virtual platforms, dedicated zones such as DMZs or services such as databases) and identify key experienced individuals to run the process with deep knowledge on your vSphere environment & understanding on the lines of business.
  2. Analyze the Information Extracted
    Create a detailed list of candidates with the information extracted from vROPs including key information such as VM name, environment, Line of Business and action to be performed (oversized CPU / Mem, powered off, idle, stressed CPU /Mem). Include cost savings opportunities to each candidate (oversized, powered off, idle) or additional costs for stressed VMs. I´ve seen this process failing many times because communications were too technical!
    ss_capacitymanagement
  3. Engage with the VM Owner
    A big part of the process is interacting with those who are responsible for the VM.  First identify who to engage with (typically someone from a line of business or within the IT or Application Development organizations). Define what the engagement process will be (ask for approval, just inform them, directly do not engage with them). Finally, standardize the communications by using templates with cost savings information and detailed technical analysis so the person responsible for the VM is confident in your recommendation.
  4. Plan
    Once the approved list of candidates is finalized and you have engaged with the VM owners about when to implement the changes, consolidate those dates into a calendar that considers change windows and freezing periods. Create change requests to track those implementations and include roll-back plans accordingly (snapshots, revert resources reclaimed, etc.).
  5. Implement
    Perform the technical implementation of the proactive capacity management. Roll-back if there is any problem during the implementation, inform the VM owner about the status completion of the implementation (successful, failed, etc.) and set the appropriate VM tag (reclaimed OK, reclaimed FAILED).
  6. Monitor
    Define a reasonable period of time to monitor the performance of the updated VM and app / service. This could be anywhere from a week, 2 weeks, a month, and so on.  Use a vROPs custom dashboard to monitor the Health of those updated VMs.
    Capacity Management
  7. Report & Close
    Consolidate the information captured during the monitoring phase, create a detailed “Proactive Capacity Analysis” report and distribute it to the appropriate list of stakeholders. This list could include the application or service owner, IT management, etc.  The report should include achieved cost savings (approved and reclaimed candidates) and potential cost opportunities (rejected candidates).

Key Considerations for Implementing Proactive Capacity Management

As we’ve worked with customers to apply this methodology, our Operations Transformation Services team has identified some key common considerations that will drive the success of this initiative:

  • Start simple, test the process and then expand it to more complex environments. At the beginning you will have a large list of potential candidates, so start by executing the process fairly regularly, such as every week, with a small number of target VMs selected from a less risky environment, such as application development. It’s much easier to power off a VM in development than in production, don´t you think?  This way you will have more control over those workloads while you continue to refine the process.
  • Sponsorship is crucial to provide the correct level of empowerment to the Virtual They need this support in order to lead the process effectively and make the appropriate decisions.
  • Build a trustful relationship with the business by presenting consistent information and establishing confidence in the IT organization around the proactive capacity management process.
  • It’s not about cost savings today, it’s about cost savings tomorrow. Resource reclamation improves long term efficiency by increasing the pool of pre-provisioned resources with the reclaimed resources (freeing up physical hosts) and continuously executing the proactive capacity process to ensure rightsizing of the infrastructure.

If you are ready to optimize your virtual infrastructure through proactive capacity management or want to know more about this key IT infrastructure capability, the VMware Operations Transformation for Performance & Capacity Management service is a great place to start.  Reach out to your VMware representative and engage with the team to get started.

—-
Alberto Martinez is an operations architect with the VMware Operations Transformation EMEA practice and is based in Spain.

Taming the Hydra: IT in a Multi-Cloud World

Kevin Lees

Photo Credit: iStock/ZU_09

Photo Credit: iStock/ZU_09

By: Kevin Lees

I know it’s hard to believe, but VMworld is upon us again. Where did the last year go? I know many of you were busy implementing, updating, extending, and managing your private cloud environment. Perhaps you’re busy implementing and getting comfortable working with NSX; busy realizing the great benefits software defined networking and security brings you as an IT service provider to you line of business customers. Regardless, I’m sure you’re busy making your customers happy with the standardized and customer-driven IT services you’re providing.

So, you’re getting comfortable in your private cloud world – but not too comfortable I hope, as a recent VMware study (VMware Customer Advocacy study”, Q1 2016) shows that 48% of enterprise applications will be cloud based within 3 years. Ok, that doesn’t sound too bad. That is until you see another statistic that says 65% of enterprises will use more than one public and/or private cloud platform and for 67%, and that:

For 67% of enterprises the ideal end state includes relying on multiple cloud platforms.

Relying on multiple clouds, really?

So how are you going to deal with that? How are you going to bring order to potentially multi-cloud chaos? It’s hard enough to get a handle on the workloads your enterprise developers are placing in one public cloud, how bad is it going to get? Well, if you start planning for multi-cloud now, it may not have to be bad at all. In fact, with proper planning, you can drive a good degree of control – without all of those pesky developers even knowing the difference.

If I’ve piqued your interest – or perhaps triggered the onset of a slight panic attack, please stop by my session, SDDC8994: Taming the Hydra: IT in a Multi-Cloud World, next Monday at 3:30 at VMworld 2016, and I’ll fill you VMworldin on some concrete steps you can start taking now to avoid the chaos as well as how the looming multi-cloud world might impact your IT role. I hope to see you there.

Download a full agenda of VMworld breakout sessions that will help IT leaders build a strategy for the digital era.

=======

Kevin Lees is Principal Architect for VMware’s global Operations Transformation practice and is based in Colorado.

3 Steps to Create an Automation Roadmap

Ahmed_croppedAutomation RoadmapBy Ahmed Al-Buheissi

Automation is at the heart of any cloud implementation.  It provides fast provisioning, resource monitoring and self-healing, capacity adjustment, and automated billing.  Also, automation will ensure consistency, prevent errors and free-up valuable staff time to work in more innovative projects.

But in order to embrace automation, the organization needs a roadmap. This roadmap needs to be based on an understanding of the current state of the organization, in terms of technology, people and process. You must also examine where the organization will want to be in terms of automation and define “to be” state. The roadmap creation process will determine what tools, skills and services are required to achieve the automation target, and then schedule these improvements to achieve the requirements.

With a comprehensive roadmap, the organization can be well-prepared for the journey, in terms or time, budget and resources.

Three Steps to Create an Automation Roadmap

There are three recommended steps to take in order to create the Automation Roadmap:

  1. Assess Your Current State: Using industry best-practices, you need to start off by assessing the organization’s current state in terms of:
    1. Technology
      What technology is available and fully adopted, in areas such as virtualization, self-service, automation and orchestration? Even DevOps-related tools should be assessed.
    2. Process
      Are related process and policies documented and implemented? For example, Service Definition, Request Fulfilment and Release Management.
    3. People
      Specific skills and roles are necessary for running an automation-oriented infrastructure. Some of these roles include Service Architect and Infrastructure Developer, which need to be documented, formalized and assigned.
    4. Interactions
      Ensure that proper interaction procedures are in place, such as interactions between groups, to the business, and to service providers.
  2. Get Your Priorities Right: You need to identify potential processes for automation, in areas such as IaaS, PaaS, Proactive Operations and capacity Monitoring. Once these opportunities are identified, they need to be evaluated and prioritized in terms of process, impact and readiness.
  3. Put it all on the Map: Now that we know where we are and what we need, we can put it all on a time-line chart. When creating the roadmap some consideration needs to be given to the length of time for the roadmap, as well as time and order required for implementing tools and processes.

If you want to learn more about establishing your Automation Roadmap, please join my Quick Talk at VMworld in Las Vegas:

VMworldAugust 28th 2016 –  1pm
“Service Automation Roadmap: Approach and Samples”
Add session SDDC7876 via the VMworld Schedule Builder

Download a full agenda of VMworld breakout sessions that will help IT leaders build a strategy for the digital era.

=======

Ahmed Al-Buheissi is a Senior Solutions Architect with the VMware Operations Transformation global practice and is based in Melbourne, Australia.

How NOT to Fail at Process Automation and Continual Improvement

Chris KunselmanProcess Automation and Continual Improvementby Chris Kunselman

A big part of my job at VMware is to help customers transform to an SDDC environment. For VMware Operations Transformation Services, that means understanding the business reasons behind their strategy for an SDDC and Private Cloud, and then defining the roadmap to achieving this strategy.  The transformation is the journey along the way.  Typically, this means significant changes to an organization’s culture, paradigms, skills, technology and operational processes.

Usually our customers already have some level of IT Service Management (ITSM) maturity around operations.  They also usually have highly qualified talent who understand the management of technology.  However, what they sometimes lack is the mindset, skills, and experience necessary to effectively scale a privately operated cloud.  To do this, they need to focus on end-to-end process automation through a rigorous approach to continual improvement.

Without an approach to automation, companies will not be able to scale their operations, retire their legacy environments, and realize the full business value from their investment in VMware technology.  Hear more about this at my VMworld 2016 breakout session, “Tips for Realizing the Full Value of Your SDDC Transformation” (add SDDC7692 to your agenda).

Continual improvement and process automation go hand-in-hand if an organization truly intends to operate their cloud as a business, and gain the benefits from the use of vRealize Automation (vRA), vRealize Orchestration (vRO), and vRealize Operations (vROps).  VMware solutions bring a new potential for an organization to finally achieve the highest level of process maturity.  Automation and continual improvement should be a component of every private cloud operations team.

The Importance of Continual Process Improvement

Imagine that you currently have six globally located private cloud data centers, and four thousand application workloads already migrated to your private cloud.  Not only that, but you are continuing to migrate an average of 400 legacy workloads per month into your SDDC.  That means in one year, the number of your workloads will have more than doubled!

In my experience working with customers, most of them don’t plan to manage their IT services in the same way and with the same number of resources as they manage their legacy environment.  They don’t plan to double their team size as their SDDC grows, but this is a very likely scenario.

Virtualizing your infrastructure creates more demand from the business, for even faster delivery of the same legacy services.  Merely moving your legacy environment to your new virtual private cloud does not give you the full payback you would expect, unless you also have a strategy for continual improvement and automation.  A vast amount of operational cost can be saved if you automate.  However, to achieve this, your continual improvement team should have a good mix of business process re-engineering, systems integration, and development skills

VMware’s Approach to Automating Processes and Establishing Continual Improvement

Say, for example, the request for increasing capacity occurs very frequently in your environment.  Let’s say it takes your team members eight hours to provision 20 of these requests in vRA.  The reasons it takes so long may vary, but it usually boils down to regulatory controls, change control approvals, documentation, and many tedious steps in various systems, performed by different teams.

You start with automating this process so that it takes just a button push to approve it and the rest happens automatically through vRO orchestration, and vRA to provision the request.  After taking out most of the manual tasks in this process, your same resource could provision 20 of these requests in an hour, becoming eight times as productive.  This is the type of scenario you want to tackle on a continual basis.

VMware operations transformation consultants use an incremental approach with customers that works well within agile IT environments.  We work with your business process team to identify these opportunities, prioritize them, and drive them to completion through a series of development sprints.  This requires a strong collaboration between IT business process experts, your ITSM systems and your VMware automation/development team.

Customers often miss crucial aspects of continual improvement, leading us at VMware to create a practical and comprehensive step-by-step approach to follow continual improvement practices by automating end-to-end IT processes.  By following this approach, customers can derive measurable value from their private cloud transformation by increasing the quality of service delivery, removing unnecessary labor, and human intervention

Deep Dive Analysis

We begin with a deep dive analysis of the particular processes we aim to automate.  We look at all types of changes that exist to identify changes that are executed frequently, performed with consistency and require many steps and approvals, then determine which of these can be automated.  We establish a backlog of these automation opportunities.

It is important to note that due to regulatory concerns, it is not possible to automate the provisioning steps of every type of change, especially major changes.  Typically, the list of potential automation opportunities is made up of standard change types that do not require approval.

Because we want to automate the end-to-end IT process, it is important to look at every segment of the manual process.  Some process segments will require forms and data capture, or integration that populates form data and automatically passes this data into vRO, and/or vRA.  Other processes may require approval steps.  This type of end-to-end automation involves integration between multiple systems, such as request ticketing, change ticketing, and VMware vRA, vRO systems for provisioning and orchestration.  We look at the business processes, business and compliancy requirements, as we engineer the automation to ensure we automate the right activities.

Calculate Expected Business Value

Next, we calculate the expected business value to be gained from the automation of each change type that we have identified as an automation candidate. This is a cost analysis of the duration, time, and number of people it currently takes perform each step in the process.  From this information, we can determine the “time-cost” of the entire process.  Once we have an idea of the time cost of every process in the backlog, we can determine which automation opportunities will drive the most benefit.  We rank and prioritize these opportunities based on how much value they will bring to the overall virtualization business case.

Develop a “To-Be” Design for Each Process

Starting at the top of the priority list, we write flow diagrams for how the process will work in an automated fashion.  The workflow diagrams include the user to user, user to system, and system to system interactions and use cases.  From these diagrams, we define functional requirements, inputs, outputs, triggers, roles and responsibilities.  Most importantly, during this step, we establish reasonable metrics for measuring the outcome of the effort.

Validation & Implementation

We then hand-off the functional automation requirements to the automation development team.  This team analyzes the functional requirements, and then creates a technical design.  During the design stage, the technical design team comes back to the business process automation engineer who validates whether or not the technical design meets the functional requirements.  This ensures that the goals for time-cost reduction will be met.

Very often, the development team cannot fit all the required functionality into the first release of this process automation.  So we also must prioritize the technical requirements associated with each automation opportunity, placing them into various releases.

By the time the final release is implemented, the full end-to-end automation exists and we are able to measure the business value metrics that we set out to achieve.  The customer begins capturing performance information on the automated process to determine if the automated effort is consistently saving the time cost it is intended to save.

Keys to Success

Following this methodology ensures that our customers get the benefits they were looking for, maximizing cost savings and optimizing operational efficiency.  By effectively prioritizing your process automations, we ensure the ongoing success of your continual improvement program.  We analyze the functional requirements of each end-to-end process first, ensure that we evaluate improvements to the process before automation, and make sure improvements align to existing policies and regulatory requirements.  It doesn’t make sense to automate a bad process.

Tight integration between your business process and your technical development teams is also key to success.  In some situations, a technical team will attempt automation on its own, often with little understanding of the full end-to-end process.  When that happens, their effort may not focus on achieving a clear business objective. By not evaluating the full end-to-end process, their attempt of automating only parts of a process, will not reduce the cost of labor effectively

By formalizing automation efforts as part of a continual improvement program, customers can achieve these improvements incrementally, over time, and within their normal operational budget.  But most importantly, they gain increasing value from the investment in VMware technology.  With our continual improvement approach, one successful automation project creates a “quick win scenario” that sets you up to tackle all the others that follow, with a focus on achieving and measuring specific business outcomes.

If you are interested in creating a plan for process automation and continuous improvement, reach out to your local VMware representative and my team would be happy to help.

=======

Chris Kunselman is a Senior Transformation Consultant with VMware Operations Transformation Services and is based in Pennsylvania.  ckunselman@vmware.com

A Day in the Life of a Cloud Service Owner

Pierre Moncassin-cropCloud Service OwnerBy Pierre Moncassin

Customers often tell me, “I totally get the principles behind the role of Cloud Service Owner – but can you describe what do they actually do throughout their work day?”

Let me start with a caveat: we are all aware that in a knowledge economy few roles have the luxury (or burden, depending on the point of view) of a completely predictable, set routine.  We are in an era where many traditional, factory assembly line jobs have been re-designed to become more agile and less repetitive, at least in some leading-edge companies.  The rationale being that job rotation and innovation if not creativity, leads to higher productivity. Less routine, more output.

What is a Cloud Service Owner?

When I say Cloud Service Owner (CSO), I am referring specifically to the Service Owner role described in the VMware white paper: Organizing for the Cloud.

A CSO is a relatively senior role that includes responsibility for the end-to-end life-cycle of cloud services, with numerous levels of interaction with the business and cloud team members. So I will endeavor to highlight some typical aspects of a ‘day in the life’ of that role – bearing in mind all the caveat above.

Cloud Service Owner

The Cloud Service Owner ensures a consistent, end-to-end Service Lifecycle

Cloud Service Owner Stakeholders and Interactions

The CSO interacts with a number of key stakeholders, first of all within the business lines. When a new service is requested, the CSO reviews the requirements with the Business stakeholders; which may include not only the definition and costing of the service but also a discussion of how quickly it can be placed into production.

In a DevOps environment, that interaction with the business lines will still take place, with the difference that business and application development may be a single team (the business stakeholder may be an application product owner). When the (DevOps) business proposes to launch a new product (i.e. cloud based application or application features), they may need to discuss with the Service Owner how to develop the continuous delivery automation to support that new product.

The CSO will also interact with the members of the cloud operations team, for example with the Cloud Service Architect who will assist in all aspects of the design of the automation workflows and blueprints underlying the services.

Interactions will also include working with other support groups such as the Service Desk – for example, to review incidents relating to the services and work out patterns or root causes; possibly involve the Service Analyst to improve the monitoring and risk management underpinning these services.

Of course the list does not end there. The CSO may also interact with third party providers (especially in a hybrid cloud or multi-cloud model), as well as contractors. If the cloud platform is part of an outsourcing arrangement, the CSO will likely have a counterpart within the outsourcer.

Key Processes for a Cloud Service Owner

From a process perspective, our CSO will be involved in all aspects of the service life-cycle – this is by definition of the broad remit of the role. But I can highlight some key ‘moments’ in that life-cycle.

  • Initial definition of the service in cooperation with the business stakeholders.
    This is a critical stage whether both the scope of the service is defined, but also the expected costs and service levels.
  • Monitoring the performance of the service.
    In traditional IT, the review of SLA performance with business takes a key role once a service is up and running. In a cloud environment, much of SLA monitoring may be automated, however SLA review is still an important role for the CSO.
  • Continuous Improvement and ultimately, de-commissioning of the service.
    It is expected that the service will evolve and that ultimately it will be de-commissioned (possibly freeing some capability). This is also an activity that needs close cooperation with business lines.

Toolsets for a Cloud Service Owner

I mentioned at the outset that the CSO is not necessarily expected to a toolset expert.  However, in order to fully leverage the capabilities of a cloud platform, the CSO will be able to leverage the key cloud management tools, specifically:

  • vRealize Automation – the CSO will have a solid understanding of how blueprints are designed and where/when existing blueprints can be re-used to create new (or amend existing) services.
  • vRealize Business – understand the costing models and how they can be built into the tool to automate charging/billing.
  • vRealize Operations – leverage the tool to track service performance, and generally managing service ‘health’ and capacity.
  • NSX – the CSO is less likely to interact with this tool on a daily basis, but will benefit from a solid understanding the capability of this tool to help design the automation workflows and to plan the security controls that may be required when deploying the services (e.g. leveraging micro-segmentation).

The list is not exhaustive. Many organizations are considering, or already working towards DevOps adoption, and in those cases the CSO will benefit from a broad grasp of industry tools whether related to continuous delivery (think Jenkins, Codestream, Puppet, Ansible), or specifically to Cloud-Native Applications (think Docker,  VMware’s Photon OS).

Take Aways:

  • For roles such as Cloud Service Owner, design activities should take precedence over fire-fighting. These roles will prefer an engineering approach to problems (fix a problem once).
  • Do not expect a rigid work-day pattern – the Cloud Service Owner is a senior role and will need to liaise with a range of stakeholders, and interact directly and indirectly with several tools and processes.
  • The Cloud Service Owner will maintain a healthy understanding of toolsets; and leverage that knowledge daily to design, manage and occasionally de-commission services. This is an aspect of the role that may be significantly different from more traditional Service Manager roles.
  • However, the Cloud Service Owner is not meant to be a toolset specialist. If they spend their entire day immersed in toolsets, it is a sign that the role is not fully developed!
  • The Cloud Service Owner will work in increasingly close cooperation with the business lines– not from silo to silo but through an increasingly permeable boundary.

=======

Pierre Moncassin is an operations architect with the VMware Operations Transformation global practice and is based in the UK.

Mind the Gap: Breaking Down Silos

Part 1:  Getting Started.

Kevin LeessilosBy Kevin Lees

For IT to truly transform into an effective, business-focused service provider it has to do more than implement an enabling technology like software defined data center, though that’s certainly a great start. In fact, according to the recently published State of IT Transformation analysis done by EMC and VMware, 95% of participants believe having an IT organization that has no silos and works together to deliver business-focused services at the lowest cost is critical.  Yet, not astonishingly based on experience, less than 4% reported they currently operate like this. That’s quite a gap!

According to the same analysis, operating without silos was one of the top 10 goals in all but one of the industries represented in the study (17 of 18 industries) and was in the top 11 for all industries. Thankfully, while there is a significant gap between desire and current state, IT operating without silos is top of mind and viewed as critical to success regardless of industry. So how do you navigate this gap? Where do you start? How do you proceed without causing an anxiety attack or worse, intransigence, within IT? In this two part blog, we’ll walk through some critical steps we use for closing this gap.

Step 1:  Secure an Executive Sponsor

First and foremost you have to realize and acknowledge that the biggest challenges you will face in breaking down silos are cultural and in all likelihood political challenges. That has been my experience and that of my colleagues when working with companies to break down their IT silos. And of the two, the political challenge can be the harder to overcome.  Which brings us to the first step in closing the gap: getting executive sponsorship and not just any executive sponsorship, you need proactive executive sponsorship.

You need an enthusiastic, proactive executive sponsor for this kind of change.  Indeed, that’s your number one goal – to have an executive involved who completely embraces this idea and the change it requires, and who’s committed to proactively supporting you.  He or she is critical to success in many ways, not the least of which in overcoming the cultural and political challenges. To overcome these challenges the executive sponsor has to have the enthusiastic support of those in the management chain of the organization in which the silos exist.

But how to you generate the enthusiasm when we know how resistant some people are to change, especially change that might affect their span of control?

Step 2:  Sell the Change

Work with the executive sponsor to craft a communication plan aimed at both the management chain and the organization as a whole. When building the communication plan, you would ideally derive the intent for the change from a strategy and roadmap focused on transforming IT into a service provider to the business that has both executive and business support. If not, developing that IT transformation strategy and roadmap becomes step one!

The communication plan should focus on why you’re making the change, why it is critical for the business, and what value embracing it has for the affected IT managers and employees– what they stand to gain as individuals.  And individuals do stand to gain, for example through recognition, increased visibility, opportunity to participate in something truly innovative, obtaining new skills that are highly valued in both the company and the industry, and new career opportunities. The goal is to make participating in the change aspirational. But enthusiasm only goes so far. You also have to provide them a safe way to modify their behaviour – as well as provide a little extra nudge to those in management who are still a bit reluctant to change.

Step 3:  Modify Behavior

Modifying behaviour is a key step but one that is overlooked more often than not. This involves modifying annual performance review criteria, and bonus critera if applicable, to reflect the desired outcome.  If this is not done individuals will default to their incentivized behaviour when prioritization decisions need to be made – or, for a few, as an excuse for not fully embracing the change.  Modifying this criteria is absolutely critical for the management chain in order to help address the political challenge. It’s also important for members of the silos whose walls are to be torn down, as we’ll see in the final step.

Step 4:  Break the Silos

I say the “final step” but that’s a bit of a misnomer, as the final step can take some time and consists of many activities as it is the actual breaking down of the silos. In part two of this blog I will focus on the approach we have found to be successful when undertaking this type of organizational change.

=====
Kevin Lees is Principal Architect for VMware’s global Operations Transformation Practice and is based in Colorado.