Home > Blogs > VMware Operations Transformation Services > Tag Archives: kai holthaus

Tag Archives: kai holthaus

Cloud Services Definition

Part 3 of the Cloud Business Management Series

By Khalid Hakim, Kai Holthaus and Bill Irvine

Services DefinitionIn our last cloud operations business transformation blog, we talked about the cloud business strategy and its importance in formulating the vision and the plan as to how you want to run your cloud as a business. In today’s blog, the focus begins to shift to executing the strategy and laying out the foundations of a service-oriented and business-driven “operating model”.

There is a saying: you can’t manage what you can’t control, and you can’t control what you can’t define.  Imagine that you are planning to open a new business. The first step is to define what services/products you want to offer your consumers and what distinguishes your market value among the others. Similarly, cloud business management starts at this point. IT should identify and define what cloud services would be offered to its consumers in order to truly drive a services-oriented and value-driven organization.

Key Areas of Services Definition

VMware recommends a unique approach for defining cloud services, through which a service owner defines a 360-degree view of how the cloud services would be established, managed and delivered effectively and efficiently to meet or exceed the expected value. To paint this panoramic view, cloud service owners should consider the following areas:

  • Service Overview – describe the service in terms of its purpose, goals, consumers, criticality, availability criteria and rhythm of business.
  • Virtual Service Team – organize your team members around the services you deliver. Team up as a virtual service team.
  • Services Definition ChartService Chart – map out the end-to-end cloud service in a graphical representation that is easy to consume. The service chart helps to visually understand the core components of a service and contributes when costing services.
  • Service Portfolio and Consumer Management – the service portfolio answers the questions, who are our customers and why should they buy the service from us. It contains all of the service categories and the business units that consume them and aids with making informed “service” and “business” based investment decisions.
  • Service Design and Development – provide high level information about how the services will be designed and developed, especially if the service isn’t yet in production. This helps with understanding the customer business need and developing the most valuable solution possible.
  • Service Catalog Management – identify service catalog structure parameters and possible blueprints. Also, define what columns or key fields should be included in service catalog entries.
  • Service Level Management – define key SLA/OLA targets to ensure provisioning time and quality meets specific business needs.
  • Service Desk Management – describe how the service will be supported. Draft a plan for service-desk requirements, skills needed and required knowledge transfer.
  • Proactive Operations Management – define the service operation requirements for support and reliability from the event and performance monitoring to availability, demand, capacity, continuity and security management.
  • Provisioning and Change Management – define the service provisioning lifecycle and associated change management policies including how the service will be pre-approved and auto-provisioned (for maximum efficiency). New leaner change management workflow needs to defined / refined (i.e. standard changes).
  • Service Financial Management – define the service cost and charge back/ show back model along with pricing and connections to the service catalog.
  • Service Performance and KPIs – define any applicable service related strategic, tactical and operational performance indicators (KPIs), and the metrics that will be collected to demonstrate that required performance was achieved. Also define how and when the KPIs and metrics will be reported, and to whom.
  • Service Reviews – define service-based review meetings to discuss and remediate any operational or consumer related topics. Follow a standard cadence for all services. Discuss potential changes in demand for services. Capture new or enhanced service requirements.
  • Service Marketing – define the key applicable service marketing elements for a successful service promotion and value realization within different company cultures.

Now, how long do you think this exercise will take? In most of our engagements, defining a service takes between 1 to 2 weeks. It is never intended to fully document all the areas above immediately, or establish all of the processes, as many organizations don’t have this all of this information available. Think of the Service Definition as a living and breathing document. The service owner should establish a working draft, develop it to the point of release and then maintain in for its life as an active service offering. All undefined services are treated as areas for improvement.

In our next blog, we will take this to the next level as we learn to establish a cloud service-based cost model and cost out cloud services end-to-end.  This will enable you to understand the cost of a unit of a cloud and provide the required level of cost transparency internally and to consumers.

=======

Khalid Hakim is an IT Business/Financial Management Lead with the VMware Operations Transformation global practice. You can follow him on Twitter @KhalidHakim47.

Kai Holthaus is a Sr. Transformation Consultant with VMware Operations Transformation Services and is based in Oregon.

Bill Irvine is a Principal Strategist with VMware Accelerate Advisory Services and is based in Colorado.

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

By Kai Holthaus

kai_holthaus-cropThe Service Owner Role

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

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

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

Let’s take a closer look…

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

Responsibilities Throughout the Service Lifecycle

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

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

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

Shifting to an ITaaS Model

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

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

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

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

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

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

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

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

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

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

The Evolution of the SDLC

By Kai Holthaus

kai_holthaus-cropThe definition of SDLC is changing. SDLC often stands for the “software development life cycle,” a methodology to develop and implement software, currently in use by many IT organizations. IT organizations have realized, however, that this narrow focus on software is insufficient in today’s IT service delivery.

Figure 1: The SDLC Continuum

Figure 1: The SDLC Continuum

In my opinion, the next logical evolutionary step for an SDLC is to look at a “solution development life cycle,” which not only considers functionality requirements for the software, but also requirements for the underlying hardware and infrastructure systems, such as storage or networks. Solution development focuses on a more complete solution, but there is still further to go in maturing the approach. Ultimately, SDLC should really stand for “service development life cycle,” with a goal of developing, implementing, maintaining, and supporting all aspects of an IT service in order to bring real value to IT customers.

Software Development Life Cycle
Project teams often use a form of a software development life cycle to provide functionality in the form of software to users. The goal of the SDLC in this form is to use repeatable, predictable processes that improve software development productivity and software quality. Project teams will commonly incorporate aspects of project management frameworks into the SDLC, because without effective project management, it is very easy to deliver software projects late and/or over budget.

This approach to SDLC typically uses a methodology that will take the software development through multiple phases, such as planning, requirements, design, building, testing, deploying, and maintaining. The phases may be organized in a waterfall model, in a spiral model, or a combination of the two. Additionally, project teams may incorporate rapid application development or agile methods, such as SCRUM. There are a number of publicly available standards that can be applied to the SDLC, such as ISO 12207 (the international standard describing the method of selecting, implementing, and monitoring the life cycle for software), as well as process improvement guidance, such as the Capability Maturity Model Integration for Development (CMMI-DEV) or ISO 15504 (Information Technology Process Assessment).

It is important to note that the software development life cycle is really only concerned with software functionality. The framework provides guidance for developing this functionality, regardless of underlying systems, such as servers or the network that the software will need to be functional. While the SDLC in this form might (and should) be describing the requirements for such systems, the provisioning of such systems is typically not a part of this form of the SDLC. This does not necessarily mean that these requirements are not addressed at all, but typically the project team deals with them in a very separate way. This can potentially lead to miscommunication and a lack of coordination between different groups, and eventually to poorly delivered results. Another pitfall in such an approach is that the infrastructure side is done in an entirely ad hoc way, which can lead to struggles for the project team to be forced to fix things up in production, or severely under-performing services, because the infrastructure cannot support what is truly needed.

Solution Development Life Cycle
In a solution development life cycle (sometimes also known as systems development life cycle), the scope of the methodology is expanded from a narrow focus on software functionality to include the underlying systems, such as hardware and infrastructure.  The SDLC in this form is seen as a process to develop an information system, aiming to produce a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, and is inexpensive to maintain and cost-effective to enhance.

The solution development life cycle approach will be similar to the software development life cycle, in that phases for requirements, design, development, building, testing, deploying, and maintaining will be defined by the project team, and in that guidance from project management methodologies or process improvement methodologies can also be incorporated. However, the focus here is still on providing software functionality to users and customers at a given point in time, and not business value in the form of delivering ongoing services.

The benefit of a solution development life cycle over a software development life cycle is that requirements for underlying systems are defined along with requirements for software functionality, and the entire solution will be developed, thus reducing the risk that these underlying systems can derail the delivery of the desired functionality late in the life cycle. The solution development life cycle therefore ensures a more complete view of how the software functionality is delivered, thereby improving the user experience.

Service Development Life Cycle
Further maturing the SDLC leads to a true service development life cycle, which, while still concerned with the software application(s) needed for success, focuses on the definition, design, build, operation, and improvement of a complete IT service, providing outcomes that customers want to achieve. This view is much bigger than the view being taken in the software or solutions development life cycle. The central idea is for the project team to figure out the end results that their customers need to accomplish and then deliver and manage IT services to achieve those outcomes.  This holistic approach requires the team to consider not only the technical aspects of the service, but also the non-technical aspects such as training, documentation, support, communications, or processes.

For Example…
Here’s an example to further illustrate the difference between these three approaches. Let’s take a look at a payroll application. When using software development life cycle methods, the project team’s focus is on functionality provided by the application. For instance, an improvement to the payroll application might be to expand state tax calculation from handling a single state to also include other states, because the company will now also open offices in more states. The focus is solely on the calculations in the software.

Moving to the solutions development life cycle approach, more aspects are looked at for this change. Since adding this functionality most likely means more users and more employee records being managed by the application, the project team would also consider additional space requirements for the database storing the information about employees, additional network bandwidth that may be required for additional users, and more CPU power being needed for those users.

Taking a service development life cycle approach would require that the project team understand the outcomes customers want to achieve (e.g., “process payroll for all employees”), taking a holistic view of the current IT service landscape, and then determining how those outcomes can be best achieved within that landscape. Besides just application functionality, other aspects of service delivery come into focus, such as availability or continuity requirements, training, support, and even marketing new capabilities in the organization.

In conclusion, the evolution of the SDLC takes us from the traditional “software development life cycle” with its focus on developing and implementing functionality provided by software to defining, designing, implementing, and maintaining services that provide value to IT customers. Doing so means expanding the processes and roles described in these life cycles to ensure this value can be realized.

====
Kai Holthaus is a transformation consultant with VMware Accelerate Advisory Services and is based in Oregon. Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags

Configuration Management in the Cloud

by Kai Holthaus

kai_holthaus-crop“The Cloud” is one of the biggest paradigm shifts in the IT world. Instead of provisioning physical hardware in a physical data center and then managing applications running on the physical hardware, virtualization has allowed IT organizations to decouple logical infrastructure from physical infrastructure, and thereby deliver new-found flexibility to provide and manage value-add services.

Additionally, IT organizations can now provision the cloud infrastructure itself, along with the infrastructure they are already running themselves. Infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) are now available to supplement or even replace traditional IT offerings. One common use case is to monitor the performance of a web server.

Once the performance reaches a certain limit, a new service is automatically provisioned in the cloud. The cloud-based server is used as long as performance demands require it, and once demand drops below a certain threshold, the additional cloud-based server is decommissioned. All of this can happen in a matter of minutes and can be fully automated.

Different cloud-based offerings need to be managed differently, in terms of configuration management, to ensure that the needs of the customer can be met.

Configuration Management Principles
According to ITIL, the purpose of the service asset and configuration management process is to ensure that the assets required to deliver services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed. This information includes details of how the assets have been configured and the relationships between assets.

The objectives of configuration management are to:

  • Ensure that assets under the control of the IT organization are identified, controlled and properly cared for throughout their lifecycle
  • Identify, control, record, report, audit, and verify services and other configuration items (CIs), including versions, baselines, constituent components, their attributes and relationships
  • Account for, manage and protect the integrity of CIs through the service lifecycle by working with change management to ensure that only authorized components are used and only authorized changes are made
  • Ensure the integrity of CIs and configurations required to control the services by establishing and maintaining an accurate and complete configuration management system (CMS)
  • Maintain accurate configuration information on the historical, planned and current state of services and other CIs
  • Support efficient and effective service management processes by providing accurate configuration information to enable people to make decisions at the right time – for example, to authorize changes and releases, or to resolve incidents and problems

In summary, configuration management supports the management of services by providing information about how the services are being delivered. This information is crucial to the other service management processes, especially such processes as change management, incident management, or problem management. It is also crucial to ensure meeting all agreed-to service levels.

Configuration Management and the Cloud
Let’s take a look at three common cloud-based offerings and the configuration management aspects to keep in mind.

20140421 SACM in the Cloud

Infrastructure as a service (IaaS) — IaaS is a service that offers computing resources, such as virtual machines, virtual networks, or virtual storage as a service to customers. The consumer of IaaS services usually has control over the configuration aspects of the resource, such as which operating system to run on a virtual machine, or how to utilize the storage resource.

This means that the resources provisioned in an IaaS model would be CIs that should be managed in the traditional way, as if they were physical CIs. IaaS offers customers a lot of control over the configuration of these resources.

Platform as a service (PaaS) — PaaS is a service that offers a computing platform to its customers. A computing platform could include an operating system, programming language, execution environment, database, and web server, so that developers have a ready-made platform for their development tasks that can quickly be deployed in various environments.  The management of the components of the PaaS is left to the service provider, who will need to meet service level agreements (SLA).

With PaaS, configuration management could be performed on the individual components of the platform, such as the virtual machine, the operating system, and the database, for instance. The configuration management could also be performed at the service level, meaning that there would only be one service-type CI for the platform to be entered into and managed in a CMS.

Software as a service (SaaS) — SaaS provides entire application environments, such as HR or procurement applications, as a service. The service provider must meet SLAs, so that customers of the service will be able to use the software when and where they choose. Such service levels can include all aspects of utility and warranty, as well as incident resolution, problem resolution, or promised delivery time frames for specific service requests, such as a new login for the application. With SaaS, there should only be a service-type CI in the CMS to be managed.

In summary, the need for good configuration management practices does not end when services (or parts of services) are moved to the cloud. It is still the service provider’s responsibility to ensure that services are being delivered as agreed to with the customers. Different cloud-based services, such as IaaS, PaaS, or SaaS, will require different levels of configuration management.

—-
Kai Holthaus is a transformation consultant with VMware Accelerate Advisory Services and is based in California . Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags