Welcome to the Professor

Please join in the conversation. The Professor is always happy to respond to your questions and hear your ideas!
Email itsmprofessor@itsmacademy.com.

Tuesday, May 16, 2017

KPIs and SLAs

A short while ago I was asked this question from one of our reader: “I want to set a KPI around how much of the time we meet the SLA. Like 'meeting the SLA x% of the time'. Can someone advise what would be that 'x'? What is the common practice?  Is there an industry standard around this?”  I’m going to have to go with the consultant answer and say it depends.   First, are we talking about a single service to a single customer? Are we talking about multiple services to multiple customers or somewhere in between those two extremes?

Your SLAs should include details of the anticipated performance that your customer expects.  First thing you need to do is discuss with your customer what are the levels of utility and warranty they are expecting? Then document and agree these targets are reachable given the resources that are at your disposal and any constraints that may be discovered. The requirements for functionality (utility) should be defined by your BRM process and documented in the SLR document.

When you say that we want to meet SLA x% of the time, there are many factors that could have an impact on your ability to meet or not meet that target. How well are these services documented in your service portfolio and catalog? How mature is your Service Level Management process, Incident and Problem Management processes?  How often do you have to allow for changes to services, which could possibly impact the availability of your service?   These and other factors can have a distinct impact on meeting SLAs.  So here are a couple of KPIs you might want to explore:
  • KPI: Total number and percentage increase in the number of SLAs in place
  • KPI: Percentage increase in SLAs agreed against operational services being run
  • KPI: Frequency of service review meetings
  • KPI: Reduction in average response time to outages and incidents
  • KPI: Reduction in outstanding (unresolved) problems for services being delivered
  • KPI: Percentage increase on issues being raised at service and SLA review meetings that are being followed up on and resolved
  • KPI: Increase in number of services with timely reports and active service levels
I hope this will be enough to get you started and stay busy for a while.  Good luck! 

For more information on KPIs and SLAs, consider ITSM Academy's ITIL Foundation and check out our Free Resource Center

Tuesday, May 9, 2017

Site Reliability Engineering

Site Reliability Engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations with the goal of creating ultra-scalable and highly reliable software systems.  Google’s mastermind behind SRE, Ben Treynor, describes site reliability as “what happens when a software engineer is tasked with what used to be called operations.”

Historically, Dev teams want to release new features in a continuous manner (Change). Ops teams want to make sure that those features don’t break their stuff (Reliability). Of course the business wants both, so these groups have been incentivized very differently leading to what Lee Thompson ((formerly of E*TRADE) coined the “wall of confusion”.  This inherent conflict creates a downward spiral that creates slower feature time to market, longer deployment cycles, increasing numbers of outages, and an ever increasing amount of technical debt.

The discipline of SRE can begin to reduce this dilemma by introducing multiple analytics and statistical analyses for green- or red-lighting launches and help to resolve the extreme focus of stability vs. agility, operational work vs. software engineering and proactive vs. reactive work. These SRE teams are staffed with developer/sys-admin hybrids who not only know how to find problems, but according to Googles Melissa Binde “figure out why it happened, what was the root cause, figure out how to detect it sooner and ideally insure that it doesn’t happen again”.  Sounds a lot like ITIL’s Problem Management process only on steroids.

So at a basic level here is how I understand this works.   As we all know from years of experience, and just being human, nothing is perfect. None of our services ever really achieve 100% uptime; it’s why we invented SLAs. Take it from someone who used to write them.  This is the concept I think is just so cool.  If a team agrees to a 99.8% SLA, it gives them an “error budget” of 0.2%.  This is the maximum allowable threshold for service interruptions. The production team can utilize this error budget however they see fit and in turn release whenever and whatever they want given they are within the SLA.  They get green-lighted based on past performance. If they are operating at or below the defined SLA, all launches are red-lighted until they reduce the number of errors to a level that allows the launch to proceed. SREs (Ops) and developers (Dev) have a strong incentive to work together to minimize the number of errors. This ties completely into the cultural and professional movement known as DevOps, which stresses communication, collaboration and integration between software developers and operational professionals while automating the process of software delivery and infrastructure changes. 


For more information; www.itsmacademy.com/devops

Tuesday, May 2, 2017

What’s New in IT?

What isn’t? With the internet of things there are so many options available to consumers that were not available even one month or one week ago.   With technology and job role functions evolving so fast, the best way to stay current is to become educated.  Here are just a few bits of interesting information.

New for Every Day Consumers:
In a recent update Google’s Virtual Globe has introduced a feature called "Voyager." No longer will you be limited to only exploring places you've heard about, nor will you have to resort to randomly clicking on areas of the planet in hopes of finding a gem. Instead, "Voyager" presents you with dozens of curated journeys around the globe. Each voyage is centered around a theme. “Museums Around the World” will take you to a Street View of museums in every corner of the globe. If natural formations are more your speed, "Earth View" will show you "the most striking and enigmatic landscapes available in Google Earth." And… if that does not excite your there are 3d glasses to use with Google Earth that will really make your view realistic.  Not only is the world evolving but how we view it is evolving too.

New Uses for Technology:
Drones. You have probably seen them and heard of them being used for espionage and for research.  I found it interesting to know that drones armed with sensors helped researchers study a volcanic eruption in Guatemala. Now think about the technology that supports services for your organization. Not only is there a lot of legacy hardware and software that doesn’t fit for today’s products and services, new ways to utilize the technology are continuously evolving, like the drone.

New IT Jobs:
New demand for new types of jobs and skillsets are evolving as you read this. Many include titles that would have been meaningless only a year or two ago:

Augmented Reality Designer
Internet of Things Architect
Container Developers
DevSecOps Engineer

Info World reports that it is no surprise, given that the IT job market is in constant flux with new technologies emerging so quickly, that hiring managers struggle to define those positions - let alone give them a title. IBM, for example, has a Director of Blockchains, and Ford Motor is among many companies looking for GPU Cluster Engineers.

New Education:
For more information regarding ITIL Best Practice, Agile Service Management (Agile and beyond), DevOps certification and more, look here!

Tuesday, April 25, 2017

Pace-Layered Application Strategy

Historically, many companies have had a single strategy for selecting, deploying and managing applications. They have had a defined structure for classifying applications by value or functionality, but failed to recognize that applications are fundamentally different based on how and when they are engaged by individuals and the organization as a whole and the pace at which these tools need to be changed and updated.  Many organizations are finding themselves with an enterprise application strategy that fails to satisfy the needs of the business community, which has often led to underutilized applications throughout their portfolio.

Gartner’s Pace Layered Application Strategy is a methodology for categorizing applications based on how they are used and how fast they change.   This strategy helps IT organizations rationalize the use of DevOps practices that ensure a faster response and a better ROI, without sacrificing integration, integrity or governance requirements. The strategy has defined three application categories, or "layers," to distinguish application types and help organizations develop more appropriate strategies for each:
  • Systems of Record — Established packaged applications or legacy homegrown systems that support core transaction processing and manage the organization's critical master data. The rate of change is low, because the processes are well-established and common to most organizations, and often are subject to regulatory requirements.
  • Systems of Differentiation — Applications that enable unique company processes or industry-specific capabilities. They have a medium life cycle (one to three years), but need to be reconfigured frequently to accommodate changing business practices or customer requirements.
  • Systems of Innovation — New applications that are built on an ad hoc basis to address new business requirements or opportunities. These are typically short life cycle projects (zero to 12 months) using departmental or outside resources and consumer-grade technologies. (1)
Yvonne Genovese, vice president at Gartner said ”One of the keys to using pace layering is to take a more granular approach to thinking about applications.  When classifying applications in pace layers, they must be broken down into individual processes or functions.  Gartner analysts said that one of the keys to developing this strategy is listening carefully to the way business people describe their vision for particular parts of the business. These categories of ideas include:
  • Common ideas — aspects of the business in which leaders are happy to follow commonly accepted ways of doing things that change fairly slowly.
  • Different ideas — aspects of the business in which leaders not only want to do things differently from comparable organizations, but also can specify the details of how the different approach should be taken, and can expect these details to change on a regular basis.
  • New ideas — aspects of the business in which leaders are thinking of an early stage concept, and are not at the point where they can be specific regarding the details of how things should work. (2)
By engaging in Pace Layered Application Strategy, DevOps practices, along with a strong Business Relation Management (BRM) process, we can realize the goals of collaboration and integration while using technology to automate the process of software delivery and infrastructure change, while providing a secure and cost-effective environment to support core business processes.


1&2 Source: Gartner - Pace Layered Application Strategy - http://www.gartner.com/newsroom/id/1923014http://www.itsmacademy.com/resourcecenter

Tuesday, April 18, 2017

Big Bang - DevOps

I learned about ‘The Diffusion of Innovation Theory’ in a DevOps Foundation training course.  I wanted to get my DevOps certification but more than that to learn about what makes a DevOps initiative successful.   When I mentioned the Diffusion of Innovation Theory to a coworker he said “It sounds like Sheldon talking to Raj on “The Big Bang Theory” TV series.  Although the name sounds Big Bangish the usage of this theory could be the real difference for success in any transformational change including DevOps.

To start let’s begin with the definition of DevOps. DevOps is a professional and cultural movement that that stresses communication, collaboration, integration and automation in order to improve the flow of work between software developers and IT operations professionals. Improved workflows will result in an improved ability to design, develop, deploy and operate software and services faster. That’s where this “Big Bang” or Diffusion of Innovation Theory comes in.   DevOps is a culture shift.

DevOps is a cultural movement that requires us to shatter the silos and to quickly integrate our teams to increase the flow of work from idea to end of life for the strategy, development, deployment and the sustaining of service over their life. Adoption of a new idea, behavior, or product (i.e., ‘innovation’) does not happen simultaneously in a social system. It is a process whereby some people are more apt to adopt the innovation than others.  Researchers have found that people who adopt an innovation early have different characteristics than people who adopt an innovation later.  Learning what those characteristics are and then how to apply the proper technique for each will help with the management of organizational change.

The Diffusion of Innovation is a theory that seeks to explain how, why, and at what rate new ideas and technology spread.  While most of the general population tends to fall in the middle categories, it is still necessary to understand the characteristics of a given target population. When promoting an innovation there are different strategies used to appeal to the different adopter categories.

Innovators – want to be the first to try the innovation. They are venturesome and interested in new ideas. These people are very willing to take risks and are often the first to develop new ideas. Very little, if anything, needs to be done to appeal to this population.
Early Adopters – represent opinion leaders. They enjoy leadership roles and embrace change opportunities. They are already aware of the need to change and so are very comfortable adopting new ideas. Strategies to appeal to this population include how‐to manuals and information sheets on implementation. They do not need information to convince them to change.
Early Majority – rarely leaders, but they do adopt new ideas before the average person. That said, they typically need to see evidence that the innovation works before they are willing to adopt it. Strategies to appeal to this population include success stories and evidence of the innovation's effectiveness.
Late Majority – skeptical of change and will only adopt an innovation after it has been tried by the majority. Strategies to appeal to this population include information on how many other people have tried the innovation and have adopted it successfully.
Laggards ‐ bound by tradition and very conservative. They are very skeptical of change and are the hardest group to bring on board. Strategies to appeal to this population include statistics, fear appeals, and pressure from people in the other adopter groups.

When promoting an innovation to a target population, it is important to understand the characteristics of the target population that will help or hinder adoption of the innovation. The Diffusion of Innovation Theory could be the “Big Bang” that you are looking for to ensure the success of your DevOps initiative.


Tuesday, April 11, 2017

Security in a DevOps Environment

Integrating Development and Operation teams as well as other functions that have previously been silo’d is key to any development project for all service providers today.   We hear a lot about this in DevOps training and certification classes.   What about security?  You may have heard the term DevSecOps.  This idea and term was coined to ensure that architects and developers include into our requirements and code those things necessary for security. Design architects will also want to ensure that security is integrated throughout the value stream of development, deployment and operations and it is done in such a way so that the complexity is as transparent as possible to the functional teams involved.   How can we do this without impeding our flow of work?    How can we still be able to meet compliance for legislative, legal or regulatory requirements relating to security?

This is where Automation comes in.  Collaboration and measurement are key values but automation is also needed to ensure success here. We hear a lot about Continuous Delivery and Continuous Deployment.  Those knowledgeable about this know that these practices include integrated/ automated testing at the same time as we commit code and complete the build.  We cannot simply disregard security. Developers, security architects and testers will be integrating the security requirements in addition to those required for the functionality of the application/code.   Simply put, in DevSecOps we are designing for security and doing that while we design and integrate the code for the functionality of a product or service.  To do this you will need to have clearly defined roles and responsibilities for integrated requirements, integrated development and integrated teams.

Developers, auditors and other members of this integrated system will need to be trained or retrained on how to develop secure code.  They will need to understand those elements required in the code to ensure it is resilient.  If the developers of an application know the security requirements prior to development, the code will look very different.   We no longer want to put security on as a wrapper after the code is developed.  Even though a single team may be responsible, different people in the team will assume different roles. The scope of their capabilities can be managed.  To do this organizations will need support for common DevOps toolchain environments and include security into each. 

For more information relating to DevOps and DevSecOps please see http://www.itsmacademy.com/devops

Tuesday, April 4, 2017

BRM Convergence

I remember reading a quote “Every business today is a technology company” or something close to that. As we move from business-IT alignment to business-IT integration and now convergence, it is becoming more and more critical to understand and manage both the business and IT capabilities so that integration of the business strategy, IT strategy and the IT portfolio are seamless.  In today’s business climate it is imperative that the IT organization not only understand what the business strategy is, but be able to initiate and deliver services that not only support it, but help to shape it.  The Business Relationship role, process and capability is integral in making that happen.

One of the tools that can be engaged to help facilitate this convergence is the “Business Capability Roadmap.   It is made up of three key components:
  • Roadmap Business Capabilities: Identifies how business capabilities need to change to achieve defined strategies.
  • Roadmap Enabling Capabilities: Identifies how provider capabilities need to change in order to underpin new business capabilities.
  • Assess Enterprise Opportunities:  Explores how new provider capabilities will be engaged across the enterprise.
The benefit that the organization derives from this activity is that we understand where the business is taking key capabilities over the next 3 to 5 years so that we can appropriately support its strategic objectives.  We can then ally business and provider processes, information, services and technology to a common vision and mission.  This will accelerate strategic thinking versus short term thinking. It drives the conversation forward to increase understanding between the business and the provider which results in the ability to identify enterprise opportunities more quickly allowing us to be more agile in the delivery of new or improved services.


For more information please see http://www.itsmacademy.com/brmp