Home > Blogs > VMware CloudOps

Key People, Process and Policy Considerations for vRealize Automation Success

Keng-Leong-Choong-cropBy Choong Keng Leong

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

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

Key Players

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

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

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

Service Models

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

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

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

Request Models

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

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

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

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

Access and Entitlement Management

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

Communication and Awareness

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

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

5 Steps to Building Your High-Performance Cloud Organization

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

Pierre Moncassin-cropBy Pierre Moncassin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Takeaways:

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

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

The Business Case for Cloud Automation

Automating in the Cloud Pays Off

Top 5 Tips for Marketing Your Cloud Services

By Alberto Martinez

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

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

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

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

When to Engage Your Organization in Their Cloud Journey

By Yohanna Emkies

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VMware vRealize Code Stream: Is DevOps Tools or Transformation?

By Ahmed Al-Buheissi

Ahmed_croppedIn a previous blog, I wrote about the need for DevOps to rapidly release software and argued that DevOps is first and foremost about transforming operations.

The Operations and Development teams can be a roadblock to each other’s work schedule. The Development team frequently requires infrastructure and platform to test their code, while Operations does not always have the resources readily available to satisfy Developers’ requirements. This means schedules slip and releases become few and far apart, resulting in dissatisfied developers.

Since that blog, VMware released VMware vRealize Code Stream for facilitating DevOps, which I spent some time recently installing, configuring, and exploring—and I wanted to share my experience with you. Amazingly, I found that VMware’s response to DevOps is a tool that can be described in three words: automate, automate, and automate. Yes, vRealize Code Stream automates the entire software release process:

  • Infrastructure provisioning automation
  • Software build automation, and
  • Testing cycles automation

And these automation steps can be executed across all environments: Development, Testing, Staging, and Production, with the premise that automation will ensure consistency across all environments and prevent issues due to human errors. The figure below shows examples of tools used in software development, and how vRealize Code Stream integrates and automates these tools.

vRealize Code Stream SDLC

 

So is it all about the tools?
There are several tools available that will assist in implementing DevOps, including VMware vRealize Code Stream. These tools can automate and expedite the software release process, and apply the organization’s policies. But is that all there is to DevOps? As this is a new paradigm and a new way of operating, the organization will also need to transform. After all, DevOps disrupts the Software Development Lifecycle (SDLC) as we know it:

  • The process is not always linear (or circular); for example the Design phase does not always precede Implementation; sometimes the design is written as the code is being developed.
  • Testing cycles (Unit Testing, System Testing, and User Acceptance Testing) are executed concurrently, and will test only random pieces of code.

Organizations implementing DevOps must also apply operational methodologies, which will clearly define the transformation processes and document the evolving roles within the IT organization.

Why transform operations?
Even though the deployment and release processes are automated, we still need to tranform operations from both people and process perspectives, including:

  • The need to define the relationship between Operations and Development (as well as other teams). Development will depend on Operations only when creating the automation workflows, and subsequently they can release the software themselves using these scripts. Operations will focus more on automation project work, and much less on reactive day-to-day operations.
  • While the focus is on automating the release process, there is little emphasis on post-release monitoring. Developers need to have access to monitoring tools to ensure deployed software is performing adequately.

To conclude…consider these operations-related steps prior to adopting tools to implement DevOps:

  1. Determine the scope of your DevOps implementation; which teams, which applications, and which environments will be impacted.
  2. Document the process that will govern the interactions between various DevOps tasks and roles.
  3. Define the roles, for example Development, Operations, and Quality Assurance, as well as their responsibilities.

The figure below depicts the process of implementing DevOps, and steps required to roll out such environment.

DevOps Blog2_Implementation_Process_v0.1

 

Also, this short video below will provide you with high-level information about VMware vRealize Code Stream, along with technical white paper: "Releasing High Quality Applications More Quickly with vRealize Code Stream."

====
Ahmed Al-Buheissi is an operations technical architect with the VMware Operations Transformation global practice and is based in Melbourne, Australia.

Code-stream-video

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 24x7 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.