Home > Blogs > VMware CloudOps

Turning IT Operations Management Dreams Into Reality

No one would blame you for dreaming about better IT operations management. You might dream up ways to make it smarter—say by anticipating problems and troubleshooting them in virtual and physical environments before they even occur.

Learn why this is no pipe dream in this infographic about VMware vRealize Operations Insight, a unified management solution with predictive analytics for performance management, capacity optimization, and real-time log analytics.

Turning IT Ops Mgmt Dreams Into Reality

7 Tips on Leveraging a Change Agent Program to Boost Cloud Adoption

By Pierre Moncassin

Pierre Moncassin-cropIn nearly every other discussion I have with customers about cloud adoption, I hear mention of their challenge with “mindset change.” That challenge is often faced on both sides of the consumer/provider equation, as users (IT consumers) and operators (internal providers) need to change their approaches in order to define, operate, and consume cloud services efficiently.

These same organizations are fully aware that tackling mindset change is essential. The question is: How to go about it with often (typically always) restricted resources and funds?

Changing mindsets for cloud adoption takes more than technical training
One option is to invest in a formal change management consultancy project. Whilst such programs certainly deliver value (and many first-tier consultancies offer such services), they also require a substantial investment both in terms of expenditure and bandwidth of your internal resources.

The next option (and often the default option) boils down to education—typically a mix of functional training for users, and technical training for operators. Without a doubt, training brings valuable knowledge; however it does not always lead to changes in behavior.

Here’s where I can provide you with some useful guidance with lessons from a “change agent” program I was involved with at VMware. This program was designed to build internal awareness and disseminate expertise within a fast-developing global practice. Each of these principles below can be generalized to your broader cloud adoption initiative:

  1. Recruit early enthusiasts—preferably volunteers who want to be ahead of the curve.
  2. Make it personal—recognize individual contributions who are making an impact. Encourage participants to share information, and network with their counterparts in other locations.
  3. Mix structured, semi-structured, and informal communication—formal (meetings, webinars), semi-structured (brainstorming), and informal (social events, ad hoc discussions).
  4. Make the most of social media—great for facilitating free-flowing communication across dispersed team members.
  5. Work with existing structures and processes—no need to re-invent the wheel—our “change agents” are encouraged to use existing internal training programs—often they will be early adopters and provide valuable feedback on how to improve the training so others will benefit.
  6. Train the trainer—or more accurately, train the evangelist. Each individual is encouraged in turn to evangelize within their own team.
  7. Recruit across a diverse range of experience, seniority, and skills—the more diverse the participants, the broader the adoption and reach of the program across the user base. Also the varied experience brings valuable knowledge and feedback into the program.

Results
Within eight months, this unique program has helped VMware’s practice develop a community of more than 100 change agents in over 20 countries! Change agents have contributed to shape and refine the structured training programs in place, and continue to be actively involved in curriculum development.

Whether you are currently struggling with cloud adoption issues or anticipating them with future cloud initiative, I encourage you to try such a program as I’ve described above, and begin to apply these principles. I’d be interested in hearing about your experiences.

===
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.

Optimizing IT Services for DevOps, Agility, and Cloud Capabilities

By Reginald Lo

ReginaldLo-cropA recent Gartner survey[1] revealed that 85 percent of IT departments are pressured by their customers to deploy new or changed IT systems or services faster. As the speed of business continues to increase, IT is having a harder time keeping up. As a result, 41 percent of business leaders attribute faster service delivery time or time to market as the reason they use outside IT service providers[2]. IT must transform itself into an agile organization in order to become a strategic partner to the business.

In the last several years, there have been some key technology and IT management innovations to improve time to market. DevOps, Agile, and cloud computing are all attempts at increasing the speed of IT. However, IT needs to systematically design its services to exploit these innovations.

In this post I’ll explore how to change the way you design IT services so they are optimized for DevOps, Agile, cloud computing, and the service broker IT business model. I’ll also provides suggestions on how to start transforming IT into a nimble organization.

Service Design and DevOps

DevOps describes an approach for re-thinking the collaboration between App Dev, QA, and IT operations. Its purpose is to remove barriers between these teams and align them to the common goal of reducing time to market while maintaining service quality. This alignment sounds easy but is actually difficult because App Dev and IT Ops have traditionally had different objectives: the former strove for innovation and speed, while the later preferred stability.

DevOps focuses on more frequent deployments, lower failure rate, faster mean time to restore and automated processes. In order to design an IT service for DevOps, you not only need to design the system that underpins the service, but also design how the release process will be automated. Nirvana is the ability to perform continuous deployments.

One mechanism you can leverage is the service request catalog and the back-end automation and orchestration. Since App Dev is familiar with provisioning IT services from the catalog, you can also use the catalog as the interface for App Dev to request automated deployments of specific systems. The same automated orchestration capability used to provision IT services, can be used to automate the deployment process by taking the binary outputs from App Dev from the source control system and deploy them into specified environments, such as test, prod, and so forth.

When designing the support process for your new or changed IT service in a DevOps environment, consider a model that integrates both IT Ops and App Dev in the process. In the past, IT Ops shielded App Dev from 24×7 support. However, to reduce failure rate and improve mean time to restore, increasing the App Dev’s role in support creates accountability for App Dev to reduce the number of bugs and develop ways to restore service faster.

Service Design and Agile Software Development

The Agile methodology is characterized by multiple sprints leading to a release. In fact, with DevOps, a single sprint may result in a release. App Dev teams maintain a backlog of stories—a way of describing requirements. It is important to note that the Agile approach is particularly useful when the requirements are not fully known at the start of the project. The implications to service design is that you cannot expect the waterfall approach of having all the requirements upfront and then build the IT infrastructure to satisfy the supposedly stable requirements. The very nature of the Agile approach means that requirements will be discovered or evolve over time. You need to plan and design with the assumption that requirements will change.

This has interesting implications on how infrastructure or supporting services are designed. IT has generally focused on the initial provisioning process when establishing its private cloud services. However, if we know requirements change, we should also invest effort into “day 2” activities, for example, making it easy to expand compute, memory, storage, or change network and security controls sometime after the initial provisioning. Hence, your catalog should not just be an entry point for provisioning requests; it also needs to be the entry point for change requests, continuous deployment requests (as I discussed with regards to DevOps), and retirement requests.

Service Design and Cloud Computing

Cloud computing can be a model for how to deliver business-facing IT services, software as a service (SaaS), or a way to deliver infrastructure and supporting services or infrastructure as a service (IaaS), and platform as a service (PaaS). Cloud-based services have certain characteristics that distinguish them from traditional IT services:

  • Self-service: The customer can easily request the service through a portal.
  • On-demand: Instantly deliver the service when it is requested.
  • Elastic capacity:  Dynamically provision more resources (and release those resources when they are no longer required) based on fluctuation in demand.
  • Highly available and resiliency: When the underlying infrastructure components suffer an outage, the service is architected in such a way that it is still available to the customer.
  • Pay as you go: The cost of the service is linked to the amount of the service that is consumed. This allows the business to make return on investment (ROI) decisions on how much of the service to consume. Contrast this to a cost allocation model for IT, where the business has no incentive to self-manage their demand of IT.

When designing an IT service, whether it is an IaaS, PaaS, or a business-facing service that sits on top of IaaS or PaaS, you should address these cloud characteristics.

cloud tableAnother aspect of service design is “Where is the service going to be hosted?” —in the private cloud, the hybrid cloud, or the public cloud?  The answer may not be straightforward. You may want to pilot the service in the public cloud and then when it grows, bring it back into the private cloud in order to manage costs. Or you may have a service hosted in the private cloud but have the ability to burst into the hybrid cloud to handle peaks in demand. These design decisions impact how App Dev might build the application. For example, if an application starts in the public cloud but may be migrated into the private cloud in the future, App Dev cannot use the public cloud provider’s proprietary technologies, such as an AWS NoSQL database, that isn’t available internally.

Service Design and Becoming a Service Broker

If your internal customers or lines of business are using shadow IT—external IT service providers—in order to meet their time to market requirements, instead of taking an adversarial position against using those external cloud services, your IT department should embrace these vendors and leverage the value that they can provide. IT must become a service broker, helping your IT service consumers select the most appropriate platform for the service they require, whether it is private, hybrid, or public.

A service broker is more than just the ability to show VMware vCloud Air, AWS, or Azure services in your catalog. In fact, showing all the offerings and options from these vendors could become confusing to your customer. Instead, the catalog should ask questions about the requirements, such as:

  • Is the environment for dev, test, or prod?
  • Will the environment store any confidential information, such as PII (personal identifying information), HIPAA, and similar?
  • Does the environment need to adhere to certain levels of compliance such as SOX, PCI?
  • What service levels do you need?

And the based on the answers, automatically provision the environment into the right cloud—private, hybrid, or public—through the automatic enforcement of policies, as shown below.

Figure 1: Service broker—providing the service regardless of where it resides

Figure 1: Service broker—providing the service regardless of where it resides

Becoming a service broker raises some interesting questions:

  • Does supplier management need to be matured in order to manage the cloud providers better and ensure they are meeting their service-level obligations?
  • How does IT provide a seamless user experience regardless of the underlying cloud provider?  How do you make the user perceive the private, hybrid, and public cloud as “one cloud”?
  • What is the support model—for example, are there hand-off points between IT and the cloud vendor?  How do you get visibility into the full incident lifecycle as it moves from IT to the cloud vendor?

Where Do You Start?

I’ve introduced how service design needs to change in order to take advantage of DevOps, Agile, cloud, and the service broker model. The next question to answer is: “How do I transform IT so that our services are designed differently?”  Here are some suggestions:

  • Build momentum and support—First, you need to educate stakeholders on what the vision of success will look like, the problems that this “new IT” will solve, and the value that this “new IT” will deliver. This article is a good starting point but you will need to give presentations, conduct workshops, and continue to provide information to stakeholders on where the IT industry is going.
  • Establish new roles—As part of the transformation, you will need to establish new roles such as service architect, service developer, automation engineer, and so forth. And it’s not sufficient just to define their responsibilities. You also need to give the people in these new roles the training and enablement to be successful.
  • Pilot the new service design model—It may be easier starting with industry-recognized services to demonstrate how the new operating model will work end to end, such as establish IaaS or PaaS an exemplar of the new way of delivering services.
  • Think “service lifecycle”—Traditional IT is project-based. Infrastructure is built in response to specific application projects. In a service lifecycle approach, the infrastructure services are designed and built outside the context of a specific application project. Once the infrastructure service is available, application projects then request the infrastructure service as needed. This challenges the way you fund the infrastructure, as the initial creation of the infrastructure service is not tied to the business justification of the application project.
    ITIL presents a service lifecycle, but it does not going into depth regarding the specific activities in each stage of the lifecycle (instead, it focuses on the service management processes in each stage). Your organization will need to develop a methodology that defines the specific activities within the service lifecycle.

Next, you will need to tie together the new roles and the new activities from the service lifecycle. Again, a high-level example is provided below.

Figure 2: Service lifecycle example

Figure 2: Service lifecycle example

Conclusion

I’ve described how service design needs to change to take advantage of the innovations brought about through DevOps, Agile, and cloud, along with tips on how to become a service broker. And, I’ve given pointers on where to start your transformation journey. Ultimately, this transformation will help your IT organization deliver at the speed of business, resulting in exploiting business revenue opportunities earlier or realizing business cost savings sooner.

====
Reginald Lo is Director of Service Management Transformation with VMware Accelerate Advisory Services and is based in California.


[1] Gartner, Inc., “2014 Service Transition Survey”

[2] IDG Research Services , “Dual Perspectives on ITaaS:  The World According to IT and Business”

Approval Policies: It’s All About the People

By David Crane

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

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

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

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

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

 

Approval Policy-Crane

 

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

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

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

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

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

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

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

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

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

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

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

Green vs. Grey: Rethinking Your IT Operations

By Neil Mitchell

Neil Mitchell-cropMany of the customers I work with wish, at least in the short term, to provide IT services internally rather than outsource. They are also considering introducing cloud services as a catalyst for transitioning away from traditional IT practices—to establish new practices and processes appropriate for effective and efficient cloud service delivery. They also recognise that this will require a fundamental shift in their approach and that they will need to modify their operating model and organisation structure to support this.

Picture the scenario: an existing IT organisation that has built up over many years; is delivering services and may follow traditional good practice frameworks such as ITIL. However, chances are that the organization is not optimised for the delivery of cloud services—it’s probably siloed, may have developed many poor and labour-intensive practices along the way, and may not be perceived to deliver value. Sound familiar?

An option therefore is to re-invent IT. Create a new greenfield IT organisation with no legacy constraints. Can it be done? Of course, anything is theoretically possible. But is it realistic? What are the challenges?

Let’s make some assumptions for this new greenfield organisation:

  • New staff can be recruited—it won’t be necessary to transition staff from the old organisation.
  • There is the opportunity to establish new, optimised processes across the new organisation.
  • There will be no need to share information or systems between the old and the new organisations.
  • The new organisation can share the current data centres.

I break the challenges around this outwardly simple greenfield goal into two primary areas: 1) organisational, and 2) process and technology. And in my experience, there can be more questions than answers. However, I encourage my clients to address these issues before establishing what may be unachievable strategies.

1. Organisational challenges.

With any programme of change such as will be triggered by the introduction of cloud services, cultural change is the greatest challenge. You can argue that introducing a new greenfield organisation will overcome this—so let’s take a closer look.

Firstly staffing. Your old IT organisation will not disappear overnight. You would be introducing a new parallel or shadow organisation. Do you transition staff across or recruit from scratch?  If you transition staff, legacy practices and behaviours will almost certainly migrate. Equally, if you do not transition staff, good practices may be lost. If you recruit from scratch then there is overall induction to the organisation and associated training to be considered—with inherent hidden costs, not to mention any additional employment obligations that come with recruiting. There may also be HR implications for the existing staff. New staff does not necessarily mean a new culture and better behaviours.

You will also need to determine if you can use contractors, either as an interim to help establish the new cloud organisation or to backfill the existing one. Either is an option, but be aware that contractors may have a different objective from what is necessarily in the best interests of the company. You will need to expend effort to ensure that you obtain well-qualified and professional contractors who would be an asset to your company in establishing the cloud organisation.

Any of these options will create a bigger IT organisation—at least in the short term—for which you must budget.

Secondly organisation structure. Should the new cloud organisation work within the existing organisation? Keeping it within the existing organisation structure runs the risk of undue influence by the “we’ve always done it this way” crowd so may not be truly greenfield. If a separate organisation or department, you will need also to determine whether to replicate management and back-office functions such as HR, Procurement, and IT Finance.

Another consideration is whether the new organisation is to be in a new location or within an existing site.  A new location certainly works from an isolation perspective and will reduce risk of migrating legacy practices, but you may also lose the positive benefits of interaction with the existing staff.

2. Process and technology challenges.  

Let’s start with the new cloud architecture and whether it will be stand-alone. Consider possible components: operating system, middleware, monitoring agents, and even application components. There may be corporate standards and configurations to be followed, which will need to be reviewed to ensure they are fit for purpose in the new environment. And, whether you set up a shadow support organisation or take advantage of existing expertise is yet another consideration.

Security, risk, and compliance concerns must also be addressed early on, as the new IT organisation will likely have to interact with the existing business to ensure the delivered services meet any regulatory or legal requirements. Your new IT organisation will not be thanked for delivering services that brought in unwelcome regulatory investigations!

IT service management brings up numerous considerations including whether to:

  • Create a parallel service desk vs. modify process and procedures for the existing service desk
  • Retain the single number your customer calls today vs. provide access to all new cloud services solely online via a service catalogue
  • Implement new parallel processes and even new systems for event, incident, problem, and change management vs. modify existing ones to account for a cloud-optimized approach

Correct provision of cloud services will introduce a major increase in policy-based automation and standardisation and result in opportunities for you to optimize operations, but not in isolation from the higher-level service management context.

Is a greenfield organisation really a practical option for you? It may be as an aspiration, but if you’re like most of the IT executives I work with, the reality is a little more grey.

Org for Cloud wpSo where to start?

VMware has built some of the largest and most successful public and private clouds in the world, and we thoroughly understand the opportunities and the challenges. My recommendation to you as a starting point—my colleague Kevin Lees, Principal Architect for VMware’s global Operations Transformation Practice, recently updated his white paper, Organizing for the Cloud. The paper looks at the organisational impacts of transformation from multiple perspectives and provides insights and advice about how to prepare for—and execute—your winning transformation strategy.

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

Why Service Owners Are Integral to IT-as-a-Service Delivery

By Kai Holthaus

kai_holthaus-cropThe Service Owner Role

The service owner role is central for an IT organization that is operating IT as a service (ITaaS). Why? Because the service owner is accountable for delivering services to customers and users, and accountabilities include:

  • To act as prime customer contact for all service-related enquiries and issues
  • To ensure that the ongoing service delivery and support meet agreed customer requirements
  • To identify opportunities for service improvements, discuss with the customer, and raise the request for change (RFC) for assessment if appropriate
  • To liaise with the appropriate process owners throughout the service management lifecycle
  • To solicit required data, statistics and reports for analysis, and to facilitate effective service monitoring and performance
  • To be accountable to the IT director or service management director for the delivery of the service

Please note that I emphasize  “accountability” instead of “responsibility.” The service owner is accountable, meaning they set the goals and oversee the execution.  The actual execution is performed by individuals or functions that have the “responsibility” for each activity.

Let’s take a closer look…

The service owner is the main escalation point for all service-related compliments, complaints, and other issues. You can think of the service owner as a sports coach, directing how the team should play a particular game, but not really participating by playing in the game. As the coach is accountable to the team’s owner for the team’s success, so is the service owner accountable to the customer(s) and the service management director for ongoing quality of the service.

Responsibilities Throughout the Service Lifecycle

The service owner role has accountabilities in each of the five lifecycle stages, as defined by ITIL:

  • Service strategy
  • Service design
  • Service transition
  • Service operation
  • Continual service improvement

I recommend to my clients that they assign a service owner very early in the lifecycle, so that there is a single point of accountability throughout its creation and life.  If we compare this to the product world, a service owner is like a product manager at an automotive company who is accountable as the new car model is designed, developed, and built—and ultimately for the satisfaction of the car’s buyers.

Shifting to an ITaaS Model

While the idea of the service owner role is just as valid in an ITaaS world as it is in a more traditional IT service provider world, there are a few important differences.

Service Owners Must Enable a Faster Time to Market
Moving to an ITaaS model typically requires faster development and release cycles than in a more traditional model. This is usually accomplished by moving to an Agile development model, such as Scrum. Using such models means that the full set of requirements for a service to be released will not be available at the time when development starts. Instead, development begins with the best set of requirements available at the time, and relying on future development / release cycles to address missing requirements.

The certainty of receiving a fully defined set of utility and warranty of a service is being exchanged for more rapid improvement of the service. Service design and transition activities are executed more in a spiral-type model than in a waterfall-type approach.

The service owner in an Agile environment becomes the Scrum product manager, representing the view of the customer in the Scrum model. As the product manager, the service owner is responsible for the pipeline of customer requirements driving the development of the service.  Business decisions on whether to advance the service through another round of development and release is based on the available information at the time.

Service Owners Need a Better Grasp on Future Demand
Some services, particularly infrastructure services, such as providing CPU power or storage, become utility-type services, comparable with the utility services everybody experiences at home, such as electrical power, natural gas, or water. Instead of provisioning dedicated infrastructure at the time of service development or deployment, the service owners must ensure there is enough capacity when needed, e.g., storage should be available instantly available when required— similar to water flowing immediately when you turn on the faucet at home. This requires a much better understanding of future demand, patterns of business activity, and user profiles than is typically the case today.

Service Owners Will Give up Some Control to Enable Automation
Due to the nature of ITaaS, service owners will be required to give up some control over the configuration of the service. For example, automation tools already move virtual machines from one physical host to another based on current workloads, without any human control. To fully deliver on the ITaaS promise, this type of automation must increase. Increased automation will require either defining more changes as standard changes, which can be implemented without approval (and in this case, automatically, after the tool has recorded the change), or give up change control completely, and let the tools handle them. Such automation tools can also automatically update the configuration management system, so that valid information will always be available.

How Will Services Operate in the Cloud?
While today’s services are largely delivered from in-house data centers, the ITaaS model makes full use of hybrid and public clouds.  Service owners must understand the ramifications of moving parts of the service infrastructure (or even the entire infrastructure) into the public cloud. This requires a better understanding of required service levels, and what will happen if cloud providers experience incidents or even disasters.

To conclude, the specific accountabilities associated with the service owner role don’t change dramatically when an IT organization moves to an ITaaS model. Primarily, a service owner will need to shift from defining architectures and infrastructure as part of the service design to defining the service in terms of requirements, and necessary service levels for supporting services. Also, traditional controls over the infrastructure may no longer apply when automation is used to fully deliver on the promise of ITaaS.

While the shift in the service owner’s responsibilities isn’t dramatic when transforming to an ITaaS model, the importance of the role grows significantly.  If you haven’t already explored implementing or expanding this role as you transform to deliver ITaaS, be sure to include this as part of your roadmap for moving forward.

=====
Kai Holthaus is a senior transformation consultant with VMware Accelerate Transformation Services and is based in Oregon.

The Cloud Architect: Change Champion for the New IT

By Rohan Kalra

RohanKalra-crop“What direction should I take my career with all the changes happening in IT?”

I get this question a lot when working with my clients’ IT teams. The old way of doing things needs to change for the new IT. From an IT operating model standpoint, that means becoming more service-focused. And that’s not all that’s changing—roles within the IT organization are, too.

As practitioners, we need to adapt. For me, it’s always much more fun to be the change champion, imagining how things could be done differently and in completely new ways, than to get left behind in the old world.

I discuss adapting to be a cloud architect in this short video below. There’s also an infographic that ran earlier in this blog that you might be interested in—The Forecast Is Sunny for Cloud Careers—with stats on what’s driving demand for IT professionals with cloud-related skills.

I’d be interested in hearing from you—@kalrarohan.

======
Rohan Kalra is an operations architect with the VMware Operations Transformation global practice. Follow him on Twitter @kalrarohan

 

4 Steps to Better Market Your Cloud Services

By Alberto Martinez

Alberto Martinez-cropSuccessful cloud providers invest in marketing their services: promoting them, showing the value to customers, implementing strong pricing campaigns—and they understand how to rapidly adapt to changing market demands. But what prevents your internal IT organization from defining an effective marketing strategy to be more competitive and foster your cloud investments? And more importantly, how should you approach this effort to ensure success?

When moving to a cloud environment, most of the IT organizations that I work with focus on defining processes such as provisioning, support, or capacity, but forget about how to market the services they will be delivering and communicate their value to their customers. The same IT organizations end up with a private cloud infrastructure without clear target customers or, even worse, their cloud services are not used by the lines of business, resulting in a poor return on investment (ROI).

To realize the full ROI that enterprises are looking for from their cloud investments, the IT organization needs to drive the uptake of those services and persuade the lines of business away from using external service providers (shadow IT) or alternative legacy internal service provision options.

In order to mitigate those situations and increase their integration with the business, I advise my clients to define a consistent approach—as outlined below—to market their (internal or external) cloud services.

Defining Your Cloud Services Marketing Strategy
The approach to defining a cloud service marketing strategy must be innovative and not follow the traditional approaches. You need to apply a special focus on your customers in order to build a stronger relationship between your IT organization and the lines of business. That innovative approach has to contain similar characteristics as those of your cloud environment —simple and agile while powerful and impactful.

Below are four steps your IT organization can follow when defining a cloud services marketing strategy:

4 steps

  1. Define a service marketing strategy. As an essential initial activity, the key elements of the marketing strategy have to be defined with your CIO and leverage the expertise of your CMO and his/her marketing organization (experience, models, tools, and so forth). Those elements include market research, branding, pricing, differentiation, and competition.
  2. Create a communications plan. As my colleague Alex Salicrup wrote recently in this blog, communication is the key pillar to a successful IT provider. Define an effective communications plan for your cloud that will communicate its unique value to your customers and why they have to believe that differentiation is real (“reason to believe”). Your plan must define at a minimum what information will be communicated, how it will be communicated, as well as when it will be distributed and to which audience. Always keep in mind to exclude any technical information from the marketing materials.
  3. Develop marketing campaigns. One mechanism to create new favorable consumer perceptions of your cloud services is the marketing campaign. When developing tailored campaigns, you must identify what you are expecting from the campaign, what your customers can expect, what the impact will be on the audience, and how you will measure success. Measuring the success of your marketing campaigns is key to knowing the impact they had on your targeted audience.
  4. Measure. Benchmark your cloud environment against your competition, and set achievable actions to improve the value to business (always provide the best to your customers!).

Bridging the Gap Between the Cloud and Marketing Organizations

Establishing an IT services marketing capability is not just about defining the above steps—it’s also about your people in your organization and how they will execute upon those activities. To be successful, you need a strong integration between your IT organization and the marketing organization at two levels:

  1. Executive level: While defining the marketing strategy for your cloud environment, both your CIO and CMO have to work in tandem to ensure consistency with the business strategy. This will lead to the cloud services vision or value proposition, its unique value including differentiating factors, and the four steps previously described.
  2. Departmental lead/individual contributor level: Once you have defined your strategy, your IT organization—through cloud tenant operations—will have to work together with at a minimum two teams: 1) the marketing communications team to execute your cloud services communications plan, and 2) with the field marketing team to develop the marketing campaigns and success measurements.

Bridging the gap between the IT and marketing organizations will encourage an open environment of collaboration. I recommend to assign champions to integrate both areas, whose responsibility will be to support the promotion of the cloud services whilst leveraging the IT organization´s functions and expertise.

In summary, an effective cloud services marketing strategy promotes the value of your services and drives the adoption of those services within the lines of business. Start your effort early and with a consistent approach, so you can compete effectively against other cloud providers and achieve the ROI the business is looking for from its cloud investments.

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

How to Take Charge of Incident Ticket Ping Pong

By Pierre Moncassin

Pierre Moncassin-cropWhen incident tickets are repeatedly passed from one support team to another, I like to describe it as a “ping pong” situation. Most often this is not a lack of accountability or skills within individual teams. Each team genuinely fails to see the incident as relevant to their technical silo. They each feel perfectly legitimate in either assigning the ticket to another team, or even assigning it back to the team they took it from.

And the ping pong game continues.

Unfortunately for the end user, the incident is not resolved whilst the reassignments continue. The situation can easily escalate into SLA breaches, financial penalties, and certainly disgruntled end users.

How can you prevent such situations? IT service management (ITSM) has been around for a long while, and there are known mitigations to handle these situations. Good ITSM practice would dictate some type of built-in mechanisms to prevent incidents being passed back and forth. For example:

  • Define end-to-end SLAs for incident resolution (not just KPIs for each resolution team), and make each team aware of these SLAs.
  • Configure the service desk tool to escalate automatically (and issue alerts) after a number of reassignments, so that management becomes quickly aware of the situation.
  • Include cross-functional resolution teams as part of the resolution process (as is often done for major incident situations).

In my opinion there is a drawback to these approaches—they take time and effort to put in place; incidents may still fall through the cracks. But with a cloud management platform like VMware vRealize Suite, you can take prevention to another level.

A core reason for ping pong situations often lies in the team’s inability to pinpoint the root cause of the incident. VMware vRealize Operations Manager (formerly known as vCenter Operations Manager) provides increased visibility into the root cause, through root cause analysis capabilities. Going one step further, vRealize Operations Manager gives advance warning on impending incidents—thanks to its analytical capabilities. In the most efficient scenario, support teams are warned of the impending incident and its cause, well ahead of the incident being raised. Most of the time, the incident ping pong game should never start.

Takeaways:

  • Build a solid foundation with the classic ITSM approaches based on SLAs and assignment rules.
  • Leverage proactive resolution, and take advantage of enhanced root cause analysis that vRealize Operations Manager offers via automation to reduce time wasted on incident resolution.


Pierre Moncassin is an operations architect with the VMware Operations Transformation global practice and is based in Taipei. Follow @VMwareCloudOps on Twitter for future updates.

 

4 Ways to Maximize the Value of VMware vRealize Operations Manager

By Rich Benoit

Benoit-cropWhen installing an enterprise IT solution like VMware vRealize Operations Manager (formerly vCenter Operations Manager), supporting the technology implementation with people and process changes is paramount to your organization’s success.

We all have to think about impacts beyond the technology any time we make a change to our systems, but enterprise products require more planning than most. Take, for example, the difference between installing VMware vSphere compared to an enterprise product. The users affected by vSphere generally sit in one organization, the toolset is fairly simple, little to no training is required, and time from installation to extracting value is a matter of days. Extend this thinking to enterprise products and you have many more users and groups affected, a much more complex toolset, training required for most users, and weeks or months from deployment to extracting real value from the product. Breaking it down like this, it’s easy to see the need to address supporting teams and processes to maximize value.

Here’s a recent example from a technology client I worked with that is very typical of customers I talk to. Management felt they were getting very little value from vRealize Operations Manager. Here’s what I learned:

  • Application dashboards in vRealize Operations Manager were not being used (despite extensive custom development).
  • The only team using the tool was virtual infrastructure (very typical).
  • They had not defined roles or processes to enable the technology to be successful. outside of the virtual infrastructure team.
  • There was no training or documentation for ongoing operations.
  • The customer was not enabled to maintain or expand the tool or its content.

My recommendations were as follows, and this goes for anyone implementing vRealize Operations Manager:

  1. Establish ongoing training and documentation for all users.
  2. Establish an analyst role to define, measure and report on processes and effectiveness related to vRealize Operations Manager and to also establish relationships with potential users and process areas of vRealize Operations Manager content.
  3. Establish a developer role to create and modify content based on the analyst’s collected requirements and fully leverage the extensive functionality vRealize Operations Manager provides.
  4. Establish an architecture board to coordinate an overall enterprise management approach, including vRealize Operations Manager.

The key takeaway here: IT transformation isn’t a plug-and-play proposition, and technology alone isn’t enough to make it happen. This applies especially to a potentially enterprise-level tool like vRealize Operations Manager. In order to maximize value and avoid it becoming just another silo-based tool, think about the human and process factors. This way you’ll be well on the way towards true transformational success for your enterprise.

—-
Rich Benoit is an Operations Architect with the VMware Operations Transformation global practice.