Home > Blogs > VMware CloudOps

Cloud Capable, Now What?

Part 1 – Defining Your Vision is the First Step to Creating a Cloud Operating Model

Dion ShingBy Dion Shing

In a recent consulting project, I worked with a customer to help design their cloud operating model. The key focus was on designing an operating model that would support a specific purpose. It was not so clear, however, what that purpose was.

Defining a Purpose Before Developing a Cloud Operating Model

As we went through the workshops, it was clear the customer understood that:

  • Operational processes adapted for cloud computing should underpin the cloud operating model
  • Integration with enterprise service management processes would be necessary
  • Standardization and automation form key principles of cloud computing which can be achieved by integrating process, coordinating people and enabled through technology

What was still ambiguous to them was how they could define an appropriate cloud operating model and structure that would solve their specific business issues.

Our initial recommendation was to develop the cloud operating model in iterative stages, addressing the majority of the business cases, but not all of them.

The Incremental Approach

The first scenario they focused on aimed at building competencies toward Cloud Service Provider Level 3 maturity (VMware’s Cloud Maturity Model) in increments over a medium time horizon.

As we progressed with that scenario, another business case emerged in which the customer would provide cloud computing services to external customers in the same time horizon. This necessitated a change to the design of the cloud operating model and required Level 5 maturity, focusing on the processes in service and business control.

Due to the time frames, an organic growth strategy would take too long and not be sufficient.  This necessitated a different approach with respect to structure. Considerations for partnership and outsourcing were put forward, altering the design of the operating model with a heavier focus on developing processes for vendor management and service brokerage.

What this highlighted to me was how critical it is to understand the overarching enterprise goals and objectives as you set out to design and build a cloud operating model that will meet your organization’s needs.

The example I just laid out represents a process that was effective, but is it possible perhaps to make it efficient as well?

What’s Next in This Blog Series?

As I continue with this blog series I will:

  • Lay out an approach for establishing a cloud operations transformation strategy that is matched to the goals and objectives of the business
  • Examine why the IT department should play an equal role in establishing and shaping business strategies and business models to support the development of innovation and sustained competitive advantages
  • Explore how a cloud organization structure and operating model can be designed based on different enterprise strategies and how to manage the implementation of the change.

Dion Shing is an Operations Architect based in Dubai.

3 Simple Steps for Benefits Realization throughout Your IT Transformation Program

Keng Leong ChoongBy Keng Leong Choong

An IT Transformation initiative to build a Software Defined Data Center or cloud does not end with the completion of technical delivery (i.e. deployment and migration to the new infrastructure and automation tools). Many organizations have invested huge sums on their IT transformation initiative only to achieve no sustainable benefits because of loss of enthusiasm and resistance to change.

To avoid letting your IT Transformation initiative rot and die, you need to ensure that the benefits you envisaged at the start, usually in your business case justification, are being realized at the end. This is done through a benefits realization management process.

What is Benefits Realization Management?

John Thorp, author of “The Information Paradox”, wrote that:

“It is a central tenet of the Benefits Realization Approach that benefits come only with change and, equally, change must be sustained by benefits.”

Benefits are only realized if the organization changes the way it operates, and the organization will only change if they see motivation to do so.

“Benefits do not just happen. They don’t just automatically appear when a new technology is delivered. A benefits stream flows and evolves over time as people learn to use it.”

You must set expectations that realization of the full benefits of transformation will not be immediate and will only grow over time as your organization adopts the new technologies and processes.

“Benefits realization is a continuous process of envisioning results, implementing, checking intermediate results and dynamically adjusting the path leading from investments to business results.”

It is important to establish regular tracking and reporting of the benefits realized and ensure that is communicated across the organization. 

Changing the way people think, work and manage is critical to achieving IT Transformation goals.

3 Simple Steps for Benefits Realization Management

So how do you establish a Benefits Realization Process? These 3 steps should be part of your IT Transformation plan.

Step 1: Define Expected Benefits

At the beginning of the IT Transformation initiative, it is very likely that you would have developed a business case for embarking this journey. Also, you will probably have identified the tangible and intangible benefits which will be achieved at some time in future (e.g. 2-3 years).

If this has not been done, you need to do it now!

Step 2: Run the IT Transformation Initiative as a Program

As I mentioned above, the initiative doesn’t end when you completed your technical delivery. To justify the investment, you have to produce results and show business benefits accomplished during the time span defined in the business case.

To do this you need a program office that manages the transformation program for the entire time span.

Step 3: Monitor, Track and Report on Benefits Realization

As John Thorp pointed out, to realize the benefits, you need to change. The best way to achieve this is to adopt a balanced scorecard to track IT transformation benefits realization from financial, people, process and customer perspectives.

Balanced Scorecard for IT Transformation

Tracking and reporting on SDDC/ Cloud adoption and usage is also important, as the faster workloads are migrated to the SDDC, the faster you achieve the cost saving goals. The longer it takes, the financial benefits become opportunity costs.

choong_migration_tracking

Consistently tracking and communicating benefits realization throughout your IT transformation to executives, senior management, the IT organization, and even the business at large is not only vital to the overall success of the program but can determine whether your IT organization is seen as trusted innovators and strategic partners, or just a necessary (and replaceable) cost center.
========
Choong Keng Leong is an operations architect with VMware Professional Services and is based in Singapore. You can connect with him on LinkedIn

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

kai_holthaus-cropBy Kai Holthaus

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

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

1&2) Event Management and Incident Management

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

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

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

3) Request Fulfillment

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

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

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

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

4&5) Change and Configuration Management

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

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

6) Continuous Deployment

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

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

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


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

Top 5 Tips for Organizing the Cloud

You’re ready to reap the rewards. Is your organization ready to deliver?

5 Tips for Organizing the CloudThe technical and business advantages of the software-defined cloud era are well understood. But all too often a critical aspect of adopting the cloud model is overlooked: the organizational impact. The fact is the transition to the cloud changes roles, skills, processes and organizational structures. Yet, many IT leaders become so focused on the vision of the cloud—or its technological requirements—that they lose sight of whether their IT staff is properly prepared for the new world.

The resource, Top 5 Tips for Organizing the Cloud, will help you prepare for—and execute—a successful move to the cloud.

Green vs. Grey — Rethinking Your IT Operations

Neil MitchellBy Neil Mitchell

Can you really create a new greenfield IT organization with no legacy constraints?

In this short video, operations architect Neil Mitchell explains that while anything is theoretically possible, most IT execs need to face the reality of impact on legacy IT operations.

====
Neil Mitchell is an operations architect with the VMware Operations Transformation global practice and is based in the UK.

Key People, Process and Policy Considerations for vRealize Automation Success

Keng-Leong-Choong-cropBy Choong Keng Leong

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

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

Key Players

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

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

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

Service Models

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

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

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

Request Models

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

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

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

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

Access and Entitlement Management

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

Communication and Awareness

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

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

5 Steps to Building Your High-Performance Cloud Organization

Make sure learning happens by design; not just trial and error.

Pierre Moncassin-cropBy Pierre Moncassin

One of the often-overlooked aspects of building an effective cloud organization lies in the training and development of team members. My customers often ask, “How do I accelerate my IT organization's transition to cloud?” Well, there is much more to my answer than relates to deploying toolsets.

What the IT organization needs is accelerated learning—learning at organizational level as well as individual. All too often, that learning happens in part by accident.  An enthusiastic project team installs the technology first, sometimes as a pilot. The technology works wonders and produces great initial results, e.g., IT services can be provisioned and managed with levels of speed and efficiency that were simply not possible before. Then sometimes, the overall project just stalls. Not because of a technical shortfall. The reason is that the organization has not completely figured out how to fully leverage that technology, and more importantly, how to fit it in with the rest of the IT organization. This is a shortfall of learning.

Faced with the challenge of learning to leverage the technology, many organizations fall back on the tried and tested approach known as “learning on the job.”  After all, this is an approach that has worked for centuries! But in the fast-paced cloud era, you want to accelerate the learning process. Really, you want learning by design not just by trial and error. So, where do you start?

Here are some practical lessons that I have collected by supporting successful projects with customers and within VMware:

1. Design a plan for the organization.
Org for Cloud wp
It stands to reason that the future organization will be different from the current, “pre-cloud” organization. However, the optimal structure will not be reached without planning. In practice we want to gradually flesh out your tenant operations and infrastructure operations teams, as describe in more details in the white paper: Organizing for the Cloud.

In turn, this means orchestrating the transition from the current roles into the target organization. Each transitioned role will require a skills development plan adapted to the individual.

2.    Plan for formal skills development.
The fist step to plan skills development is to carry out a gap analysis of each selected team member, against their future roles (e.g. , service owner, service architect, and so forth). Each role carries specific requirements in terms of technical skills—without delving in all the details, a blueprint manager will need deeper knowledge of VMware vRealize Automation than a customer relationship manager; however the customer relationship manager will need some awareness of the blueprints and how they can be leveraged to meet customer requirements effectively.

3. Reinforce learning with mentoring and coaching.
Mentoring and coaching are effective ways to reinforce the individual's own learning. Typically mentoring will focus on knowledge transfer based on personal experience. For example, encourage sharing of experience by pairing up the new service architect with an experienced service architect (either in another part of the organization—if existing—or from another organization).

Coaching will focus on individual skill development—either by learning directly from the coach, or from the coach supporting an individual's own learning journey.

Although coaching/mentoring is by definition highly personalized  (learner centric), it is a good idea to establish a formal structure around it. For example, assign coaches/mentors to all future cloud team members, with a mechanism to track activity and results.

4.    Develop leaders with both business and technical skills.
As when building any team, it is important to identify and nurture a cadre of leaders for the cloud organization.  These leaders will be both the formal leadership roles (tenant operations leader, infrastructure operations leader), but also critical roles such as service owner and service architect.

Such leaders will hold a key role in representing the cloud organization within the broader business.  Part of their development will include broadening their understanding of the business. For example, by assigning them mentors within the lines of business—this is another example where mentoring comes in handy.

However business acumen, whilst important, is not enough. These roles also need to develop broad technical skills to be able to articulate solutions across technical silos and understand the new capabilities introduced by cloud automation.

5.    Reach out to the broader organization with a champions community.
Champions, a.k.a change agents, are advocates within the rest of the organization (especially within the lines of business) who will spread the awareness and support for the cloud. These champions help bridge the silos with business users and win "hearts and minds." Refer to my earlier blog where I explained how we leverage a change agent program within VMware and the lessons that can be inferred. Your change agents will make sure that the broader organization/business learns about the cloud project and ultimately adopts it.

Takeaways:

  • Plan the transition and learning curve both for your organization and the individuals.
  • Combine formal learning with individual-centric learning (coaching and mentoring).
  • Invest effort in developing at an early stage, the future leaders and champions  for cloud adoption. Make sure that their planned learning spans across both technical and business knowledge.

==========
Pierre Moncassin is an operations architect with the VMware Operations Transformation global practice and is currently on long-term assignment in Asia-Pacific. Follow @VMwareCloudOps on Twitter for future updates.

The Business Case for Cloud Automation

Automating in the Cloud Pays Off

Top 5 Tips for Marketing Your Cloud Services

By Alberto Martinez

Alberto Martinez-cropA couple of years ago when I was working in Australia, one of my customers was starting to deliver cloud services to its external customers—mainly infrastructure as a service (IaaS). It was not a very mature market at that time though they knew what they had to do to promote those services: enable a marketing capability with a strong customer focus. As the IT organization was evolving its cloud service offering from a technology point of view, that marketing function was driving the change and ensuring customers recognized the value of their cloud.

One key takeaway from the recent Computerworld Forecast Study 2015 is that companies like yours are now investing (or are planning to invest) large portions of their IT budgets to enable a cloud service offering. In my previous blog entry, I briefly mentioned the key steps to define a process for marketing your cloud services within your organization in order to maximize ROI.

cover top tipsNow let´s take those steps to the next level of detail by considering the lessons learned and the critical success factors from those early adopters of cloud. Take a look at this brief: Top 5 Tips for Marketing Your Cloud Services. I think you'll find some very useful tips for building a marketing capability for your cloud service offering.

=======
Alberto Martinez is an operations architect with the VMware Operations Transformation global practice and is based in Spain.

When to Engage Your Organization in Their Cloud Journey

By Yohanna Emkies

Yohanna-cropThe most common question I hear from my customers is: “What’s going to happen to me (read: my organization) if we introduce the cloud?”  Closely followed by:

“How are we going to begin the planning process…?” These are fair questions, which have to be discussed and worked out.

A question that is often underestimated, although it’s no less important than "what" and the "how" is “when." When is the right time to tackle operational readiness and organizational questions?

I notice two types of customers when it comes to addressing operational and organizational-related topics. Many simply omit or keep postponing the subject, until they are in the midst of cloud technical go-lives. At some point they realize that they need to cover a number of basics in order to move on and are forced to rely on improvisation. I call them the “late awakeners.”

Others—“early birds” keen to plan for the change—will come up with good questions very early on, but expect all answers to be concrete, before they even start their cloud journey. Here are my observations on each type:

1. Let’s start with the late awakeners.
Quite naturally, the customers I'm working with tend to focus on the technical aspects of the software-defined data center (SDDC), deploying all their resources, putting all the other things on hold, working hard for the technical go-live to succeed, until…

“Hold on a minute, who will take care of the operational tasks once the service is deployed? What is the incident management process? How are we going to measure our service levels? What if adoption is too rapid? And what if we don’t get enough adoption?”

In such cases, critical questions are raised very late in the process, when resources are already under pressure from heavy workloads and increasing uncertainty. These customers end up calling for our support urgently but at the same time find themselves unable to free up resources and attention to address the transformation. And when they do, they fail to look at the big picture, getting caught up in very short-term questions instead of defining services or processes properly.

Doing a first tour in these organizations and mapping the gaps, we may discover entire subjects, which have been left aside, because they are too complex to be addressed on the fly. But even worse, some subjects have already been treated because they were critical… but not treated consciously nor fully. The teams may feel that they don’t have time for these questions, think that it’s taking focus from the “important stuff,” but in reality that’s mostly because they are not aware that they are ALREADY spending a lot of time on these same questions, except they don’t focus their effort on it.

That results not only in poor awareness and maturity at day 1, but also in a low capacity to grow this maturity over time because no framework has been put in place.

Putting things back on track may eventually take more time and focus than if they had been addressed properly in the first place. But it is still feasible.

Clearly, it is an IT senior manager’s role to provide strategic direction, while project managers must include these important work streams in their planning from the start. Ultimately, it’s all part of one holistic project.

2. The early birds are also a tough catch.
From accompanying many organizations in different types of transformations, I cannot advocate loudly enough the need to encourage planning and designing before doing. Being mature in terms of the “what” before running to the “how” is undoubtedly the right approach.

A key lesson learnt is that in order to reorganize successfully for the cloud you have to accept some level of uncertainty while you are making your journey.

Some organizations get stuck upfront with one recurring question: "What will our future organization look like?" Relax.

First no pre-set organization design, even roughly customized to your needs, should be taken for granted. Secondly, no design—even accurate—will ever bring the move about. It’s the people that support the organization who are the critical success factor.

Don’t get me wrong, giving insight, best practices, and direction will definitely help the management in envisioning the future organization, which is essential, but at the same time, an organization is a lively thing by definition. There is also a psychological impact. When you start raising words like “people” and “organization,” concern and fear about change come with.

Sometimes it is even trickier because some organizations are already—or still—in the midst of other transformations started a few years back and lingering. In that case, the impression of “yet another change” may be perceived negatively by the core team and may put them in a situation of stress and stop them from moving forward. What if your team has just finished redesigning and implementing incident management processes, only to realize that they have to do it again to adapt to the cloud?

It will take time for the organization to mature. Embracing the cloud is a big change, but no drastic overnight revolution will take you there. Moving to the cloud is not “yet another re-org” but an ongoing, spreading move, which relies on existing assets, and it's here to last.

Your organization will evolve as you grow, your skills will improve as your service portfolio and cloud adoption increases. And this will happen organically as long as you put the right foundations in place: the right people, the right processes, the right metrics…and the right mindset.

The right balance to the “when” is somewhere in between the two behaviors of late awakeners and early adopters. Here are some of the most important best practices that I share with my customers:

  1. Gain and maintain the full commitment of senior management sponsors who will support your vision and guarantee focus all along the journey.
  2. Plan your effort and get help: dealing with operational readiness and with technical readiness should be one holistic project, and for the most part, it involves the same people. The project has to integrate both streams together from the start and wisely split effort among the teams to avoid bottlenecks, rework, and wastage.
  3. Opt for an iterative approach: be strategic and pragmatic. Designing as much as you can while you start implementing your cloud, and then refining as you go, will provide a more agile approach and guarantee you reach your goals more efficiently.
  4. Practice full awareness: create a common language on the project, hit important communication milestones, and reward intermediary achievements, so people feel they contribute and see the progress. It is key that your cloud project will be seen positively in the organization and that the people involved in it convey a certain positive image.
  5. Engage your people, engage your people, and engage your people.

As is often said, timing is everything. When dealing with people and their capacity to change, it’s even more critical to find a balance between building momentum and keeping the distance. Your teams will equally need to embrace the vision, feel the success, and at some point also breathe…and when you empower them efficiently across the process you will have the best configuration for success.

=====
Yohanna Emkies is an operations architect in the VMware Operations Transformation Services global practice and is based in Tel Aviv, Israel.