Home > Blogs > VMware Operations Transformation Services > Monthly Archives: July 2014

Monthly Archives: July 2014

Service Catalog Is The New Face of IT

By Choong Keng Leong

Keng-Leong-Choong-cropMany organizations on their journey to delivering IT as a service have chosen to adopt and implement VMware vCloud® Automation Center™ to automate the delivery and management of IT infrastructure and services through a unified service catalog and self-service portal.  As this transformation requires a new IT operating model and change in mindset, a common challenge that IT organizations encounter is:

  • How do I define and package IT services to offer and publish on the service catalog?

This is analogous to a mobile operator putting together a new mobile voice and data plan that the market wants and pricing it attractively.

Here’s a possible approach to designing a service catalog for vCloud Automation Center implementation.

Service Model
Service catalog is the new face of IT. It is a communication platform and central source of information about the services offered by IT to the business. It is also empowering users through an intuitive self-service portal that allows them to choose, request, track, and manage their consumption and subscription to IT services.

The first step to developing the service catalog and identifying the services within it is to understand the business requirements as to how these demands are going to be fulfilled — that is to develop a service model. For example, you could start with a business function — Sales — and then pick a business process — client relationship management (CRM). CRM can be further broken down into three domains: operational CRM, collaborative CRM, and analytical CRM. Each of the CRM systems can be instantiated in different environments (product, test, and development). Each instance is technically implemented and delivered via a three-tier system architecture. What you would get is shown below in Figure 1, which is a service model for CRM.

ServiceCatalog

Figure 1. Service Model for CRM

Repeat the above steps for the other business functions. At the end of the exercise, you have defined service categories, catalog items, and service blueprints for implementation of a service catalog and self-service portal in vCloud Automation Center.

Service Catalog
Using the above business centric approach allows you to define a customer-friendly service catalog of business services. The service categories and catalog items are in business-familiar terms, and only relevant information is presented to the business user so as not overwhelm him/her with the complexities of the underlying technologies and technicalities.

The business services are provisioned using service blueprints, which are templates containing the complete service specifications, technical service levels (e.g., RTO, RPO, and IOPS), and infrastructure (e.g., ESXi cluster, block or file storage, and network).  The service blueprints allow IT to automate provisioning through vCloud Automation Center. To maximize business benefits and optimization of infrastructure resources, it is also important to establish a technical service catalog of technical capabilities and to pool infrastructure resources with similar capabilities. Then, vCloud Automation Center can provision a service via the service blueprint to the most cost-effective resource pool and providing optimal performance.

In summary, using a business-centric approach to designing your service catalog elevates IT to speaking in business terms and provides a whole new IT experience to your users.

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

The Operations Transformation Track at VMworld: What’s It All About?

VMworldVerticalGIF_07.14.14 (1)As businesses move toward the software-defined data center model, it’s not just the technology that changes. IT organizations must evolve – sometimes radically – to ensure a more service-oriented and business value focused way of operating. Sure, that’s a logical argument, but how do you make sure those operational changes happen? How do you hire or retrain employees with the right skills to manage these new technologies? Which processes do you need to overhaul? Which processes are no longer necessary? Is your org chart even relevant anymore?

Come hear real-world experiences from companies like Boeing and McAfee, which have successfully shifted their operating models. Boeing’s Enes Yildirim explains how the company put itself on the path to multi-million dollar cost savings. McAfee’s Meerah Rajavel details how the security software firm turned the vision of IT transformation into business achievement.

Check out the SDDC > Operations Transformation track in the Schedule Builder for these and more sessions that will share best practices and key considerations to accelerate your journey to the software-defined data center.

7 Key Steps to Migrate Your Provisioning Processes to the Cloud

By David Crane

dcrane-cropIn an earlier blog, my colleague Andy Troup shared an experience where his customer wanted to embark on a process automation project, which could have had disastrous (and consequently frustrating and costly) results, as the process itself was inherently unsuitable for automation.

Automating processes is one of the first projects that organizations embark on once a cloud infrastructure is in place, but why? The answer lies in legacy IT organizations structures that have typically operated in silos.

Many of the IT organizations that I work with have a number of groups such as service development, sales engineering, infrastructure engineering, and IT security that face similar challenges that can include (among many others):

  • Applications provisioned across multiple environments such as development, QA, UAT, sales demonstrations, and production
  • Managing deployments of application workloads in a safe and consistent manner
  • Balancing the speed and agility of deploying the services required to deliver and improve business results while meeting compliance, security, and resource constraints

With the agility that cloud computing offers, organizations look to the benefits that automating the provisioning processes may bring to overcome the above challenges such as:

  • Reduced cycle time and operating costs
  • Improved security, compliance, and risk management
  • Reduced capital and operating expenditures
  • Reduced need for management/human intervention
  • Improved deployment/provisioning time
  • Consistent quality in delivery of services

The IT organizations I work with are often sold these benefits without consideration of the operational transformation required to achieve them. Consequently, when the IT team kicks off a project to automate business processes, especially service provisioning, their focus is on the potential benefits that may be achieved. The result of this focus is that automation becomes a panacea, and not something that should underpin the IT organization’s overall operational transformation project.

As IT leaders, when considering migrating your provisioning processes to your cloud environment, you need to realize that automation alone will not necessarily provide the cure to problems that exist within a process.

You should not consider the benefits of automation in isolation. For example, too much focus on cost reduction can frequently lead to compromise in other areas leading to objections and resistance from business stakeholders. You should consider other benefits that have non-tangible (or direct) metrics, such as improved staff satisfaction. Automation frees your technical staff from repetitive (and uninteresting) activities, which results in both improved staff retention and indirect cost benefit.

As you select processes to migrate from a physical (or virtual) environment to the cloud, the subsequent automation of those processes should not be an arbitrary decision. Frequently my clients choose processes as candidates for automation for reasons based on personal preferences, internal political pressures, or because some process owners shout louder than others!

Instead the desired business benefits the organization wishes to achieve should be considered in conjunction with the characteristics, attributes, and measurable metrics of a process characteristics and a formal assessment made of its suitability for automation.

Your automation project should also be implemented in conjunction with an organization structure assessment, which may require transformation and the introduction of new roles and responsibilities required to support the delivery of automated and self-optimizing processes.

Important Steps to Your Successful Process Assessment
Based on my experience assisting customers in this exercise, I recommend taking these steps before you embark on a process assessment:

  1. Understand automation and what it actually means and requires. Many organizations embark on automation without actually understanding what this means and the context of automated processes and their capabilities. Subsequent delivery then either leads to disappointment as automation does not meet expectations, or the process is not truly automated but instead has some automated features that do not deliver all the expected benefits.
  2. Identify and document the expected business benefits to be achieved through introduction of process automation. This is an important task. Without understanding the benefits automation is expected to achieve, you cannot identify which processes are the correct choices to help you do just that.
  3. Understand cloud infrastructure system management capabilities required to support process automation (e.g., ability to detect environmental changes, process throughput monitoring capability) and implement if required.
  4. Identify ALL processes required to support automated provisioning (e.g., instantiation, governance, approval) to create a process portfolio.
  5. Identify the common process automation characteristics that exist across the process portfolio (e.g., self configuration, self healing, self audit and metric analysis). Note that process characteristics are unique, high-level identifiers of automation across the portfolio.
  6. Identify the common attributes that the process characteristics share. These are more granular than process characteristics and thus may be common to more than one characteristic in the same process.
  7. Identify the metrics available for each process in the portfolio, and apply a maturity assessment based on their ability to be measured and utilized. Metric maturity is an essential part of the assessment process as it determines not just the suitability of the process for automation, but also its capability to perform self optimization.

Process Assessment Weighting and Scoring
When undertaking a process assessment program, an organization needs to understand what is important and prioritize accordingly. For example, if we consider the business benefits of automation, a managed service provider would probably prioritize business benefits differently to a motor trade retail customer.

Once you’ve prioritized your processes, they can be assessed more accurately and weighted based on each identified business benefit. Prioritization and weighting is essential, and you need to carefully consider the outcomes of this exercise in order for your process assessment to reflect accurately whether processes are suitable for automation or not.

And remember, as previously mentioned avoid considering each assessment criteria in isolation. Each process characteristic and associated attribute can have a direct impact on the desired business benefit, however if its metric maturity is insufficient to support it, then the business benefit will not be fully achieved.

For example, let’s say that you have identified that a business process you wish to automate has a self-healing characteristic. One of the attributes the characteristic possesses is the ability to perform dynamic adjustment based on real-time process metrics. The characteristic and attribute would lead you to expect the realize benefits such as reduced cycle time, reduced OpEx, consistent quality of service, and improved staff retention.

However, although you’ve identified the metrics required to meet the characteristic and attribute needs, they are neither measured or acted upon. Consequently, because the metric maturity level is low, then the expected business benefit realization capability is also lowered.

Figure 1 below shows a small sample of the assessment of a process in relation to a single process characteristic, common attributes, anticipated business benefits and their weighting and the impact that a poor metric maturity has on their capability to deliver the anticipated business benefit.

Figure 1. Assessment displaying impact of low metric maturity

Contrast this to Figure 2 below, which assesses a process with exactly the same characteristics, attributes, business benefits, but has supporting management capabilities and consequently much improved metric maturity:

Figure 2. Assessment displaying impact of high metric maturity

Based on this small data sample, the process in Figure 2 is a more likely candidate for process automation. The assessment process also then identifies, and allows the IT organization to focus on, areas of remediation needed to optimize processes to enable them to be suitable automation candidates.

The result is the IT organization is able to realize not just the business benefits that have been promised by automation more effectively, but they are also able to set realistic expectations with the business, which brings benefits all of its own.

In summary, automation is not the “silver bullet” for broken or inefficient processes. IT leaders need to consider expected business benefits in conjunction with process characteristics, attributes, and metrics and in the context of what is important to the business. By assessing the suitability of a process for automation, you can save the cost of a failed project and disappointed stakeholders. Finally, you should not undertake any provisioning process project in isolation to other operations transformation projects, such as organization structure and implementation of cloud service management capabilities.

I will discuss the steps to success mentioned above in more detail in my next blog.

===

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

 

3 Steps to Get Started with Cloud Event, Incident, and Problem Management

By Rich Benoit

Benoit-cropWe are now well entrenched in the Age of Software. Regardless of the industry, there is someone right now trying to develop software that will turn that industry on its head. Previously, companies worked with one app that had the infrastructure along with it. It was all one technology, and one vendor’s solutions. Now there are tiers all over the place, and the final solution uses multiple components and technologies, as well as virtualization. This app is a shape shifter, one that changes based on the needs of the business. When application topology is changing like this over time, it creates a major challenge for event, incident, and problem management.

Addressing that challenge involves three major steps that will affect the people, processes, and technologies involved in managing your app.

1. Visualize with unified view
The standard approach to monitoring is often component- or silo-focused. This worked well when apps were vertical where an entire application was on one server; but with a new, more horizontal app that spans multiple devices and technologies – physical, virtual, web – you need a unified view that shows all tiers and technologies of an application. That view has to aggregate a wide range of data sources in a meaningful way, and then identify new metrics and metric sources. The rule of thumb should be that each app gets its own set of dashboards: “big screen” dashboards for the operations center that shows actionable information for event and incident management; detailed interactive dashboards that allow the application support team to drill down into their app; and management level dashboards that show a summary business view of application health and KPIs.

By leveraging these dashboards, event and incident management teams can pull up in real time to diagnose any issues that arise (see example below). Visualization is key in this approach, because it allows you to coordinate the data in a way that will actually allow for identification of events, incidents, and problems.

big screen dbVMware® vCenter™ Operations Manager™ “big screen” dashboard

2. Aggregate
When you’re coordinating a number of distributed apps, establishing timelines and impact becomes a much more complicated process. Here’s where your unified view can start to help identify problems before they occur. Track any changes that occur, and then map them back to any changes that have happened. When I’m working with clients, I demonstrate the VMware® vCenter™ Operations Manager™ ability to establish dynamic thresholds. The dynamic thresholds track back what constitutes common fluctuations, and leverages those analytics to establish baselines around what constitutes “normal.” By looking at the overall data in a big picture, the software can avoid false triggering around normal events.

3. Leveraging Problem Management
Ideally, you will be catching events and incidents before they result in downtime. However, that requires constantly looking for new metrics and metrics sources to create a wider view of the app. Problem management teams should be trained to identify opportunities for new metrics and new metrics sources. From there, the development team should take those new metrics and incorporate them into the unified view. When an issue occurs, and you look for the root cause, also stop to see if any specific metrics changed directly before the problem occurred. Tracking those metrics could alert you to a possible outage before it occurs the next time. Problem management then becomes a feedback loop where you identify the root cause, look at the surrounding metric, and then update the workflows to identify precursors to problems.

This doesn’t require you to drastically change how you are managing problems. Instead, it just involves adding an extra analytics step that will help with prevention. The metrics you’re tracking through the dashboard will generally fall into three basic buckets:

  • Leading indicators for critical infrastructure
  • Leading indicators for critical application, and
  • Metrics that reflect end-user experiences

Once you have established the value of finding and visualizing those metrics, the task of problem management becomes proactive, rather than reactive, and the added level of complexity becomes far more manageable.

—————-
Richard Benoit is an Operations Architect with the VMware Operations Transformation global practice and is based in Michigan.