Home > Blogs > VMware Operations Transformation Services > Tag Archives: “cloud operations”

Tag Archives: “cloud operations”

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.

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.

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

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.

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

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.