Home > Blogs > VMware Operations Transformation Services > Tag Archives: thought leadership

Tag Archives: thought leadership

Top 3 Tips for Optimizing DevOps

More collaboration is a noble goal. Make the reality match the promise.

Optimizing DevOpsThe concept of DevOps is so appealing. Who wouldn’t agree that better communication between development and operations teams will expedite release cycles, improve software quality, and make the business more agile? Just one question: why is DevOps still a “concept” at most companies rather than an operational reality? The short answer is that DevOps requires new ways of working, and that can create cultural upheaval.

Download 3 Top Tips for Optimizing DevOps from our Consultant Corner for guidance around addressing the people and process issues of DevOps in a VMware environment—so you can reap the business benefits sooner.

Rethinking IT for the Cloud, Pt. 1 – Calculating Your Cloud Service Costs

By: Khalid Hakim

So you’re the CIO of an organization and you’ve been asked to run IT like a business. What do you do?

You can start by seeing IT as a technology shop, with “services” displayed on its shelves. Each service is price-tagged, with specs printed on the back-tag. A service catalog is available for customers to pick up and request services from. Each service or set of services is managed by the “service manager/owner” role. Your IT shop would have an Income Statement (Profit-Loss P&L) and a Balance Sheet.

Think of it – in other words – as a business within a business: IT is just a smaller organization within the main business org. And where’s the value to you in that? Well, it’s because your boss is right: IT should be a business enabler, a revenue supporter, and a value creator. And because it helps you ditch your colleagues’ long-held impression that IT is nothing more than a revenue drain.

Next, you need to show exactly how your organization contributes to the success and profitability of the business. How can the CEO and CxOs further realize the value of the IT you’re supplying? How can you calculate the contribution of every dollar of investment in IT to their net income? These are just a few of the questions that you need to consider when positioning IT on a critical value path.

Cloud is Here to Help

As you look to transform IT from a passive order-taker to an IT service broker, or even to a strategic business partner, you’ll likely look to cloud computing for agility, reliability, and efficiency. Cloud can deliver all of these things, with stunning results. But this transformation cannot happen without a paradigm shift in how you operate and manage your technology.

Luckily, cloud computing embraces consumerization and commoditization and is a perfect fit for the IT shop/P&L model: Everything is expressed in terms of “services” and business value. If I could introduce a new English word, it would be “servicizing,” as in “servicizing your IT.” Part of this transformation means moving from C-bills to S-bills, that is, moving from Component level bills (e.g. an IT bill that has IT components) to Services bills, which are more clear and understandable. And to begin this process, you need to “servicize” your whole IT context.

There are multiple steps involved here, but for any of this to be worthwhile, what you do has to be justifiable within your new cost/benefit framework. So you need to start off with a true understanding of how much each and every service is costing your company.

In the remainder of this post, I’m going to suggest a few key points that will help you identify and calculate what each cloud service costs. Future blog posts in this series will address other important steps to IT transformation for the cloud, such as the importance of automating your IT cost transparency as well as a step-by-step guide to tagging costs as CAPEX and/or OPEX.

Calculating Cloud Service Costs

Step 0: Define your cloud service – I am calling this step zero because you first need to truly understand what makes up your cloud service before you can go any further. Service definition is a separate exercise and discipline whose foundations should be deeply rooted in your organization if you want to describe it as “service-oriented.” Defining a cloud service helps you see the boundaries of your service, as well as correctly understand and identify its components. And it solves one of your biggest service cost challenges, reducing the “unabsorbed costs” bucket by clearly identifying all cost components, including your service’s technology, processes and team.

Step 1: Identify direct and indirect fixed costs – With an accurate service definition, all components that contribute to your service delivery (technology, processes, and team) are now identified. This next step is to identify the direct costs that your drivers and elements contribute to your service. In addition, you’ll need to identify all indirect fixed cost drivers and apply the allocation percentage that has been agreed upon during the establishment of your service’s cost model. Your support contract is a common example of an indirect fixed cost: The cost of your support contract should be split over the number of products and calls, as previously detailed in your contract.

Step 2: Identify direct and indirect variable costs – Another challenge is dealing with your variable costs and how to allocate them to the services that depend on these costs. Much of this should have been defined in the service’s cost model, so you should apply those same policies on the identified variable-cost drivers and elements. Your monitoring tool is a great example of an indirect variable cost, as the costs need to be distributed over your fluctuating number of applications or services being monitored at any given time.

Step 3: Identify any unabsorbed costs – The “unabsorbed costs” bucket is a group of cost drivers and elements whose costs you cannot attribute to any particular service, meaning they must be attributed across all services. During the development of your service’s cost model, you need to decide how to deal with such costs. Typically, there will be a certain uplifting amount that needs to be added or allocated to each service. A good example of this would be the cost of labor (i.e. service managers) that should be distributed across all services.

Step 4: CAPEX/OPEX tag and adjust – There is no major decision-making in this step, as most of these Capex and Opex discussions should have taken place during the time you purchased your cloud service components. However, it is very important to tag each cost with a CAPEX or OPEX (or both in some cases) because that will eventually impact the way that you distribute and allocate operational or depreciated costs of each element.

Step 5: Finalize your service cost calculations – After identifying and defining all of your cost units (e.g. per User or Consumption: per GB) and metering options (e.g. hourly, weekly, monthly, etc.), finalize your service cost per cost unit calculations considering all the elements gathered in the previous steps I’ve just outlined.

In summary, when preparing your IT team for cloud computing, keep in mind the following:

  • Successfully implementing cloud computing in your company starts by changing the way you see IT (and making sure everyone on your team is aware and on-board as well).
  • It is essential to carefully and correctly define your cloud service and to keep in mind the cost model you established for your service as you do so.
  • Identifying the costs of your cloud service will let you illustrate the value of IT at your company and show how your cloud service positively impacts your business as a whole.
  • You can follow the 5-step process outlined above to ensure that you have fully identified your costs.

You may not be personally on the hook to figure all this out, but service owners/managers or someone in your IT department probably is.  So why not forward this post to folks you work with in IT, and suggest that they attend the IT Financial Management Association Conference in Savannah, Georgia next week. I’ll be hosting a workshop on Monday, July 8th at 8am on cloud IT service financial management, and on Wednesday, July 10th at 10am, I’ll be presenting an overview of cloud service financial management.

Stay tuned for the next post in this series, where I will discuss service definition in more detail. In the meantime, if you’re interested in reading more on the transformation of IT, check out these other posts:

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.

Automation – The Scripting, Orchestration, and Technology Love Triangle

By Andy Troup

In speaking with some of my customers, the message comes resoundingly across “WE WANT TO AUTOMATE.” So this is the sweet spot for cloud solutions as they have in-built automation to provide the defined benefits of cloud computing such as On-demand self service, Resource pooling and Rapid elasticity (as defined by NIST here).

However, upon scratching the surface and digging a little deeper, the other thing I’ve found is that when I’m told “yes we’ve got automation,” it typically means that a lot of effort has gone into developing a whole heap of scripts that have been written to solve a very specific problem. This, I would argue, is not the best way for automation to be achieved.

I was in conversation with a customer a few weeks ago where they wanted to automate a particular part of their provisioning process, and my recommendation to them was “DON’T DO IT.” Why did I say this? Well, the process was broken, inefficient, relied on spreadsheets & scripts and meant there was constant rework to have a satisfactorily provisioned system. Their provisioning process took weeks and weeks. There was no point in automating this broken process – what needed to happen was that the process had to be fixed or changed first. I won’t go into anymore detail about this particular problem, but my point is that sometimes you have to take a step back and see if there are other ways of solving a particular problem.

In summary – there’s no point in automating a broken process.

So, why do we want to automate our IT systems and the provisioning of them anyway? Primarily because we want two things:

  1. To take the boring repeatable activities that many IT administrators undertake and get a system to do it instead. This frees up time for the administrator to do the more interesting and difficult things.
  2. Remove the potential for errors. Anything that is done as a manual activity involving people is liable to be inconsistent and error-prone (I say liable, but really we all know that they will be inconsistent and error-prone). Cloud solutions are all based on the premise that everything is standardized, and thus we need to remove any activity that introduces unreliability.

OK, so we’ve now established that automation is a good thing. All we need to do now is work out HOW we’re going to automate, and this may introduce some difficult decisions.

So what are the automation options? Well, in my mind automation comes in three different flavours which should be used together to solve the automation challenge. Here they are with some definitions I found:

  1. Script – programs written for a special runtime environment that can interpret and automate the execution of tasks which could alternatively be executed one-by-one by a human operator. (http://en.wikipedia.org/wiki/Script_(computing))
  2. Orchestration – describes the automated arrangement, coordination, and management of complex computer systems, middleware, and services. (http://en.wikipedia.org/wiki/Orchestration_(computing))
  3. Policy – Policy-based management is an administrative approach that is used to simplify the management of a given endeavor by establishing policies to deal with situations that are likely to occur. (http://whatis.techtarget.com/definition/policy-based-management)

In terms of their use, the image below shows how I believe they should be used and in what quantities. As you can see, we should be aiming for as much policy implementation as possible with as little script as we can achieve.

If you have a process you’d like to automate, to find the solution, you should work up the pyramid from the bottom.

So the first question you should ask yourself is “can I create a policy or several policies to solve the problem?” This will have a dependency on the technology available to utilize the policy, but should be the first port of call. It may even be worth considering investing in the technology to make the policy implementation possible. The overhead of creating and maintaining policies are small and they will provide a robust solution to your problem with reliability and consistency.

If it isn’t possible to create a policy to solve the challenge, next consider orchestrating a solution. This will provide a reusable, standardized capability that has an element of management/maintenance overhead and will be reliable.

Finally, if neither policy nor orchestration will work for you, then utilize scripting as a last resort. Why a last resort? Scripting is a tactical, bespoke solution for a specific requirement and will require managing and maintenance during its entire life, which in turn will incur costs and will be less reliable.

So in summary, when you are considering automating a process:

  • Step back from the automation challenge and consider the options. They may not be what you expected.
  • Work up the “Love Triangle” from the bottom.
  • If you can’t implement a policy, consider orchestration and use scripting as a last resort.

For more great insight on automation, see our previous posts highlighting automation economics and IT automation roles.

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.

The Cloud Service Initiation Process – In Four Acts

By Andy Troup and David Crane

Business users’ demands on IT are fairly constant – as is the tension between the two. The business wants to do things quickly and cost effectively so that they have a competitive advantage. IT, meanwhile, wants to maintain control and proceed carefully to ensure security, performance, and service quality – which are table stakes for running IT.

The goal of IT as a cloud provider is much the same: to meet the business requirements in as efficient a manner as possible while still maintaining the control it needs. This way, the business user (now known as the cloud customer) gains the trust of the cloud provider and has no motivation to bypass IT and take on 3rd party “shadow IT” cloud implementations (i.e. removing its “IT overhead”, but leaving no control or policies in place).

So far, so good. But how do you get there? This post details a process for service initiation that, based on our experience with a variety of customers, allows IT to offer the business the services it needs without it having to resort to playing in the shadows.

Think of the process as a (hopefully, not too dramatic!) story in four acts.

Act 1- Outlining the Service

First, of course, you need to define the services you will deliver.

Just to be clear, by ‘service’ we’re referring to the creation of something that will ultimately be offered from within a portal and that end users will then be able to deploy. So when a business user has a requirement for a new service, it’s the responsibility of the customer relationship manager to have the conversation with them to understand exactly why (from a business point of view) the service is required, and what the service will look like when it’s been implemented.

The customer relationship manager (as we’re defining the role) will document this information in a service proposal, detailing things such as business benefits, financial benefits & costs, risks, organizational considerations, service overview, high level service requirements and high level functional & non-functional requirements.

Act 2 – Enter the Service Portfolio Manager

On completion, this proposal & business justification is handed off to the service portfolio manager for review. This is essential, because the service portfolio manager is in the unique position of having a full overview of the current portfolio of cloud services – including services that are in the pipeline (i.e. either being built, or planned to be built), services that are currently live and are being offered from the cloud service catalog for customers to deploy, and services that are no longer required and that have been retired.

Additionally, if the organization is of a reasonable size, it is very possible that a number of customer relationship mangers, each with their own set of cloud customers, are documenting and passing on their own ideas for new services to the same service portfolio manager . The service portfolio manager, then, is uniquely positioned to view all the new services that are being requested from all the cloud customers, and thus notice those with similar requirements that could be combined into a single service offering.

So now the service portfolio manager has:

  • The service proposal & business justification,
  • Knowledge of the current portfolio of cloud services
  • Knowledge of other requested cloud services

That means he or she is now in an excellent position to make a decision on the service proposal.

It’s quite likely that service portfolio managers won’t make that decision in isolation (although they may). They may seek advice from different individuals depending on the service proposal, its requirements and any potential impact on the cloud implementation (it may have huge capacity requirements for example). There could also be executive sponsors to consult, business unit managers, the tenant operations leader, a project stakeholder board, etc.

Act 3 – The Assessment and its Aftermath

Now, though, comes the assessment. For that, we’ve established that the service portfolio manager needs to look at 3 considerations:

  1. Does the business justification stack up, and does the service portfolio manager think the benefits detailed will be realised?
  2. Does the service portfolio manager think the service requirements can be fulfilled by the cloud implementation they are managing the portfolio for?
  3. What is the demand for the service, both today and in the future, and does this demand warrant providing the service?

When the decision is made, if the service proposal is rejected, then the customer relationship manager will need to inform the customer and work with them to decide whether to move on, or review and update the proposal.

What they decide will likely depend on the feedback provided by the service portfolio manager as to why the proposal was rejected. For example, if the business case doesn’t stack up, then the service may be dropped. But if there are specific requirements that couldn’t be fulfilled, then a decision may be made to adjust the requirements so they can be satisfied.

If the service portfolio manager approves the service, the next decision to make is whether the service is required now, or whether this is a service for the future. Future services, like those that depend on future cloud capabilities, are placed into the service portfolio pipeline until the service needs to be created. This service portfolio pipeline now becomes your road map of cloud services and will develop in maturity, providing you with a good view of how the cloud services will change over time.

Act 4 – Assigning the Service Owner

The final act in the cloud service initiation process is to assign a service owner for services that are approved and that are required now. The tenant operations leader assigns the service owner to the service, and from that point forward the service owner is responsible for the overall life cycle of the service from definition to creation, to release to maintenance, to retirement and all points in between.

To recap, here are the four steps to service initiation:

  • Outline the service
  • Hand off to the Service Portfolio Manager
  • Do the assessment
  • (If it’s a go), assign the service owner

Stay tuned for the sequel, where Khalid Hakim will start discussing how best to approach defining your cloud services.

For more information, see the related webcast by David Crane and Kurt Milne, Service Initiation: Understanding the People and Process Behind the Portal.

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.

Note: This blog uses the roles that are part of the Tenant Operations organization as described in the VMware white paper, Organizing for the Cloud.

Workload Assessment for Cloud Migration, Part 1: Identifying and Analyzing Your Workloads

By: Andy Troup

Conducting a thorough workload analysis can make or break the success of a cloud strategy.

If you are successful with assessing workloads and placing them in the appropriate private, hybrid and public cloud environments, then this will help you fulfill your cloud strategy, thus helping you enable greater agility and cost efficiency. If your assessment is unsuccessful, then these benefits will be much harder to achieve and you could see higher costs, lower performance and unhappy customers.  Remember, success breeds success, so if you have happy customers who are realizing the benefits of your cloud implementation, others will be knocking at your door. If you are unsuccessful, the pipeline of customers will very rapidly dry up.

In this four-part series, I’ll explain four main considerations that you should examine when performing a workload assessment. In this blog, I’ll suggest a framework to use to classify workloads as potential candidates for moving to a cloud environment. My next three blog posts in this series will cover service portfolio mapping, analyzing the cost and benefits of moving to the cloud, and last but not least, stakeholder analysis.

Common Questions

When assessing workloads to identify candidates, I often find myself asking:

  • What criteria should be considered when determining what workloads are a good fit for a new cloud environment?
  • What is the best way to capture and evaluate the criteria with minimal effort and impact on a busy IT department?

A thoughtful and efficient workload assessment framework can simplify and streamline the analysis. Without the right methodology, it can be difficult to know where to start, let alone where to finish. The larger the number of workloads, the more complex the prioritization task becomes.

Here are common considerations and requirements that factor into a potential migration:

Business Impact:

  1. Take a look at the workload and evaluate its impact on your business. Is it a business critical workload? How does it affect and impact your company? Take the answer to this question and assess it against where you are on your cloud journey. You wouldn’t want to move mission critical workloads in to your cloud during your first days after “go live” would you?
  2. For which application lifecycle phase will the workload be used (for example, development, test or production)? What are the different requirements for each environment?

Application Architecture:

  1. Is the application written for cloud environment? If not, make sure you understand the impact of migrating it into the cloud.
  2. How hard/expensive is it to refactor the application for new environment e.g. do you need to remove hard coded resource paths? What are the scaling considerations, can you already horizontally scale to add capacity by adding instances or can you only scaling up by adding more resource to a single instance?

Technical Aspects:

  1. What operating systems, databases or application servers are being consumed or provided and how hard will it be to also migrate them into the cloud?
  2. Do your database, application server and web server run on the same type of platform?
  1. What quantity of CPU, memory, network and storage are typically used/needed? Can your cloud implementation support this?
  2. What commercial and custom software support the workload?
  3. What are the dependencies or integration touch points with other workloads?

Non-Functional Requirements:

  1. What are the required service levels, performance, capacity, transaction rates and response time? Again, can your cloud implementation support this?
  2. What are the supporting service requirements?  Backup, HA/DR, security or performance monitoring?  Are specific monitoring or security agents required?
  3. Are there encryption, isolation or other types of security and regulatory compliance requirements?

Support & Costs:

  1. What are the support resources and cost for a given workload? For example, two full-time equivalent employees per server – how much does this resource cost?  Also, don’t forget licensing, how does the software vendor deal with cloud implementations of their software and what are the cost implications?
  2. What are the operational costs for space, power, cooling and so on? What will be saved by migration?

One thing remains through all of this – the benefits of moving these workloads must always outweigh the costs and the risks.

To get started on the journey of migrating your workloads to the cloud, remember these takeaways:

  • Always think about how your workload directly affects your company. With a thorough review of each of your workloads, you’ll know what changes to anticipate when you begin the migration process.
  • Make sure you’re thinking in the cloud mindset. Before beginning the migration process, make sure your applications are cloud-ready. If they aren’t already, make sure you have the proper strategy in place to bring them up to cloud-ready speed.
  • Be prepared. Not only do your employees need to know about these changes, but make sure your cloud implementation is prepared for the capacity (including cost) it will take your company to migrate to the cloud.

Check out our list of great blogs on workload migration and stay tuned for Part 2 of this series, where we’ll look at service portfolio mapping and how to determine the target cloud service and deployment model for each candidate workload.

Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.