Tag Archives: ITSM

Building a Resilient Integration from Your Cloud to your IT Service Management Platform

Pierre Moncassin-cropBy Pierre Moncassin

In the vast majority of cloud implementations the integration between the self-service provisioning workflow and the configuration management system (CMS) will need to be addressed.

On the surface the use case is a ‘no brainer’. Once a cloud infrastructure service has been provisioned we want to ensure that the newly created configuration items are recorded in the CMS so that IT can support the new service. Incidents occurring in the newly created infrastructure need to be detected, managed and resolved.

In most cases the IT Operations team will be relying on an IT Service Management toolset for its day-to-day activities. In this typical scenario, we would need a technical integration between the provisioning workflow engine and the IT Service Management toolset.

In order to enable IT Support with Event and Incident Management, we need the newly created workloads (or applications) to be “visible” from the Service Management toolset. This means creating the configuration items in the service management toolset’s configuration management system (CMS). Vendors of service management tools have various approaches to their configuration management system, but in principle this will require the creation of configuration records in their CMS.

Here’s the simplified diagram:

Cloud ITSM Integration

However the range of integration scenarios is by no means limited to event/incident management. There is actually a broad range of possible scenarios including:

  • Change Management – tracking updates to the configuration items that have been created
  • Financial Management – being able to evaluate the cost of newly created item, which In turn will enable chargeback, billing and more broadly help meet the financial requirement
  • Compliance & security – being able to verify that the infrastructure meets corporate policy and security standards as appropriate
  • Business Continuity Management – ensuring resilience, disaster recovery, backups/archiving etc.

Given the number of possible use cases, it is important to decide early on which the key scenarios will be. Which processes do you want to enable as a priority?

That initial decision will drive the complexity of the technical integration, especially the number of parameters and values being passed around.

The Technical Side of Integration: Tools & Guidance

Fortunately when it comes to the technical side, there are many options to integrate VMware vRealize Operations into a third party tool. The typical avenue is to leverage the connectivity features of VMware vRealize Orchestrator.

On the other side of the integration, we will have an IT Service Management (ITSM) toolset (from vendors such as BMC, HP, CA, ServiceNow, and many others).

Here are some example resources for the some commonly used toolsets:

The integration workflow reflects the process requirements: typically, creating Configuration Items (CI’s) in the Service Management toolset and passing on CI information.

However one aspect that can be easily overlooked when first setting up the integration, is to build in resilience. For example, the ability for this integration to handle exceptions and errors.

Another key to resilience is to consider the operational aspects of the integration itself.

  • Maintenance is often where integrations fail over the long run – the organization lacks the resources or roles to keep the integration up to date. It is recommended to assign someone the responsibility for maintaining this integration.
  • The skills to maintain the integration may need to be developed and refreshed.

Your Take-Aways

These three angles must be covered to produce a robust integration SDDC-ITSM:

  • People: decide how your organization will maintain this integration for the long term (and who will maintain it). Ensure than the relevant skills (and knowledge) is retained to keep the integration up to date in the future.
  • Process: decide on the key process (use cases) for the integration – and document them.
  • Technology: Leverage exiting tools and know-how – no need to re-invent the wheel. Build in resilience early on: plan for exception handling, testing and future version upgrades early in the development of the technical integration.

—-
Pierre Moncassin is an operations architect with the VMware Operations Transformation global practice and is based in the UK.

Change Management’s Balancing Act

worthingtonp-cropBy John Worthington

I had some interesting discussions with a client about Change Management the other day. There was considerable focus around the risk matrix; after all, the risk of a change dictates approval flow….change is about managing risk right?

Balancing ActThe change management challenge is about balancing positive risk (value) with negative risk (service interruption), and as always we want to maximize positive risk and minimize negative risk.

From a change management perspective, maximizing positive risk is focused on acceleration and velocity. In order to do this, we need proven repeatable procedures. Building a library of proven change models will not only provide higher quality (via repeatability), but a rich source of information for automation that can further increase velocity (and time to value). Standard changes are an easy and logical place to start building this library.

The focus on minimizing negative risk, and a desire to perfect the risk matrix, can divert attention to the process. Don’t get me wrong, we do want a consistent way to assess risk across all stakeholders, but tuning the risk matrix will not build repeatability into the process and will not by itself reduce risk.

It’s the actions taken by change management practitioners – change managers, CAB Members and change analysts – that can increase the velocity of change while reducing risk. This is accomplished by fine-tuning a library of predefined procedures for known types of changes.

So if the powers that be seek to slow the process down by formally reviewing more and more changes, don’t focus on the risk matrix — at the end of the day the powers that be will decide what needs to be reviewed (think change freeze, major incidents) and it won’t matter what the risk matrix looks like.

The risk matrix is a guide that should direct all staff to do look at how changes can be more effectively modeled. As the library of repeatable changes increased, as automation is enabled, risk can be managed at higher velocities. Start with standard changes and move up from there; the risk matrix is likely to take care of itself.


John Worthington is a VMware transformation consultant and is based in New Jersey. Follow @jMarcusWorthy and@VMwareCloudOps on Twitter.

 

How to Take Charge of Incident Ticket Ping Pong

By Pierre Moncassin

Pierre Moncassin-cropWhen incident tickets are repeatedly passed from one support team to another, I like to describe it as a “ping pong” situation. Most often this is not a lack of accountability or skills within individual teams. Each team genuinely fails to see the incident as relevant to their technical silo. They each feel perfectly legitimate in either assigning the ticket to another team, or even assigning it back to the team they took it from.

And the ping pong game continues.

Unfortunately for the end user, the incident is not resolved whilst the reassignments continue. The situation can easily escalate into SLA breaches, financial penalties, and certainly disgruntled end users.

How can you prevent such situations? IT service management (ITSM) has been around for a long while, and there are known mitigations to handle these situations. Good ITSM practice would dictate some type of built-in mechanisms to prevent incidents being passed back and forth. For example:

  • Define end-to-end SLAs for incident resolution (not just KPIs for each resolution team), and make each team aware of these SLAs.
  • Configure the service desk tool to escalate automatically (and issue alerts) after a number of reassignments, so that management becomes quickly aware of the situation.
  • Include cross-functional resolution teams as part of the resolution process (as is often done for major incident situations).

In my opinion there is a drawback to these approaches—they take time and effort to put in place; incidents may still fall through the cracks. But with a cloud management platform like VMware vRealize Suite, you can take prevention to another level.

A core reason for ping pong situations often lies in the team’s inability to pinpoint the root cause of the incident. VMware vRealize Operations Manager (formerly known as vCenter Operations Manager) provides increased visibility into the root cause, through root cause analysis capabilities. Going one step further, vRealize Operations Manager gives advance warning on impending incidents—thanks to its analytical capabilities. In the most efficient scenario, support teams are warned of the impending incident and its cause, well ahead of the incident being raised. Most of the time, the incident ping pong game should never start.

Takeaways:

  • Build a solid foundation with the classic ITSM approaches based on SLAs and assignment rules.
  • Leverage proactive resolution, and take advantage of enhanced root cause analysis that vRealize Operations Manager offers via automation to reduce time wasted on incident resolution.


Pierre Moncassin is an operations architect with the VMware Operations Transformation global practice and is based in Taipei. Follow @VMwareCloudOps on Twitter for future updates.

 

How to Measure the Impact of Your IT Transformation

By Matt Denton

Matt_Photo1Generally when a company makes a decision to move in a new direction, a lot of analysis and rigor take place to ensure the decision is the right one. Business cases are created and vetted until everyone is in agreement and the project is approved. This is all great and necessary to kick off a new initiative. However, once the project is in motion, how often do we measure the results against the original business case to see if we are delivering on what the company expected?

Think about it. A project gets kicked off and everyone is heads down implementing the new changes and making sure they meet their deadlines. Going back to review a business case is usually not a priority and, quite frankly, who has the time? But at some point, senior leadership will ask for an analysis, and one will be created to meet that one-time request. Then, it is back to business as usual—until the next request comes along.

What if you could measure the impact IT transformation has on the business proactively and in real time? Projects become more meaningful. Employees can see how their work is impacting the business. Transformation begins to make sense and can be justified. This can be done if you take the time to generate key performance indicators and metrics ahead of time.

Start by asking the team these questions at the beginning of a project:

  1. Why are we doing this?
  2. What are we trying to improve?
  3. How will we measure it?
  4. What is our current state benchmark?
  5. What is our target?
  6. How will we impact the business if we reach our target state?
  7. Do we have data to measure progress?

What Metrics Matter Most?
Usually I see companies measure progress based on financial metrics. For example, did we save the company money? However, there are hundreds of metrics that relate to agility, cost, and quality. The key is to pick those that are most impactful to the processes you expect to improve as part of the transformation. These may not all be financially driven, but will still have a measurable impact on the business.

Below are some other areas where you can measure business impact:

  • IT financial management
  • Service level management
  • Demand management
  • Service desk management
  • Incident management
  • Problem management
  • Change management
  • Configuration management
  • Availability management
  • Continuity management
  • Release management
  • Capacity management
  • Security management

Some of the metrics that fall into these categories are what I refer to as the “hard to quantify” or “soft” benefits. These are generally thrown out or overlooked during the business case development. I believe that once you can quantify these, you can translate them into real benefits and measure their impact on the business.

Provided the data exists, I’ve been able to help many clients both track the metrics they decide to measure and demonstrate how they can show the impact IT transformation has on their company. By quantifying these metrics and showing the impact your improvements are making on the business, you will know at any given time if the changes you are undertaking are making a difference or if you are falling short of your expectations. And, you will also be able to identify if additional changes are required to meet the project’s objective.

Too often, I see clients lose focus on the reason they started a project. This is easy to do on long projects. People change roles, leadership changes, or other projects take priority. Putting metrics in place and understanding their impact on the business will help you maintain that focus. The qualitative data gathered during implementation and post implementation are important to measure the impact IT transformation has made on your business. The data you collect and analyze will begin to tell a story and allow you to make precise decisions on where additional improvements are needed to make the biggest impact.

======
Matt Denton is a VMware transformation architect and is based in Wisconsin.

Incorporating DevOps, Agile, and Cloud Capabilities into Service Design

By Reg Lo

ReginaldLo-cropShadow IT is becoming more prevalent because the business demands faster time-to-market and the latest innovations—and business stakeholders believe their internal IT department is behind the times or hard to deal with (or both!). The new IT requires new ways of designing and quickly deploying services that will meet and exceed customer requirements.

Check out my recent webcast to learn how to design IT services that:
• Take advantage of a DevOps approach
• Embody an Agile methodology to improve time-to-market
• Leverage cloud capabilities, such as elastic capacity and resiliency
• Remove the desire of the business to use shadow IT

BrightTalk webinar

===
Reg Lo is the Director of the Service Management practice for VMware Accelerate Advisory Services and is based in California.

 

 

What Metrics Should Be Measured for Change Management?

By Kai Holthaus

kai_holthaus-cropThat, of course, depends (favorite answer of consultants everywhere…). As an IT executive, start by asking yourself what you want to achieve. Once you select a critical success factor (CSF), key performance indicator (KPI) or associated metrics and start to report on those metrics, you will see two types of behavior within your IT organization.

Most of your employees will want to be good team players, and they will work to meet the desirable metrics (and avoid undesirable ones). For example, if you start reporting on the number of changes implemented without proper authorization (which could be discovered through configuration audits), and you start disciplining staff for implementing changes without authorization, you will see the number of unauthorized changes go down (in most cases). However, you will also find that some staff will try to game the system by implementing changes without proper authorization, then making it look as if (in your tracking system) they’d had the authorization.

Also keep in mind, that metrics can have unintended consequences. Sticking with the example of tracking (and trying to reduce) the number of unauthorized changes, you may be surprised to see the backlog of changes waiting to be approved grow, because your approval process was not yet ready to handle all the change that was going on in your environment. So, it’s a good practice to be prepared to adjust your metrics accordingly. This also applies to metrics that have been in place for a while. If you have driven the number of authorized changes to zero, and have held it there for the last 12 months, you may want to consider adjusting your focus to other issues (but don’t lose sight completely…unauthorized changes can quickly creep back in).

Finally, make sure that you can actually measure the things you need to measure to report on CSFs and KPIs. Setting a goal of no unauthorized changes is laudable but will remain a goal until you have found a way to detect unauthorized changes.

To conclude, here are some examples of KPIs to consider for your change management process:
kai graphic

=========

Kai Holthaus is a transformation consultant with VMware Accelerate Advisory Services and is based in Oregon.

How to Avoid 5 Common Mistakes When Implementing an SDDC Solution

By Jose Alamo

Jose alamo-cropImplementing a software-defined data center (SDDC) is much more than implementing or installing a set of technology — an SDDC solution requires clear changes to the organization vision, policies, processes, operations, and organization readiness. Today’s CIO needs to spend a good amount of time understanding the business needs, the IT organization’s culture, and how to establish the vision and strategy that will guide the organization to make the adjustments required to meet the needs of the business.

The software-defined data center is an open architecture that impacts the way IT operates today. And as such, the IT organization needs to create a plan that will utilize the investments in people, process, and technology already made to deliver both legacy and new applications while meeting vital IT responsibilities. Below is a list of five common mistakes that I’ve come across working with organizations that are implementing SDDC solutions, and my recommendations on how avoid their adverse impacts:

1. Failure to develop the vision and strategy—including the technology, process, and people aspects
Many times organizations implement solutions without setting the right expectation and a clear direction for the program. The CIO must use all the resources available within the IT organization to create a vision and strategy, and in some cases it is necessary to bring in external resources that have experience in the subject. The vision and strategy must align with the business needs, and it should identify the different areas that must be analyzed to ensure a successful adoption of an SDDC solution.

In my experience working with clients, it is imperative that as part of the planning a full assessment is conducted, and it must include the areas of people, process, and technology. A SWOT analysis should also be completed to fully understand the organization’s strengths,  weaknesses, opportunities, and threats. Armed with this insight, the CIO and IT team will be able to express the direction that must be taken to be successful, including the changes required across people, process, and technology.

Failing to complete this step will add complexity and lack of clarity for those who will be responsible for implementing the solution.

2. Limited time spent reviewing and understanding the current policies
There are often many policies within the IT organization that can prevent moving forward with the implementation of SDDC solutions. In such cases, the organization needs to have an in-depth review of the current policies governing the business and IT day-to-day operations. The IT team also needs to ensure it devotes a significant amount of time with the company’s security and compliance team to understand their concerns and what measures need to be taken to make the necessary adjustments to support the implementation of the solutions. For example, the IT organization needs to look at its change policies; some older policies could prevent the deployment of process automation that is key to the SDDC solution. When these issues are identified from the beginning, IT can start the negotiation with the lines of business to either change its policies or create workarounds that will allow the solution to provide the expected value.

Performing these activities at the beginning of the project will allow IT leadership to make smart choices and avoid delays or workarounds when deploying future SDDC solutions.

3. Lack of maturity around the IT organization’s service management processes
The software-defined data center redefines IT infrastructure and enables the IT organization to combine technology and a new way of operating to become more service-oriented and more focused on business value. To support this transformation, mature service management processes need to be established.

After the assessment of current processes, the IT organization will be able to determine which process will require a higher level of maturity, which process will need to be adapted to the SDDC environment, and which processes are missing and will need to be established in order to support the new environment.

Special attention will be required for the following processes:  financial management, demand management, service catalog management, service level management, capacity management, change management, configuration management, event management, request fulfillment, and continuous service improvement.

Ensure ownership is identify for each process, with KPIs and measurable metrics established—and keep the IT team involved as new processes are developed.

4. Managing the new solution as a retrofit within the current environment
Many IT organizations will embrace a new technology and/or solution only to attempt to retrofit it into their current operational model. This is typically a major mistake, especically if the organization is expecting better efficiency, more flexibility, lower cost to operate, transparency, and tighter compliance as potential benefits from an SDDC.

Organizations must assess their current requirements and determine if they will be required for the new solutions. Most processes, roles, audit controls, reports, and policies are in place to support the current/legacy environment, and each must be assessed to determine its purpose and value to the business, and to determine whether it is required for the new solution.

IT leadership should ask themselves: If the new solution is going to be retrofitted into the current operational model, then why do we need a new solution?  What business problems are we going to resolve if we don’t change the way we operate?

My recommendation to my clients is to start lean, minimize the red tape, reduce complex processes, automate as much as possible, clearly identify new roles, implement basic reporting, and establish strict change policies. The IT organization needs to commit to minimize the number of changes to the new solution to ensure only changes that are truly required get implemented.

5. No assessment of the IT organization’s capabilities and no plan to fill the skill set gaps
The most important resource to the IT organization is its people. IT management can implement the greatest technologies, but their organizations will not be successful if their people are not trained and empowered to operate, maintain, and enhance the new solution.

The IT organization needs to first assess current skill sets. Then work with internal resources and/or vendors to determine how the organization needs to evolve in order to achieve its desired state. Once that gap has been identified, the IT management team can develop an enablement plan to begin to bridge the gap. Enablement plans typically include formal “train the trainer” models to cascade knowledge within the organization, as well as shadowing vendors for organizational insight and guidance along with knowledge transfer sessions to develop self-sufficiency. In some cases it may be necessary to bring in external resources to augment the IT team’s expertise.

In conclusion, implementing a software-defined data center solution will require a new approach to implementing processes, technologies, skill sets, and even IT organizational structures. I hope these practical tips on how to avoid common mistakes will help guide your successful SDDC solution implementations.

====
Jose Alamo is a senior transformation consultant with VMware Accelerate Advisory Services and is based in Florida. Follow Jose on Twitter @alamo_jose  or connect on LinkedIn.

The Secret to Avoiding the Portfolio Management Bottleneck: Simplicity

By: David Crane  

Delivering a set of standardized infrastructure services is a critical dependency as IT becomes more service oriented. Getting application owners who are used to custom infrastructure to agree to only use standard service configurations may be the defining problem of the cloud era.

The lifecycle of defining new service elements, adding them to the service portfolio, then formally releasing them for use by adding to service catalog is the very heart of the problem when getting multiple developers and application owners to agree to use standard services.

The process is critical.  And the process must be streamlined and oriented to the needs of users and funders of the service, and not the internal machinations of the IT organization.

However, traditional ITSM Service Portfolio Management is a cumbersome process geared to the needs of the IT organization.  IT includes numerous points of IT management sign-off, and the process is not optimized for actually developing and releasing new services into use.  The traditional approach tends to be heavy on oversight, and light on actually doing work. This approach reduces agility and wastes scarce resources. Not good in an era where increased agility and reduced operating costs are key measures of success.

Things are different within a virtual cloud ecosystem like VMware’s vCloud Automation Center (vCAC). With vCloud Automation Center, authorized users can access standardized services through a secure self-service portal, as vCAC acts as a service governor to help enforce business and IT policies throughout the service lifecycle. In this environment, a radically simplified design lets IT service managers focus their energy on the needs of users and funders and helps them get their work done with minimal internal IT process overhead and friction.

vCAC simplifies portfolio management in two main ways:

  • Policy-based service definition – Through vCloud Automation Center, users can request and manage their compute resources within established operational policies – cutting IT service delivery times. Users can build specifications into vCAC that contain the automation policies that specify the inputs needed and actions required to maintain your portfolio.
  • Improved service transition – Moving a new service out of the portfolio and into the catalog where it can be used requires keeping the portfolio and catalog elements up-to-date and aligned with each other. With vCAC, release and ongoing management functions are built into the tool set, and thus both automated and massively simplified.

One way to think of what’s changed here is in terms of oversight versus enablement. Traditional ITSM can be geared as much as 80% towards oversight, with just a 20% focus on the people who actually go and do the work. The vCAC approach flips that around.

Oversight is still essential, and it’s built in to the new model.  Prior to vCAC, traditional ITSM involved significant initial investment, top heavy input requirements, with repetitive multiple touch points to senior management., vCAC presents fewer, better-designed gates to your workflow, so you can work both safely and fast while gaining the agility that comes with a true cloud environment.

It’s About Standardization

The key to giving cloud consumers the services they want as quickly as possible, while still keeping the necessary corporate controls in place, is standardization.

Under vCAC’s blueprint model, service elements (e.g. backup, capacity, and provisioning requirements, security and other policies etc.) are preapproved to sit in the catalog and are thus ready to be deployed in new ways whenever they’re needed. In other words, if an item is in the catalog, and you have authority to access it, then you can provision at will – without having to go up the chain of command every time you want to respond to customer demand.

The result:

  • Fast efficiency processes focused on quickly and efficiently delivering new services to users, so that users don’t feed the internal IT machine.
  • Simplified processes with policy-based service definition capability and improved service transition, business agility and time to market.
  • Automated interfaces between the service portfolio and service catalog, with minimal resources and overhead required.

And you do it with higher quality, and at scale. With a set of preapproved blueprints and policies, it’s much easier to address increases in either the volume or variety of demand that you want to meet, and do it in a way that is more deterministic and improves service quality over time.

What’s more, you’ve done all that while reducing your company’s overhead and the resources you need to draw on.

With the help of vCAC, your portfolio management is simpler, more agile, more efficient and faster-to-market, too.

This is the first in a series of posts we’ll be writing about service portfolio management in a vCloud ecosystem. Next up, we’ll go deeper in to the simplified, three-step process of vCloud portfolio management.

Be sure to follow @VMwareCloudOps for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags.