Stakeholders Services Service Management System (SMS) Providers Suppliers Value Flow Design & transition Strategy & GRC Learning & improvement Development Release & deployment Change & configuration Customers Users Things Worth Managing Promotion Support Delivery Human-Led Service Configuration IT-Led Service Configuration Human-Led Service Qualities Budgeting & accounting Systems and tools People Service IP Service Kits Service Collateral Facilities (Human-Led) Software Applications Data Platform Runtime Middleware Operating System Infrastructure Virtualization Server Storage Network Hardware Reliability (Human-Led) Responsiveness Trustworthiness Empathy Attractiveness Availability Manageability Serviceability Performance Reliability (IT-Led) Recoverability Discoverability Security Integrity Credibility Compliance Usability Internationalization Accessibility Adaptability Interoperability Scalability Elasticity Trustworthiness (IT-Led) Value Flow Portability Extensibility Facilities (IT-Led) Service functionality Service qualities Marketing Advertising Uptake Event handling Incident handling Request handling Problem handling Major incident & disaster handling Stakeholder relations Administration Provisioning, metering & billing Service Configuration Desired states Best practices Community Service management Open Service Management (OSM) IT-Led Service Functionality

Stakeholders

Services

Service Management System (SMS)

Providers

Suppliers

Value Flow

Design & transition

Strategy & GRC

Learning & improvement

Development

Release & deployment

Change & configuration

Customers

Users

Things Worth Managing

Things worth managing: Stakeholders, Value Flow, Services, Service Management System (SMS)

Promotion

Support

Delivery

Human-Led Service Configuration

IT-Led Service Configuration

Human-Led Service Qualities

To be added

Budgeting & accounting

TBD

Systems and tools

People

Service IP

Service Kits

Service Collateral

Facilities (Human-Led)

Software

Applications

Data

Platform

Runtime

Middleware

Operating System

Infrastructure

Virtualization

Server

Storage

Network

Hardware

Reliability (Human-Led)

Responsiveness

Trustworthiness

Empathy

Attractiveness

Availability

Manageability

Serviceability

Performance

Reliability (IT-Led)

Recoverability

Discoverability

Security

Integrity

Credibility

Compliance

Usability

Internationalization

Accessibility

Adaptability

Interoperability

Scalability

Elasticity

Trustworthiness (IT-Led)

Value Flow

Portability

Extensibility

Facilities (IT-Led)

Service functionality

Service qualities

Marketing

Advertising

Uptake

Event handling

Incident handling

Request handling

Problem handling

Major incident & disaster handling

Stakeholder relations

Administration

Provisioning, metering & billing

Service Configuration

Desired states

Best practices

Community

Service management

Open Service Management (OSM)

IT-Led Service Functionality

 

Open Service Management®

OPEN COMMUNITY-DRIVEN BEST PRACTICE

Open Service Management Foundation Body of Knowledge

Version 1.0, January 1, 2018

Your comments and feedback are welcome. If you’d like to contribute directly, contact us at [email protected].

Open Service Management® (OSM) Foundation, 2018 Edition

The Open Service Management Alliance

The Open Service Management Alliance

100 South King Street, #100 Suite 201, Seattle, WA 98104

Copyright information

©2017 the Open Service Management Alliance. All commercial use rights reserved under Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0). Used under license of the Open Service Management Alliance. Open Service Management® (OSM®) is a registered trademark of the Open Service Management Alliance. The OSM® Logo is a registered trademark of the Open Service Management Alliance. Used under license of the Open Service Management Alliance.

Foreword

There have been many changes in IT since the last major publication of traditional ITSM guidance in 2007. These changes have left practitioners with a formidable task, and a giant hole.

The formidable task comes in two parts. Part one is extrapolating from decade-old guidance to apply to today’s stakeholders, value flow, services, and service management principles, concepts and practices—all of which have changed substantially over 10 years. Part two is trying to compile what to do from the myriad of emerging practices, including DevOps, Agile, and Lean.

The giant hole is simple: should we attempt all this work, there is a 100% guarantee that whatever we come up with will not match what our colleague in the next cubicle over had done, let alone what our suppliers and tool vendors have come up with.

What is missing is a common framework that assumes a current environment (a hybrid of traditional and cloud), that compiles current best practices, in a format that is easy for traditional ITSM practitioners to grasp; that updates, but does not replace, traditional ITSM guidance as found in ITIL, ISO 20000, and so on, and that reaches out to cloud native practitioners unfamiliar with ITSM, or who seek a lightweight, modern approach attuned to their ways of working.

This last point is important. For service management to be relevant today, it must be useful to individual practitioners, lean, and lightweight. It was that way in the beginning; service management got its start with Jan Carlzon’s idea of focusing on key “moments of truth”, empowering individual contributors to solve problems quickly in the moment, armed with information; this is precisely the kind of thing the DevOps, Lean and Agile movements call for, and why often proponents of these movements are allergic to service management in its currently received view.

Somewhere along the way (in my estimation, during the reengineering era), service management got refactored into something process and management heavy. It was not that way at its start, and Open Service Management seeks to return service management back to its lean and lightweight roots, with a focus on value and outcomes (the “ends in mind”) versus processes and hierarchical management structures (one “means”, or, one could argue, one obstacle to achieving those ends in mind).

The big, audacious goal of this volume is to provide a body of knowledge to fill that gap.

If you are an ITSM practitioner, Open Service Management (OSM) Foundation will bring you up to date on current practices; if you are unfamiliar with cloud/mobile practices, like DevOps, Agile, and Lean, it introduces you to these concepts through the familiar lense of ITSM.

If you are a cloud native, OSM Foundation introduces you to concepts you will find useful, in an up-to-date format you can grep.

If you are reading this forward, and this book, you are probably aiming to increase your knowledge and capability to further your career and the objectives of your organization. I wish you the best of luck in these, and all your endeavors.

One final thing: this is a labor of love. We are a small band of people trying to help our industry advance with open standards, in an agile (think GitHub) way. If you don’t see something in this content that you’d like, that’s because it needs you. Please consider sharing your talents and treasure, your subject matter expertise, not just on service management, but on promoting the content, running a website, running a consortium, moderating forums, and so on. We need lots of help, and yes, your tax-deductible contributions to [email protected] will help, too.

Gina Scarpello

Philadelphia, PA USA

June 17, 2017

Preface

I got my first “big boy” job in IT at Johnson & Johnson / McNeil Consumer Products in the mid-1980’s. It would be another 10 years before I would hear about IT service management. I spent a good deal of time and effort over those 10 years trying to extrapolate from what was available at the time, i.e., somewhat outdated guidance specific to a particular traditional vendor and platform of the time (the IBM blue books, and Digital Equipment Corporation’s “Building Dependable Systems” come to mind) as a basis for figuring out how to manage the new platforms I was dealing with, e.g., PC networks and applications.

After Johnson & Johnson, I went to work for an IT consulting company engaged in outsourcing; a key problem we had was articulating how we were going to run the piece of their organization they would outsource to us (certainly, with, “best practices”), and what our responsibilities would be as providers, and what theirs would be as subscribers.

I tripped over ITIL in 1997 when I got a flyer in the mail for a Foundation course. I initially threw it out and later picked it out of the trash and signed up. My instructor was David Ratcliffe :). I was excited to find a vendor-/platform neutral approach to managing IT. At the time, I was a voice in the wilderness in the US, one of only a handful of practitioners applying and promoting IT service management in the US.

In the decade that followed, I was excited to benefit from and contribute to the IT service management body of knowledge. It was a real treat going over to the UK to the itSMF conferences, and working with other IT professionals with a passion for IT service management. IT was a real thriving community, that provided a good reason to contribute back.

The last significant update of an IT service management body of knowledge was with ITIL V3 in 2007 (there was a revision in 2011 for conciseness, but the core principles and the target environment were the same as in 2007).

It doesn’t take a lot of cogitation to realize there has been a sea change in IT in the decade since 2007. While many IT service management principles remain evergreen–the “what to do” and “why to do”, the typical target environment has shifted to traditional + cloud + hybrid, and the “how to do”—the best practices—what people actual do today that works–has changed dramatically as well, as evidenced by the emergence of DevOps, Agile, and Lean best practices.

In fact, every facet of IT has experienced significant change–stakeholders (customers, users, providers, suppliers), value flow, services, service management.

In my work with clients I see them facing the same scenario way back in the day when I got started, and the similarities are striking. They are putting massive amounts of effort into extrapolating from guidance that’s a decade old, that is aimed at a target environment that doesn’t exist anymore for them. What’s more, they’re needing to assemble a view of what to do from a balkanized set of emerging best practices. For those brave souls who attempt this work, their reward when they finish “rolling their own” is 100% assurance that what they’ve come up with isn’t the same as that of the person over in the next workstation, let alone at another company.

This is a sad and wasteful situation for our industry. We need some sort of lightweight frame that lays out the evergreen “what and why” of service management for those new to the subject, i.e., DevOps practitioners, a frame they find useful. We need a frame that describes best practices that are suited to the typical environment we find ourselves managing–traditional/hybrid/cloud. And we need a frame that puts new best practices into context–so that IT service management practitioners can learn and understand them and put them to use, and so that newcomers familiar with these practices can see how the fit into the service management frame.

In the end we need a common, ubiquitous, lightweight framework that is “good enough”. By “we” I mean everyone–individuals in IT, end user IT organizations, and the vendors that service them–including those who provide platforms and tools, as well as consulting and training services.

It makes even less sense in the gig economy of today than it did a decade ago to not have a common frame. We tend even more so traverse many organizations–a “universal decoder ring” of a common frame and common language certainly would help us all to better understand and be understood.

And for such a frame to be successful, it has to be like it was back in the day–open–where we all had a reason to contribute to the community because the benefits of doing so were obvious.

And that is why we wrote Open Service Management Foundation, 2018 Edition. Our dream is to give service management back to the practitioners, to seed a thriving community that can once again take IT service management where it needs to go, with fresh, living, relevant, timely content and community.

We envision this content–a lightweight, open framework; a consortium (to shape the direction of the content), and a community (to drive new and fresh content while benefit from interchange of ideas). We are excited again about the future of service management and hope you will join us in our excitement and come along with us on this journey.

David Pultorak

Pultorak & Associates, LTD

Seattle, WA USA

May, 2017

Table of Contents

Chapter 1: Introduction to Service Management and Open Service Management 11

1.1. Things worth managing 11

1.2. Desired states and force field analysis 12

1.3. Best practices: Deterministic, Adaptive, Emergent, Mode 1 & 2 14

1.4. How things worth managing, desired states and best practices relate 18

1.5. Stakeholders of service management 18

1.6. Value, value flow and their characteristics 19

1.7. Service and its characteristics 20

1.8. Service management and its characteristics 26

1.9. Service management system (SMS) and its characteristics 27

1.10. Open Service Management (OSM), its characteristics and structure 29

1.11. The OSM training and certification path 32

Chapter 1 Summary 33

Chapter 2: Stakeholder Concepts, Desired States and Practices 35

2.1. Stakeholders – the four main stakeholders of service management 35

2.2. Stakeholder: Customer definition, desired state and practices 39

2.3. Stakeholder: User definition, desired states and practices 41

2.4. Stakeholder: Providers definition, desired states and practices 43

2.5. Stakeholder: Suppliers definition, desired states and practices 46

Chapter 2 Summary 48

Chapter 3: Value and Value Flow Concepts, Desired States and Practices 49

3.1. Value and its characteristics 49

3.2. Value flow in relation to value 50

1.3. Value stream and value stream mapping 51

1.4. Lean, its relation to value and the five lean principles 53

1.5. Agile, its relation to value and the four agile statements of value 54

1.6. Value flow definition, desired state and practices 55

Chapter 3 Summary 56

Chapter 4: Service Concepts, Desired States and Practices 57

4.1.1. Overall Service definition, desired state, practices 57

Introduction 4.1: Service Configuration concepts, desired states and practices 64

4.1.2. Service configuration definition, desired state, practices 65

4.1.3. Human-Led service configuration 68

4.1.4. IT-Led service configuration 71

4.1.5. IT-Led service configuration: Software 75

4.1.6. IT-Led service configuration: Applications 76

4.1.7. IT-Led service configuration: Data 77

4.1.8. IT-Led service configuration: Platform 78

4.1.9. IT-Led service configuration: Runtime 80

4.1.10. IT-Led service configuration: Middleware 80

4.1.11. IT-Led service configuration: Operating system 81

4.1.12. IT-Led service configuration: Infrastructure 83

4.1.13. IT-Led service configuration: Virtualization 84

4.1.14. IT-Led service configuration: Server 86

4.1.15. IT-Led service configuration: Storage 87

4.1.16. IT-Led service configuration: Network 88

4.1.17. IT-Led service configuration: Hardware 90

4.1.18. IT-Led service configuration: Facilities 91

Chapter Section 4.1 Summary 93

Chapter Section 4.2: Service Functionality & Qualities concepts, desired states and practices 94

4.2.1. IT-Led service configuration: Applications 95

Chapter Section 4.2.1. Summary 97

4.2.2. Service Qualities definition, desired states, practices 97

Chapter Section 4.2.3: Human-Led Service Qualities concepts, desired states and practices 101

4.2.3. Human-Led Service Qualities definition, desired states, practices 101

4.2.4. Human-Led service quality: Reliability 105

4.2.5. Human-Led service quality: Responsiveness 106

4.2.6. Human-Led service quality: Trustworthiness 108

4.2.7. Human-Led service quality: Empathy 110

4.2.8. Human-Led service quality: Attractiveness 111

Chapter Section 4.2.9: IT-Led Service Qualities concepts, desired states and practices 113

4.2.9. IT-Led Service Qualities definition, desired states, practices 113

4.2.10. IT-Led service quality: Availability 116

4.2.11. IT-Led service quality: Manageability 118

4.2.12. IT-Led service quality: Serviceability 120

4.2.13. IT-Led service quality: Performance 121

4.2.14. IT-Led service quality: Reliability 123

4.2.15. IT-Led service quality: Recoverability 125

4.2.16. IT-Led service quality: Discoverability 126

4.2.17. IT-Led service quality: Trustworthiness 127

4.2.18. IT-Led service quality: Security 128

4.2.19. IT-Led service quality: Integrity 130

4.2.20. IT-Led service quality: Credibility 132

4.2.21. IT-Led service quality: Compliance 133

4.2.22. IT-Led service quality: Usability 135

4.2.23. IT-Led service quality: Internationalization 136

4.2.24. IT-Led service quality: Accessibility 138

4.2.25. IT-Led service quality: Adaptability 139

4.2.26. IT-Led service quality: Interoperability 141

4.2.27. IT-Led service quality: Scalability 143

4.2.28. IT-Led service quality: Elasticity 144

4.2.29. IT-Led service quality: Portability 146

4.2.30. IT-Led service quality: Extensibility 147

Chapter 4 Summary 149

Chapter 5: Service Management System (SMS) Concepts, Desired States and Practices 155

Introduction 5.1: SMS concepts, desired states and practices 155

5.1.1. SMS definition, desired states, practices 155

Chapter Section 5.2: SMS Design & transition concepts, desired states and practices 155

5.2.1. SMS Design & transition overall definition, desired state, practices 155

5.2.2. SMS Design & transition: Strategy & GRC definition, desired state, practices 159

5.2.3. SMS Design & transition: Learning & improvement 160

5.2.4. SMS Design & transition: Development 164

5.2.5. SMS Design & transition: Release & deployment 166

5.2.6. SMS Design & transition: Change & configuration 168

Chapter Section 5.3: SMS Promotion concepts, desired states and practices 172

5.3.1. SMS Promotion overall definition, desired states and practices 172

Chapter Section 5.3 Summary 174

Chapter Section 5.4: SMS Support concepts, desired states and practices 175

5.4.1. SMS Support overall definition, desired state, practices 175

5.4.2. SMS Support: Event handling 178

5.4.3. SMS Support: Incident handling 180

5.4.4. SMS Support: Request handling 182

5.4.5. SMS Support: Problem handling 184

5.4.6. SMS Support: Major incident & disaster handling 186

1.12. Chapter Section 5.4 Summary 187

Chapter Section 5.5: SMS Delivery concepts, desired states and practices 188

5.5.1. SMS Delivery overall definition, desired states, practices 188

5.5.2. SMS Delivery: Stakeholder relations 191

5.5.3. SMS Delivery: Administration 193

5.5.4. SMS Delivery: Provisioning, metering & billing 194

5.5.5. SMS Delivery: Budgeting & accounting 196

Chapter 5 Summary 198

Chapter 6: Getting Started with Open Service Management 199

Welcome and Introduction

This publication covers the foundational principles, practices, and terminology associated with service management, as described by the Open Service Management Alliance. It is divided into six main topics or chapters:

Chapter one, Introduction to Service Management and Open Service Management, introduces the concept of services and service management in general, and the structure and core concepts of Open Service Management.

OSM® has four components parts to its structure, four, “things worth managing”, and the next four chapters cover those parts. In each, core concepts are covered, along with desired states (basically, what good looks like), and best practices.

Chapter two, Stakeholders, covers stakeholder concepts, desired states and practices.

Chapter three, Value and Value Flow, covers value and value flow.

Chapter four, Services, covers services, including their parts (or configuration), features (or functionality), and qualities (or non-functional characteristics).

Chapter five, the Service Management System, covers the service management system (or SMS), which is your mechanism to ensure value flows through services to stakeholders, including design & transition, promotion, support and delivery desired states and practices.

Chapter six, Getting Started, provides suggestions for getting started, including tips for how to prepare for taking the OSM® Foundation certification examination.


Chapter 1: Introduction to Service Management and Open Service Management

This chapter defines core service management and OSM® concepts, including things worth managing, desired states, best practices, stakeholders, value and value flow, services, service management, and the service management system, and explain the training and certification path for OSM® Foundation.

After reading this, you should able to:

Explain what things worth managing are

Explain what desired states and force field analysis are

Explain what best practices are, and the three types: deterministic, adaptive, emergent, and two categories: mode 1 and mode 2

Explain how things worth managing, desired states, and practices relate

List and describe the stakeholders of service management

Define what value and value flow are, and their characteristics

Define what a service is, and its characteristics

Define what service management is, and its characteristics

Define what a service management system is, and its characteristics

Explain what Open Service Management is, its characteristics and structure

Explain the training and certification path for OSM®

Things worth managing

What are “Things worth managing?”

1Figure 01-01.1 Things worth managing

For all things worth doing, there are “things worth managing” for which we must aim to achieve and sustainably maintain a desired state. Service management is no exception; it has four, “things worth managing”: stakeholders, value and value flow, services, and the service management system.

OSM seeks to compile the generic set of things worth managing common to all providers as a starting point for desired state-based management of services. For every service provider, these are the generic set of things worth managing.

In addition, there are typically additional things worth managing due to the provider’s specific situation, tools used, and so on. The idea is that each service provider needs to identify their “things worth managing” and work to keep them in a “green” or “good” state.

Desired states and force field analysis

What is a desired state?

There are two main approaches to managing things worth managing: focusing on desired states (“ends”), or “means”; e.g., seeking to “minimize the business disruption of change, and know what changed” is a desired state or “end”; you might focus on this, or on “means”—e.g., engineering processes, etc.; OSM® describes means (best practices), but focuses on ends.

Many things can be barriers or enablers to achieving and maintaining desired states, e.g., a process or tool can be a means to achieving and maintaining desired states, or it can be a blocker, or some combination thereof, depending on how it was designed, tools used, organizational culture, cadence, etc.

In OSM®, desired states are written from the perspective of the service provider.

At its inception, with Jan Carlzon’s “Moments of Truth”, service management was lightweight, agile, and focused on outcomes, or ends, and interactions among people (“moments of truth”).

And while more traditional ITSM guidance sought to be outcome based, mentioning “What to do and why”, and giving an EXAMPLE of how, which may or may not be fitting for your environment or situation, quite often in practice people would apply this guidance with a focus on a heavy-handed how, layering heavyweight, end to end processes on top of the work, without a call to action for individuals, teams, and the organization to know and drive towards service management outcomes.

OSM instead returns to the roots of service management, and puts its focus squarely on outcomes, on maintain desired states for things worth managing. So for example, “changes” are a “thing worth managing”, with an outcome of, “we minimize the business disruption of change, and can track what changed”; a process could enable—or disable—this desired state.

OSM instead focuses squarely on outcomes, to ensure individuals and teams in organizations are aware of the things worth managing, and their desired states, and are working within their patch to drive to achieve and maintain desired states for things worth managing. They do this by making driving towards the desired state, “how we do things around here”, and by working to remove and reduce barriers and add and amplify enablers to maintaining those desired states.

Desired states – typical rollup states

2Figure 01-02.01 Desired state

In a typical monitoring system, you have four typical states for anything you are monitoring:

  1. Green means good, it’s in the desired state.
  2. Yellow means potentially or actually degraded in some way, for example, disk space is filling up or circuit utilization is high, which may be affecting performance
  3. Red means bad, dead, down, or critical.
  4. Grey means “unknown”—the thing worth managing is in an unknown state.

Think of it this way, if you join or start a service provider organization, and are responsible for managing it, you’ll want to know a couple of things. First, what is “it”? In other words, what are the things worth managing?

Once you know what “it” is, your first concern will be anything that’s red, or critical—how do we get that back online, to green. Next, you’ll want to address anything that’s degraded or potentially degraded—the yellow stuff. And lastly, anything that’s in an unknow state, you’ll want to get to a known state, and the make and reds, then yellows, green.

Force field analysis

Force field analysis, developed by Kurt Lewin, helps identify driving and restraining forces you must amplify and reduce to achieve a desired state. Here’s how: brainstorm enablers (driving forces), and barriers (restraining forces); identify actions to add or amplify enablers / remove or minimize barriers; prioritize based on effort and impact; pick a subset to go after to move towards the desired state.

Force field analysis is a key technique for achieving and maintaining desires states for things worth managing.

So, you’ve got these things worth managing, and they have a desired state that you want to achieve and maintain, sustainably. What’s a simple technique you can use to do that?

The most universally applicable technique is force field analysis. It works like this:

  • You are “here”. You’d like to be somewhere else. To get there, you ask, “what forces can we add or amplify to drive towards our goal?”; “what barriers are between us and our goal, and how do we minimize or eliminate them?”

3Figure 01-02.2 Force field analysis

  • You then look at the barriers and enablers and act to minimize or eliminate barriers, and add or amplify enablers, putting your resources to work on the subset of these that will give you the greatest “bang for your buck”.

When you think about build pipelines and continuous integration and delivery and the like, this is precisely what we are doing. We are removing barriers and amplifying enablers to increase flow. And in today’s organizations, we all do it—we all own the desired state, and we all pull on oars to get there.

Best practices: Deterministic, Adaptive, Emergent, Mode 1 & 2

What are best practices?

Best practices are things people are commonly doing now that work well when aiming to achieve and maintain desired states / desired states for things worthy of managing.

Best practices are not bleeding, or leading-edge practices; they are practices people are currently using that work across multiple organization, and are producing successful results.

Like traditional ITSM guidance, OSM® does not create best practices, but seeks to provide a platform that gives the IT community a reason to compile and maintain a source of current best practices, within a common structure that makes finding, understanding, applying, and improving them easier.

Traditional ITSM frameworks talk about best practices as being commodity practices, not bleeding, or leading edge, which is true; best practices should be common practices.

OSM defines best practices as, “what people are doing now that works”. This is important. Like more traditional ITSM frameworks, OSM compiles, rather than creates, best practice.

Unlike traditional ITSM frameworks, OSM endeavors to do this in an agile way, driven by community contributions, to ensure fresh, relevant content. The basis for this is that nowadays, without this approach, “best practice” guidance devolves into, “what people said they did years ago that worked for an environment that no longer exists”.

Now lets’ talk about the three types, and two modes of best practice OSM defines.

Three types of practices: deterministic, adaptive and emergent

There are three broad categories of practices—deterministic (like McDonalds), adaptive (like Agile / Scrum), and emergent (completely new-to-you, e.g., the first time doing container orchestration—there is no precedent).

All three are valid and can be enablers in some circumstance and barriers in others, or some combination of both; your goal should be to make sure there is a good match between the type of practices and your situation, and to be open to changing based on changing circumstances, e.g., target environment.

Figure 01-03.1 Three broad categories of practices

David Pultorak defines three types of practices: deterministic, adaptive, and emergent. This may sound fancy, but the basic idea is as follows.

First, if you’re going to do something repeatedly, and want consistent results, you’ll want to make it like a machine, or a coocoo clock—wind it up and it always produces the same result—those chicken nuggets always come out in so many seconds, and always look and taste like this. That’s deterministic. It’s appropriate for such situations.

Another situation is where what you will do—the activities you do, in what sequence, with what tools, for what duration, etc.—will change based on feedback loops. This is the domain of Agile Scrum projects. In them, you might have chapters or routines or patterns that you pull from, but precisely what you will do, you will adapt to the situation.

Lastly, you have emergent practices, like when container orchestration is a new thing and it’s the very first time you and others are trying it. There is no precedent, no roadmap, you are literally making it up as you go, with patterns and practices emerging along the way.

Why make these distinctions? Because quite often, in heavyweight implementations of service management, most or all emphasis is put on setting up deterministic, end-to-end processes, with no room left for what is adaptive or emergent.

OSM attempts to correct this by “shifting left” towards innovation and allowing room for all three modes of practice; the bottom line is all three are valid, as driven by the situation.

Two modes of best practices: mode 1 and mode 2

The target environment to be managed in current organizations is typically a hybrid of traditional / on premises IT and cloud. Each has unique and shared practices.

Figure 01-03.2 Two modes of best practices; Source: https://commons.wikimedia.org/wiki/File:Cloud_computing_types.svg

In addition to three types of practices—deterministic, adaptive, and emergent, there are two modes of practices, as driven by the target environment you manage.

Gartner calls these Mode 1 (traditional) and Mode 2 (cloud / mobile); OSM® tags the best practices it compiles as Shared, Mode 1 (traditional) or Mode 2 (cloud), or SH, M1, M2.

5Figure 01-03.3 Mode 1 and mode 2 best practices; Source: https://www.redhat.com/cms/managed-files/Rakesh_Kumar.pdf

“Mode 1” practices are ideally suited to traditional IT environments, things like traditional IT configuration management, where we work hard to have a good logical picture of the components of our environment, along with how they relate to one another.

“Mode 2” practices are ideally suited to cloud / mobile environments, things like infrastructure-as-code and immutable deployments, where the emphasis shifts in configuration management to making sure the code that is used to create things is good, because we know what things look like, as they are uniform (as they are “cattle”, not “pets”, as DevOps practitioners like to say).

Today, the typical IT environment is a hybrid of cloud and mobile; therefore, the typical practices are (or should be) an appropriate blend of the two.

How things worth managing, desired states and best practices relate

6Figure 01-04.1 How things worth managing, desired states and practices relate

So OSM seeks to compile current best practices, both mode 1 and 2. The idea is that you can apply the subset and blend of these that are suited to your environment, as a basis for driving towards and achieving and sustainably maintaining desired states, for things worth managing.

Stakeholders of service management

The four stakeholders of service management

Stakeholders are one of the four, “things worth managing” defined by OSM.

7Figure 01-05.1 Four stakeholders in service management

You should see some similarities and key differences here from traditional ITSM guidance.

First, the similarities: traditional ITSM guidance cites customers, users, and suppliers as stakeholders.

Now for the difference: more traditional ITSM guidance does not include the provider as a stakeholder in service management, perhaps because it is assumed that the provider is THE key stakeholder. Here, in OSM, we list the provider as a stakeholder, as the provider certainly does have a stake in the key outcomes of service management.

Value, value flow and their characteristics

What is value? And where does it reside?

Since value is in the mind of stakeholders, as providers we must influence both the reality of our services and their perception by stakeholders.

What is value flow?

Value flow is good when it proceeds to stakeholders with no undue stoppages, scrap, rework or backflows. Barriers to flow include inconsistency and variation (Mura) and overburden or unreasonableness (Muri). Enablers to flow include just-in-time (JIT) systems and corrections for overburdened and unreasonable practices.

Three other key differences between OSM and more traditional ITSM guidance are:

  1. The emphasis on value flow, in line with agile and lean practices.
  2. Value flow as multi-directional (in more traditional guidance, it flows in one direction, from the provider to the customer)
  3. Value as flowing to all stakeholders, with key stakeholders defined as customers, users, the provider, and suppliers

These differences are important, especially in the cloud portion of today’ typical hybrid environment. Teams are aligned around build pipelines and are working to make value flow unencumbers by inconsistency, variation and overburden. So, they get value flow, and their role in making it happen, and are creating and looking for best practices to help them do it.

Service and its characteristics

What is a service?

Services are one of four key categories of things worth managing in service management

Services can be internal or external, i.e., provided to customers and users in the same business entity as the provider; or to those outside of the provider’s business entity.

8 Figure 01-07.1 Customer and service provider

A service is a means of delivering value to customers by facilitating the desired states customers want to achieve, at (what should be) a lower cost and risk than doing it themselves, or other alternatives, and without the need to pay attention to all the details (or means) of delivering the service. The general idea—and you should be familiar with this because this is why you utilize services instead of simply doing it yourself, or using an alternative—is that you can focus on the ends, or outcomes, instead of the means, and because the service presents a better value in the end than doing it yourself or alternatives.

Services must also provide value to users, and value back to the provider and its suppliers, for services to be sustainable. Not that in this definition, the value flow is multidirectional; also, the nature of value is not just in new services and features, it is multi-dimensional; for example, value can flow back to the provider from customers and users in the form of feedback on services, feature sets, features, and new feature requests.

Services are comprised of three things worth managing: configuration, functionality and qualities.

9Services are comprised of their configuration, functionality and qualities

  1. Configuration (components / what it is made of) that constitute the service.
  2. Functionality (features / what it does) the service provides, including telemetry that facilitates direction and control of the service by the SMS.
  3. Qualities (characteristics / how it behaves) of the service, the non-functional “-ilities” of the service.

Each has a desired state to be achieved and maintained through best practices.

The service continuum – from goods to IT-Led services

A Service is some combination of an idea, physical good, or service a provider provides to customers and users; we are concerned with two types of services, Human-Led and IT-Led; we concerned with goods here only as components of services (e.g., a physical router) or as delivered by a service (e.g., PC install).

10 Figure 01-07.2 The Service Continuum; Source: Adapted from https://www.slideshare.net/vikashkumarbibhakar/godds-services-continuum slide 5

Goods are different in nature from services. For example, a candy bar is different from a haircut, and a Bluetooth speaker is different from Office365. Generally, goods are more tangible, storage, separable, and come in some sort of standard format.

On the other end of the spectrum, IT services tend to be delivered and consumed in the same moment; they are intangible, perishable, inseparable, and, like goods, standardized in quality.

And that’s the point: there’s a spectrum. We all have seen over the years how products have become service-like, and services have taken on product characteristics. It might be better to just call them all serv-octs or prodices, but all kidding aside, that’s what we’ve got on our hands. For example, that piece of software running on your desktop—it’s kind of a product, but now you download it digitally, you get updates, you get new features delivered in streams, you pay for it as a subscription—it’s getting servicy.

OSM is Open Service Management for the sake of simplicity and congruence with what came before, but it recognizes that we deliver value through products and services, and that there is a continuum. This acknowledgement—that we deliver value through products and services, and combinations of the two—is also a key departure from traditional ITSM guidance.

A further departure is that OSM acknowledges two key types of services—again, along a continuum—namely, Human, and IT led. Human-Led services are led by humans, assisted in varying degrees by automation; IT-Led services (like Office365) are primarily represented by the automation, with humans assisting on the back end to varying degrees.

This distinction is important because both Human-Led and IT-Led services are different in nature and have different characteristics to tend to. The lack of this distinction in more traditional ITSM guidance led some practitioner to some degree of confusion with, for example, what to put in their service catalogs.

Services are of two types, Human-Led and IT-Led

Services of two types:

  1. Human-Led Services, performed by humans, e.g., moves, adds and changes; technology may assist / facilitate, but the primary driver is human, and
  2. IT-Led Services, e.g., AD, DNS, etc.; technology is the driver, humans may assist / facilitate.

11Services are of two types, Human-Led and IT-Led

Other characteristics of services

12Figure 01-07.3 Other characteristics of services

Servicers are means for a provider to deliver value to customers and users and return value back to the provider and its suppliers by facilitating desired states customers and users want to achieve and sustainably maintain. Characteristics of services include:

  • Services can be provided in whole or in part by suppliers
  • Service can be fully or partially automated or manual
  • Services can involve the provision of goods, e.g., replacement keyboard
  • End-services are what that the customer recognizes and pay for; they typically include sub-services (e.g., updates, DHCP)
  • Services can be broken down into types, e.g.,
    • Core services (e.g., for mobile phone service, dial tone),
    • Optional services (e.g., data plan), and
    • Supporting services (e.g. backups, update)
  • Services can be stratified in tiers (e.g., gold, silver, bronze level packages)

Service management and its characteristics

What is service management?

In service management, we (the provider), present ourselves to customers and users as a set of services. We align all things—our capabilities, resources, activities, and systems—around this set of services. Our goal is to make sure we provide value consistently and sustainably. To do this, we make sure everything lines up behind the services, that we have, up front, the wherewithal to consistently delivery on service commitments.

Part of this is making explicit, discrete commitments; an important part of this is what we will do, but also, what we won’t do. The general posture towards customers and users should not be, “no”—often, a posture traditional IT shops are accused of—the problem with this is that customers and users don’t’ get the value they need when they need it. It should also not be, “yes”—to everything, another posture many traditional shops have—the problem with this is everything becomes “best effort”—i.e., you literally cannot count on the provider—not a good situation either.

The right posture is, “yes we can do it, and this is what it will cost”. In other words, we insist on having the wherewithal to consistently deliver on our commitments, or adjust what we commit to align to the wherewithal we do have.

In service management, we seek to align all our capabilities around services, including:

  1. Technical systems – equipment, databases, software systems etc.
  2. Managerial systems – for management of operations, including that of technical systems
  3. Learning systems – for the maintenance of personal and team skills and knowledge
  4. Cultural systems – for the regulation of values and norms, i.e., behaviors and objectives

The “bet” is that organizing around and presenting ourselves as a set of services is a superior operating model, that given the same set of resources, we will do better than if we simply organized around caring and feeding technology.

Service management system (SMS) and its characteristics

What is a service management system (SMS)?

The term, “service management system” may sound fancy or complicated, but it’s basically the sum of whatever mechanisms you have in place to make sure you have the right set of services, and that they are valuable.

The SMS must be a dynamic mechanism, because with the passing of time, stakeholder needs change, and new technologies create new possibilities, and so the value equation changes. As a result, we must continuously improve services, by adding or changing services, feature sets and features, and retiring services that no longer add value.

As you can see in the figure, a service management system can be broken down into Design & transition, promotion, support, and delivery. OSM handles these a bit differently than traditional ITSM frameworks, which position these as sequential phases and processes.

13Figure 01-09.1 Service Management System (SMS)

In OSM, these are going on simultaneously, not sequentially. In other words, while of course there is sequence in workflow, it is not helpful to, for example, put incident handling in one “phase” because “that’s where it first becomes important”.

OSM position these elements not as “processes”, but as “things worth managing”—in other words, each represents a key outcome or desired state that we want to achieve and maintain. The focus here is on ends, not means, as we know that a process is just one means to achieve an outcome, and that a broken process (or a focus on process without attention to other enablers), can disable as well as enable sustained achievement of desired outcomes.

Further, in OSM, we seek to focus on outcomes, as opposed to activities, as this is more lightweight, and suited to today’s environment and agile practices.

Open Service Management (OSM), its characteristics and structure

What is Open Service Management?

OSM is brought to you by the OSM Alliance, www.osmalliance.org, a non-profit whose mission it is to promote fresh, community-driven open content that is free for individuals and end user organizations to use and share and contribute to.

OSM is shared under a Creative Commons, Attribution-NonCommercial-ShareAlike, ”some rights reserved” license, which lets individuals and organizations remix, tweak, and build upon it non-commercially.

Licensing is required for commercial use. Commercial rights are reserved by the OSMA for OSM for the sole purpose of funding the OSMA’s operation, and OSM’s development and promotion. Sources of funding for the OSMA include exam fees, Authorized Training Organization (ATO) fees, and Authorized Consulting Organization (ACO) fees, all of which are nominal, as a source of funding for the OSMA’s development, promotion and operation.

The OSM is also funded through OSMA consortium member fees. Consortium member organizations can shape the direction of OSM content.

Importantly, the OSMA also supported by the generous donations of its members, both in terms of monetary donations, which are tax-deductible, and their contributions of the time and subject matter expertise to contribute to improving OSM to the benefit of our community.

All fees other than exam fees are annual.

To find out more about becoming an OSMA ATO, ACO or consortium member, contact the OSMA at [email protected].

14Figure 01-10.1 Open Service Management

This is figure is the Open Service Management (OMS) framework. OSM, and the OSMA, are intended to give today’s IT professionals a reason, and a much easier way to navigate, learn, and contribute to up-to-date, open best practices for managing today’s typical (hybrid Mode 1 / Mode 2, legacy and cloud / mobile) environments. Without a framework with up-to-date best practices, it is incumbent on each IT pro and organization to interpret older best practice guidance for application to their current situation, or to compile best practices from the myriad of emerging best practices, with 100% certainty that what the “roll” will not match what others do. The idea is that snapping to an open framework you can contribute to is a better bet.

Let’s dig in to the framework. As shown in the figure, everything above the line that says, “Things worth managing” are the things worth managing in service management:

  1. Stakeholders; (as you see on the left and right of the diagram, these are providers and suppliers, and customers and users); note two differences from traditional ITSM guidance: providers are considered part of the key stakeholder group
  2. Value flow; note here another difference from traditional guidance: value is show to flow multidirectionally, to all stakeholders, as this is needed to sustain a service
  3. Services; again different from traditional guidance, are subdivided into Human-Led and IT-Led services, and further apportioned into configuration (parts), functionality (features) and qualities (non-functional characteristics), all of which are “things worth managing
  4. The SMS; the mechanisms used to continuously and sustainably provide value to stakeholders over time and changing circumstances. The SMS is partitioned into Design & transition, promotion, support and delivery, which are not phases and processes, but sets of “things worth managing”, each of which has a desired state to be maintained.

At the bottom of the figure you see that the community produces best practices for achieving and maintain desired states for everything above the line, which are things worth managing.

What are Open Service Management’s characteristics?

Open Service Management (OSM) is a new and dramatically different set of best practice guidance for service management.

OSM has a couple of characteristics that make it unique.

First, OSM is strongly aligned to ISO 20000, and traditional ITSM guidance is strongly aligned to ISO 20000, it is compatible with traditional ITSM guidance. Said another way, it can be used alongside traditional ITSM guidance, and understood easily alongside it, as it shares some common framing and terminology.

Secondly, OSM is up-to-date – published in 2018. Traditional ITSM guidance can be over 10 years old, and a lot has changed since then, both in terms of the nature of the target environment that service providers manage, and the best practices—what they do that works—that suit current environments.

What’s more, OSM is meant to be fresh, relevant, community-driven content. This can happen because OSM is free to use for end-user organizations, and open (with some commercial rights reserved as a basis for funding), and uses an agile (think GitHub) method for development, This in turn provides both the ability to contribute, and a reason for doing so, unlike closed, proprietary traditional ITSM guidance.

OSM® is open for end-users, licensed under a Creative Commons Attribution-NonCommercial-ShareAlike “some rights reserved” license; this license lets you remix, tweak, and build upon OSM® non-commercially, if you credit the OSMA and license your new creations under the identical terms. The intention is that all end-users get OSM® for free, and to use it for free, and this freedom give them a reason to contribute to OSM®. OSM® features an open source pull-style mechanism so all IT pros and organizations can contribute.

OSM is also the product of a sustainable not-for-profit. Other traditional ITSM guidance is the product of for-profits; in the case of OSM, our primary driver is not profit, but the betterment of our community through affordable, ubiquitous, fresh, relevant, community-driven practices. O

SM is sustainable because some rights for commercial use are reserved on the license so to provide a revenue source for the non-profit that owns OSM®, the Open Service Management Alliance. The reserved rights include rights for Authorized Training Organizations (RTOs), Authorized Consulting Organizations (ACOs), and Authorized Product Organizations (APOs) to deliver training, consulting and products aligned to OSM®.

OSM is also light-weight. One small volume makes up the core OSM® Foundation body of knowledge (BOK); OSM® Foundation, a compilation of current best practices from, e.g., from Agile, DevOps, and Lean, suited for today’s enterprise, hybrid and cloud environments.

You can start contributing and benefiting from OSM today, by signing up as a member at https://osmalliance.org or contacting us at [email protected]

The OSM training and certification path

The path to OSM® training and certification is straightforward.

The first level is OSM® Foundation training and certification: 14 contact hours of training, followed by a 1-hour, 40-question exam, with 65% (26 of 40) to pass. The OSM Foundation training and exam are available since January 1, 2018. The only prerequisite for the OSM Foundation exam is that you must take the training from an Authorized Training Organization. This helps fund the non-profit OSMA.

The exam is like traditional ITSM exams—one hour, 40 questions, 26 out of 40 to pass, multiple choice. Exam are offered by the OSM Authorized Examination Institute (AEI), Acquiros.com.

For those who’d like to continue, there is OSM® Practitioner training, which has3 types: 1) General, 2) Situational, and 3) Tool-driven

Each practitioner training is a 35 contact-hour course with a 1-hour, 20-question multiple choice exam, with 65% is required to pass, worth 10 points towards Master.

OSM® Masters certification is achieved by any combination of 34 points.

15Figure 01-11.1 OSM® Training and Certification Path

OSM practitioner courses are under development. The idea here with practitioner is to provide content that helps you apply what you learned in foundation generically (practitioner—general application), or to specific situations, like small shops or regulated environments (practitioner—situational application), or with specific tool chains (practitioner—tool-driven application).

If you would like to contribute to these bodies of knowledge, please contact the OSMA at [email protected].

Chapter 1 Summary

Service management is a set of specialized organizational capabilities in the form of a service management system (SMS) for managing the resources required to provide value to customers and users in the form of services.

Things worth managing are the small set of critical things—stakeholders, value flow, services, and the SMS—for which a service provider must aim to achieve and sustainably maintain desired states.

There are four key categories of things worth managing in service management:

Stakeholders, those who have a “stake” in service management desired states: customers, users, providers, and suppliers.

Value flow, which in the multidirectional stream of value through services to stakeholders

Services, means for providers to deliver value to customers and users by facilitating desired states customers and users want to achieve.

Service management system (SMS), a set of interrelated or interacting mechanisms that service providers use to direct and control their service management activities.

A desired state is a state of “goodness” to achieve and maintain, sustainably, for a thing worth managing. It is the continuous “end in mind” for things worth managing.

Best practices are things people are commonly doing now that work well when aiming to achieve and maintain desired states / desired states for things worthy of managing.

Open Service Management (OSM®) is a new and dramatically different set of best practice guidance for service management that is free and open, with a mechanism to keep it fresh and relevant, light-weight, and with two editions, enterprise and cloud.

The basic structure of OSM® consists of “things worth managing” for service providers, in three key categories—stakeholders, value flow, services, and the SMS, for each thing worth managing, OSM® identifies a desired state that the provider must achieve and continuously maintain to sustainably provide value to customers and users; lastly, it provides best practices—things IT pros are doing now that work—for achieving desired states for things worth managing.

OSM® Foundation training is 14 contact hours with a 40 question 1-hour simple multiple choice exam with 65% required to pass, worth 4 points towards master certification.


Chapter 2: Stakeholder Concepts, Desired States and Practices

In this chapter, we will introduce the concept of stakeholders, and their desired states (that is, what “good looks like” for the state of stakeholders, the completion of the statement, “Performance is effective when:” for stakeholders.

We’ll also cover best practices for achieving and maintain desired states for stakeholders, sustainably.

So, let’s get started!

    1. Stakeholders – the four main stakeholders of service management

Stakeholders are one of four key categories of things worth managing in service management; there are four primary stakeholders in service management:

 

16Figure 01-05.1 Four primary stakeholders in service management

You should immediately see some similarities and key differences here in comparison to traditional ITSM guidance.

First, the similarities: traditional ITSM guidance cites customers, users, and suppliers as stakeholders.

Now for the differences: more traditional ITSM guidance does not include the provider as a stakeholder in service management, perhaps because it is assumed that the provider is THE key stakeholder. Here, in OSM, we list the provider as a stakeholder, as the provider certainly does have a stake in the key outcomes of service management.

Stakeholders are people or organizations with a vested interest in their being continual value from a provider’s services over time and through changes, including customers, users, the provider itself, and suppliers.

Providers are people or organizations that manage and deliver services to one or more internal or external customers.

Customers are people or organizations that pay for and receive services and are the primary judge of their value; they may be internal (a person or group in the same business as the provider) or external (a person or business in a separate legal entity from the provider).

Users are people or organizations who use services, including people who use the service but do not pay for it, and customers who pay for the service, in their role as a user of the service; they may be internal or external to the provider.

Suppliers are people or organizations that are 3rd parties, external to providers (not part of the provider’s legal entity) who supply providers with goods or services needed to deliver services to the provider’s customers and users.

The idea here is stakeholder are a key, “thing worth managing”, and when you have a, “thing worth managing”, the thing to do is to get clear on what the desired state is for that thing, which you can do by filling in the blanks on the sentence, “Performance is effective when…”, and then driving towards achieving and maintaining that desired state, over time and changing stakeholder needs and technologies possibilities.

So, let’s have a look at the desired states for stakeholders overall.

Stakeholders – desired states

Performance is effective when:

  • We know who all our stakeholders are, and what their stake in our services is, and we use this information to systematically maintain productive relationships and tailored communications with all key stakeholders, so there are no or few negative surprises
  • We continuously listen to stakeholders and use that listening to “get better reality”—make our stakeholder relationships, service, and service management system better—and “get better perception” – set stakeholder expectations and manage stakeholder perceptions systematically
  • When asked, all stakeholders indicate they are pleased with the value they are getting from our services, or are confident, if there is a gap, that we are working to close it and capable of doing so

Unidentified stakeholders (and therefore, stakeholders where the relationship and value have no chance of being systematically kept in a desired state) represent a risk to the service provider.

The idea is to put mechanisms in place to ensure customers, users, members of the provider organization itself, and suppliers are kept in a desired state of “goodness”.

A lot of this can be accomplished through listening posts and feedback loops.

The desired states stated here may not be precisely right for your situation. The idea with OSM is not to provide a set of desired states, “for all time”, but to provide a structure, and example that you can contribute to, and adapt for your purposes.

Stakeholders – practices

Some of the practices you can use to achieve desired states for stakeholders include:

  • Stakeholder analysis / mapping / management

  • Stakeholder satisficing
  • Moments of Truth
  • Getting better reality (Guy Kawasaki)
  • Tailored, crisp communication (Mary Munter)
  • Feedback loops
  • Satisfaction = Perception – Expectation (David Maister)
  • Conditions of Satisfaction (Winograd & Flores)
  • Customer experience management (CEM)
  • User Experience

Again, as with desired states, the practices we mention here are not meant to be an exhaustive list, valid for all time, and so on. They are meant instead as a starter list, which you can contribute to as part of the community.

We will not, in this volume, describe each practice. What we will do is mention them, to get the conversation going, with the assurance that you know how to use a search engine to find out more, and that if you have a different idea or want to expand on any of these, you can contribute.

Three further points here:

First, the OSM Foundation exam is based on this publication, and so the syllabus does not require you to define each of these best practices, but only to recognize some of them from a list.

Secondly, the practitioner – general application volume will address these in more detail; sign up today at https://osmalliance.org if you’d like to contribute.

Thirdly, what we will do in this publication is to give an example of at least one best practice.

So, with that having been said, here’s one example: Satisfaction = Perception – Expectation (from “Managing the Professional Service Firm”, pg. 71): One of the simplest laws of service delivery is that if a stakeholder’s expectations exceed their perceptions, they will be dissatisfied. This is especially significant because a client’s perceptions and expectations may not necessarily reflect reality. Therefore, the achievement of stakeholder satisfaction requires the management of both stakeholder expectation and perception.

    1. Stakeholder: Customer definition, desired state and practices

Customers – definition and two types: internal and external

Customers are a key stakeholder in service management.

Customers are individuals, organizations, or units within organizations that pay for services, may specify requirements for new services and service improvement, and who are the primary judge of the value of services; they may be internal to the service provider (a person or group within the same legal entity as the provider) or external (a person or business or business unit within a separate legal entity from the provider); customers who pay for services may also be users of those services.

Customers – desired state

Let’s have a look at the desired state for customers.

Performance is effective when:

  • We have a good working relationship with “pay the bills” customers by seeking to both understand and shape customer needs, and by working to ensure those needs are met through the right set of services, which are informed by both changing customer needs and technology possibilities
  • We automate our relationship with customers, and that automation facilitates satisfaction (versus being a blocker to it), e.g., through a portal where they can administer their subscription, make requests, log incidents, etc.
  • We know which services are used by what customers, and to what extent
  • Conflicts with and among customers are rare, but when they do occur, it is easy for the customer to escalate, we handle them promptly and effectively
  • We take the time to understand the value of our services from the customers’ perspective, and not just our own, and use that understanding to manage both the reality and perception of our services
  • Customers are highly satisfied with, and continue to buy services, refer us, rarely complain, are engaged, and when asked, speak positively about us services, and say they meet their requirements and compare well against alternatives, as business conditions and technology and the value equation changes over time

There is a distinct difference between a customer, who pays the bills, and a user of a service, who does not. If you have children, and they have mobile service on your plan, you are the customer, and they are the users. You and your children are in distinctly different roles relative to the service, and the provider, to be successful, must recognize this, and have mechanisms in place to keep each of you in a desired state of happy with their service.

Customers – practices

Some practices that can help you achieve and maintain the desired state for customers include:

  • Customer experience management

  • Business relationship management
  • Self-service portals
  • Public status pages
  • Multi-channel support
  • SERVQUAL
  • Service level management
  • Service catalog management
  • Service portfolio management
  • Service reporting
  • Service reviews
  • Service improvements
  • Service retirement

One example of a practice is public status pages (or transparent uptime).

A public status page gives you a place to transparently show information about the availability and performance of your services. You can post announcements, update current issues, and allow people to opt-in to notifications.

In his blog on transparentuptime.com, Lenny Rachitsky gives four points he recommends as prerequisites for doing public status pages

  1. Admit failure. Really own it.
  2. Sound like a human.
  3. Have a communication channel.
  4. Be authentic.

02-02. Stakeholders – Customers – Definition, desired state, best practices

    1. Stakeholder: User definition, desired states and practices

Another key stakeholder of service management besides customers who pay the bills for services are uses.

Users literally use—interact with your service, product, website or app. You want to make sure these are easy for them to use.

Users – desired state

Performance is effective when:

  • We have a good relationship with users of our services; we seek to understand and shape user needs, and meet those needs through our services.
  • Users say they are highly satisfied with, and continue to use services, refer us to others for services, rarely complain, are engaged, and when asked, speak positively about our services
  • We take the time to understand the value of our services from the users’ perspective, and not just our own, and use that understanding to manage both the reality and perception of our services
  • We automate our relationship with users, and that automation facilitates satisfaction (versus being a blocker to it), e.g., through a portal where they can make requests, log incidents, etc.
  • Users say our services help them meet their objectives, and that they are getting higher value from our services as compared to alternatives, including doing it themselves, at a lower effort and risk

Some additional indicators of effective performance:

  • Users see us as providing the right mix of services, each with the right mix of features and attractive quality
  • Users are happy with the features (including the pace of introduction of new features), performance, service levels and support for our services
  • Users understand the terms of our service and their responsibilities as users of our service(s)
  • This feedback is steady over changing services, time, and circumstance, including fluctuations in user demand for our servicesand changes in the user environment

Users – practices


Some practices that can help you achieve and maintain the desired state for users include:

  • User experience management (UX)
  • Self-service portals
  • Service desk
  • Public status pages
  • Multi-channel support
  • User satisfaction surveys
  • User training
  • User story
  • Continuous Delivery

One example: Continuous Delivery, which enables users to start using new functionality and qualities quickly to realize value and provide feedback sooner.

Continuous Delivery, or CD, is about automated implementation of the application build, deploy, test and release processes meant to ensure performance (fast delivery) and conformance (to requirements), enabling users to start using new functionality and qualities quickly to realize value and provide feedback sooner.

It may be useful to you to differentiate between the different types of users, to ensure the mechanisms you have in place to ensure they are in a “good” state of happiness are differentiated enough based on their roles, needs and expectations.

Users – definition and types: end, super, and admin

There are different types of users; each type must be recognized and systematically “loved” to ensure satisfaction; user types include:

  • End users (whose role is limited to using the service and asking for support or service items they are entitled to)
  • Super users (users who have some level of administrative privilege
  • for other users, e.g., to assign roles within a project system)
  • Admin users (who administer a subscription / service for others, for
  • example, Office365 admin users)

Now let’s have a looks at the next key stakeholder in service management: the provider. OSM’s inclusion of providers as a stakeholder in service management is a departure from traditional ITSM guidance.

    1. Stakeholder: Providers definition, desired states and practices

Stakeholders – Providers – definition

There are several types of provider staff, each of which must be recognized and systematically related to, including:

  • Developers
  • Infrastructure Engineers
  • Support staff
  • Delivery staff
  • Managers

For sustained success at service provision, it is imperative that team members within the provider are satisfied with their work.

https://www.thebalance.com/improve-employee-satisfaction-1917572 indicates this is a function of respectful treatment, fair compensation, benefits, job security, trust, opportunities to use skills and abilities, financial stability of the organization, the employee’s relationship with their immediate manager, feeling safe in the work environment, and the employee’s immediate manager’s respect for their ideas.

Stakeholders – Providers – desired state

Performance is effective when:

  • We maintain a positive, effective and sustainable working relationship among provider staff
  • We get good value out of our providing services, and customers and users and suppliers do as well
  • We automate our relationships internally among different parts of our provider organization, and that automation facilitates satisfaction (versus being a blocker to it), e.g., through a portal where provider staff can make requests, log incidents, etc.
  • We take the time to understand the value of our services from the suppliers’ perspective, and not just our own, and use that understanding to manage both the reality and perception of our services
  • We hire the right people in the first place, and they happy, healthy, and productive, with a service orientation, continuously learning and innovating, rarely complain, are engaged, and when asked, speak positively about their job and our organization

Some additional indicators of effective performance:

  • Our people have the right skills, knowledge, and mindset to succeed, and are good at managing, facilitating meetings, communicating clearly, negotiating and problem solving
  • We make time for continuous learning, development, and improvement, about things:
    • to achieve and maintain the desired state of things worth managing
    • required to understand what makes customers and users successful and how our services contribute to that, including new technologies that provide advantages
  • We have good financial performance
  • We have the resources (money, infrastructure, applications, information, people), capabilities, and authority to succeed
  • We have clear and shared goals and objectives
  • We have capabilities that are hard for competitors or customers to duplicate
  • We manage both the reality and perception of our services
  • We have good financial performance
  • We have satisfied customers
  • Our people are aware of our business objectives and those objectives inform what they do

Providers – practices


Some practices that can help you achieve and maintain the desired state for providers include:

  • Hiring the right people in the first place
  • Employee engagement
  • CAMS
  • OLAs
  • RACI
  • Roles: Process owner, manager, practitioner; service owner
  • Affinity (DevOps)
  • Blameless Culture (DevOps)
  • Collaboration (DevOps)
  • Communication, Osmotic (DevOps)
  • Self-organizing Teams
  • Product Owner (in Agile Scrum)
  • Roles: Service Owner, Scrum Master, Scrum Team, embedded teams
  • Scaling (of DevOps or Agile Scrum)

Best practices must be aimed at the reality and perception of the employee on the following parameters: respectful treatment, fair compensation, benefits, job security, trust, opportunities to use skills and abilities, financial stability of the organization, the employee’s relationship with their immediate manager, feeling safe in the work environment, and the employee’s immediate manager’s respect for their ideas.

One example of a practice for driving towards desired states for the provider is embedded teams. The DevOps practice of embedded teams can help bring down barriers between disparate, siloed teams. An embedded product team consists of all the people and skills needed to independently take product all the way from requirements to delivery. In DevOps, which is Dev + Ops, the place to start is by embedding Dev representatives in Ops teams, and vice versa.

Source: alistair.cockburn.us/Osmotic+communication

Now let’s have a look at the last of four key stakeholder groups that OSM identifies, suppliers.

    1. Stakeholder: Suppliers definition, desired states and practices

Stakeholders – Suppliers – definition

There are many types of suppliers, each of which must be related to systematically, including:

  • Commodity, tactical and strategic suppliers
  • Goods suppliers and service suppliers
  • Transactional suppliers and subscription-based suppliers

Examples of suppliers include:

  • Hardware vendors
  • System software vendors
  • Network vendors
  • Application vendors
  • DBMS vendors
  • Goods vendors
  • Services vendors
  • Hosting companies

Stakeholders – Suppliers – desired state

Performance is effective when:

  • We get good value out of suppliers, and suppliers get good value out of supplying services to us
  • We know who our suppliers are, including contacts, contracts, and historical performance, and we regularly review contracts for suitability / performance
  • Our contracts have the right legal language to protect us and our relationship with the supplier
  • Contractual disputes are rare, but when they do occur, we have an effective process for resolving them
  • We automate our relationship with suppliers, and that automation facilitates satisfaction (versus being a blocker to it), e.g., through a portal where they can view and report performance against contracts, etc.
  • We do not have to deal with the day to day details of the costs or risks associated with the services suppliers provide us
  • We have the right balance between what we do internally and what is outsourced to suppliers

Other indicators of effective performance include:

  • Suppliers consistently meet or exceed our business needs and contractual commitments for the goods and services we depend on from them
  • We have a good relationship with suppliers, and we proactively manage their performance
  • Contract terms with all suppliers are good
  • We are not using expensive / higher risk / custom supplier services and goods where cheap / low risk / commodity services and goods will do
  • Supplier staff know our key business desired states and how their services support them
  • Supplier staff are aware of our patterns of activity, and carry out their activities with this knowledge in mind, avoiding issues
  • Supplier transitions go smoothly
  • When we manage stakeholder relations, services and the SMS, we take into consideration the suppliers’ patterns of business activity
  • We have an effective an efficient process for renewing and terminating contracts
  • We ensure all supplier contracts support business needs and provide value for money
  • We sign up for the right contracts in the first place, with the right commitments in them
  • Suppliers used and the goods and services we acquire from them are aligned to our supplier policies, and are compliant with applicable regulatory requirements
  • We categorize our suppliers from commodity to strategic, based on the value and risk they present to us; we use this information effectively to apportion our time to suppliers in managing their performance appropriately, in proportion to their importance to us
  • Suppliers consistently meet the commitments incorporated in our contracts with them
  • While finance and legal may be involved in ensuring supplier contracts are sound, we take ownership for making sure contracts support services and service level and manage the performance of suppliers to their contractual commitments.

Stakeholders – Suppliers – practices

Some practices that can help you achieve and maintain the desired state for suppliers include:

  • Supplier management – contacts, contracts, performance
  • Vendor value management
  • Contract management
  • Underpinning contracts
  • Supplier categorization
  • Cloud cost containment

One example of a practice is supplier categorization. The Kraljic Portfolio Purchasing Model was created by Peter Kraljic and first appeared in the Harvard Business Review in 1983.

The model involves four steps:

  1. Purchase classification
  2. Market analysis
  3. Strategic positioning
  4. Action planning

You can use this model to classify your suppliers and apportion your time during the year according to whether they are strategic suppliers, commodity suppliers, or somewhere in between.


Chapter 2 Summary

Stakeholders, along with services and the service management system, are one of the four categories of things worth managing in OSM®

There are four primary stakeholders in service management: 1) customers, 2) users, 3) the provider, and 4) suppliers

As providers, we seek to continuously provide value to stakeholders through services over time and through changes by achieving and sustainably maintaining desired state for things worth managing through best practices

For services to be sustainable, value must flow multidirectionally to all stakeholders

There are desired states for each stakeholder; many shared, mode 1, and mode 2 practices exist to help providers achieve and maintain those states.


Chapter 3: Value and Value Flow Concepts, Desired States and Practices

In this chapter, we’ll cover concepts of value and value flow, to help you describe value and value flow in service management, its desired state, and best practices for achieving that desired state, including:

  • 03-01. Define what value is, and its characteristics
  • 03-02. Describe value flow in relation to value
  • 03-03. Define value stream, and describe value stream mapping
  • 03-04. Describe Lean, its relation to value, and the five lean principles
  • 03-05. Describe Agile, its relation to value, and the four agile value statements
  • 03-06. Value flow – Overall definition, desired state, best practices
    1. Value and its characteristics

What is value? And where does it reside?

As you can see from this definition, value is in the mind of stakeholders. That being the case, as providers we must influence both the reality of our services and their perception by stakeholders.

Here again you should see some similarities and differences between OSM’s conception of value, and that of tradition ITSM guidance.

One key difference from traditional ITSM guidance is that while in OSM, the pay-the-bills customer is the PRIMARY arbiter of value (as without them, you have no business), all stakeholders have a stake in value, and a perspective that must be honored for sustainable success.

Another key difference is that in OSM, value must flow multidirectionally, that is, in all directions, among all stakeholders (customers, users, the provider, and suppliers) for a service to be sustainable.

When is a service valuable to stakeholders?

For customers, a service is of value when it is attractive as compared to alternatives, in terms of price, risks, and effort required (including the need to attend to details), and where what is gained exceeds what is lost by using it, and where it helps achieve outcomes whose worth exceeds the service cost.

For users, a service is of value when it helps them achieve a desired outcome without undue effort as compared to alternatives.

For the provider, a service is of value if it results in profits, enhanced market share, competitive advantage, capability, compliance, safety, reputation, goodwill, and learning.

For suppliers, the service is of value if it results in the same outcomes as that of the provider, but for the supplier’s portion of the service, and for the supplier’s business.

So, you see, value is not the same for each stakeholder, because “what you see depends on where you sit.” Each stakeholder has a unique stake, and therefore, each service presents a different value equation for each.

    1. Value flow in relation to value

What is value flow?

Value flow is good when it proceeds to stakeholders with no undue stoppages, scrap, rework or backflows.

Barriers to flow include inconsistency and variation (Mura) and overburden or unreasonableness (Muri); enablers to flow include just-in-time (JIT) systems and corrections for overburdened and unreasonable practices.

You should see three other key differences between OSM and traditional ITSM guidance are when it comes to the subject of value:

First, OSM emphasizes not just value, but also value flow, in line with agile and lean practices.

Secondly, OSM positions value flow as multi-directional, among all stakeholders, defined as customers, users, the provider, and suppliers, as a basis for sustainability, where in traditional ITSM guidance, value flows in one direction, between two stakeholders: from the provider to the customer.

These differences are important, especially in the cloud portion of today’ typical hybrid environment. Teams are aligned around build pipelines and are working to make value flow unencumbers by inconsistency, variation and overburden. So, they get value flow, and their role in making it happen, and are creating and looking for best practices to help them do it.

    1. Value stream and value stream mapping

What is a value stream, and what is value stream mapping?

Value Stream mapping (VSM) is typically described in the following four steps:

  1. Identify the target product, product family, or service.
  2. Draw (preferably by walking on the shop floor or the virtual flow of information) a current state value stream map (CSVSM).
  3. Draw a future state (with waste removed) value stream map (FSVSM).
  4. Develop an action plan to work toward the future state condition, and implement the plan.

Value stream mapping is a critical technique in OSM, because the flow of value through services is critical to success at service management. There are many places to apply VSM. Your build pipeline is a no-brainer to start with if you haven’t already.

But keep in mind that value takes many forms and flow multidirectionally in our conception. So, for example, you can apply VSM to feedback loops between, for example, to amplifying feedback loops; for example, you could instantiate tighter feedback loops between BRM, strategy, continual improvement, and sprint planning and retrospectives. In this example, the core value that flows are knowledge—user and customer feedback, changing technology possibilities, changing business conditions—not code, as in a build pipeline. In general, you should seek shorter cycles and smaller, more frequent increments for all four, and that starts with understanding the value stream.

OSM draws on Lean principles and Agile values as a basis for delivering more value, faster, with quality and continual improvement.

17Figure 03-04.1 Lean and Agile and their relation to value

The five Lean principles are:

  1. Identify value
  2. Map the value stream
  3. Create flow
  4. Establish pull
  5. Seek perfection

The four Agile values are:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

The idea is to keep things lightweight—applying these principles and values to “things worth managing”, focusing on outcomes, not activities—focusing on every understanding and driving towards maintaining desired states, rather than a few engineering and enforcing heavyweight processes.

Let’s have a further look at Lean and Agile, as they are important principles and values for OSM.

    1. Lean, its relation to value and the five lean principles

Lean, its relation to value, and the five lean principles

18Figure 03-04.1 Five Lean Principles

Source: https://www.ame.org/sites/default/files/query_archive_docs/LeanGlossary_01_08_1.pdf, https://www.lean.org/WhatsLean/

The five lean principles as cited by ame.org are:

  1. Identify Value: When a product or service has been perceived or appraised to fulfill a need or desire–as defined by the customer–the product or service may be said to have value or worth. Components of value may include quality, utility, functionality, capacity, aesthetics, timeliness or availability, price, etc.
  2. Map the Value Stream: All the activities (both value-added and non-value added) required within an organization to deliver a specific service; “everything that goes into” creating and delivering the “value to the end-customer.
  3. Create Flow: The progressive achievement of tasks and/or information as it proceeds along the value stream, flow challenges us to reorganize the Value Stream to be continuous… “one by one, non-stop”.
  4. Establish Pull: Principle the no one upstream function or department should produce a good or service until the customer downstream asks for it. Pull is a system of cascading production and delivery instructions from downstream to upstream activities in which nothing is produced by the upstream supplier till the downstream customer signals a need
  5. Seek Perfection: A never ending pursuit of the complete elimination of non-value adding waste so that all activities along a value stream create value; perfection challenges us to also create compelling quality (“defect free”) while also reducing cost (“lowest cost”). Perfection is Complete elimination of waste (Muda) so that all activities along

Lean systems focus on the parts of the system that add value by eliminating waste everywhere else, whether that be overproduction of some parts, defective products that must be rebuilt, or time spent waiting on some other part of the system. Waste to be eliminated in these areas can include unnecessary software features, communication delays, slow application response times, and overbearing bureaucratic processes.

    1. Agile, its relation to value and the four agile statements of value

What is Agile, and what are the four Agile statements of value?

19Figure 03-05.1. The Agile Manifesto

“Agile” (with a capital A) refers to a set of frameworks used for development and management of programs and projects intended to make development quicker and smoother, and to create output that is more satisfying for the customer.

So far, you know that an Agile framework is one that uses an adaptive development lifecycle instead of a predictive one. Agility was around back in the 50s, where it was considered a strange and sometimes anarchistic viewpoint; in a time when the traditional method did not even have a name such as Waterfall, because it was the de-facto way of working.

The term “Agile” has become more and more established and was formalized by a group that prepared and signed a statement of values for Agile projects back in 2001, known as the Agile Manifesto.

Items on the right are obviously important but they are a means to an end. Often peple focus on items on the right, thereby spending energy (and time) on the wrong things. Items on the right are the things that really matter to a (business/customer) organization.

Now that we’ve discussed the nature of value and value flow, and how Lean and Agile principles and values can contribute to acheiving and maintaining them, let’s have a look at the desired state for value flow.

    1. Value flow definition, desired state and practices

Value and value flow – desired state

Performance is effective when:

  • Value flows to all stakeholders (customers, users, us (the provider), and suppliers) multidirectionally and unencumbered, with no undue stoppages, scrap, rework or backflows
  • When asked, stakeholders indicate they are pleased with the value they get from our services, both in terms of what they get, and the pace at which they get it
  • Value flows continually—over time and through changes—from services, to customers and users, and back to the provider and suppliers
  • The value from our services compares favorably to alternatives, because we have taken the time to seek out changing business needs and new technology possibilities, and to incorporate that looking and listening into our service
  • Uptake of services, features and feature sets is widespread in users and they are getting good value out of them

So, you see, performance is effective when value flows multidirectionally, to all stakeholders, and is sufficient for the sustainability of the service, as we change it continuously over time to account for changing stakeholder needs and technology possibilities.

What are value and value flow best practices?


Some practices that can help you achieve and maintain the desired state for value flow include:

  • The five lean principles
  • The four agile values
  • Value attribute tree
  • Value stream mapping
  • Feedback loops
  • Build pipeline
  • Continuous integration
  • Continuous delivery
  • Continuous deployment
  • Blue / Green Deployment

Here is one example: blue / green deployment.

Blue/Green Deployment is supplanting rolling upgrades as a method for releasing software code, where two environments, Blue and Green, are initially configured identically, with one active and the other environment inactive. New code is released to the inactive environment, where it is thoroughly tested; Then the active and inactive environments are switched. If problems are discovered after the switch, traffic can be directed back to the inactive configuration that still runs the original version. Once the new code has proven itself in production, the team updates the code in the inactive environment to match the active environment. The process reverses itself when the next software iteration is ready for release.

This technique eliminates downtime due to application deployment, and reduces risks and dramatically lowers the transaction cost and time required to revert to a prior known, good state; if something unexpected happens with your new version on Green, you can immediately roll back to the last version by switching back to Blue.


Chapter 3 Summary

Value is the worth in the mind of stakeholders, of a product or service.

Value must flow to all stakeholders multidirectionally for a service to be sustainable.

Value flow is the multidirectional stream of value delivered through services to all stakeholders, primarily customers, users, the provider, and suppliers.

Value is created and added through design, transition, promotion, support, and delivery activities (which can be fully or partly automated or manual), as an applied to a service and its associates configuration, features, and qualities.

Lean and Agile principles can help providers deliver value.


Chapter 4: Service Concepts, Desired States and Practices

This is the fourth chapter of the publication, where we focus on services, their constituent components, desired states, and best practices for driving towards desired states.

We’ll start with what a service is and then proceed to discussing its configuration (or parts), then functionality (or features), and qualities (or characteristics / behaviors).


      1. Overall Service definition, desired state, practices

What is a service?

Services are one of four key categories of things worth managing in service management.

Services can be internal or external, i.e., internal services are services provided to customers and users belonging to the same business entity as the provider; external services are provided to individuals and organizations outside of the provider’s business entity.

A service is a means of delivering value to customers by facilitating the desired states customers want to achieve, at (what should be) a lower cost and risk than doing it themselves, or other alternatives, and without the need to pay attention to all the details (or means) of delivering the service. The general idea—and you should be familiar with this because therefore you utilize services instead of simply doing it yourself, or using an alternative—is that you can focus on the ends, or outcomes, instead of the means, and because the service presents a better value in the end than doing it yourself or alternatives.

Services must also provide value to users, and value back to the provider and its suppliers, for services to be sustainable. Not that in this definition, the value flow is multidirectional; also, the nature of value is not just in new services and features, it is multi-dimensional; for example, value can flow back to the provider from customers and users in the form of feedback on services, feature sets, features, and new feature requests.

Services are comprised of three things: their configuration (or parts), their functionality (or features), and their qualities (that is, their non-functional characteristics). All are things worth managing.

What three things are worth managing when it comes to services?

20Figure 04-01-01. Human-Led and IT-Led things worth managing

Each of these “things worth managing”—a service’s configuration, functionality, and qualities—has a desired state to be achieved and maintained through best practices.

Here’s an example that may help clarify the difference between configuration, functionality and qualities, for an IT-Led service (adapted from https://ux.stackexchange.com/questions/47897/what-are-the-differences-between-features-and-components): Take Microsoft Word:

Its components:

  • spell-checker,
  • Page designer,
  • Word art etc.

Its features:

  • can detect your spelling mistake
  • you can customize page-design
  • you can draw simple arts, etc.

Its qualities:

  • Internationalization
  • Accessibility
  • Security, etc.

What are the characteristics of services?

Characteristics of services include:

  • Services can be fully or partially automated or manual
  • Services can involve the provision of goods, e.g., replacement keyboard
  • Services can be internal or external, i.e., internal services are provided to customers and users belonging to the same business entity as the provider; external services are provided to individuals and organizations outside of the provider’s business entity
  • End-services are what that the customer recognizes and pay for; they typically include sub-services (e.g., updates, DHCP); services can be broken down into core services (e.g., for mobile phone service, dial tone), optional services (e.g., data plan), and supporting services (e.g. backups, update); services can be stratified in tiers (e.g., gold, silver, bronze level packages)

In addition to these characteristics, services can be divided into two main types: human-led and IT-led.

What are the two main types of services?

21Figure 04-01-01.2 Human-Led & IT-Led Service Types; Source: Five modes regarding the role of technology in customer contact. Adapted from: Froehle and Roth, 2004, p. 3.

The two main types of services are:

1) Human-Led Services, performed by humans, e.g., moves, adds and changes; technology may be assist / facilitate, but the primary driver is human, and

2) IT-Led Services, e.g., AD, DNS, etc.; technology is the driver, humans may assist / facilitate.

As you can see from the figure, services sit along a continuum from technology to technology generated; we’ve adapted Froehle and Roth’s five modes of human and technology interaction model to help illustrate:

Technology-free customer contact, for example, the face-to-face contact between a psychological therapist and patient. This type of contact does not require the use of technology; thus, it is the most traditional and direct mode of customer contact.

Technology-assisted customer contact, for example, hotel check-in and check-out procedures, transactions conducted over manned bank counters, and passenger check-ins for airline boarding. During these processes, technology (i.e., a computer) is used by the service provider only. However, the customer and service personnel still experience face-to-face contact.

Technology-facilitated customer contact, for example, the use of Microsoft PowerPoint by a financial expert to present and discuss financial plans with customers during a conference. Although technology is used by both parties, face-to-face customer contact still occurs.

Technology-mediated customer contact, for example, telephonic interaction between service personnel and customers and the provision of professional advice by a consulting company using Videoconference technology. In these contexts, a shared technological platform is used by the service personnel and the customer without face-to-face contact.

Technology-generated customer contact, e.g., ATM withdrawals. In these, customers operate the technology without assistance of service personnel, and face-to-screen contact replaces face-to-face contact. Online shopping is an example of this mode.

We add a 6th one here, Human-free, where technology represents both the provider and the consumer of the service, as in EDI.

Let’s have a closer look at human-led and IT-led services.

What are Human-Led services?

22Figure 04-01-01.3 Human-Led Services

Human-led services include a continuum of use of technology, from none to integral, including:

  • Technology-free customer contact, for example, the face-to-face contact between a psychological therapist and patient. This type of contact does not require the use of technology; thus, it is the most traditional and direct mode of customer contact.
  • Technology-assisted customer contact, for example, hotel check-in and check-out procedures, transactions conducted over manned bank counters, and passenger check-ins for airline boarding. During these processes, technology (i.e., a computer) is used by the service personnel only. However, the customer and service personnel still experience face-to-face contact.
  • Technology-facilitated customer contact, for example, the use of Microsoft PowerPoint by a financial expert to present and discuss financial plans with customers during a conference. Although technology is used by both parties, face-to-face customer contact still occurs.

In the end, the defining characteristic of a human-led service is that humans (versus automation) are in the lead, taking the front position, representing the service to stakeholders.

In contrast, IT-lead services are primarily or wholly represented to stakeholders by technology or automation. Let’s have a closer look at these now.

What are IT-Led Services?

23Figure 04-01-01.4 IT-Led Services

IT-Led services include a continuum of technology involvement, from technology in the lead, supported by humans, to total representation of the service by technology. Here are some of the levels:

  • Technology-mediated customer contact, for example, telephonic interaction between service personnel and customers and the provision of professional advice by a consulting company using Videoconference technology. In these contexts, a shared technological platform is used by the service personnel and the customer without face-to-face contact.
  • Technology-generated customer contact, for example, ATM withdrawals, vending machine purchases, or coin-operated automatic photograph booth operations. In these processes, customers operate the technology without the assistance of service personnel, and face-to-screen contact replaces face-to-face customer contact. The recent trend of online shopping is considered an example of this mode.
  • Human-free, where technology represents both the provider and the consumer of the service, as in EDI.

Now that we’ve discussed human-led and IT-led services, it’s time to look at the desired state for services overall.

What is the desired state for services?

Performance is effective when:

  • We have the right mix of IT-Led and Human-Led services, with the right level of automation and human activities in each
  • We have rooted out of IT-Led services any unnecessary complexity, variation, and dependencies and any other factors that slow down stakeholders, services, and the SMS
  • Customers and users are happy with the value they are getting from our services and are sticking with us, because we as time and circumstances change, we listen to how their needs and value equation is changing, and understand and educate them on what new technologies can offer, and bring these two things together to continuously add, change, and remove services so our portfolio is compelling to them
  • We have both “better reality” and “better perception” in our services in the eyes of customers and users

Some additional indicators of effective performance:

  • Customers and users can focus on their “ends-in-mind” because we handle the details of the services we provide, and because we have (and they see we have) the specialized capability to provide the services they value at a lower cost, effort and risk than doing it themselves or as compared to alternatives
  • The provider (us) and our suppliers are happy with the value we are getting from providing services over time and through changes
  • Services are profitable, over time and across changes, because we add, modify, and remove services continuously to achieve and increase value as time passes and circumstances change

Services – practices

For services, overall best practices are divided into Human-Led and IT-Led, and within each, practices to achieve and maintain desired states for configuration, functionality, and qualities, as well as shared, mode 1 and mode 2 best practices suitable for all environments, traditional IT, and cloud environments

24Figure 04-01-01.1 Overall services best practices

04-01-01. Service – Overall definition, desired state, best practices

For services, overall best practices are divided into Human-Led and IT-Led, and within each, practices to achieve and maintain desired states for configuration, functionality, and qualities, as well as shared, mode 1 and mode 2 best practices suitable for all environments, traditional IT, and cloud environments. Configuration is what the service is made up of, it’s parts; functionality is its features / what it does; qualities are its characteristics / how it behaves.

Now, let’s have a look at the specifics for the configuration portion of services.


Introduction 4.1: Service Configuration concepts, desired states and practices

Service configuration definitions, desired states and practices

In this chapter, we’re covering topics that will help you describe the components that make up the configuration of services, their desired states, and best practices for achieving them, including:

  • 04-01-02. Service Configuration
  • 04-01-03. Human-Led Services
  • 04-01-04. IT-Led Services
  • 04-01-05. Software
  • 04-01-06. Applications
  • 04-01-07. Data
  • 04-01-08. Platform
  • 04-01-09. Runtime
  • 04-01-10. Middleware
  • 04-01-11. Operating System
  • 04-01-12. Infrastructure
  • 04-01-13. Virtualization
  • 04-01-14. Server
  • 04-01-15. Storage
  • 04-01-16. Network
  • 04-01-17. Hardware
  • 04-01-18. Facilities

Service configuration definitions, desired states and practices (120m)

To reiterate, in OSM, services are made up of three things: configuration (parts), functionality (features), and qualities (non-functional characteristics, like availability). This is the first section in chapter four, where we focus on definitions, desired states and practices for the configuration portion of services.


      1. Service configuration definition, desired state, practices

Service configuration – definition

25Figure 04-01-02.1 IT-Led and Human-Led services configuration

Source: adapted from https://ux.stackexchange.com/questions/47897/what-are-the-differences-between-features-and-components

An example may help illustrate the configuration component of a service: For a bicycle delivery service in a metropolitan area, the configuration would include the couriers, the fleet of bikes, the repair shop, etc. The features would include different size and type packages that could be dropped off. The qualities would include the delivery area, and so on.

Service configuration example: Human-Led service – Office365

26Figure 04-01-02.3 Human-Led service configuration example – Office365

You should see that the configuration, or parts, are distinct from the functionality, or features, and the qualities, or characteristics.

Each contributes (or takes away from) the value of a service, and as such, each need to be recognized and systematically managed.

Service configuration example: Human-Led service – device bar

26Figure 04-01-02.4 Human-Led service configuration example – device bar

You’ve probably visited the Apple Genius bar or the Microsoft In-Store Answer Desk at one time or another, or perhaps you have concierge-style support locations in you company.

Think about a few specific instances of when this has worked well for you (or not).

Were the positives or negatives driven by the configuration, functionality, or qualities of the service?

Now think about your services, along the same lines—this may give you an idea of where best to focus to improve achieving and maintaining desired states for these things worth managing.

Now let’s have a look at the configuration for human-led services.


      1. Human-Led service configuration

Human-Led service configuration – definition

Figure 04-01-03.1 Human-Led service configuration

Human-Led service components include:

  • People – the roles and individuals and teams that deliver the service and their skills, knowledge and mindset(s)
  • Service IP, kits, collateral—the knowledge and materials teams rely on to deliver services
  • Systems & Tools—for example, a process template for a process engineering engagement
  • Goods—for services where goods are involved, e.g., installing a new physical monitor
  • Facilities—for example, a physical location for concierge-style device support

Examples of human-led services include:

  • Moves, adds and changes
  • New hire setup
  • Legal hold
  • Consulting
  • Auditing practices

For value to be realized by stakeholders of your Human-Led services, you must keep the components of Human-Led services in good repair, so that they contribute to a desired state of being reliable, responsive, trustworthy, empathetic, and with good attractiveness.

You most certainly have been on the receiving end of Human-Led services, like getting your office moved, or using consulting services.

Think about a few specific instances of when this has worked well for you (or not). Were the positives or negatives driven by the configuration, functionality, or qualities of the service?

Now think about your services, along the same lines—this may give you an idea of where best to focus to improve achieving and maintaining desired states for service configuration.

Now let’s have a look at the desired state for service configuration for human-led services.

Human-Led service configuration – desired state

Performance is effective when:

  • People—individuals and teams that deliver the service, are the right people with the knowledge, skills and mindset, and are attractive
  • Service IP, kits, collateral—the knowledge and materials teams rely on to deliver services—is up to date, complete, and easy to locate, navigate and use

Source: https://en.wikipedia.org/wiki/SERVQUAL

“Attractive” in this sense does not mean that all our people are models, that all our facilities are slick, etc. It means at a minimum that they are not off-putting, and are suitable for the purposes of the service and its stakeholders. For example, there is one standard of dress you might expect a dollar store employee to have, and quite another for say, a Nordstrom salesperson. And if the dollar store fixtures were too expensive-looking, you might wonder what you’re getting for your dollar—similarly, if the fixtures in a Nordstrom’s were shoddy or cheap looking, you might be wondering if the t-shirt you’re buying is worth $30.

For value to be realized by stakeholders of your Human-Led services, you must keep the components of Human-Led services in good repair, so that they contribute to a desired state of being reliable, responsive, assurant, empathetic, and with good attractiveness. This means keeping the following in good order:

  • People—the individuals and teams that deliver the service
  • Service IP, kits, collateral—the knowledge and materials teams rely on to deliver services
  • Systems & Tools—for example, a process template for a process engineering engagement
  • Goods—for services where goods are involved, e.g., installing a new physical monitor
  • Facilities—for example, the tangible appearance of a physical service location

Human-Led service configuration – practices

Some practices that can help you achieve and maintain the desired state for value human-led service configuration include:

  • SERVQUAL Valerie Zeithaml and Mary Jo Bitner
  • Service IP, kits, collateral Thomas E. Lah
  • Systems and tools Thomas E. Lah
  • Goods TSIA
  • Facilities Micah Solomon

There isn’t a lot of good writing out there on packaging the parts of Human-Led service kits. One good source is Thomas E. Lah.

Now let’s have a look at IT-led service configuration.


      1. IT-Led service configuration

IT-Led service configuration – definition

Figure 04-01-04.1 IT-Led service configuration

An IT-Led services configuration is comprised of three layers: software, platform and infrastructure. For cloud environments, these are all, “as a service”; for traditional environment, they are not.

IT-Led services are services where IT takes the lead in representing the provider, anything from being an equal partner with humans, up to fully representing the provider to a human, and beyond—where the provider is represented by technology, and the consumer is, too, as in EDI.

IT-Led service configuration – definition

Infrastructure, Software, and Platform or IaaS, SaaS and PaaS

The IT-Led Services stack includes infrastructure, platform, and software components; in traditional IT, you are the provider for the entire stack; in the cloud, “as a service” model, you use an external service provider for:

In traditional IT, the software / platform / infrastructure stack is provided on-prem, and not “as-a-service”. In a cloud environment, each of these layers is provided, “as-a-service.”

The typical environment at the time of this writing is a hybrid of traditional IT and cloud, so it is important to recognize and systematically manage the configuration of both.

IT-Led service configuration – desired state

Performance is effective when:

  • We have the right mix of traditional and cloud-based IT-Led services, or are moving towards that mix at the right pace
  • We know what we have, what we are paying for and using (and we are not paying for stuff we aren’t using)
  • We have a balance of flexibility for choice of services for customers and users, but not such a proliferation of options that the work of customers and users is negatively impacted (learning curve, interoperability issues, etc.)
  • Our IT-Led service configuration “adds up” to consistently and sustainably support the levels of service expected by stakeholders, over time and through changing stakeholder needs and new technology possibilities

Knowing what you have so you can manage it sounds like a basic and expected thing, but the reality, with things like growth through acquisition, and the proliferation of people buying cloud services, is that it “ain’t necessarily so.”

Getting a good handle on what you’ve got out there is step one, both in a traditional and cloud environment. A key next step is extreme standardization on both; if, for example, you know all SQL servers look like so-and-so, and only come in a small, medium or large, it’s easier to grasp and manage the environment.

The same goes for dependencies; you can reduce them with techniques like inversion of control, and use of versioned API and data contracts.

Your enemy is irrational variation and dependencies, so rooting that out should be job one.

Think about how you spend your time each day. Why do you need to meet with others to discuss projects, or changes, or risks, etc.? There are two main drivers: variation, and dependencies. So, root those out relentlessly to reduce the overhead of managing your environment.

IT-Led service configuration – practices

Practices for achieving desired states for IT-led services configuration include:

  • Dependency reduction
  • Inversion of control
  • Versioned APIs
  • Data contracts
  • Microservices architecture / REST
  • Variation reduction
  • Immutable deployment
  • Infrastructure-as-code
  • Service mapping, and
  • Containerization

Knowing what you have so you can manage it sounds like a basic and expected thing, but the reality, with things like growth through acquisition, and the proliferation of people buying cloud services, is that it “ain’t necessarily so.”

Getting a good handle on what you’ve got out there is step one, both in a traditional and cloud environment. A key next step is extreme standardization on both; if, for example, you know all SQL servers look like so-and-so, and only come in a small, medium or large, it’s easier to grasp and manage the environment.

The same goes for dependencies; you can reduce them with techniques like inversion of control, and use of versioned API and data contracts.

Your enemy is irrational variation and dependencies, so rooting that out should be job one.

Think about how you spend your time each day. Why do you need to meet with others to discuss projects, or changes, or risks, etc.? There are two main drivers: variation, and dependencies. So, root those out relentlessly to reduce the overhead of managing your environment.

In the sections that follow, we’ll explore the parts of an IT-led services configuration, their desired states, and practices that can help you achieve and maintain them, starting with Software.


      1. IT-Led service configuration: Software

IT-Led service configuration – Software – definition

04-01-05. service configuration – Software – Definition, desired state, best practices

https://www.techopedia.com/definition/4224/application-software

Whether software is delivered in a traditional manner, or as a service, it must be the right software, fitting for the service(s) it supports.

IT-Led service configuration – Software – desired state

Performance is effective when:

  • We know what software we have, both licensed application software (mode 1) and SaaS (mode 2) and it is being used (we don’t have any application software or SaaS we don’t know about or aren’t using)
  • Software that is part of a service – we control its configuration in a known good state, and its functionality and service qualities meet what is required for the services by customers and users
  • Software includes not just a UI, but an API and command line interface, so that it can be integrated
  • Software is instrumented for direction and control by the SMS

Knowing what you have (software, licenses, etc.) is step one in understanding and managing your software configuration.

IT-Led service configuration – Software – practices

Best practices for software configuration include:

  • License management
  • SaaS software best practices
  • Cloud cost containment

An example: cloud cost containment.

It is typical now to find in organizations lots of unused seats, e.g., for Office365, that sit unused, or environments that were spun up in, e.g., AWS that nobody turned down. The problem is that the meter is running on this unused capability, and the resources going to waste there are typically sorely needed for things that will add value.

As a result, a new role is emerging in organizations for individuals and teams and technologies and policies that help identify dis-used resources and turn them off, and that make sure the organization has visualization into what is getting stood up and down, and used and not used. A further aspect of this role is identifying, from the services and feature sets and features being firehosed at the organization by vendors, what small subset of them are of high value, and therefore should be socialized within the organization to ensure value uptake. Similarly, for organizations that produce services, features, and feature sets and spew them at their own consumers, there is a need for a function in the provider organization to ensure uptake by consumers, to ensure value is as fully realized as possible.


      1. IT-Led service configuration: Applications

IT-Led service configuration – Applications – definition

Typically, at the time of this writing, most organization have a mix of traditional on-prem and locally running apps on devices and hosted or subscription-based apps.

IT-Led service configuration – Applications – desired states

Performance is effective when:

We have the right mix of Mode 1 / purchased applications that run locally on the client device, and Mode 2 / Software as a Service (SaaS applications) that are cloud- and subscription-based where a supplier hosts applications and makes them available to customers over the Internet

  • For applications, we buy or subscribe to, costs are in control, and we do not have an inordinate amount of purchased or subscribed applications that go unused
  • For applications, we buy or subscribe to, we know without undue effort, what new features sets and features are high value, and make sure they are taken up in the organization; for applications we make, we enable our consumers to do the same

Uptake for realization of value is a top concern for both providers of apps and their consumers. Regardless of what functionality an app has, no value is realized if the functionality goes unused. As the pace of feature introduction increases dramatically with Agile and DevOps approaches, ensuring uptake because a key need and skill in provider and consumer organizations.

IT-Led service configuration – Applications – practices

Best practices include:

  • Application Lifecycle Management (ALM)
  • Microservices architecture
  • Software configuration management

      1. IT-Led service configuration: Data

IT-Led service configuration – Data – definition

IT-Led service configuration – Data – desired state

Performance is effective when:

  • Automation

IT-Led service configuration – Data – practices

Best practices include:

  • SaaS data integration
  • Tenancy patterns
  • Sharding
  • Microservices
  • REST

An example: Sharding.

Sharding is a type of database partitioning that separates very large databases the into smaller, faster, more easily managed parts called data shards, where a shard means a smaller part of a whole.


      1. IT-Led service configuration: Platform

IT-Led service configuration – Platform – definition

Source: https://stackoverflow.com/questions/16820336/what-is-saas-paas-and-iaas-with-examples

In Mode 2, PaaS (Platform as a Service), the platforms are cloud- and subscription-based where a supplier hosts the platform and makes it available to customers over the Internet, e.g., AWS Elastic Beanstalk, Windows Azure, Heroku, Force.com, Google App Engine, Apache Stratos.

The platform is the runtime environment for software.

IT-Led service configuration – Platform – desired state

Performance is effective when:

The platform compares well across the following criteria categories:

  1. Characteristics – characteristics (i.e. on-demand self-service, resource pooling, rapid elasticity, and measured service)
  2. Dimensions – how widely the solution can be shared (i.e. private, public, community), who is responsible for environment management (i.e. internal, external), and where the platform is located (i.e. on-prem, outsourced)
  3. Production ready – platform suitability for enterprise, mission critical use
  4. Development activities and lifecycle phases – Measures how to design, build, deploy, and manage applications and services (e.g., with DevOps practices: continuous integration / delivery, automated release, incremental testing)
  5. Architecture – principles, concepts, and patterns enable applications to dynamically execute parallel workloads across a distributed environment
  6. Platform services – how fully the platform satisfies development of complex applications with comprehensive application middleware components, services
  7. Programming model – programming languages and frameworks, which facilitates building applications and services exhibiting the right characteristics

Source: https://wso2.com/wso2_resources/wso2-whitepaper-selecting-a-cloud-platform.pdf

The typical environment at the time of this writing is a hybrid of traditional IT and cloud, so a mix of both kinds of platforms are in evidence.

IT-Led service configuration – Platform – practices

Best practices include:

  • PaaS
  • Cloud
  • PaaS security

An example: PaaS security. The PaaS security link above cites what a PaaS service should be able to do:

  • Scan and analyze mobile applications.
  • Scan web apps on the internet or private networks.
  • Perform static analysis to scan source code for security vulnerabilities.
  • Employ single sign-on capabilities.
  • Drain logs over the syslog, syslog-tls or HTTPS, including all the events related to the application.
  • Distinguish logs from different instances of the same application.
  • Encrypt data at rest.
  • Facilitate secure communication between the application and database instance.

Discover sensitive data and stored procedures for masking sensitive data.


      1. IT-Led service configuration: Runtime

IT-Led service configuration – Runtime – definition

https://techterms.com/definition/rte

https://www.pcmag.com/encyclopedia/term/56079/runtime-engine

Software like Adobe Flash Player provides a runtime environment for its associated file format, allowing, in this case, Flash movies to be run within the player software.

IT-Led service configuration – Runtime – desired state

Performance is effective when:

  • The runtime environment provides an effective means for testing, debugging, and running the application component of a service, including provisions like crash dumps, step execution, and logging and monitoring.

Runtime refers to the runtime environment within which the application component of a service executes, e.g., Java RTE.

IT-Led service configuration – Runtime – practices

Best practices include:

  • Runtime environment

This example, while specific to a specific RTE, provide a good checklist that can be adapted for other RTEs.


      1. IT-Led service configuration: Middleware

IT-Led service configuration – Middleware – definition

https://searchmicroservices.techtarget.com/definition/middleware

https://azure.microsoft.com/en-us/overview/what-is-middleware/

Middleware is the basis for integrating separate applications. For a good list of types of middleware, see https://apprenda.com/library/architecture/types-of-middleware.

IT-Led service configuration – Middleware – desired state

Performance is effective when:

  • We don’t have Developers building our production middleware configuration
  • We have put in place in-depth historical middleware and monitoring
  • We have scripted and versioned installation, configuration and deployment

Source: blogs.oracle.com/emeapartnerweblogic/5-best-practices-for-middleware-operations-teams-by-c2b2

Middleware is the software that serves to “glue together” separate, often complex and already existing, programs. Some software components that are frequently connected with middleware include enterprise applications and web services.

IT-Led service configuration – Middleware – practices

Best practices include:

  • Middleware best practices
  • Middleware checklist

Middleware best practices cover provisioning, monitoring, configuration management, compliance, lifecycle management, and information publishing.


      1. IT-Led service configuration: Operating system

IT-Led service configuration – Operating system – definition

https://www.webopedia.com/TERM/O/operating_system.html

Common operating systems include Windows (in a variety of versions), as well as iOS, Android, Macintosh, Chrome OS.

Containerization is OS virtualization in which the kernel allows the existence of multiple isolated user-space instances, called containers.

IT-Led service configuration – Operating system – desired state

Performance is effective when:

We have practices that work well for deploying and securing the OS, cleaning up unnecessary software, keeping OS instances up-to-date with service packs and patches, group policies, security templates, and configuration baselines.

Source: www.continuum.net/blog/6-important-steps-to-harden-your-clients-operating-systemshttps://en.wikipedia.org/wiki/List_of_system_quality_attributes

As you can see, these are basic hygiene practices that, if ignored, can lead to unwarranted overhead, at a minimum, or worse, a major incident or a disaster, because, e.g., you are not keeping your attack surface to a minimum.

IT-Led service configuration – Operating system – practices

Best practices include:

  • OS hardening
  • Programs clean-up
  • Use of service packs
  • Patches and patch management
  • Group policies
  • Security templates
  • Configuration baselines
  • Containerization

https://www.continuum.net/blog/6-important-steps-to-harden-your-clients-operating-systems

Two best practices for operating systems are OS hardening and containerization.


      1. IT-Led service configuration: Infrastructure

IT-Led service configuration – Infrastructure – definition

Adapted from: https://www.gartner.com/it-glossary/infrastructure-as-a-service-iaas

https://stackoverflow.com/questions/16820336/what-is-saas-paas-and-iaas-with-examples

Your infrastructure underpins your platform and the software you run, whether that infrastructure is traditional / on-premise or in the cloud.

IT-Led service configuration – Infrastructure – desired state

Performance is effective when:

  • We have the level of access we need to our infrastructure
  • We know how much modification our software requires to run on it
  • We know who owns the infrastructure we are paying for
  • We are crystal clear on our (if we host) or the vendor’s monitoring and support process
  • We know our (if we host) or our vendor’s backup plan and have made sure it is in the SLA process
  • We understand the cost (if we host) or vendor’s pricing model and how to control usage
  • We have made sure we (if we host) or the vendor can ensure compliance with regulations

Source: https://www.zdnet.com/article/iaas-checklist-best-practices-for-picking-an-iaas-vendor/

Whether you in-source or outsource your infrastructure, and whether it is traditional or cloud infrastructure, you still need to make sure you have visibility into what it is, that it is monitored, backed up, what SLAs apply to it, what it costs, and whether it is in compliance with relevant regulations.

IT-Led service configuration – Infrastructure – practices

Best practices include:

IaaS

Infrastructure-as-cloud

IaaS security

An example: IaaS security. The source reference above indicates the security controls in an effective IaaS program should include the ability to:

Manage data center identities and access.

Authenticate, authorize and manage users.

Secure and isolate virtual machines (VM).

Patch default images for compliance.

Monitor logs on all resources.

Isolate networks.


      1. IT-Led service configuration: Virtualization

IT-Led service configuration – Virtualization – definition

Source: https://www.gartner.com/it-glossary/virtualization/

Top virtualization platforms as of this writing include Vmware vSphere, Microsoft Hyper-V, Citrix XenServer, and Oracle VM.

IT-Led service configuration – Virtualization – desired state

Performance is effective when:

We know the advantages and disadvantages of virtualization

We know the performance bottlenecks of each system role

We don’t over-prioritize management, patching and security of virtual systems

We don’t treat virtual systems differently than physical systems unless necessary

We backup early, backup often

We are careful when using any “undo” technology

We understand our failover and our scale-up strategy

We control virtual machine proliferation

We centralize our storage

We understand our security perimeter

Source: https://technet.microsoft.com/en-us/library/gg131921.aspx

One key thing here is managing VM proliferation—just like physical server sprawl, it is a must to keep on top of what has been spun up and is not dis-used.

IT-Led service configuration – Virtualization – practices

Best practices include:

Virtualization / Hypervisor

    • Tuning
    • Patching
    • Security
    • Backup
    • Failover
    • Scale-up
    • Controlling proliferation
    • Storage centralization
    • Securing the perimeter

Container management and orchestration

Source: adapted from https://searchitoperations.techtarget.com/definition/container-management-software

Container management is handling tasks associated with the administration of individual containerized applications and application components deployed on individual hosts. Applications are packaged into containers for ease of scaling, duplication and upgrading.

Container orchestration is managing multiple containers deployed on multiple hosts, extending lifecycle management capabilities to complex, multi-container workloads deployed on a cluster of machines.


      1. IT-Led service configuration: Server

IT-Led service configuration – Server – definition

Source: Adapted from https://www.techopedia.com/definition/2282/server

For an example of the different kinds of roles a server can take on, see https://technet.microsoft.com/en-us/library/hh831669(v=ws.11).aspx.

IT-Led service configuration – Server – desired state

Performance is effective when:

We know of (and can quickly and easily visualize) each server that we have, and the configuration of each server, to a level of detail that is useful to us

We maintain strict control over server build templates

We relentlessly root out unnecessary server complexity, variation and dependencies

In general, we want to avoid the situation of “snowflake” servers—where servers are unique—to avoid the overhead associated with variation—in term of the time and effort required to sort out the risks of variations and dependencies when we make changes, and the cost associated with mistakes due to missed variation and dependencies.

IT-Led service configuration – Server – practices

Best practices include:

Server Management

#10. Implement a Regular Maintenance Schedule

#9. Automate Everything + Manage by Exception

#8. Run Weekly Windows Updates + Install All Security Patches

#7. REBOOT

#6. Housekeeping

#5. Diskspace, Defrag and Memory

#4. Inventory of Running Software

#3. Stagger Updates

#2. Run During Weekdays

#1. Report Results

Visible Ops-style change control

Continuous delivery

For example, #9. Automate Everything + Manage by Exception: Almost any task that you run at the server console can be automated and scheduled. If you do any maintenance regularly, or at least four times per year, automate it, for two reasons:

  1. Once automated, it is much less prone to human errors. Human errors or oversights are a big reason why maintenance is not performed, or performed incorrectly.
  2. Automated tasks have much better Run Tracking Logs for history and troubleshooting.

Once these maintenance tasks are automated, you can Manage by Exception and only work on failed server upgrades when, for example, a server does not return to service after a reboot.

What you want with servers is what DevOps practitioners refer to as cattle, not pets. The Visible Ops Handbook, and the book by Jez Humble, Continuous Delivery, both discuss the dangers of snowflakes and how to avoid them, the first in the context of a solid basis for effective change control, the latter as a solid basis for an effective build and delivery process.


      1. IT-Led service configuration: Storage

IT-Led service configuration – Storage – definition

Source: Adapted from https://www.techopedia.com/definition/1115/storage

Storage needs to be managing, just as compute and network, and regardless of if that storage is traditional on-premise storage or in the cloud.

IT-Led service configuration – Storage – desired state

Performance is effective when:

We leverage tiered storage

We analyze application workloads and make educated decisions on where to store data

We consolidate storage pools

We implement staged backup to disk

We employ automated storage management tools

https://esj.com/articles/2009/10/27/best-storage-practices.aspx

IT-Led service configuration – Storage – practices

Storage best practices include:

Tiered storage

Workload analysis

Storage pooling

Staged backup

Automated storage management

Cloud storage best practices

According the link above, cloud storage considerations include:

Getting the degree of redundancy right (multi-site redundancy, single-site redundancy (mirroring, etc.) or none)

Automatic fail-over in case of a disk/server/site failure

Versioning capability, not just storage of the most current version of a file or data object, with the right retention period for deleted files, and a flexible retention policy

Data backup, with the right backup cycle and retention policy, and the right time-to-restore data

An easy-to-use management console that is web-based and can be accessed from any location in case of emergency

A pricing structure that fits your business model? For example, some vendors charge for every file access (read, write, etc.) in addition to per-gigabyte upload and download charges. If you are moving large blocks of data those access charges will be minimal. If you are doing primarily database lookups and updates, however, they can add up quickly.


      1. IT-Led service configuration: Network

IT-Led service configuration – Network – definition

Source: Adapted from https://www.techopedia.com/definition/5537/network

Physical and virtual and cloud networking resources must be known and managed to ensure the services they depend on are as they should be.

IT-Led service configuration – Network – desired state

Performance is effective when:

Our network is made up of components that support the level of, e.g., availability, performance, and security our services require

Networks components must meet the levels of availability, performance, and security services require. This is not possible if the components they are comprised of do not. For example, you will never get 5 nines on a 1 nine network, or a network that lacks redundancies in switches, power supplies, and so on.

IT-Led service configuration – Network – practices

Network configuration management practices include:

Administrator Approval for Changes

Auto Discovery

Automated Software Distribution

Automatic Network Mapping

Backup and Restore

Baseline NRA

Bulk Configuration Changes

Change Management

Compliance Audits/Reports

Configuration Archive

Configuration Compare

Configuration Templates

Copy Configuration

Inventory/Asset Management

Multi-vendor Device Support

Network Provisioning

Pre-Provisioning

Real-time Change Notifications

Remote Configuration

Resource Initialization

Resource Shutdown/Startup

Scheduled Backups

Scheduled Configuration Changes

Scheduled Device Shutdown/Startup

Scheduled Tasks

An example: reducing variation in networking equipment is key. For example, if you have several models of routers or switches, all with different defaults, it will be easy to make a mistake when configuring a device initially. Better to make it all “vanilla”, or whatever flavor you like, to avoid the time it takes to sort out differences and the cost of recovering from mistakes made because of variations.


      1. IT-Led service configuration: Hardware

IT-Led service configuration – Hardware – definition

Source: https://www.techopedia.com/definition/2210/hardware-hw

IT-Led service configuration – Hardware – desired state

Performance is effective when:

We know of all the hardware our services depend on, along with its configuration to a level of detail that is useful to us, and this information is visible and readily accessible

We can track what hardware belongs to which service(s), along with any other relationships and attributes that are useful, e.g., what P.O. introduced it, whether it is under warrantee, whether it is a leased or bought asset, etc.

We introduce new hardware and retire hardware at a pace that matches business needs; we proactively retire hardware before it becomes problematic for us

We perform physical maintenance (e.g., changing filters) on an appropriate schedule to avoid issues

Hardware assets require maintenance that virtual assets do not.

IT-Led service configuration – Hardware – practices

Practices include:

Hardware IT asset management

IT asset management and the cloud

The link above on ITAM and the cloud emphasizes a few open questions that highlight the disruption the cloud is causing in IT asset management processes born into and based on a physical, on-prem situation:

Who is responsible? For deploying servers into the Cloud, monitoring costs in the Cloud, managing the “hardware” specification of servers in the Cloud?

And, “How do we control?”, who can deploy services in the Cloud, the level and size of services deployed in the Cloud, and what licenses are used in the Cloud?


      1. IT-Led service configuration: Facilities

IT-Led service configuration – Facilities – definition

With the cloud and IaaS, facilities management becomes the concern of the host vendor, not the consumer. For any on-prem equipment, including wiring closets, data centers, and so on, this is the concern of the provider.

IT-Led service configuration – Facilities – desired state

Performance is effective when:

Our facilities are constructed of components that “add up” to supporting the right levels of availability, recoverability, performance, and so on, that our services require

Our physical equipment is compatible with our applications

We have a fast refresh schedule and detailed roadmap, and a coordinated equipment refresh process

We have experienced local staff and expert support

We have good management and performance tools

https://searchdatacenter.techtarget.com/tip/A-data-center-checklist-for-facility-design-and-IT-ops

Ignore the physical layer at your peril; hardware needs to operate within set tolerances, and therefore needs power conditioning to avoid over and under-voltage conditions, backup power for emergencies, the right air conditioning and air flow to meet equipment requirements for operating temperatures, and sensors and filters and the like to avoid exposing the equipment to things that would harm it, like airborne contaminants, water, and the like.

IT-Led service configuration – Facilities – practices

Practices include:

Configuration management

Facilities management

https://www.facilitiesnet.com/datacenters/article/8-Ways-To-Bring-Down-Data-Centers–17445 cites 8 ways to bring down datacenters:

  1. A standby/emergency generator fails to start when utility power fails for more than a few seconds, or generator transfer switchgear fails to transfer, or the generator fails to run until utility power is restored.
  2. A UPS system randomly fails even though utility power is good, and then fails to successfully transfer to bypass.
  3. A UPS system or batteries fail when utility power fails, and the generator (if available) has not yet started and run up to speed, or during transfer between generator and utility sources.
  4. Circuit breaker nuisance tripping.
  5. Circuit breakers installed in 24/7 live switchgear that have not been recently cycled (opened and closed) or energized (design voltage applied) or tested can be problems waiting to surface at the worst time
  6. Neutral and grounding issues.
  7. Bypass and transfer mechanisms that have not recently been operated, or operated under load, or operated at all (even many years after installation).
  8. Emergency power off (EPO) circuitry for 24/7 live facilities, which have not been recently tested or where validated (trusted) wiring diagrams are not available.


Chapter Section 4.1 Summary

The configuration of a service is one of three things worth managing, next to service functionality and qualities.

There are two types of services, Human-Led and IT-Led; each has within it a set of components for which we must aim to achieve and maintain a desired state through best practices.

Human-Led service configuration consists of people, service IP, service kits, collateral, systems & tools, goods and facilities.

IT-Led services configuration consists of software, platforms, and infrastructure; for mode 1, these can be on-prem and a combination of physical and virtual; for mode 2, these are, “…as a service”—IaaS, SaaS and PaaS.

Service concepts, desired states and practices – Functionality and Qualities (120m)


Chapter Section 4.2: Service Functionality & Qualities concepts, desired states and practices

In this chapter, we’re covering topics that will help you list and describe the functionality and qualities of services, their desired states, and practices for achieving them, e.g.:

04-02-01. Service Functionality

04-02-02. Service Qualities

04-02-03. Human-Led Service qualities

04-02-04. Reliability

04-02-05. Responsiveness

04-02-06. Trustworthiness

04-02-07. Empathy

04-02-08. Attractiveness

04-02-09. IT-Led Service qualities

04-02-10. Availability

04-02-11. Manageability

04-02-12. Serviceability

04-02-13. Performance

04-02-14. Reliability

04-02-15. Recoverability

04-02-16. Discoverability

04-02-17. Trustworthiness

04-02-18. Security

04-02-19. Integrity

04-02-20. Credibility

04-02-21. Compliance

04-02-22. Usability

04-02-23. Internationalization

04-02-24. Accessibility

04-02-25. Adaptability

04-02-26. Interoperability

04-02-27. Scalability

04-02-28. Elasticity

04-02-29. Portability

04-02-30. Extensibility

This is section two of chapter 4. We’re focused here on the functionality (features) and qualities (what Devs call non-functional requirements, or the “-ilities”—availability, capacity and the like).


      1. IT-Led service configuration: Applications

Service functionality – definition

A service is made up of its component parts, its functionality (or features), and its qualities.

For a Human-Led service, you can think of it this way: Let’s say you have a landscaping service. The configuration of the service is all the moving parts—your van, mower, leaf blower, edger, string trimmer, your clipboard, the phone you use to take payment, and so on. The functionality is the feature set of your service—does it include edging? Do you do weeding, or fertilizing, and so on. The qualities are things like how reliable and responsive you are, as judged by your customers

For IT-Led services, components are things like containers, servers, active directory, etc. Let’s say your service was a financial calculator website—a feature might be a removal calculator, a margin calculator, or a mortgage payment calculator. The service qualities would be things like how available your website is (uptime) and how performant it is (fast or slow).

Service functionality – definition

04-02-01. Service Functionality – Definition, desired state, best practices

So, functionality is the set of features of a service, what it does, independent of how well it performs, how available it is, etc.

There are two types of functionality. First, there is what the user sees and uses, the user functionality. Next, there is the telemetry functionality—the features you bolt on to a service so that you can direct and control it, through whatever service management system it is that you have, for example, if you have a landscaping company, several crews out doing work on a given day, what do you have in place to tell if a crew has a client cancel on them and is available for work so you can re-direct them to another job? If you have a financial calculator website, what have you put in place to tell you if the site is performing slowly, or has an extraordinary number of concurrent users on it, and so on?

Remember, functionality is features, what a service does, and qualities are how a service behaves, like how available it is, how performant it is, and so on. You can also think of service qualities as all service characteristics that are not features or functionality.

Service functionality – desired state

Performance is effective when:

Our services have the user features required by customers and users; where this is not the case, we move quickly and transparently to make it so, or to reset customer and user expectations and perceptions for the service functionality.

Our services have the telemetry needed to direct and control them.

Our services meet the minimally agreed to feature and viability requirements, operates within the principles, governance, and security boundaries of the organization, and are built and maintained by the revenue stream that needs the service, and are constantly evolving using automated testing and delivery techniques, with feature list and prioritization based on direct end-user feedback.

04-02-01. Service Functionality – Definition, desired state, best practices

Both end user functionality, and management functionality (telemetry) are required for a manageable service that is consistently valuable to stakeholders.

Service functionality – practices

Agile requirements modeling

Epics, stories, versions, and sprints

04-02-01. Service Functionality – Definition, desired state, best practices

Whatever the method used, it’s important that the outcome is that customers and users get functionality they value quickly, and with quality.


Chapter Section 4.2.1. Summary

  • The functionality (features, what it does) of a service is one of three things worth managing, next to the service’s configuration (component parts / what it is made of) and its qualities (how it behaves)
  • There are two types of services, Human-Led and IT-Led; each has within it a set of features for which we must aim to achieve and maintain a desired state through best practices
  • A critical part of a service’s functionality is its telemetry embedded for direction and control by the service management system (SMS)

      1. Service Qualities definition, desired states, practices

Service qualities – overall definition

Figure 04-02-02.1 Human-Led & IT-Led Service qualities

In contrast to a service’s functionality, or features, that is, what it does, service qualities are how a service behaves.

As you can see in the figure, both Human-Led and IT-Led services have system qualities, just as they have features.

The Human-Led service quality taxonomy in OSM are adapted from the SERVQUAL model, which is commonly applied to Human-Led services. The IT-Led service quality taxonomy is adapted from the Open Group’s taxonomy of non-functional requirements.

Each of these will be defined in turn as we move through this chapter.

Human-Led and IT-Led services: six modes of human/technology interaction

Five modes regarding the role of technology in customer contact. Adapted from: Froehle and Roth, 2004, p. 3.

Figure 04-02-02.2 Five modes regarding the role of technology in customer contact. Adapted from: Froehle and Roth, 2004, p. 3.

Froehle and Roth identify five modes of human and technology interaction.

  1. Technology-free customer contact, e.g., the face-to-face contact between a psychological therapist and patient. This type of contact does not require the use of technology; thus, it is the most traditional and direct mode of customer contact.
  2. Technology-assisted customer contact, e.g., hotel check-in and check-out procedures, transactions conducted over manned bank counters, and passenger check-ins for airline boarding. In these, technology (i.e., a computer) is used by the service personnel only. However, the customer and service personnel still experience face-to-face contact.
  3. Technology-facilitated customer contact, e.g., the use of Microsoft PowerPoint by a financial expert to present and discuss financial plans with customers during a conference. Although technology is used by both parties, face-to-face customer contact still occurs.
  4. Technology-mediated customer contact, e.g., telephonic interaction between service personnel and customers and the provision of professional advice by a consulting company using Videoconference technology. In these contexts, a shared technological platform is used by the service personnel and the customer without face-to-face contact.
  5. Technology-generated customer contact, e.g., ATM withdrawals, online shopping. In these, customers operate the technology without the assistance of service personnel, and face-to-screen contact replaces face-to-face customer contact. We add a 6th one here, Human-free, where technology represents both the provider and the consumer of the service, as in EDI.

The point here is that services run on a continuum from technology-free to technology generated; Human-Led services begin at the left-hand side of this continuum, up to the point where technology is the primary means of representing the service; IT-Led services start on the right, up to the point where humans are the primary means of representing the service.

Service qualities – overall desired state

Performance is effective when:

  • The service qualities required by customers and users are present in the service; where this is not the case, we move quickly and transparently to make it so, or to reset customer and user expectations and perceptions for the service qualities.

Service qualities have a technical aspect and a qualitative aspect. For example, a service might, for accessibility, be ADA compliant, technically speaking. However, the customer and user are the judge of whether the system is accessible.

Service qualities – overall best practices

Service Level Management

Non-functional requirement framework

Non-functional requirements specifications

Non-function requirements checklist

IT-Led service qualities adapted from: https://publications.opengroup.org/w098

You should notice two major differences here between OSM and traditional ITSM guidance.

The first is that OSM covers Human-Led services, and their non-functional characteristics or qualities, where traditional ITSM guidance does not.

The second is that the list of non-functional requirements (what traditional ITSM guidance calls, “warranty” aspects) is much longer in OSM. Traditional ITSM guidance typically focused on operational qualities, things that went in an SLA, e.g., availability, performance (or capacity), IT service continuity (or disaster recovery), security, and supplier details.

As you can see, OSM’s list of service qualities greatly expands the list to include a “shift-left” to the non-functional qualities developers care about, such as accessibility.

OSM’s list of IT-Led service quality characteristics are adapted from the TOGAF taxonomy of service qualities.


Chapter Section 4.2.3: Human-Led Service Qualities concepts, desired states and practices


      1. Human-Led Service Qualities definition, desired states, practices

Human-Led service qualities – definition

Human-Led services run the gamut from:

  1. Technology-free customer contact, e.g., the face-to-face contact between a psychological therapist and patient. This type of contact does not require the use of technology; thus, it is the most traditional and direct mode of customer contact.
  2. Technology-assisted customer contact, e.g., hotel check-in and check-out procedures, transactions conducted over manned bank counters, and passenger check-ins for airline boarding. During these, technology (i.e., a computer) is used by the service personnel only. However, the customer and service personnel still experience face-to-face contact.
  3. Technology-facilitated customer contact, e.g., the use of Microsoft PowerPoint by a financial expert to present and discuss financial plans with customers during a conference. Although technology is used by both parties, face-to-face customer contact still occurs.

Human-Led service qualities – definition

Examples of Human-Led services

Moves, adds and changes

New hire setup

Legal hold

Consulting

Auditing

Source: Human-Led service qualities in OSM® are adapted from SERVQUAL

Human-Led services are provided primarily by humans, possibly with the assistance of technology, but where the human-to-human interaction is the primary driver. Contrast this with IT-Led Services, where services are provided primary by technology, possibly with the assistance of humans, but where technology-to-technology or technology to human interaction is the primary driver. Human-Led service qualities in OSM are adapted from SERVQUAL.

Key questions for Human-Led service qualities include:

People—the individuals and teams that deliver the service—how reliable and responsive are they? Are they dressed appropriately for what they’re doing, from the perspective of customers and users?

Service IP, kits, collateral—the knowledge and materials teams rely on to deliver services–for example, if you are running workshops as part of the service, are the materials attractive and well-organized, or do you have a lot of bad graphics and spelling errors in them?

Systems & Tools—for example, process mapping software for a process engineering engagement—is the tool easy to use for the facilitator and the customer, or is it clunky and error-prone?

Goods—for services where goods are involved, e.g., installing a new physical monitor—is your packaging for goods neat and complete, or do goods show up dented or broken or in the wrong place because of shoddy addressing?

Facilities—is your service location neat, organized, appealing, or shoddy / off-putting?

Human-Led service quality – desired state

Performance is effective when:

Stakeholders see us and our services as reliable, responsive, trustworthy, empathetic, and attractive

People—the individuals and teams that deliver the service, have the knowledge, skills and mindset required

Service IP, kits, collateral—the knowledge and materials teams rely on to deliver services—is up to date and easy to location

Systems & Tools—for example, a process template for a process engineering engagement—exist and are good enough to ensure successful delivery

Goods—for services with goods involved, e.g., installing a new physical monitor—we manage inventory to meet demand

Facilities—are physically appealing, and strongly support the conduct of the service

Source: https://en.wikipedia.org/wiki/SERVQUAL

“Attractive” as used here does not mean that all our people are supermodels, that all our facilities are slick, etc. It means at a minimum that they are not off-putting, and are suitable for the purposes of the service and its stakeholders. For example, there is one standard of dress you might expect a dollar store employee to have, and quite another for say, a Nordstrom salesperson. And if the dollar store fixtures were too expensive-looking, you might wonder what you’re getting for your dollar—similarly, if the fixtures in a Nordstrom’s were shoddy or cheap looking, you might be wondering if the t-shirt you’re buying is worth $30.

Human-Led service quality – practices

Valerie Zeithaml and Mary Jo Bitner created the most widely used and accepted model for professional service quality, in 5 dimensions:

Figure 04-02-03.1 Human-Led service qualities; Source: Adapted from SERVQUAL

Valerie Zeithaml and Mary Jo Bitner created the most widely used and accepted model for professional service quality, in 5 dimensions shown here. OSM adopts and adapts this model, renaming “Assurance” trustworthiness, and “Tangibles” attractiveness.

As you can see, Human-Led service qualities are in some cases the same (reliability, responsiveness, trustworthiness, and attractiveness) as many of the qualities we seek in an IT-Led services. If for example, you are using an online banking service, you’ll want it to be reliable, responsive, trustworthy, and attractive enough. And while an online banking service can’t necessarily exhibit empathy per se, the empathy of its designers for you as the customer or user should shine through in its design.

Human-Led service quality – practices

SERVQUAL Valerie Zeithaml and Mary Jo Bitner

The Nordstrom Way

How to Buy/Sell Services HBR

People (David Maister)

Facilities Micah Solomon

An example: Anything by David Maister is great advice for managing Human-Led services. While most of it is pointed towards consulting firms, the advice is sound and impactful nonetheless. Here are two classics:

  • Maister, David H. Managing the Professional Service Firm. (New York: Free Press, 1993.) Maister is a former Harvard Business School professor and is currently a consultant to the world’s top professional firms. He is recognized as the foremost expert in professional service firm management and this is the first comprehensive text on the managerial problems of professional firms. Maister explores a wide range of topics including marketing, staffing, service quality, and personal development. The book is full of insightful and practical advice.
  • Maister, David H. True Professionalism: The Courage to Care About Your People, Your Clients, and Your Career. (New York: Free Press, 1997.) In this follow-on to Managing the Professional Service Firm, Maister discusses his definition of “true professionalism”–a personal commitment to self-betterment and a dedication to providing excellence and efficiency in client service. He also strongly emphasizes the importance of ethical behavior as the primary means to commercial success. Maister examines these subjects at both the individual level and the firm level and includes excellent recommendations.

Another worth of mention is, Wittreich, Warren J. “How to Buy/Sell Professional Services.” (Harvard Business Review, March-April 1966.) The author explores the complexity of buying and selling professional services and provides guidance to both buyers and sellers. Among Wittreich’s key ideas are that the selling and rendering of a service can seldom be separated and that most of the “sale” occurs in delivering on the initial promise made when the engagement was initiated.


      1. Human-Led service quality: Reliability

Human-Led service quality – Reliability – definition

Source: Adapted from SERVQUAL

Your Human-Led services have the quality of being reliable to the extent that customers and users perceive them as being so; this perception comes from either a demonstrated capacity to do so, or through a track record of doing so, in either case directly or by a trusted reference.

Human-Led service quality – Reliability – desired state

Performance is effective when:

We commit to deliver something by a certain time and follow through on that commitment, both in terms of what is delivered, and when

We perform services right the first time

Service providers provide the service at the time they commit to doing so

Service providers keep error-free records

The service we provide is consistently as it should be, regardless of variable such as the time of day it is delivered, or by what person or team

Adapted from: https://www.ermt.net/docs/papers/Volume_6/1_January2017/V6N1-132.pdf and www.ec.tuwien.ac.at/~dorn/Courses/SDMC/RATER%20Questionnaire.pdf

One good way to think about what your customers and users look for in the qualities of your services is to think through some good and bad service experiences you have had, and to write down what was good and bad about them, then ask yourself, “how would my customers and users say my services compare along these lines?”

Human-Led service qualities – Reliability – practices

SERVQUAL Valerie Zeithaml and Mary Jo Bitner

How to Buy/Sell Services HBR

Trusted Advisor (David Maister)

The 7 Habits of Highly Effective People

TSIA

Being a more reliable professional

Being reliable is about being true to your word, confronting mistakes, making sure service is done right the first time, and ultimately, consistently under-promising and over-delivering.

The key ingredient here is a service mindset and an understanding of how to execute on it. Some things that help include:

Scheduling systems

Committing to wait time

Record keeping and review, and

Performance reviews

David Maister’s book, The Trusted Advisor, is an excellent reference, as is Stephen Covey’s 7 Habits of Highly Effective People. While the first focuses on consulting firms and the latter on individual behaviors, the advice in both cases applies very much to organizations as providers of services.


      1. Human-Led service quality: Responsiveness

Human-Led service quality – Responsiveness – definition

Source: Adapted from SERVQUAL

Customers and users see our Human-Led services as responsive when we do things like getting back to them quickly when they make a request, and providing prompt service.

Human-Led service quality – Responsiveness – desired state

Performance is effective when:

We get back to customers and user quickly, acknowledging them when they make a request

We tell customers and users up front, exactly when services will be executed

We fulfill services to customers and user’s stakeholders promptly

When there is an issue with our service, we handle that promptly, too

We are always willing to provide prompt service and answer customer and user questions

We are never too busy to respond to stakeholder requests

Public situations are treated with care and seriousness

Customers and users find it easy to talk to a knowledgeable service member when they have a request or issue

Customers and users find it easy to reach the right service provider in person, by telephone, or email or chat, or by whatever channel we have provided and that they find convenient

Customers and users say that service access points for our services are conveniently located

Adapted from: https://www.ermt.net/docs/papers/Volume_6/1_January2017/V6N1-132.pdf and www.ec.tuwien.ac.at/~dorn/Courses/SDMC/RATER%20Questionnaire.pdf

When you look at this list, you should see that good performance here needs to be underpinned by things like:

Good tools, for example, for scheduling

Good processes and procedures, e.g., for exception handling

Well-trained service personnel, with the right skills, knowledge and mindset

The right service culture and rewards

The right services in the first place, and the right mechanisms for setting expectations and perceptions

Human-Led service quality – Responsiveness – practices

Hire the right people in the first place

Moments of Truth

SERVQUAL Valerie Zeithaml and Mary Jo Bitner

The Nordstrom Way

People (David Maister)

When you look at this list, you should see that good performance here needs to be underpinned by things like:

The right, well-trained service personnel, with the right skills, knowledge and mindset

Good tools, for example, for scheduling

Good processes and procedures, e.g., for exception handling

The right service culture and rewards

The right services in the first place, and the right mechanisms for setting expectations and perceptions

The first item on this list is most important. Everything starts and ends with hiring the right people in the first place. In practice, other than by parents, instilling a service mindset in a person who just doesn’t have that mindset is an exercise in futility.

Another key element is making sure you are focusing on making “moments of truth” shine—Jan Carlzon’s book is the classic on such matters, and is a cornerstone book in the birth of service management. While later iterations of traditional ITSM guidance features some over-pivot on process reengineering, it is refreshing to recall the roots of service management, lightweight, agile, and focused on people and individual interactions, and making them better.


      1. Human-Led service quality: Trustworthiness

Human-Led service quality – Trustworthiness – definition

  • Typically achieved through knowledge and courtesy of employees

Source: Adapted from SERVQUAL

As a consumer, you use many services. You get haircuts, you use a mobile phone service, and so on. How can you trust that you’ll get what you’re paying for, that the results will be satisfactory?

If it’s the first time you’re getting you haircut at a place, you’d look for evidence that it’s the place for you, that they’ll do a good job. For example, you’ll check out how people walking out look—how’s their hair? If it’s not good, you’ll move on and find another place. You might also ask a friend for a referral. So, in new-to-you situations, you’ll look for evidence or trustworthiness.

If you’ve been using a service for a while, trust is built through repeated delivery on commitments—in this case, a long track record of good haircuts. Should personnel or other factors change, results might change, and trust might be broken after a bad result.

So, flip this situation around and apply it to how you assure trust in your services.

Human-Led service quality – Trustworthiness – desired state

Performance is effective when:

Our behavior instills confidence in customers and users, so they feel safe in transactions with us, and with our premises and equipment, and they see us as courteous and competent

We have, and demonstrate that we have, the skills, knowledge and mindset to do the service well and address customer / user needs

Materials we provide with the service are appropriate / up-to-date

Customers and users say we use technology to perform the service quickly and skillfully and appear to know what we are doing and that they are confident that we have and will perform services correctly

We have a good reputation with customers and users

We do not pressure customers and users

We respond accurately and consistently to customer / user inquiries

We guarantee our services

We store customer and user documents, records and other data secure from unauthorized use

Adapted from: https://www.ermt.net/docs/papers/Volume_6/1_January2017/V6N1-132.pdf andwww.ec.tuwien.ac.at/~dorn/Courses/SDMC/RATER%20Questionnaire.pdf

Some things that contribute to these desired states:

Communications, especially keeping confidentiality

Soft-skills training (courteousness)

Knowledge/skills/technical training

Material review and updated regularly

Guarantee policies

Safety ensured

Security

Record keeping

Human-Led service quality – Trustworthiness – practices

SERVQUAL Valerie Zeithaml and Mary Jo Bitner

People (David Maister)

Trusted Advisor (David Maister)

The 7 Habits of Highly Effective People

David Maister’s book, The Trusted Advisor, is an excellent reference, as is Stephen Covey’s 7 Habits of Highly Effective People. While the first focuses on consulting firms and the latter on individual behaviors, the advice in both cases applies very much to organizations as providers of services.

Other practices that can contribute to trustworthiness as a service provider include:

Staff training: trusted advisor skills, service provision skills, knowledge and mindset—consistent across staff

Safety and security for transactions, data, premises, and equipment

Mechanisms to ensure service materials are appropriate and current

Demonstration of competence, e.g., displaying of certifications, endorsements


      1. Human-Led service quality: Empathy

Human-Led service quality – Empathy – definition

Source: Adapted from SERVQUAL

Think about service situations you’ve had recently—maybe it was rescheduling a flight with an airline, perhaps working with a bank on an online banking issues for your checking account. Or maybe you had an appliance break down and you were calling the manufacturer.

Did you feel the person on the other end of the phone or chat was just going through the motions, or were they really trying to listen and understand what your situation was, and what you needed? In other words, was their posture, “I am here to help you with your problem”?

Now flip that around for the services you provide. What do your customers and users think of you? Do you know if they find you empathetic? You may be good to go, or you may have some work to do in this area—the first step is knowing their perceptions and expectations.

Human-Led service quality – Empathy – desired state

Performance is effective when:

We give customers / users individualized attention, convenient hours

Customers and users say we have their best interest at heart and work to understand their specific needs and objectives

We recognize each regular customer / user and address them by name

Our level and cost of service is consistent with what customers and users need and can afford

We are polite, respectful, considerate and friendly, with a pleasant demeanor, and refrain from acting busy or being rude, and respond politely and with consideration when customers / users ask questions

We listen to customer and users and show understanding and concern

We can explain clearly various options available to a query

We avoid using technical jargon when speaking with customers / users

We contact customers / users if we will miss a scheduled appointment

Adapted from: https://www.ermt.net/docs/papers/Volume_6/1_January2017/V6N1-132.pdf and www.ec.tuwien.ac.at/~dorn/Courses/SDMC/RATER%20Questionnaire.pdf

Empathy can be summed up as the feeling that the service provider has the attitude, “I am here to help you with your request or issue”. It’s about listening, and social and customer service skills as much as anything else. The opposite of an empathetic person is one who give off the attitude, “I am here to demonstrate my technical skills—bow down, you’re not worthy!”.

As with other Human-Led service qualities, it’s important to understand how the quality of empathy is perceived by your customers and users—it’s not what you think that counts.

Human-Led service quality – Empathy – practices

SERVQUAL Valerie Zeithaml and Mary Jo Bitner

The Nordstrom Way

Developing Empathy

The 7 Habits of Highly Effective People

https://www.mindtools.com/pages/article/EmpathyatWork.htm

You can avoid a lot of hassles with services staff by hiring people with a service orientation in the first place. Yes, they must have technical skills to succeed, but without an attitude of, “I am here to help you with your request or issue”, all will be lost.

Some people contend that you can train people into a service mindset. This may be so, but often it seems that the only ones that can do that is a person’s parents. By the time they get to the workplace, it may be an intractable situation for some people, so it’s best to hire for a service skill and mindset from the start.

The 7 Habits, especially, “see first to understand, then to be understood”, are an excellent place to start in developing empathy.

Some other ways to developing or showing empathy include:

Training for customer service skills, knowledge and mindset, including other-centered listening and communication skills

Using customers’ and users’ names when dealing with them

Acting on, or forwarding along for action, customer and user feedback


      1. Human-Led service quality: Attractiveness

Human-Led service qualities – Attractiveness – definition

Source: Adapted from SERVQUAL

Think about the last time you were put off by some aspect of the appearance of a service provider. Maybe you were in a restaurant and the windows and tabletops and restrooms were dirty looking. Maybe you were at a mobile phone shop and the store looked out of date, shopworn, with some broken shelves, chipped paint here and there, and boxes and merchandise kind of messily lying about. Or maybe it was the person helping you—she had pizza stains on her shirt, or was disheveled in her appearance.

These may seem like little things, but they can add up quickly to a customer or user going “tilt”, so it’s important to pay attention to them.

So, flip this around and think about this for your services. If you provide deskside support, are your personnel neatly dressed, or are they the crew that can’t show up with an unwrinkled shirt, or can’t keep their pants tucked in? If you provide, for example, concierge repair and update services for client devices at a physical location, how does it look? You may be good to go, or you may have some work to do. Be honest, and make sure you’re ship shape.

Human-Led service quality – Attractiveness – desired state

Performance is effective when:

The tangible aspects of our services—what customers and users can see and touch—are pleasing to customers and users

Customers and users find our materials associated with the service (pamphlets or statements) visually pleasing and easy to understand

Customers and user find appearance of service providers pleasing; we dress appropriately and have good hygiene

Customers and users find our physical facilities / fixtures pleasing

Customers and users say our technology/equipment looks modern

Adapted from: https://www.ermt.net/docs/papers/Volume_6/1_January2017/V6N1-132.pdf and www.ec.tuwien.ac.at/~dorn/Courses/SDMC/RATER%20Questionnaire.pdf

So, when asked, what do customers and users say about the tangible aspects of our services? Do they see them as appealing? Off-putting? We need to know, or we risk losing customers and users, or at least losing points with customer and user satisfaction.

Human-Led service quality – Attractiveness – practices

SERVQUAL Valerie Zeithaml and Mary Jo Bitner

The Nordstrom Way

Facilities Micah Solomon

The Nordstrom Way

Customer Experience Management (CXM)

User Experience Management (UXM)

Micah Solomon’s writing on retail facilities are a good place to start on understanding the impact of the tangible on customer and user perceptions.

Think about a time where you were super-pleased with a service encounter in a physical space—what made it great?

Now think of another encounter where you were not happy—what made it lousy for you?

Lastly, think about your services and their tangible aspects. How do they compare against these two scenarios?

You may have this covered, or you may have some work to do.

Attention needs to be paid here to:

Physical facilities and fixtures

Product and material appearance, layout and organization

Staff appearance—dress and hygiene

Technology appearance

CXM, an emerging field for IT-Led systems, and UXM, are in some ways the parallel best practices for attractiveness in Human-Led systems, and can be food for thought for the physical experience.


Chapter Section 4.2.9: IT-Led Service Qualities concepts, desired states and practices


      1. IT-Led Service Qualities definition, desired states, practices

IT-Led service quality – definition

Figure 04-02-09.1 IT-Led service qualities

IT-Led service qualities include:

Availability

Manageability

Serviceability

Performance

Reliability

Recoverability

Discoverability

Trustworthiness

Security

Integrity

Credibility

Compliance

Usability

Internationalization

Accessibility

Adaptability

Interoperability

Scalability

Elasticity

Portability

Extensibility

While this is a long list, it is by no means comprehensive or final. IT-Led service qualities are basically any non-functional characteristic of a service.

IT-Led service quality – desired state

Performance is effective when:

Customers and users and other stakeholder (e.g., those concerned with governance / regulatory compliance, or accessibility, or security, or internationalization, disaster recovery, and so on), say our services have the right set of qualities, including availability, manageability, serviceability, performance, reliability, recoverability, discoverability, trustworthiness, security, integrity, credibility, compliance, usability, internationalization, accessibility, adaptability, interoperability, scalability, elasticity, portability, and extensibility)

When you look at this list of qualities, you should see a number that pop out as important to customers and users.

The same goes for the provider.

Suppliers, also, are stakeholders in this, for the IT-Led services they provide and contribute to.

And besides the four primary stakeholders of service management—customers, users, the provider, and supplier—there are others that have a stake in these qualities. Those that own regulatory compliance will be concerned about ensuring compliance with, e.g., PCI, Sox, Basel 2, and SAS 70, or whatever regulations are pertinent. Those that own security will want to make sure the services are secure. And those concerned with uptake of the service will want to make sure perhaps that it is 401 compliant for accessibility, or supports French, Dutch, Spanish, etc. where those languages are needed.

IT-Led service quality – practices

Service Leve Management

Service Level / Operational Level Agreements

Underpinning Contracts

Non-functional requirements

Two additional sources of best practice are:

https://dalbanger.wordpress.com/2014/01/08/a-basic-non-functional-requirements-checklist/, and

carrotschool.com/blog/the-definitive-non-functional-requirements-checklist


      1. IT-Led service quality: Availability

IT-Led service quality – Availability – definition

  • Reliability & Maintainability – see definitions here https://www.iso.org/obp/ui/#iso:std:iso-iec:2382:-14:ed-2:v1:en
  • Reliability measured by MTBF; maintainability by MTTR

Source: ISO/IEC 20000-1:2011(E) 3 Terms and definitions

Availability is percentage of time within the agreed or committed window a service is up. It’s made up of reliability, which is the “keep it up and running part”, as measured by meant time between failures or MTBF, and maintainability, an engineering term that means the ease with which a service which has failed can be returned to working order, which is measured by mean time to repair, or MTTR.

It’s important to note that availability is the quality related to NORMAL operating conditions, e.g., it’s a regular Tuesday here at XYZ corporation, whereas Recoverability is the quality related to the ABNORMAL situation of being out of business—and regaining availability of services in priority order to get back into business. While measures taken for the one can benefit the other, and vice versa, they are two distinct domains and qualities of services.

IT-Led service quality – Availability – desired state

Performance is effective when:

  • We ensure availability of services in normal business operations by designing and managing services to keep them up and running. Should they go down, get them up quickly within specified service levels and costs
  • We develop services for the required levels of availability in the first place, with some “wiggle room” so that we can consistently hit targets; this includes design for reliability (keep thing up and running, measured by MTBF), maintainability (if they go down, get them up quick, measured by MTTR)
  • Services provide us with easily accessible, accurate data on their availability
  • We work to take measures and choose platforms that provide the levels of automated failover and recovery our stakeholders need; to the extent possible on the platforms we are on, we automate failover and recovery

Design for both reliability and maintainability are required to promote the right levels of availability; one or the other does not cut it. Some IT service provider shops are very engineering oriented towards reliability, and stumble when things go down because they don’t usually go down. Others are good at getting things back up and running, because they have a lot of practice, because the engineering for reliability just isn’t there. Balance is needed here.

IT-Led service quality – Availability – practices

  • Design for reliability – Building Dependable Systems
  • Design for maintainability Michael Tortorella
  • Cloud reliability – Simian Army / Antifragility
  • Cloud maintainability
  • Availability management
  • Availability levels
  • Public status pages / transparent uptime
  • Incident Command System (ICS)
  • Kepner Tregoe problem analysis

For reliability, even though it’s ancient (1994), the Digital Equipment Corporation publication, “Building Dependable Systems” remains a very clear and well written guide that can be applied to any service.

A key part of availability is getting availability levels right, because each involve a price / performance tradeoff. These levels include:

  • High availability. The service is available during specified operating hours with no unplanned outages.
  • Continuous operations. The service is available 24 hours a day, 7 days a week, with no scheduled outages.
  • Continuous availability. The service is available 24 hours a day, 7 days a week, with no planned or unplanned outages, for example, like amazon.com.

Public status pages are a great way to build confidence in you “skin in the game” on availability.

And while it’s really a way of handling major incidents, ICS deserves mention here because of it’s potential for reducing MTTR in reactive situations. The same goes for KT analysis.


      1. IT-Led service quality: Manageability

IT-Led service quality – Manageability – definition

  • Manageability is largely a function of the quality and extent of service instrumentation, telemetry and logging, and automation for remedial action.

Source: www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Instrumentation refers to an ability to monitor or measure the level of a service’s performance, to diagnose errors and to write trace information. Developers implement instrumentation in the form of code instructions that monitor specific components in a service (for example, instructions may output logging information to appear on screen). When a service contains instrumentation code, it can be managed using a management tool. Instrumentation is necessary to review the performance of the service. Source: adapted from https://en.wikipedia.org/wiki/Instrumentation_(computer_programming)

Telemetry is a term for technologies that accommodate collecting information in the form of measurements or statistical data, and forward it to IT systems in a remote location. This term can be used about many different types of systems, such as wireless systems using radio, ultrasonic or infrared technologies, or some types of systems operating over telephone or computer networks. Others may use different strategies like SMS messaging. Source: https://www.techopedia.com/definition/14853/telemetry

IT-Led service quality – Manageability – desired state

Performance is effective when:

  • We can easily and automatically gather information on the state of all things worth managing—stakeholders, services, and the SMS—compare it to desired states, and act where there is a gap
  • We generally don’t have gaps in manageability, but when we do, we close them quickly and permanently

Manageability must be designed for and continuously improved for it to be effective for services. Instrumentation, telemetry, and logging and monitoring functionality don’t just appear out of nowhere—a proper health model should ship with a service, as part of the design.

IT-Led service quality – Manageability – practices

  • Making it manageable fuel Palo Alto
  • Instrumentation / Telemetry
  • Monitoring
  • Cloud Monitoring / Telemetry
  • Logging / Instrumentation
  • Logging cheat sheet
  • Event management

While event management / service monitoring and control are part of the service management system, they are joined at the hip with the quality of manageability, so they are mentioned here. In the end, manageability is about putting hooks into services so they can be monitored and controlled.


      1. IT-Led service quality: Serviceability

IT-Led service quality – Serviceability – definition

  • Services are serviceable to the extent that, in a repair, maintenance, or restocking situations, what to do, where, and how and so on is readily apprehended and easily reached

Source: www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

https://en.wikipedia.org/wiki/Serviceability_(computer)

One difference between OSM and traditional ITSM guidance should be clear here. Traditional ITSM guidance uses the term, “serviceability” in a way that is out of step with the industry, attaching it to a supplier’s contribution to the uptime or downtime of a service or one of its components. The typical definition, which is taken up here by the Open Group, is basically—how easy is it to service?

IT-Led service quality – Serviceability – desired state

Performance is effective when:

  • Our services are designed to help identify problems and take corrective action, such as to repair or upgrade to a service or one of its components
  • In repair, maintenance, and restocking situations, what to do, where, and how and so on is readily apprehended and easily reached

www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

For example, if I am to work on an office printer / copier / scanner with a tray feeding system, how hard or easy is it to clear jams, to figure out which tray is what, and so on, while trying to service the unit? How hard or easy is maintenance, or to replenish the paper or toner? Is it ready to hand? That is the quality of being serviceable. It requires design for serviceability, as it’s much harder and costlier to try to “bolt it on” later.

IT-Led service quality – Serviceability – practices

  • Design for serviceability NDP
  • Design for serviceability Guy Carafone
  • Design for supportability

NDP lists he key design for serviceability guidelines as:

  • Simplification
  • Standardization
  • Access
  • Ergonomics
  • Safety
  • Disconnecting/Reconnecting
  • Unfastening/Refastening
  • Part Handling
  • Location and Insertion, and
  • Mistake-Proofing

      1. IT-Led service quality: Performance

IT-Led service quality – Performance – definition

Performance, or throughput, is a function of capacity, of, e.g., storage, compute, and network.

Traditional ITSM guidance focuses on capacity, which is a means to the end; the end is performance. OSM focuses on performance.

IT-Led service quality – Performance – desired state

Performance is effective when:

  • Performance meets committed rates for our services
  • We ensure capacity matches demand at the right time and at the right cost by seeking to understand current and future demand and capacity, and delivering the right resources, at the right time and at the right cost. We understand and influence demand, and avoid excess and insufficient capacity and associated costs and service impact.
  • We design services for required performance levels up front, with “wiggle room” so we consistently hit targets; this includes design and automation for elasticity—scaling to meet demand, and with easily accessible, accurate performance data
  • When we size services, we factor in consumers’ patterns of business activity where possible

This article https://en.wikipedia.org/wiki/Computer_performance does a good job of laying out aspects of performance for computers that can apply also to networks, virtual machines, etc.

IT-Led service quality – Performance – practices

  • Capacity management

  • Demand management
  • Load balancing
  • Network performance management
  • Database performance management SQL
  • Autoscale scale up/down in/out
  • Elasticity

There are many more areas of performance management, this is just a sampling. Some other practices to enhance performance include:

  • Automation
  • Trend analysis
  • Tuning
  • Influencing demand (e.g., by differential charging)
  • Workload analysis
  • Performance analysis / benchmarking

      1. IT-Led service quality: Reliability

IT-Led service quality – Reliability – definition

Source: Adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Reliability is the extent to which a service stays up and running, and is measure by mean time between failures (MTBF).

IT-Led service quality – Reliability – desired state

Performance is effective when:

Generally, services don’t fail, because of how we plan, build, deploy, test and release them

Should services fail, we find out why and harden the service(s) so failure does not re-occur

As with many similar qualities, reliability must be designed into a service up front, and continually improved, in this case to support service objectives or commitments for uptime.

IT-Led service quality – Reliability – practices

  • Design for reliability – Building Dependable Systems
  • Design for reliability – DFR including FMEA
  • Fault tree analysis
  • Cloud reliability – Simian Army / Antifragility
  • Availability management
  • Availability levels’
  • Server hardening

Many techniques are available for designing more reliable systems, including Failure Modes and Effect Analysis (FMEA) is a step-by-step approach for identifying all possible ways, or modes, in which a service might fail, and the effects of each failure, as a basis for prioritizing hardening activities.


      1. IT-Led service quality: Recoverability

IT-Led service quality – Recoverability – definition

Source: adapted from opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Recoverability requires a restore point—something to rely on to go back to a known good state. It could be, for example, that you’re using immutable deployment, where all components are “vanilla”, and you simply replace rather than repair or change to restore a known good state. Or, for example, you could use a VM baseline image and apply a snapshot to restore it to what it looked like when the snapshot was taken.

Ensuring you have a good restore point for key components of services should start in design. At what interval will you snapshot? Will you simply record basic information with which you can recreate a component, or a full image? These decisions belong in design. Without them, you’ll be left with a need to restore and no way to get back to that known, good, state.

IT-Led service quality – Recoverability – desired state

Performance is effective when:

  • We design for recoverability
  • We capture known good recovery points for our services and their components, at an interval, and with a technique suitable for restoring services and their component to a known good state in a timely fashion, e.g., through backups, baselines, snapshots, records and code through which known good states can be restored, and redundant failover equipment, etc.
  • We test our recovery capability for services thoroughly enough and at a frequent enough interval, and make improvements based on those tests, such that we are confident in the ability to recover quickly and completely should failures occur

Good recovery capability requires design up front, ongoing execution of restore point captures, including deltas, and frequent and thorough enough testing and improvement to ensure recovery capability is sufficient.

IT-Led service quality – Recoverability – practices

  • Availability Management
  • Backup and recovery
  • Backups (website)
  • Backups (VMs, Hyper-V)

The general idea here is to capture points you can restore to, in a format that restores the service or component in a timely enough fashion for the situation at hand.


      1. IT-Led service quality: Discoverability

IT-Led service quality – Discoverability – definition

Source: adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm 04-

Services need to be locatable when needed. This is key in service-oriented architecture, where an instance goes away, and is replaced by another in a recovery or scaling situation.

IT-Led service quality – Discoverability – desired state

Performance is effective when:

  • Services can be easily located when needed

In a relatively static system, discovery can almost be an afterthought. But in a dynamic environment, as in today’s cloud platforms, it is an essential part of locating changing components that provide the same functionality, as they are needed.

IT-Led service quality – Discoverability – practices

  • Service Discovery (microservices architecture)
  • Service Discovery (and dependency injection)
  • Service Discovery (REST API)
  • Service Discovery (service oriented architecture)

Service discovery allow us to not have to know up front, in a static way, where the services that do functions x, y, and z that they depend on are located up front; such a static mapping would create an unnecessary dependency, and quickly breaks down in a dynamic environment.


      1. IT-Led service quality: Trustworthiness

IT-Led service quality – Trustworthiness – definition

Another aspect of trustworthiness is availability, which is one of the three primary tenets of information security, and in this context, means that information assets are available to those that are authorized to use them, that is, there is no denial of service to authorized users.

IT-Led service quality – Trustworthiness – desired state

Performance is effective when:

  • Services and their data can be and have been tested continuously to demonstrate that they have required levels of:
  • Security: information assets are protected from unauthorized access
  • Integrity: assurance that information assets have not been corrupted
  • Credibility: the level of trust in the integrity of the information assets is high
  • Compliance: it is compliant with all relevant regulatory requirement

See whatis.techtarget.com/definition/Confidentiality-integrity-and-availability-CIA for a good discussion of the CIA triad, or the three primary tenets of information security.

IT-Led service quality – Trustworthiness – practices

  • Trustworthy computing
  • Trustworthy cloud computing

Services and their data can be and have been tested continuously to demonstrate that they have required levels of:

  • Security: information assets are protected from unauthorized access
  • Integrity: assurance that information assets have not been corrupted
  • Credibility: the level of trust in the integrity of the information assets is high
  • Compliance: it is compliant with all relevant regulatory requirements

      1. IT-Led service quality: Security

IT-Led service quality – Security – definition

IT-Led service quality – Security – desired state

Performance is effective when:

We align IT security with business security and ensure security is effectively managed in all service and Service activities and provide a focus for all IT security issues and activities.

We design services that ensure the confidentiality, integrity, and availability of assets, information, data, and IT services

Access to services and the service management system are provided only to authorized users

We monitory security and automate security contingencies where possible and useful for faster response to security situations

Security must be agile to keep up with the number and variety of threats and vulnerabilities in IT today.

IT-Led service quality – Security – practices

  • Information Security Management
  • Three primary tenets of information security—confidentiality, integrity, and availability (CIA)
  • Identify management
  • Security policies
  • Security controls
  • Security and penetration testing
  • Security, governance, validation
  • Security automation

The three primary tenets of information security are confidentiality, integrity, and availability (CIA):

  1. Confidentiality – information is available to only those with a right to it, and kept private from those who do not have a right to it
  2. Integrity – information is complete, accurate and free from unauthorized modification
  3. Availability – information can be accessed by those with a right to it when required (there is no denial of service)

      1. IT-Led service quality: Integrity

IT-Led service quality – Integrity – definition

Source: www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Integrity is the quality of information assets, in this case, the data associated with services, where it is assured to be complete, accurate and free from unauthorized modification.

IT-Led service quality – Integrity – desired state

Performance is effective when:

  • We can continuously demonstrate that services and their data have not been corrupted
  • Data is typically not corrupted; in the rare event that it becomes corrupted, we are okay, because we have taken precautions and can restore to a known good state; we also learn how it became corrupted and take steps to learn and improve so that the corruption does not reoccur

Services and their data can become corrupted through:

  • Power-related issues
  • Improper shutdowns / dismounts
  • Hardware issues
  • Software issues
  • Transmission issues
  • Faulty updates, and
  • Hacking, including data breaches caused by malware, viruses or malicious internal or external attacks.

IT-Led service quality – Integrity – practices

  • Admin, physical, and technical security
  • Data integrity

Services and their data can be protected from corruption through:

  • Power conditioning and backup
  • Proper shutdowns / dismounts
  • Hardware, software and transmission assurance
  • Integrity checks after updates, and
  • Mitigations and contingencies against malware, viruses or malicious internal or external attacks.

      1. IT-Led service quality: Credibility

IT-Led service quality – Credibility – definition

Source: www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

IT-Led service quality – Credibility – desired state

Performance is effective when:

  • Stakeholders have a well-founded trust in the level of integrity of services and their data, because we take a proactive approach of demonstrating trustworthy data, and provide evidence of our activities and results of doing so

Credibility is the ability to ensure the level of trust in the integrity of the service and its data.

IT-Led service quality – Credibility – practices

  • Data integrity

See https://www.fda.gov/downloads/drugs/guidancecomplianceregulatoryinformation/guidances/ucm495891.pdf for an example of data integrity guidance.


      1. IT-Led service quality: Compliance

IT-Led service quality – Compliance – definition

Common regulations for compliance, for example in data centers include:

  • HIPPA
  • PCI DSS
  • SAS 70
  • SSAE
  • SOC 1/2/3
  • EU-U.S. Privacy Shield

Governance, Risk and Compliance, or GRC for short, refers to a company’s coordinated strategy for managing the broad issues of corporate governance, enterprise risk management (ERM) and corporate compliance regarding regulatory requirements. Source: https://www.webopedia.com/TERM/G/grc-governance-risk-compliance.html

IT-Led service quality – Compliance – desired state

Performance is effective when:

  • Services conform to all applicable legislative and regulatory requirements
  • We are good at determining the cost of compliance for stakeholders, services, and the SMS, including money and resources, and advocating for those costs, and building them in to our services and SMS
  • We work proactively to have efficient and effective compliance, to reduce the cost and effort to maintain compliance
  • Stakeholders, services, and the SMS are all in compliance with policies and laws, e.g., software licenses

Governance – The effective, ethical management of a company by its executives and managerial levels.

Risk – The ability to effectively and cost-efficiently mitigate risks that can hinder an organization’s operations or ability to remain competitive in its market.

Compliance – A company’s conformance with regulatory requirements for business operations, data retention and other business practices

Source: https://www.webopedia.com/TERM/G/grc-governance-risk-compliance.html

IT-Led service quality – Compliance – practices

  • Governance, Risk and Compliance (GRC)

ISACA, with their product, COBIT, is an excellent source of information on GRC.


      1. IT-Led service quality: Usability

IT-Led service quality – Usability – definition

Source: Adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Services can run the gamut from “one size fits all”, to supporting multiple languages, to supporting people with low or no vision, or hearing, and so on.

IT-Led service quality – Usability – desired state

Performance is effective when:

  • All users indicate our services and the service management system are easy to operate
  • Are services meeting regulatory requirements and the needs of our users, including multi-language capability and the capability to support, for example, users with low or no vision or hearing.

See https://www.ada.gov/pcatoolkit/chap5toolkit.htm for some examples of ADA compliant websites.

IT-Led service quality – Usability – practices

  • User Experience (UX)
  • Usability (website)
  • Usability (mobile app)
  • Internationalization and localization
  • Accessibility (website)
  • Accessibility (mobile app)

Internationalization and localization includes support for different languages, but also currencies, VAT, and so on.


      1. IT-Led service quality: Internationalization

IT-Led service quality – Internationalization – definition

Source: Adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Here’s a good list of multi-cultural considerations – www.webanddesigners.com/multicultural-web-design/. It includes things like data and time formats, time zones, languages, currency, and colors with cultural significance to avoid or use.

IT-Led service quality – Internationalization – desired state

Performance is effective when:

  • For the services and service management system components that require it, support for multi-lingual and multi-cultural requirements is available in our services and the SMS, and stakeholders are pleased with its qualities

Obviously, if you do not have a presence, say, in Canada or the UK, you may not have to be concerned with these issues. But if you plan such growth, better to set your systems up (and choose platforms) that support it, then to have to later retool to do so—it can be very painful.

IT-Led service quality – Internationalization – practices

  • Internationalization and localization (website)
  • Internationalization and localization (mobile apps)

Internationalization is the quality of being easily adaptable for multiple languages, regions and cultures, through things like using Unicode character sets, using text labels that can be translated instead of text embedded in graphics, leaving space in layouts for different languages, avoiding local jargon or colloquialisms in written text, using or avoiding colors, etc. with specific cultural meaning, accommodating different time and date layouts and time zones, as well as different currencies, and so forth.

Localization is the process of adapting a service to a language, region or culture.


      1. IT-Led service quality: Accessibility

IT-Led service quality – Accessibility – definition

Source: Adapted from en.wikipedia.org/wiki/Computer_accessibility

Access to services for the impaired can be facilitate through specialized hardware and software, but services and their components must have the quality of accessibility to support that access.

For example, if a person with low vision has a screen reader device, the service or its components must support use of such device. So, for example, PDF files can be read with a screen reader, but if the PDF files don’t’ have transcripts for videos, or text labels behind graphics and buttons, a low vision person cannot “see” this information—in other words, for this scenario, the system lacks the quality of accessibility.

IT-Led service quality – Accessibility – desired state

Performance is effective when:

  • For the services and service management system components that require it, support for accessibility is available in our services as required by customer and user needs and applicable standards and regulations, including, where applicable, support for specialized hardware and software for accessibility, and support for access by users with disabilities, such as visual, hearing, physical or cognitive impairments, for example, color blindness or Dyslexia.

For internationalization and accessibility, as well as for things like security and compliance, there are a lot of considerations. Often, the levels of expertise required in just one of these areas are well beyond what some individuals and businesses have or can afford in-house. That is another reason why SaaS, PaaS and IaaS offerings have grown in popularity—they have the wherewithal to build things like compliance and internationalization into their offerings, so you don’t have to keep up on the latest requirements and needs and capabilities, you just need to use the capabilities of the offering.

IT-Led service quality – Accessibility – practices

  • ADA compliance (for websites)
  • ADA compliance (for mobile apps)
  • ADA compliance (for software)
  • Specialized HW/SW for accessibility

There is even a browser extension that helps color blind persons better see the web; see https://www.pcworld.com/article/2919980/this-chrome-extension-helps-color-blind-users-see-the-web.html


      1. IT-Led service quality: Adaptability

IT-Led service quality – Adaptability – definition

Source: Adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

One key criteria for DevOps tool chains is that they have an API and a command line interface, and not just a UI, so you can string them together into something that adds value, sometimes in high-value, unanticipated ways, as in ChatOps. So, tools that are UI-only could be said to have low adaptability, and those with an API and command line interface, high adaptability.

IT-Led service quality – Adaptability – desired state

Performance is effective when:

  • It is not impossible or hard to adapt services or the service management system over time and as circumstances change
  • Our services and SMS have the right level of adaptability, including interoperability, scalability, portability, extensibility, and the ability to accept new functionality, and the ability to offer access to services in new paradigms, such as ChatOps and microservices architecture.

Adaptability is a matter of degree, and the right balance that is cost-effective. Some platforms and systems are inherently more interoperable, scalable, portable, and extensible than others, and we should look to these qualities when we evaluate what goes into our service components and into our tool chains.

IT-Led service quality – Adaptability – practices

  • API and CL interface, not just UI
  • ChatOps

https://docs.stackstorm.com/chatops/chatops.html defines ChatOps as bringing work that is already happening in the background today into a common chatroom. By doing this, you are unifying the communication about what work should get done with the actual history of the work being done (both manually and through automation, including timestamps). Things like deploying code from Chat, viewing graphs from a TSDB or logging tool, or creating new Jira tickets…these are examples of tasks that can be done via ChatOps. Besides enhancing collaboration, ChatOps provides a timestamped record of who did what, when, useful as input to blameless postmortems.


      1. IT-Led service quality: Interoperability

IT-Led service quality – Interoperability – definition

Source: Adapted from https://en.wikipedia.org/wiki/Interoperability

Systems that have the quality of being interoperable can be strung together to add more value. So, for example, a CRM system may integrate with a system that provides data on businesses, so that contact information, and other vital statistics for each system are auto populated into CRM.

IT-Led service quality – Interoperability – desired state

Performance is effective when:

  • It is possible and easy for all services and SMS components to communicate, exchange data, and work with all other services and SMS components, to the extent that it is useful and cost-effective to have this capability, without any special effort required to do so.

One key thing about interoperability is that if a system has it as a quality, it requires no special effort to integrate it with another compatible system. So, for example, google Chrome extensions just snap right into the browser, boom, you’re done. You plug an HDMI cable into an HDMI port, and it just works, no special effort.

Often, interoperability is supported by standards like TCP/IP, HTML, and so on, as well as hardware interface standards.

IT-Led service quality – Interoperability – practices

  • Achieving interoperability

According to https://en.wikipedia.org/wiki/Interoperability#Achieving_software_interoperability, software interoperability can be achieved in five ways:

  1. Product testing
  2. Product engineering
  3. Industry/community partnership
  4. Common technology and IP, and
  5. Standard implementation

      1. IT-Led service quality: Scalability

IT-Led service quality – Scalability – definition

Source: adapted from: www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

IT-Led service quality – Scalability – desired state

Performance is effective when:

  • Our services (and the service management system) can scale up / down and out / in, as needed, at a rate of speed and cost that meets our needs, in proportion to the demands placed on them by the environment within which they operate, and to the extent that the level of scalability is cost-effective.

The ability to grow or shrink in capacity or performance appropriately in proportion to demands of the environment in which it operates

Source: adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

IT-Led service quality – Scalability – practices

  • Scale up / down, or scale out / in
  • Elasticity and scaling differences (cloud)
  • Scaling (cloud)

Scaling can be vertical (up and down) or horizontal (in or out).


      1. IT-Led service quality: Elasticity

IT-Led service quality – Elasticity – definition

Source: Adapted from en.wikipedia.org/wiki/Elasticity_(cloud_computing)

https://www.stratoscale.com/blog/cloud/difference-between-elasticity-and-scalability-in-cloud-computing/ points out that scalability and elasticity are not the same, as scalability can be accomplished by simply over-provisioning resources statically. In elasticity, we scale dynamically, up and down, through automation, so that capacity meets demand.

IT-Led service quality – Elasticity – desired state

Performance is effective when:

  • Services (and the SMS) can adapt automatically to workload changes by provisioning and de-provisioning resources in an autonomic manner, such that at each point in time available resources match current demand as closely as possible.

https://en.wikipedia.org/wiki/Elasticity_(cloud_computing) provides an example of elasticity, as follows: say a service provider wants to run a website on an IaaS cloud. At moment, the website is unpopular and a single machine (most commonly a virtual machine) is sufficient to serve all web users. Suddenly, the website becomes popular, for example, because of a flash crowd, and a single machine is no longer sufficient to serve all users. Based on the number of web users simultaneously accessing the website and the resource requirements of the web server, it might be that ten machines are needed. An elastic system should immediately detect this condition and provision nine additional machines from the cloud, to serve all web users responsively. Now let’s say the website becomes unpopular again. The ten machines that are currently allocated to the website are mostly idle and a single machine would be sufficient to serve the few users who are accessing the website. An elastic system should immediately detect this condition and deprovision nine machines and release them to the cloud.

IT-Led service quality – Elasticity – practices

  • Auto scaling AWS
  • Auto scaling Azure

Autoscaling is the process of dynamically allocating resources to match demand to meet performance requirements.


      1. IT-Led service quality: Portability

IT-Led service quality – Portability – definition

Source: Adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

For example, software that is portable could be moved from one machine platform to another, say, a VM that could move from Hyper-V to a Vmware environment and vice versa.

IT-Led service quality – Portability – desired state

Performance is effective when:

  • Services and their components and the SMS and its components can be moved or copied from one environment to another, including data, people, applications and components, without inordinate time or special effort being required

Portability can also be due to using a standard format, as when a .JPEG file can be sent to and viewed on say, a Windows or Mac device, or an iOS or Android phone.

IT-Led service quality – Portability – practices

  • Portability (Software)
  • Portability (Cloud)
  • Portability (Mobile Apps)
  • Portability (VMs and Containers)

The quality of portability can apply, in a greater or lesser degree, to all elements that make up a service, for software, to cloud resources, to mobile apps, VMs, and containers.


      1. IT-Led service quality: Extensibility

IT-Led service quality – Extensibility – definition

Source: www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Extensibility is different from scalability; scalability means a service has the quality of being able to accommodate growth (with elasticity, this scaling can be automated); generally, when you scale, the unit you scale with is uniform, e.g., you are scaling storage, compute, network, or some other uniform resource.

In contrast, extensibility means you can add something new to the system, something that is not “more of the same”, so it doesn’t have to be growth-related. For example, you might extend a CRM system by adding a component that auto-populates Hoovers information into the records for each customer and prospect.

IT-Led service quality – Extensibility – desired state

Performance is effective when:

  • Services and their components (and the SMS and its components) can accept new functionality without inordinate time and special effort being required to do so.

Some services and their components lend themselves to extension, some do not. Those that do have the quality of extensibility.

IT-Led service quality – Extensibility – practices

  • Extensibility (GitHub)
  • Extensibility (XML)

Some language development packages allow for extensibility, but it’s difficult to understand and implement, so this is yet another factor to consider in choosing a development environment.


Chapter 4 Summary

Chapter summary

  • Service qualities are the “-ilities” that are how a service behaves, what developers refer to as the non-functional requirements of the service (versus service configuration which is what components a service is made up of, and service features which are what a service does)
  • Both Human-Led and IT-Led services have qualities

    • OSM®’s list of Human-Led service quality characteristics is adopted from Valerie Zeithaml and Mary Jo Bitner’s SERVQUAL
    • OSM®’s list of IT-Led qualities is adapted from the TOGAF taxonomy of service qualities
  • Each of these service qualities has a desired state that, for relevant qualities for a service, must be achieved and maintained continuously over time and through changing circumstances to ensure value is continuous

Chapter 5

Service Management System (SMS) concepts, desired states and practices (300m)

What is a service management system? What does it look like when it is in its desired state? What are some best practices for getting it there, and keeping it there? We’ll cover that here in this chapter.

OSM® Foundation Course Agenda

Chapter Objectives

Service management system – overall definition

The service management system or SMS may sound fancy, but it’s basically whatever mechanisms you have in place to direct and control services so that they achieve and sustainably maintain the desired state of providing value for stakeholders.

Generally, such mechanisms can be said to fall into four groups of related activities:

  1. Design & transition – where we figure out what to add, change, or retire—either entire services, features, or feature sets, based on our strategy and what we have learned, especially about changes in stakeholder needs and opportunities and what new technology makes possible.
  2. Promotional activities—activities that create uptake of our services, features set and features.
  3. Support – whatever we do to capture and resolve the issues and to fulfill the requests of stakeholders
  4. Delivery – the business operations functions of administering services, Provisioning, metering & billing, budgeting for, and accounting for services.

Service management system – overall desired state

Performance is effective when:

  • We continuously and sustainably provide value to stakeholders through services, over time and changing customer and user needs and technology capabilities
  • We are achieving and maintaining the desired state for all things worth managing—stakeholders, value flow, services, and the SMS itself
  • We continuously improve all aspects of our SMS capabilities, e.g., management, organization, practices, people (skills, knowledge, mindset) policies, objectives, procedures, tools, documents, and resources
  • We continuously improve how we to direct and control services, including how services are planned, designed, developed, implemented, deployed, delivered, monitored, measured, reviewed, maintained, and improved

There are some key differences between the SMS as specified in ISO 20000-1 and the guidance contained in OSM, just as there are key difference between ISO’s conception of the SMS and traditional ITSM guidance. Some key differences are:

  1. ISO emphasizes management’s responsibility; OSM positions the outcomes of service management as everyone’s job—individuals, teams, and the organization as whole.
  2. ISO positions the components of the SMS as processes; OSM positions them as “things worth managing” with desired states to be achieved and maintained; the difference is between a focus on ends (outcomes, or desired states) and means (a process is a potential means).
  3. ISO categories by design, delivery, relationship, resolution and control processes; OSM breaks it down into Design & transition, promote, support, and delivery things worth managing with outcomes or desired states.
  4. Value flows from the provider to the customer through services as controlled by the SMS in ISO; OSM is similar, except value flows multi-directionally from and to providers and suppliers, customers and users.

Service management system – overall best practices

Design & transition

  • Strategy & GRC
  • Learning & improvement
  • Development
  • Release & deployment
  • Change & configuration
  • Uptake

Promotion

  • Marketing
  • Advertising

Support

  • Event handling
  • Incident handling
  • Major incident & disaster handling
  • Problem handling
  • Request handling

Delivery

Stakeholder relations

Administration

Provisioning, metering & billing

Budgeting & accounting

Chapter 5:

As you can see in the figure, a service management system can be broken down into Design & transition, promotion, support, and delivery. OSM handles these a bit differently than traditional ITSM frameworks, which position these as sequential phases and processes.

In OSM, these are going on simultaneously, not sequentially. In other words, while of course there is sequence in workflow, it is not helpful to, for example, put incident handling in one “phase” because “that’s where it first becomes important”.

OSM position these elements not as “processes”, but as “things worth managing”—in other words, each represents a key outcome or desired state that we want to achieve and maintain. The focus here is on ends, not means, as we know that a process is just one means to achieve an outcome, and that a broken process (or a focus on process without attention to other enablers), can disable as well as enable sustained achievement of desired outcomes.

Further, in OSM, we seek to focus on outcomes, as opposed to activities, as this is more lightweight, and suited to today’s environment and agile practices.


Chapter 5: Service Management System (SMS) Concepts, Desired States and Practices


Introduction 5.1: SMS concepts, desired states and practices


      1. SMS definition, desired states, practices

Chapter 5

Chapter Section 1

SMS – Design & transition (90m)

05-02-01. SMS – Design & transition

05-02-02. Strategy & GRC

05-02-03. Learning & improvement

05-02-04. Development

05-02-05. Release & deployment

05-02-06. Change & configuration

In this section, we cover the Design & transition group of activities of the SMS.


Chapter Section 5.2: SMS Design & transition concepts, desired states and practices


      1. SMS Design & transition overall definition, desired state, practices

SMS – Design & transition – definition

In this section, we cover the Design & transition group of activities of the SMS.

Recall that the purpose of your SMS is to direct and control services so the continuously deliver value to stakeholders, sustainably, over time and through changing circumstances.

This will not happen if you don’t have the right strategy for services in the first place, aligned gyroscopically to changes in what stakeholders value and what new technology makes possible, including ensuring they meet any regulatory compliance requirements. This is the strategic learning and improvement loop of the SMS, Strategy & GRC.

Strategy and designs need to be fed through learning loops, and in a dynamic environment, continual improvement is necessary to ensure all things worth managing are as they should be, and if not, are moving gyroscopically towards that desired state—this is the operational and tactical feedback loop of the SMS, Learning & improvement.

The SMS activity group of Development is just what is sounds like—the planning and building of new or changed services, feature sets, and features, qualities (such as availability), and service configuration components, e.g., infrastructure for the service.

Release & deployment is the set of activities within the Design & transition activity group that ensures a quick and quality introduction of new or changed services, features, features sets, qualities, and configuration components. Release & deployment also includes activities for the removal of the same.

Change & configuration is the set of activities that ensures any changes to services are done quickly, with quality, that “what changed?” can be tracked, and that at any time, we have ready visualization everything that constitutes the services we manage.

SMS – Design & transition – desired state

Performance is effective when:

  • We have the right services, over time and as stakeholder value and technology possibilities change, because we have strategic feedback loops that we use to gyroscopically align our services, features, qualities and configuration to what is valued, over time and through changes in stakeholder needs and technology possibilities
  • We have smooth, unencumbered, automated value
  • flow in our Release & deployment and change &
  • configuration activities, because we all continuously
  • work towards fast time-to-value, with quality and
  • continuous improvement

Recall that the purpose of your SMS is to direct and control services so the continuously deliver value to stakeholders, sustainably, over time and through changing circumstances.

This will not happen if you don’t have the right strategy for services in the first place, aligned gyroscopically to changes in what stakeholders value and what new technology makes possible, including ensuring they meet any regulatory compliance requirements. This is the strategic learning and improvement loop of the SMS, Strategy & GRC.

Strategy and designs need to be fed through learning loops, and in a dynamic environment, continual improvement is necessary to ensure all things worth managing are as they should be, and if not, are moving gyroscopically towards that desired state—this is the operational and tactical feedback loop of the SMS, Learning & improvement.

The SMS activity group of Development is just what is sounds like—the planning and building of new or changed services, feature sets, and features, qualities (such as availability), and service configuration components, e.g., infrastructure for the service.

Release & deployment is the set of activities within the Design & transition activity group that ensures a quick and quality introduction of new or changed services, features, features sets, qualities, and configuration components. Release & deployment also includes activities for the removal of the same.

Change and configuration is the set of activities that ensures any changes to services are done quickly, with quality, that “what changed?” can be tracked, and that at any time, we have ready visualization everything that constitutes the services we manage.

SMS – Design & transition – practices

M1

  • Business Relationship Management
  • Strategy Management
  • Service Portfolio Management
  • Knowledge Management
  • Continual Improvement
  • Release and Deployment Management
  • Change Management
  • (Production) Configuration Management

M2

  • The Three Ways (feedback loops)
  • Sprint Planning, Sprint Review
  • CAMS
  • Blameless postmortems
  • Governance, Risk and Compliance
  • Visible Ops-Style Change Control
  • Pets versus Cattle
  • Immutable Deployment
  • Infrastructure Automation
  • Site Reliability Engineering
  • Continuous Integration
  • Continuous Delivery
  • Continuous Deployment
  • Blue/green deployment

Traditional ITSM guidance somehow leaves out GRC as a process, and positions BRM, strategy, and portfolio management as processes in a strategy phase.

OSM combines strategy and GRC into one “thing worth managing”, because both are “north star” considerations that should inform all planning and decisions and actions in organizations.


      1. SMS Design & transition: Strategy & GRC definition, desired state, practices

SMS – Design & transition – Strategy & GRC – definition

Strategy cannot be decided in a vacuum, it must be informed by constraints; chief among these are governance, risk and compliance considerations.

SMS – Design & transition – Strategy & GRC – desired state

Performance is effective when:

  • We have the right strategy at any given time, which is adjusted continually as stakeholder needs and technology possibilities change, and that strategy is in action in our organization; the strategy includes a strategy for stakeholders: how to keep them in a desired state; for services: which services to offer, and to whom, and which to add, change, or decommission, as well as a strategy for the SMS: for what we need to add, change, or decommission to properly direct and control services
  • Our stakeholders, services, and service management
  • system follows all applicable regulatory
  • and legislative requirements, as well as internal standards
  • and policies; we have the right set of effective policies,
  • controls and required documentation in place to maintain
  • a state of compliance, including regulatory compliance,
  • standards, and security policies

      1. SMS Design & transition: Learning & improvement

Strategy is the practice of defining key objective and a direction, allocating resources to pursuing that direction, and putting mechanisms in place to guide the achievement of key objectives. GRC is made up of 1) Governance, which describes the leadership, decision-making structure, processes, and accountability that determine how an organization gets work done, 2) Risk, which is helping to achieve objectives by managing risk through internal controls, and 3) Compliance, or ensuring conformance with company policies, governmental regulations, and industry-specific laws.

SMS – Design & transition – Strategy & GRC – practices

M1

  • Business Relationship Management
  • Strategy Management
  • Service Portfolio Management

M2

  • The Three Ways (feedback loops)
  • Sprint Planning, Sprint Review
  • CAMS
  • Governance, Risk and Compliance

With the M2 SMS, you’ll need to put in place more, faster, and tighter feedback loops between BRM, strategy, knowledge management, continual improvement and sprint planning and reviews than in traditional ITSM. You should expect shorter roadmaps, and for the typical unit of work to shift from entire services to feature sets and individual features, and for the whole thing to happen much faster. A core part of strategy will also have to be figuring out what you will do to ensure uptake of new features and feature sets, so that value is realized by consumers; as you ratchet up the pace of deployment, it becomes more difficult for consumers to take up what you are putting down—you’ll need a strategy to ensure they do.

You’ll also need to integrate GRC in with strategy, which was missing in some traditional ITSM models. As for change control, for Visible Ops-style is recommended. There is a shift-left in configuration management, from managing the logical picture of your configuration, to managing the scripts and templates that create it. Immutable deployment and blue/green deployment have a profound effect on release and change, as do continuous integration, deployment, and delivery.

SMS – Design & transition – Learning & improvement – definition

Learning & improvement is the set of practices roughly analogous to traditional ITSM’s service strategy and continual service improvement phases; OSM combines strategy, compliance and improvement into one set of practices for the following reasons:

  • Both consider the same topic: give our situation, constraints (including regulatory) and scarce resources, where should we invest?
  • As the cadence for introducing new services and SMS components and changes and improvements to them increases, as it tends to in more modern IT environments, the utility of separating out this work into two phases decreases, and in fact, the separation may become a blocker

OSM concentrates the Learning & improvement mechanisms that traditional ITSM separates out by process into the Learning & improvement component of the service management system.

SMS – Design & transition – Learning & improvement – desired state

Performance is effective when:

  • We are continually learning about and improving aspects of stakeholders, services (both IT-Led and Human-Led, including their configuration, functionality and qualities), and the SMS, taking changing stakeholder needs and new technology possibilities into account
  • Stakeholders can freely share and access knowledge when it is needed; Because of this, we make better quality decisions and can move faster with less risk
  • We review all services, at least annually, after major changes, and three months after the introduction of a new service, and reflect the health of the service and improvement actions back to stakeholders

Other indicators of effective performance include:

  • We work to understanding of patterns of business activity and forecast demand and build those understandings into the service improvements we make
  • We have built effective and efficient mechanisms and feedback loops into our practices, services, and service management system that result in the right actions being taken at the right pace and in the right order to ensure we have the right mix of services, by helping us decide which services and SMS components to add, change, or remove, and that those services and the SMS components are of higher value than alternatives to stakeholders as business circumstances change and new technologies create new possibilities
  • We have a continuously evolving vision for what we want to be as a provider, and that vision aligns with stakeholder values, and our portfolio of services aligns with that vision, and where it does not, we have a strategy and action to close the gap by adding, changing, or retiring services and service management system components
  • Improvements to services and the SMS are continual, and at the right pace and priority, given available resources
  • We have the right set of services in the first place, and where that is not the case, we are working quickly to close the gap by adding, modifying, or removing services, features, quality, and pricing models
  • We are continuously aware of how our services stack up against alternatives in terms of price, features, and quality, and where we are not, we move quickly to close the gap; based on this knowledge, we are acting to close the gap in differentiation by adding, modifying, or removing services, features, quality, and pricing models

SMS – Design & transition – Learning & improvement – practices

M1

  • Knowledge Management

  • Continual Improvement
  • Plan-Do-Check-Act (PDCA)
  • CSFs and KPIs
  • Service reviews
  • Post-implementation reviews
  • Trend analysis

M2

  • The Three Ways (feedback loops)
  • Sprint Planning, Sprint Review
  • CAMS
  • Blameless postmortems

The Deming cycle, is also known as the PDCA or plan-do-check-act cycle.

Conduct blameless postmortems, e.g., after a major incident, problem, disaster, or failed change or release.


      1. SMS Design & transition: Development

SMS – Design & transition – Development – definition

So, you can see from this definition that development’s scope in OSM is not just applications, but stakeholder mechanisms, services (including their configuration, functionality, and qualities), and the SMS.

SMS – Design & transition – Development – desired state

Performance is effective when:

  • We develop stakeholder mechanisms, and the SMS, and not just services; when we develop services, we get the configuration, functionality, and qualities right
  • We continuously listen and improve what and how we Design & transition, with more, faster, and tighter feedback loops between stakeholders, demand and capacity and financial data, strategy & GRC, knowledge management, continual improvement and sprint planning and reviews, shorter roadmaps, and smaller work packages
  • We automate and provide self-service for development resources and activities well, for faster time-to-value with quality from our build pipeline

There are of course many aspects to development, more than can be incorporated within this space and within the scope of a service management foundation course. Having said this, it’s important to note what we are developing—not just services, but stakeholder mechanisms and the SMS; that we have a “smaller + faster = better” approach, with a focus on automation and self-service in the build pipeline.

SMS – Design & transition – Development – practices

M1

  • Design Coordination
  • Service Catalog Management
  • Service Level Management
  • Capacity Management
  • Availability Management
  • IT Service Continuity Management
  • Information Security Management
  • Supplier Management

M2

  • The Three Ways (feedback loops)
  • Sprint Planning, Sprint Review
  • CAMS
  • Blameless postmortems
  • Infrastructure Automation
  • Site Reliability Engineering
  • Continuous Integration
  • Continuous Delivery
  • Continuous Deployment
  • Lean and Agile Practices
  • Application Lifecycle Management
  • Test-Driven Development
  • User Stories

Some definitions:

Continuous Delivery

Automated implementation of the application build, deploy, test and release processes meant to ensure performance (fast delivery) and conformance (to requirements), enabling users to start using new functionality and qualities quickly to realize value and provide feedback sooner.

Application Lifecycle Management (ALM)

The supervision of, and documentation and tracking of changes to a software application from its initial planning through removal. Source: searchsoftwarequality.techtarget.com/definition/application-lifecycle-management-ALM


      1. SMS Design & transition: Release & deployment

SMS – Design & transition – Release & deployment – definition

A release is a set of related components and changes that we manage as a set, because it makes sense to do so; for example, we could roll out SAP as 5700 changes, one at a time, but it makes more sense to manage it as a release—to put a team on it, to make sure the live environment is ready for the releases, to make sure the release itself is good, and the plan and mechanism to deploy it and back it out if necessary are good, and so on. Each individual change associated with a release still needs to be managed through change control, it’s just that it makes sense to also manage at the “zoom level” of a release.

SMS – Design & transition – Release & deployment – desired state

Performance is effective when:

  • Stakeholders realize value quickly, with quality, from new or changed services, feature sets, features, and qualities, which are released quickly and with quality, through a pipeline whose flow we automate and continuously improve
  • We’ve put mechanisms in place that make it easy to try new services, feature sets, and features, and roll them back where necessary and useful
  • We do a good job at making sure we have the right resources and enough of them when we release and deploy new or changed services, especially when there are concurrent releases and deployments, and resolving schedule and resource conflicts
  • when they do arise
  • We have consistency across releases and deployments, no
  • irrational variation
  • Cost, schedule, and resource estimates are sufficiently accurate
  • We have good feedback loops from stakeholders back to
  • Release & deployment

With release and deployment management, we are working to get customers and users the services, feature sets, and features and qualities they need, quickly, with quality, and with continuous improvement, both of services and the build pipeline.

SMS – Design & transition – Release & deployment – practices

M1

  • Release and deployment
  • Release policy
  • Definitive Media Library

M2

  • Continuous Delivery
  • Blue/green deployment
  • CAMS
  • Immutable deployment

A definition:

Continuous Delivery

Automated implementation of the application build, deploy, test and release processes meant to ensure performance (fast delivery) and conformance (to requirements), enabling users to start using new functionality and qualities quickly to realize value and provide feedback sooner.


      1. SMS Design & transition: Change & configuration

SMS – Design & transition – Change & configuration – definition

Change and configuration are tied at the hip; change is make the actual changes well, and configuration is making sure that we have a good logical picture of what we have out there, and for each component of our configuration, know what it looks like, to a level of detail that is useful to us, and how it relates to other things we have out there.

SMS – Design & transition – Change & configuration – desired state

Performance is effective when:

  • We get stakeholders the changes they need quickly and with quality, so they can start realizing value as soon as possible.
  • We minimize disruptions due to changes, and can track, “what changed?” precisely enough; and we don’t have a lot of backed out changes, but when we must, we can back out easily.
  • The reality and how stakeholders see it, is how we handle changes as not as slowing down needed changes, but as helping those making changes move quickly, taking appropriate risks and facilitating speed with quality
  • We ensure a logical model of IT Services, Assets and IT
  • Components needed is defined, controlled, maintained and kept accurate and detailed enough as a source of information for fact-based management of IT services and to comply with corporate governance requirements.

Some other indicators of effective performance include:

We minimize the number of eyeballs that need to be on changes, and work relentlessly to root out unnecessary complexity, variation, and dependencies, so that fewer stakeholders must be involved in looking at few changes, and can focus on the ones that really need their attention

We know, precisely enough, what configuration items we have, how they relate to one another and to relevant classes or groups, and what their configuration is to a sufficient level of detail and accuracy to do the work that we do well, and all stakeholders who need the information have easy access to this information when they need it, e.g., when troubleshooting or planning; this includes configuration items that are internal to us as the provider, and external to us, where they are components of our stakeholders, services, and the SMS; this goes for production and pre-production configuration items

We build out configuration items that make up components of stakeholders, services, and the SMS from known good sources and keep them in a known good state.

We have a baseline of configuration items as a reference point and all the snapshots we need for reference and to be able to restore to a prior state, or for other purpose we have

We can tell multiple versions of the same configuration items apart easily, and can easy compare and see how they are the same and different

We can produce accurate information on stakeholder, service, and SMS components and their configuration, versions, and relationship among components easily, e.g., for audits.

Our configuration is under control—it is always the case that the components, versions, and relations between components of stakeholders, services and the SMS are in a known and controlled state, with demonstrable integrity. And we have visualization into current state, planned state, and past state for all configuration items when we need it

SMS – Design & transition – Change & configuration – practices

M1

  • Change management
  • Configuration management
  • Baselining and snapshotting
  • CMDB

M2

  • Microservices architecture / REST
  • Variation reduction
  • Immutable deployment
  • Infrastructure-as-code
  • Service Discovery
  • Cloud
  • Standardizing resource configurations
  • Software configuration management

The general shift from traditional ITSM practices is due to a shift from traditional to cloud/mobile environments. For cloud/mobile, suitable practices are needed to fit the target environment to be managed.

Chapter Section summary

A Service management system (SMS) is a set of specialized organizational capabilities (management, organization, processes, knowledge, people (experience, skills, relationships)) and interrelated or interacting elements (including policies, objectives, procedures, tools, documents, and resources) service providers use to direct and control services, including how services are planned, designed, developed, implemented, deployed, delivered, monitored, measured, reviewed, maintained, and improved. The aim of the SMS is to achieve and sustainably maintain the desired state of providing value to customers and users in the form of services.

Chapter Section summary

  • Design & transition are the set of SMS practice areas concerned with:
  • Strategy & GRC — ensuring there is a strategy and governance and compliance mechanisms, and that services are continually aligned to it
  • Learning & improvement of services—ensuring the set of services is continuously aligned to stakeholder needs over time and through changing circumstances; this includes knowledge management, and continuous improvement
  • Development of services—the initial planning and building of services
  • Release & deployment — the initial release and deployment of services
  • Change & configuration of services — changes to services and
  • subsequent releases and deployments, through the lifecycle
  • of the service, including removal
  • Each of these practice areas has a desired state that must be
  • achieved and maintained continuously over time and through
  • changing circumstances to ensure value continually flows to
  • all stakeholders; these desired states can be achieved and
  • maintained through best practices


Chapter Section 5.3: SMS Promotion concepts, desired states and practices


      1. SMS Promotion overall definition, desired states and practices

SMS concepts, desired states and practices – Promotion (30m)

Promotion

In this chapter, we’re covering topics that will help you describe what a service management system is, its typical components, their desired states, and best practices for achieving them, including the following SMS components in the category Promotion.

SMS – Promotion – overall definition

Source: adapted from www.ama.org/aboutama/pages/definition-of-marketing.aspx

Both internal and external services need to be taken up for value to be realized. Externally, to external customers, this is marketing, advertising, and sales. For internal customers, it’s internal marketing and “selling”. Once services are subscribed to, either internally or externally, it is vital that they get used (the pejorative term for software that is paid for but not used is “shelfware”) for value to be realized fully by stakeholders.

SMS – Promotion – Desired state

Performance is effective when:

  • New customers are buying our services, and referring others to buy our services in numbers meeting or exceeding our revenue and profit requirements
  • Existing customers are staying with us and referring others to buy our services
  • New users are using our services, including existing, new and changing services and new and changing service functionality and qualities, and referring others to use them in numbers meeting or exceeding our requirements
  • Existing users are staying with us and referring others to use our services

SMS – Promotion – practices

M1

  • Service catalog

M2

  • Lead generation and Enrollment
  • Driving uptake

Some best practices for human-led services promotion:

Delivery is a services firm’s most valuable sales tool. (“The PSF 50”, pg. 156, “How to Buy/Sell Professional Services”) A services firm’s ability to sell begins and ends with the ability of its consultants to deliver. A sale does not end when an engagement begins—the only thing a client has at the beginning of an engagement is the promise of results. A sale ends when all results have been achieved to the client’s satisfaction.

Existing clients are our highest probability prospects. (“Managing the Professional Service Firm”, pg. 97) Existing clients are a services firm’s best source of new business. When dealing with existing clients, services firms have already earned their trust and confidence, they often understand other aspects of the sales process important to the final decision, and there is often little or no competition, especially in cases where the firm discovers the need.

The best way to sell is to care. (“Managing the Professional Service Firm”, pp. 71, 120) The essential nature of services revolves around relationships, not technical matters. Clients shop for trust, confidence, and peace of mind as much as they do technical expertise. They respond most favorably to consultants with an interest in their problems and a sincere desire to help. Therefore, the best means of attracting clients is to care about helping clients succeed.

The marketing of services must be a seduction, not an assault. (“Managing the Professional Service Firm”, pg. 122) Marketing services is most effective when it demonstrates competence, not when it asserts it. Successful marketing of services is ultimately about attracting clients in a manner that they want to take the next step in the relationship.

The goal of marketing is to create face-to-face interaction. (“Managing the Professional Service Firm”, pg. 121) The goal of all marketing efforts in a services firm is to generate face-to-face dialogues with prospects. Individualized content delivered through face-to-face interaction is much more effective than general messages broadcast to large audiences.


Chapter Section 5.3 Summary

Services must be purchased and used for all stakeholders (customers, users, the provider, and supplier) to realize value

Value is a function of uptake of services, including existing, new, and changing functionality and service qualities; the goal of the provider is to have the right services and functionality and service qualities in the first place, and as time passes and customer and user circumstances and technology possibilities change, to add, modify, and remove services, functionality, and qualities to ensure services continuously provide value; but this is not enough; providers must ensure uptake of services, including existing and new and changing functionality and service qualities, to ensure customers and users fully realize value

The promotion practice area of the service management system is aimed at ensuring uptake of services through marketing, advertising, and sales of external services to external customers and users, or the equivalent activities for internal services for internal customers and users

The promotion practice area has a desired state that must be achieved and maintained continuously over time and through changing circumstances to ensure value continually flows to all stakeholders; this desired state can be achieved and maintained through best practices


Chapter Section 5.4: SMS Support concepts, desired states and practices


      1. SMS Support overall definition, desired state, practices

SMS concepts, desired states and practices – Support (90m)

Support

05-04-01. SMS – Support

05-04-02. Event handling

05-04-03. Incident handling

05-04-04. Request handling

05-04-05. Problem handling

05-04-06. Major incident & disaster handling

In this chapter, we’re covering topics that will help you list and describe the what a service management system is, its typical components, their desired states, and best practices for achieving them, including the following SMS components in the category Support.

SMS – Support – overall definition

We want to detect events related to services must be detected and notifications sent out, so that desired control actions (either automated or manual) can be taken, including triggering incident handling for exceptions we have trapped. We also want to make sure all transactions that come in from our users, either through the portal or some other channel, get handled—both requests and incidents, either through automation, or by human intervention, or by some combination of the two. Lastly, we want to make sure major incidents (which lie somewhere between a regular incident and an all-out disaster, and which, if left alone, tend to become disasters) and disasters get handled properly. Handling in all these cases includes both proactive provisions for these transactions and scenarios, as well as the reactive dispatching of them when they do occur.

SMS – Support – desired state

Performance is effective when:

  • Stakeholders typically do not require support, because our services just work and are easy to grasp and use; in the rare occasion that they do require support, stakeholders are satisfied with the level of support they receive, both with the result they get and with the interaction / experience of support
  • Stakeholders indicate that we detect all events (informational, warning, or exception) related to services that are worth knowing about and managing, and send out notifications so that desired control actions (either automated or manual) can be taken, including triggering incident handling for exceptions
  • Stakeholders indicate that all requests and incidents that come in from users, either through the portal or another channel, get handled, through automation, human intervention, or some combination of the two.
  • Stakeholders agree that we make sure major incidents (which lie somewhere between a regular incident and an all-out disaster, and which, if
  • left alone, tend to become disasters) and disasters get handled properly, including both proactive provisions for these transactions and scenarios, and reactive dispatching when they do occur
  • We automate and continuously improve to reduce support cost, timescales and effort

In the end, we want to provide responsive support at the right cost.

SMS – Support – practices

M1

  • Event handling
  • Incident handling
  • Major incident & disaster handling
  • Disaster handling
  • Request handling
  • Problem handling
  • Self-service portal

M2

  • Event handling
  • Monitoring and logging
  • Incident handling
  • Multi-channel service
  • Major incident & disaster handling
  • Incident Command System (ICS)
  • Infrastructure Automation
  • Request handling
  • CAMS (for automation)
  • Problem handling

Traditional ITSM guidance positions the handling events, incident, major incidents, problems and requests as processes in an operations phase of a lifecycle. OSM positions them as “things worth managing” with desired states to be achieved and maintained. The difference in positioning is the difference in a means (process) versus end (outcome or desired state) model. Traditional ITSM guidance positions disaster handling in a service design phase. OSM places it in line with other support and response processes here; note that the service quality of recoverability associated with disaster preparedness is covered in the service qualities portion of the OSM model.

One example here of a mode 2 practice: Infrastructure automation is based on the cloud-based reality that infrastructure components can and should be treated like code. System specs should be checked into source control, go through a code review whether a build, an automated test. Then you can automatically create uniform instances from the spec and to manage them programmatically. There are so many ITIL challenges you can overcome by infrastructure automation. For example, we can start by applying the DevOps method of infrastructure automation to your ITIL-driven IT Service Continuity, or disaster recovery process. We used to talk a lot about design for availability and a DR site and hardware in another city, keeping two data centers in sync; now because I can script my infrastructure deployment I can just grab my script, point it at the other datacenter, run it and bam, I’ve got another instance of my infrastructure. Some organizations I work with have gone beyond infrastructure as code, to operations a code (automating every ITIL process with code); alerts, incidents, problems, provisioning, capacity, demand, availability, performance, everything can be reduced to automation through code.


      1. SMS Support: Event handling

SMS – Support – Event handling – definition

SMS – Support – Event handling – desired state

Performance is effective when:

  • We have the right set of event detection and alert notification mechanisms set up, so that we can detect all changes of state in stakeholders, services, and the SMS that are significant and may require a control response; These include normal situations, e.g., informational “chron job just ended”, to warning “you set a threshold of 15% utilization on this storage array and told me to tell you when it happened; I am telling you”; to exception / abnormal situations “server down”; we have these set up to monitor for all quality of all services, including financials, service levels, continuity, availability, throughput, configuration, security, and compliance, as well as the components of services, including environment

(E.g., temperature, fire, water detection), hardware, system software, networks, applications, and DBMS

Event management in OSM is not just about capturing infrastructure or application events, but capturing and notifying about all “things worth managing”.

SMS – Support – Event handling – practices

M1

  • Event handling

M2

  • Instrumentation / Telemetry
  • Monitoring
  • Cloud Monitoring / Telemetry
  • Logging / Instrumentation
  • Logging cheat sheet
  • API and CL interface, not just UI
  • ChatOps

The general trend is to take point solutions with an API and a command line interface, and string them together to create a toolchain, rather than seeking monolithic solutions. Part of the interesting shift in recent year has been that tools that were built assuming a physical on-prem environment haven’t necessarily made it over to the cloud, because their core model is so different, and cloud solutions are being produced more through iteration (leading initially to smaller, more point solution offerings), which seems to have led to this trend.


      1. SMS Support: Incident handling

SMS – Support – Incident handling – definition

With an incident, something is broken. It could be an error trapped in the infrastructure, or a user who is “broken”, i.e., cannot work.

SMS – Support – Incident handling – desired state

Performance is effective when:

  • Incidents are handled within service level targets, and stakeholders are satisfied with the professionalism and speed with which we handle incidents
  • Incidents are handled effectively and efficiently, while minimizing disruption on stakeholders, services, and the SMS
  • Feedback to Learning & improvement for improving both services and the service management system to better handle similar situations going forward
  • We employ automation in the handling of incidents
  • Incidents are resolved within agree service level targets, including incidents concerning quality of a service, including financials, service levels, continuity, availability, throughput, configuration, security, compliance; in addition to resolving incidents, we analyze cycle time components to see how we can
  • crash MTTR/MTTRS, by taking time out of the cycle,
  • e.g., time to record, respond, resolve,
  • repair/replace, recover

We work to prevent incidents in the first place, and should they occur, we work to resolve incidents as quickly as possible, certainly within service level targets for MTTR / MTTRS; further, we work to proactively crash the cycle time for incidents through analysis, action, and automation by analyzing where time is spent in the cycle, e.g., time to record, respond, resolve, repair / replace, recover

SMS – Support – Incident handling – practices

M1

  • Incident management
  • Service desk

M2

  • Public status pages
  • Multi-channel support
  • ChatOps
  • Devs on Call

The DevOps practice Putting Devs On Call for the services they create is based on the golden idea of, “you dealt it, you deal with it”—the idea that Devs will take more care of the quality of what they produce if the will must suffer the pain of dealing with it later, and not just chucking it over the fence for somebody else to test. The Devs on Call DevOps practice has the greatest impact on traditional ITSM-driven Application Management, Service Desk, and IT Operations functions.

You put Devs on call for the service they create to create a fast feedback loop that helps rapidly improve logging and deployment, and more quickly resolve application issues.


      1. SMS Support: Request handling

SMS – Support – Request handling – definition

Note here that requests can be self-service. They can be requested and fulfilled totally manually, or totally automated, on both sides of the equation. Also, note that requestors in this model are not just customers and users. For example, self-service and requests are part of the normal fabric of working within a build pipeline, by provider staff and suppliers.

SMS – Support – Request handling – desired state

Performance is effective when:

  • Requests are handled within service level objectives or targets, and stakeholders are satisfied with the professionalism and speed with which their request are handled

  • Feedback to Learning & improvement for improving both services and the service management system to better handle similar situations going forward
  • We support all request channels stakeholders are inclined to make most use of
  • We automate and continuously improve request handling, to reduce time-to-value and irrational variation and the costs and effort that come with it
  • We have a graceful method for rejecting service requests where the requestor is not entitled to what has been requested

When rejecting a request for which the requestor is not entitled, we must always provide the reason to the requestor in a graceful way.

SMS – Support – Request handling – practices

M1

  • Request handling
  • Self-service portal

M2

  • Request handling
  • Multi-channel service
  • CAMS (for automation)

The key idea here is providing channels to stakeholders that stakeholder want to use, that make making requests “ready-to-hand”, easy to get to, easy to do, just easy. And further, to automate, automate, automate, with self-service on the front-end, and scripted fulfillment on the back end.

SMS – Support – Problem handling – definition


      1. SMS Support: Problem handling

A problem is the root cause, the unknown, underlying of one or more incidents. What capability do we have to handle problems?

SMS – Support – Problem handling – desired state

Performance is effective when:

  • At any given time, we can list the top ‘n’ problems we’re working on, what we’ve done so far, and what we’re going to do next
  • We work proactively to prevent problems up front, and to prevent them from reoccurring; when a problem is live, we work to minimize the disruption the problem causes, through workarounds and crisp communication and action
  • We have effective shared root cause analysis in “muscle memory”, that multiply our capability to solve problems as a group
  • Feedback to Learning & improvement for improving both services and the service management system to better handle similar situations going forward
  • We practice blameless postmortems to review problems, which focus on learning and improvement, and are fact-driven and
  • action-oriented, balancing accountability with a
  • safe environment to share failures
  • We arm problem solvers with the right skillset
  • and authorization to handle problems

While traditional ITSM guidance describes problem handling as a process, and while you could draw a process map for it, there wouldn’t be much to it. In the end, problem management is the sum of your application of shared techniques for preventing and solving problems, techniques like Kepner-Tregoe problem analysis.

SMS – Support – Problem handling – practices

M1

  • Problem handling

M2

  • Problem handling
  • Site Reliability Engineering
  • Blameless postmortems

Site reliability engineering (or SRE), is defined by Ben Treynor, founder of Google’s Site Reliability Team, as, “what happens when a software engineer is tasked with what used to be called operations”. 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. SRE focuses on engineering continuous operations at the point of customer consumption.

The largest impact of SRE on traditional ITSM-driven shops is that the SRE is an entirely new role in many shops. Part systems administrator, part second tier support and part developer, SREs ask questions, acquire new skills and knowledge, and embrace automation, and have the coding skills to solve problems and ensure the highest levels of reliability and availability. SREs are involved in the handling and management of late-night incidents, escalations, root cause analysis, service level objectives, availability and performance metrics, and other ITIL-driven practices. SREs provide a basis for instilling agility into many ITIL processes to meet changing demands brought about by the march to the cloud and DevOps, Lean and Agile practices.


      1. SMS Support: Major incident & disaster handling

SMS – Support – Major incident & disaster handling – definition

You can think of a major incident as an incident that is much more significant than the average incident, that, if left untended, can become a disaster.

Traditional ITSM guidance places major incident management under incident management as a process, and refers to disaster handling as continuity management, which it places in a service design phase. OSM see major incidents and disasters as things worth managing, to a desired state. Note that some of the service qualities in the OSM model directly correspond to these two “things worth managing”—for example, supportability and recoverability. In OSM, these are not processes, but qualities built into services that must be kept in a desired state.

SMS – Support – Major incident & disaster handling – desired state

Performance is effective when:

  • Major incidents and disasters are handled effectively and efficiently, within service level objectives or targets agreed with stakeholders
  • Feedback to Learning & improvement for improving both services and the service management system to better handle similar situations going forward, and we’ve applied learning and automation to improve recoverability capability and speed by design up front and continual improvement
  • We work proactively to prevent major incidents and disasters, and to prevent their reoccurrence; when a major incident or disaster is living, we work to minimize the disruption it causes, through workarounds, crisp communication and action
  • We have effective shared major incident and disaster command systems in “muscle memory”, that multiply our capability to solve problems as a group
  • We practice blameless postmortems to review problems, which focus on learning and improvement, and are fact-driven and action-oriented, balancing accountability with a safe environment to share failures

SMS – Support – Major incident & disaster handling – practices

M1

  • Major incident & disaster handling
  • Disaster handling

M2

  • Public status pages / transparent uptime
  • Incident Command System (ICS)

Incident Command System is applicable to both major incidents and disasters, as it is a method of scaling up or down with self-similar teams.


Chapter Section 5.4 Summary

  • Support is the practice area of the SMS that directs, controls and executes the day-to-day support of services, including handling events, requests, incidents, problems, major incidents and disasters. Contrast support with delivery, which is the component of the SMS that directs, controls and executes the day-to-day operation of services, including stakeholder relations, administration, provisioning, metering, and billing, and budgeting and accounting. Support is characterized by handling of customer and user requests within a timeline set in an SLA, as well as major incidents, problems, and disasters; while there are reactive aspects of the delivery components of the SMS, they are primarily characterized by planned activities on a set schedule, whereas support is primarily characterized by responding to customer and user requests, as well as problems, major incidents and disasters, with proactive aspects being important, but less frequent, than those that are unplanned.

  • Each of these practice areas has a desired state that must be achieved and maintained continuously over time and through changing circumstances to ensure value continually flows to all stakeholders; these desired states can be achieved and maintained through best practices


Chapter Section 5.5: SMS Delivery concepts, desired states and practices


      1. SMS Delivery overall definition, desired states, practices

SMS concepts, desired states and practices – Delivery (90m)

Delivery

05-05-01. SMS – Delivery

05-05-02. Stakeholder relations

05-05-03. Administration

05-05-04. Provisioning, metering & billing

05-05-05. Budgeting & accounting

SMS – Delivery – overall definition

Stakeholder relations is a “thing worth managing” in OSM, related to BRM in traditional ITSM guidance, but extending the idea to all stakeholders—customers, users, provider staff, and suppliers, and substituting a desired state (end-in-mind) for a process (means).

Administration consists of adding, modifying and deleting service subscriptions, add-ins and integrations, licenses, users, groups, resources, account and billing settings; getting sysadmin-level support for subscribed services; reviewing reports on usage, security and compliance; monitoring service health.

Provisioning, metering, and billing is concerned with initial set up of services for customers, monitoring their usage, and charging customers for the services they use. It also covers related items like handling upgrades, downgrade and cancellations that affect billing. In organizations where chargeback is not used, this area is concerned with showback.

Lastly, being able to budget and account for IT services is a “thing worth managing” that is part of the delivery of services.

You may see a departure here form some traditional ITSM guidance, that positions “delivery” as such things as service level, availability, capacity, continuity, and financial management. As you can see, OSM includes only financial management (budgeting & accounting) is service delivery. In OSM, availability, capacity (performance) and continuity (recoverability) are not processes, as in traditional ITSM, but qualities of IT-led services.

SMS – Delivery – overall desired state

Performance is effective when:

  • Stakeholders are satisfied with the delivery of our services, as time passes and stakeholder and overall industry circumstances change, as new technologies and possibilities emerge, and as our services change, including:
  • Stakeholders feel listened to, and feel we are adapting to new possibilities and changing circumstances appropriately and quickly, so that our services and their functionality and qualities reflect their feedback and needs
  • Stakeholders feel administrative transactions are quick and easy to administer, and that that there is an appropriate level of automation and self-service to them
  • Stakeholders feel that the process of provisioning services is quick and painless, that how services are metered is easy to understand up front and transparent, and that the billing or showback process is quick and easy and has the right options to meet their needs
  • Services are budgeted for accurately, so there are no unpleasant surprises like cost over-runs, and accounted for accurately, so there are no surprises as to costs, expenses, or profits
  • Stakeholders feel both planned and unplanned delivery activities are handled well

These desired states are for the “things worth managing” in service delivery, which is the day-to-day administrative operations of services, including:

  • Stakeholder Relations
  • Administration
  • Provisioning, metering & billing
  • Budgeting & Accounting

SMS – Delivery – practices

M1

Business Relationship Management

Financial Management

M2

Stakeholder relations

  • Customer relations
  • User relations
  • Provider relations
  • Supplier relations

Administration

Provisioning, metering, and billing

Budgeting & accounting

Best practices are what people do now that works to help them achieve and maintain desired states for things worth managing like stakeholders, day-to-day administration, provisioning, metering, and billing, and budgeting and accounting.


      1. SMS Delivery: Stakeholder relations

SMS – Delivery – Stakeholder relations – definition

You should see the difference here between stakeholder relations and BRM. BRM is a traditional ITSM process; the outcome of BRM is valid, and included in stakeholder relations in OSM, but extended to apply to all stakeholders, including provider staff.

SMS – Delivery – Stakeholder relations – desired state

Performance is effective when:

  • Customers are satisfied both with the value of our services and with how we engage with them as time passes and circumstances change and as we adapt our services to those changes; our relationship with customers is constructive, productive and mutually beneficial, and characterized by our service portfolio continuously being adapted based on a combination of continuous customer listening and our bringing forward the possibilities new technologies and changing business circumstances bring
  • Users are satisfied both with the use of our services and with how we engage with them as time passes and circumstances change and as we adapt our services to those changes; we have a constructive, productive and mutually beneficial relationship with users characterized by providing value in every interaction.
  • Suppliers are satisfied with the value they get from our constructive, productive and mutually beneficial relationship; they consistently meet or exceed their commitments to us, and strive to bring more to the table than simply fulfilling them obligations
  • We, the provider staff, are satisfied with our work, over time and through change

In the end, what we are aiming for is a sustainable situation where all key stakeholders are satisfied. This is a dynamic system, since what will satisfy stakeholders will change, as will the means, e.g., the technology possibilities. Note here that satisfying stakeholders is not meant to mean everyone is obliviously happy and gets everything they want, like a parent giving a child ice cream for breakfast, lunch and dinner. Relationships take work, sometimes hard, and educational conversations in both directions about what is needed, what is possible, and what wherewithal is required to deliver it consistently.

SMS – Delivery – Stakeholder relations – practices

Stakeholder relations

  • Customer relations
  • M1
  • Business Relationship Management
  • Service Level Management
  • User relations
  • M1
  • Service Desk
  • Provider relations
  • Supplier relations

In OSM, service level management is accomplished by making sure the service has the right configuration, features (including instrumentation), and qualities (which are the things like availability and performance (capacity) that go into a service level agreement, and making sure these “things worth managing” are kept in a desired state, over time and through changing circumstances.


      1. SMS Delivery: Administration

SMS – Delivery – Administration – definition

In delivery of services, someone’s got to do the day to day sysadmin tasks, and they need to be done right—accurately, and in a timely manner.

SMS – Delivery – Administration – desired state

Performance is effective when:

  • Stakeholders are pleased with responsiveness and quality of our conduct of technical (sysadmin) tasks associated with adding, modifying and deleting service subscriptions, add-ins and integrations, licenses, users, groups, resources, account and billing settings
  • Stakeholders are pleased with the responsiveness and quality of our sysadmin-level support for subscribed services
  • We review reports on usage, security and compliance, and monitoring service health, to avoid issues and outages
  • Wherever possible and cost-effective, we automate sysadmin tasks to reduce time-to-value, as well as unnecessary variation and its associated costs

Automating sysadmin tasks is a key part of this, and the SRE role can be a key part of this.

SMS – Delivery – Administration – practices

M1

  • Sysadmin

M2

  • Site Reliability Engineering

Site Reliability Engineering, which is described as “what happens when a software engineer is tasked with what used to be called operations”, is a discipline that incorporates aspects of software engineering and applies them to IT operations problems, with the aim of creating ultra-scalable and highly reliable software systems.


      1. SMS Delivery: Provisioning, metering & billing

SMS – Delivery – Provisioning, metering & billing – definition

Provisioning, metering and billing is the set of activities required to bill customers for services they consume (or, if you don’t do chargeback, at least showback). It requires sound IT accounting practices and systems, and includes a periodic negotiation cycle to set (usually annually) pricing policy and price lists, monthly compiling and issuing of bills (either charge- or show-back).

SMS – Delivery – Provisioning, metering & billing – desired state

Performance is effective when:

  • Stakeholders are satisfied both with the efficiency and results of provisioning (including initial setup and later, decommissioning) as well as with the engagement / interaction itself
  • Stakeholders are satisfied with the accuracy of metering and billing (whether it is chargeback or showback), including the transparency of algorithms for both, and the provisions we make to allow them to influence their usage and costs to their advantage
  • If we charge back, our charging model is transparent and communicated up front so there are no negative surprises to customers, and it is easy for customers to pay and for us to collect payment; we are also clear on our goal for charging (e.g., loss leader, break even, profit) and our algorithms

Chargeback is providing pay-the-bills customers with an analysis of the provider service costs on, for example, a monthly basis, and charging them for those costs. Showback (also known as memo billing), is providing the same analysis, but without charging them for those costs. The idea with showback is to provide information to drive the right behaviors. Showback is like the note you get from your insurance provider for a medical procedure you have had that is fully covered—this is what it would have cost you, etc.

Some other indicators of performance include:

  • Customers can easily determine what services have and will costs, and can easily manage their subscription through a portal
  • Stakeholders see Total Cost of Ownership (TCO) for services as reasonable

SMS – Delivery – Provisioning, metering & billing – practices

M1

  • Financial Management

M2

Provisioning, metering, and billing

  • Consumptive billing model
  • Chargeback and showback
  • Provisioning (User)

We can be doing well as a provider in a lot of areas, but screwing up on “the last mile”—on things that touch the client directly and greatly impact their preferences and perceptions—is something we cannot afford to do. Provisioning, metering and billing are part of that last mile.


      1. SMS Delivery: Budgeting & accounting

SMS – Delivery – Budgeting & accounting – definition

Source: www.accountingtools.com/dictionary-budget,

www.accountingtools.com/questions-and-answers/what-is-accounting.html

It is important that budgeting and accounting systems be set up with a chart of accounts, reports, etc. that can record and show, e.g., budget versus actual, by services.

SMS – Delivery – Budgeting & accounting – desired state

Performance is effective when:

  • We accurately account for IT costs, map cost data back to categories and services, and use that data for investment and budgeting decisions.
  • Whether we offer services to make a profit or offer services at no profit, our services and the SMS have a sustainable funding model
  • We can easily determine and communicates the full cost of providing services and the SMS and revenue and profit, and we are proactively managing costs down and revenue and profit and value to stakeholders up
  • We can quantify the value of each service we provide, and of the SMS
  • We operate in line with our organization’s financial policies
  • Expenses are the same or less, and revenues and profits are the same or higher than projected for services

ISO/IEC 20000-1:2011(E) 6.4 Budgeting and accounting for services indicates that there must be policies and documented procedures for

  1. budgeting and accounting for service components including at least

1) assets — including licenses — used to provide the services,

2) shared resources,

3) overheads,

4) capital and operating expenses,

5) externally supplied services,

6) personnel, and

7) facilities

  1. apportioning indirect costs and allocating direct costs to services, to provide an overall cost for each service
  2. effective financial control and approval.

SMS – Delivery – Budgeting & accounting – practices

  • Budgeting & accounting

One key best practice here is to set up your chart of accounts and reports to be able to budget, account, and report on the planned and actual expenses and revenues, by service.


Chapter 5 Summary

  • Delivery is the practice area within the SMS that covers:

  • Stakeholder relations – ensuring the relationship between the provider and customers, users and suppliers is good
  • Administration – ensuring administration of services is easy for all stakeholders
  • Provisioning, metering, and billing—setting up (and later, decommissioning) services and service components; tracking and reporting on usage; invoicing customers.
  • Budgeting & Accounting—preparing budgets for services and accounting for expense and revenue
  • Each of these practice areas has a desired state that must be achieved and maintained continuously over time and through changing circumstances to ensure value continually flows to all stakeholders; these desired states can be achieved and maintained through best practices


Chapter 6: Getting Started with Open Service Management

We’ve covered a lot here! What services and service management are, and what Open Service Management is. Things worth managing, desired states and practices for stakeholders, value and value flow, human-led and IT-led services and their configurations, functionality, and qualities, and the service management system.

These are the foundational concepts covered in the OSM Foundation exam.

To get started with OSM, you can begin by taking a course from an Authorized Training Organization (or ATO), as a course from an ATO is required to register for the exam.

Take the sample exams, which should be included in your courseware, and review your results. Make sure you understand the rationale for the book answer for any questions you did not get right.

Then sign up for the actual exam and take it to earn the certification and demonstrate your knowledge.

Let’s have a look at its format.

Format of the OSM Foundation Examination

You must achieve a passing score in the Foundation Exam to gain the OSM Foundation Certificate in IT Service Management.

Tips for Taking the OSM® Foundation Exam

Here are some tips for taking the exam:

  • Attempt all 40 questions; if you don’t know the answer, guess and mark for review
  • There are no trick questions or patterns in how the answers are laid out
  • Mark all answers on the paper answer sheet (or if taken online, on the web page)
  • Skip and go back to a question you can’t answer right away
  • Don’t forget to use the process of elimination
  • Skip the preamble; it might be a misdirection, go right to the question; only read the preamble if it is necessary to answer the question
  • Watch for absolutes, for example, “always”, and “guarantees”
  • If stuck between choices ask, “What is this, and who owns it?”
  • Read questions carefully—don’t miss the word “NOT”!
  • For testing purposes, take the book view, rather than your own

Besides getting certified, and more importantly, you can get started by taking what you’ve learned and applying it back on the job. You don’t have to do it all, but you should be able to cherry pick a couple of things that have obvious value for you, like a best practice you haven’t tried, or a desired state you know needs work and that you can contribute to, as an individual, or within your team or entire organization.

You can also learn more about IT Service Management and OSM® by visiting https://osmalliance.org.

If you are a consultant or trainer, or part of a consulting or training organization, consider signing up as an Authorized Training Organization (ATO) or Authorized Consulting Organization (ACO).

If you are part of an end-user organization or vendor, please consider joining our consortium. We all win if we have an open standard we can snap to.

Please also consider contributing to OSM® as an individual, team, or organization. There are lots of ways—you can contribute to content, to the community, or the consortium, with your talent and treasure. You can help by writing or reviewing content based on your subject matter expertise. You can sign up as a forum moderator for the community. Or you can help with promotion and marketing, or website stuff, if that’s where your talents lie. And you can help with the consortium. And you can always help with your tax-deductible contribution to [email protected]

We started this initiative not because we had all the answers, and everything we needed to succeed out of the gate, but because we thought that if we could get started with the right idea, people who cared about our industry would bring their time and treasure and talent and help us all pull ourselves up by our bootstraps. Let’s do this thing!

Sign up today at osmalliance.org, or contact us at [email protected]. Thank you for taking the time to help your brothers and sisters and be part of something good and bigger than all of us.

Open Service Management®

OPEN COMMUNITY-DRIVEN BEST PRACTICE

Open Service Management Foundation Body of Knowledge

Version 1.0, January 1, 2018

Your comments and feedback are welcome. If you’d like to contribute directly, contact us at [email protected].

Open Service Management® (OSM) Foundation, 2018 Edition

The Open Service Management Alliance

The Open Service Management Alliance

100 South King Street, #100 Suite 201, Seattle, WA 98104

Copyright information

©2017 the Open Service Management Alliance. All commercial use rights reserved under Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0). Used under license of the Open Service Management Alliance. Open Service Management® (OSM®) is a registered trademark of the Open Service Management Alliance. The OSM® Logo is a registered trademark of the Open Service Management Alliance. Used under license of the Open Service Management Alliance.

Foreword

There have been many changes in IT since the last major publication of traditional ITSM guidance in 2007. These changes have left practitioners with a formidable task, and a giant hole.

The formidable task comes in two parts. Part one is extrapolating from decade-old guidance to apply to today’s stakeholders, value flow, services, and service management principles, concepts and practices—all of which have changed substantially over 10 years. Part two is trying to compile what to do from the myriad of emerging practices, including DevOps, Agile, and Lean.

The giant hole is simple: should we attempt all this work, there is a 100% guarantee that whatever we come up with will not match what our colleague in the next cubicle over had done, let alone what our suppliers and tool vendors have come up with.

What is missing is a common framework that assumes a current environment (a hybrid of traditional and cloud), that compiles current best practices, in a format that is easy for traditional ITSM practitioners to grasp; that updates, but does not replace, traditional ITSM guidance as found in ITIL, ISO 20000, and so on, and that reaches out to cloud native practitioners unfamiliar with ITSM, or who seek a lightweight, modern approach attuned to their ways of working.

This last point is important. For service management to be relevant today, it must be useful to individual practitioners, lean, and lightweight. It was that way in the beginning; service management got its start with Jan Carlzon’s idea of focusing on key “moments of truth”, empowering individual contributors to solve problems quickly in the moment, armed with information; this is precisely the kind of thing the DevOps, Lean and Agile movements call for, and why often proponents of these movements are allergic to service management in its currently received view.

Somewhere along the way (in my estimation, during the reengineering era), service management got refactored into something process and management heavy. It was not that way at its start, and Open Service Management seeks to return service management back to its lean and lightweight roots, with a focus on value and outcomes (the “ends in mind”) versus processes and hierarchical management structures (one “means”, or, one could argue, one obstacle to achieving those ends in mind).

The big, audacious goal of this volume is to provide a body of knowledge to fill that gap.

If you are an ITSM practitioner, Open Service Management (OSM) Foundation will bring you up to date on current practices; if you are unfamiliar with cloud/mobile practices, like DevOps, Agile, and Lean, it introduces you to these concepts through the familiar lense of ITSM.

If you are a cloud native, OSM Foundation introduces you to concepts you will find useful, in an up-to-date format you can grep.

If you are reading this forward, and this book, you are probably aiming to increase your knowledge and capability to further your career and the objectives of your organization. I wish you the best of luck in these, and all your endeavors.

One final thing: this is a labor of love. We are a small band of people trying to help our industry advance with open standards, in an agile (think GitHub) way. If you don’t see something in this content that you’d like, that’s because it needs you. Please consider sharing your talents and treasure, your subject matter expertise, not just on service management, but on promoting the content, running a website, running a consortium, moderating forums, and so on. We need lots of help, and yes, your tax-deductible contributions to [email protected] will help, too.

Gina Scarpello

Philadelphia, PA USA

June 17, 2017

Preface

I got my first “big boy” job in IT at Johnson & Johnson / McNeil Consumer Products in the mid-1980’s. It would be another 10 years before I would hear about IT service management. I spent a good deal of time and effort over those 10 years trying to extrapolate from what was available at the time, i.e., somewhat outdated guidance specific to a particular traditional vendor and platform of the time (the IBM blue books, and Digital Equipment Corporation’s “Building Dependable Systems” come to mind) as a basis for figuring out how to manage the new platforms I was dealing with, e.g., PC networks and applications.

After Johnson & Johnson, I went to work for an IT consulting company engaged in outsourcing; a key problem we had was articulating how we were going to run the piece of their organization they would outsource to us (certainly, with, “best practices”), and what our responsibilities would be as providers, and what theirs would be as subscribers.

I tripped over ITIL in 1997 when I got a flyer in the mail for a Foundation course. I initially threw it out and later picked it out of the trash and signed up. My instructor was David Ratcliffe :). I was excited to find a vendor-/platform neutral approach to managing IT. At the time, I was a voice in the wilderness in the US, one of only a handful of practitioners applying and promoting IT service management in the US.

In the decade that followed, I was excited to benefit from and contribute to the IT service management body of knowledge. It was a real treat going over to the UK to the itSMF conferences, and working with other IT professionals with a passion for IT service management. IT was a real thriving community, that provided a good reason to contribute back.

The last significant update of an IT service management body of knowledge was with ITIL V3 in 2007 (there was a revision in 2011 for conciseness, but the core principles and the target environment were the same as in 2007).

It doesn’t take a lot of cogitation to realize there has been a sea change in IT in the decade since 2007. While many IT service management principles remain evergreen–the “what to do” and “why to do”, the typical target environment has shifted to traditional + cloud + hybrid, and the “how to do”—the best practices—what people actual do today that works–has changed dramatically as well, as evidenced by the emergence of DevOps, Agile, and Lean best practices.

In fact, every facet of IT has experienced significant change–stakeholders (customers, users, providers, suppliers), value flow, services, service management.

In my work with clients I see them facing the same scenario way back in the day when I got started, and the similarities are striking. They are putting massive amounts of effort into extrapolating from guidance that’s a decade old, that is aimed at a target environment that doesn’t exist anymore for them. What’s more, they’re needing to assemble a view of what to do from a balkanized set of emerging best practices. For those brave souls who attempt this work, their reward when they finish “rolling their own” is 100% assurance that what they’ve come up with isn’t the same as that of the person over in the next workstation, let alone at another company.

This is a sad and wasteful situation for our industry. We need some sort of lightweight frame that lays out the evergreen “what and why” of service management for those new to the subject, i.e., DevOps practitioners, a frame they find useful. We need a frame that describes best practices that are suited to the typical environment we find ourselves managing–traditional/hybrid/cloud. And we need a frame that puts new best practices into context–so that IT service management practitioners can learn and understand them and put them to use, and so that newcomers familiar with these practices can see how the fit into the service management frame.

In the end we need a common, ubiquitous, lightweight framework that is “good enough”. By “we” I mean everyone–individuals in IT, end user IT organizations, and the vendors that service them–including those who provide platforms and tools, as well as consulting and training services.

It makes even less sense in the gig economy of today than it did a decade ago to not have a common frame. We tend even more so traverse many organizations–a “universal decoder ring” of a common frame and common language certainly would help us all to better understand and be understood.

And for such a frame to be successful, it has to be like it was back in the day–open–where we all had a reason to contribute to the community because the benefits of doing so were obvious.

And that is why we wrote Open Service Management Foundation, 2018 Edition. Our dream is to give service management back to the practitioners, to seed a thriving community that can once again take IT service management where it needs to go, with fresh, living, relevant, timely content and community.

We envision this content–a lightweight, open framework; a consortium (to shape the direction of the content), and a community (to drive new and fresh content while benefit from interchange of ideas). We are excited again about the future of service management and hope you will join us in our excitement and come along with us on this journey.

David Pultorak

Pultorak & Associates, LTD

Seattle, WA USA

May, 2017

Table of Contents

Chapter 1: Introduction to Service Management and Open Service Management 11

1.1. Things worth managing 11

1.2. Desired states and force field analysis 12

1.3. Best practices: Deterministic, Adaptive, Emergent, Mode 1 & 2 14

1.4. How things worth managing, desired states and best practices relate 18

1.5. Stakeholders of service management 18

1.6. Value, value flow and their characteristics 19

1.7. Service and its characteristics 20

1.8. Service management and its characteristics 26

1.9. Service management system (SMS) and its characteristics 27

1.10. Open Service Management (OSM), its characteristics and structure 29

1.11. The OSM training and certification path 32

Chapter 1 Summary 33

Chapter 2: Stakeholder Concepts, Desired States and Practices 35

2.1. Stakeholders – the four main stakeholders of service management 35

2.2. Stakeholder: Customer definition, desired state and practices 39

2.3. Stakeholder: User definition, desired states and practices 41

2.4. Stakeholder: Providers definition, desired states and practices 43

2.5. Stakeholder: Suppliers definition, desired states and practices 46

Chapter 2 Summary 48

Chapter 3: Value and Value Flow Concepts, Desired States and Practices 49

3.1. Value and its characteristics 49

3.2. Value flow in relation to value 50

1.3. Value stream and value stream mapping 51

1.4. Lean, its relation to value and the five lean principles 53

1.5. Agile, its relation to value and the four agile statements of value 54

1.6. Value flow definition, desired state and practices 55

Chapter 3 Summary 56

Chapter 4: Service Concepts, Desired States and Practices 57

4.1.1. Overall Service definition, desired state, practices 57

Introduction 4.1: Service Configuration concepts, desired states and practices 64

4.1.2. Service configuration definition, desired state, practices 65

4.1.3. Human-Led service configuration 68

4.1.4. IT-Led service configuration 71

4.1.5. IT-Led service configuration: Software 75

4.1.6. IT-Led service configuration: Applications 76

4.1.7. IT-Led service configuration: Data 77

4.1.8. IT-Led service configuration: Platform 78

4.1.9. IT-Led service configuration: Runtime 80

4.1.10. IT-Led service configuration: Middleware 80

4.1.11. IT-Led service configuration: Operating system 81

4.1.12. IT-Led service configuration: Infrastructure 83

4.1.13. IT-Led service configuration: Virtualization 84

4.1.14. IT-Led service configuration: Server 86

4.1.15. IT-Led service configuration: Storage 87

4.1.16. IT-Led service configuration: Network 88

4.1.17. IT-Led service configuration: Hardware 90

4.1.18. IT-Led service configuration: Facilities 91

Chapter Section 4.1 Summary 93

Chapter Section 4.2: Service Functionality & Qualities concepts, desired states and practices 94

4.2.1. IT-Led service configuration: Applications 95

Chapter Section 4.2.1. Summary 97

4.2.2. Service Qualities definition, desired states, practices 97

Chapter Section 4.2.3: Human-Led Service Qualities concepts, desired states and practices 101

4.2.3. Human-Led Service Qualities definition, desired states, practices 101

4.2.4. Human-Led service quality: Reliability 105

4.2.5. Human-Led service quality: Responsiveness 106

4.2.6. Human-Led service quality: Trustworthiness 108

4.2.7. Human-Led service quality: Empathy 110

4.2.8. Human-Led service quality: Attractiveness 111

Chapter Section 4.2.9: IT-Led Service Qualities concepts, desired states and practices 113

4.2.9. IT-Led Service Qualities definition, desired states, practices 113

4.2.10. IT-Led service quality: Availability 116

4.2.11. IT-Led service quality: Manageability 118

4.2.12. IT-Led service quality: Serviceability 120

4.2.13. IT-Led service quality: Performance 121

4.2.14. IT-Led service quality: Reliability 123

4.2.15. IT-Led service quality: Recoverability 125

4.2.16. IT-Led service quality: Discoverability 126

4.2.17. IT-Led service quality: Trustworthiness 127

4.2.18. IT-Led service quality: Security 128

4.2.19. IT-Led service quality: Integrity 130

4.2.20. IT-Led service quality: Credibility 132

4.2.21. IT-Led service quality: Compliance 133

4.2.22. IT-Led service quality: Usability 135

4.2.23. IT-Led service quality: Internationalization 136

4.2.24. IT-Led service quality: Accessibility 138

4.2.25. IT-Led service quality: Adaptability 139

4.2.26. IT-Led service quality: Interoperability 141

4.2.27. IT-Led service quality: Scalability 143

4.2.28. IT-Led service quality: Elasticity 144

4.2.29. IT-Led service quality: Portability 146

4.2.30. IT-Led service quality: Extensibility 147

Chapter 4 Summary 149

Chapter 5: Service Management System (SMS) Concepts, Desired States and Practices 155

Introduction 5.1: SMS concepts, desired states and practices 155

5.1.1. SMS definition, desired states, practices 155

Chapter Section 5.2: SMS Design & transition concepts, desired states and practices 155

5.2.1. SMS Design & transition overall definition, desired state, practices 155

5.2.2. SMS Design & transition: Strategy & GRC definition, desired state, practices 159

5.2.3. SMS Design & transition: Learning & improvement 160

5.2.4. SMS Design & transition: Development 164

5.2.5. SMS Design & transition: Release & deployment 166

5.2.6. SMS Design & transition: Change & configuration 168

Chapter Section 5.3: SMS Promotion concepts, desired states and practices 172

5.3.1. SMS Promotion overall definition, desired states and practices 172

Chapter Section 5.3 Summary 174

Chapter Section 5.4: SMS Support concepts, desired states and practices 175

5.4.1. SMS Support overall definition, desired state, practices 175

5.4.2. SMS Support: Event handling 178

5.4.3. SMS Support: Incident handling 180

5.4.4. SMS Support: Request handling 182

5.4.5. SMS Support: Problem handling 184

5.4.6. SMS Support: Major incident & disaster handling 186

1.12. Chapter Section 5.4 Summary 187

Chapter Section 5.5: SMS Delivery concepts, desired states and practices 188

5.5.1. SMS Delivery overall definition, desired states, practices 188

5.5.2. SMS Delivery: Stakeholder relations 191

5.5.3. SMS Delivery: Administration 193

5.5.4. SMS Delivery: Provisioning, metering & billing 194

5.5.5. SMS Delivery: Budgeting & accounting 196

Chapter 5 Summary 198

Chapter 6: Getting Started with Open Service Management 199

Welcome and Introduction

This publication covers the foundational principles, practices, and terminology associated with service management, as described by the Open Service Management Alliance. It is divided into six main topics or chapters:

Chapter one, Introduction to Service Management and Open Service Management, introduces the concept of services and service management in general, and the structure and core concepts of Open Service Management.

OSM® has four components parts to its structure, four, “things worth managing”, and the next four chapters cover those parts. In each, core concepts are covered, along with desired states (basically, what good looks like), and best practices.

Chapter two, Stakeholders, covers stakeholder concepts, desired states and practices.

Chapter three, Value and Value Flow, covers value and value flow.

Chapter four, Services, covers services, including their parts (or configuration), features (or functionality), and qualities (or non-functional characteristics).

Chapter five, the Service Management System, covers the service management system (or SMS), which is your mechanism to ensure value flows through services to stakeholders, including design & transition, promotion, support and delivery desired states and practices.

Chapter six, Getting Started, provides suggestions for getting started, including tips for how to prepare for taking the OSM® Foundation certification examination.


Chapter 1: Introduction to Service Management and Open Service Management

This chapter defines core service management and OSM® concepts, including things worth managing, desired states, best practices, stakeholders, value and value flow, services, service management, and the service management system, and explain the training and certification path for OSM® Foundation.

After reading this, you should able to:

Explain what things worth managing are

Explain what desired states and force field analysis are

Explain what best practices are, and the three types: deterministic, adaptive, emergent, and two categories: mode 1 and mode 2

Explain how things worth managing, desired states, and practices relate

List and describe the stakeholders of service management

Define what value and value flow are, and their characteristics

Define what a service is, and its characteristics

Define what service management is, and its characteristics

Define what a service management system is, and its characteristics

Explain what Open Service Management is, its characteristics and structure

Explain the training and certification path for OSM®

Things worth managing

What are “Things worth managing?”

1Figure 01-01.1 Things worth managing

For all things worth doing, there are “things worth managing” for which we must aim to achieve and sustainably maintain a desired state. Service management is no exception; it has four, “things worth managing”: stakeholders, value and value flow, services, and the service management system.

OSM seeks to compile the generic set of things worth managing common to all providers as a starting point for desired state-based management of services. For every service provider, these are the generic set of things worth managing.

In addition, there are typically additional things worth managing due to the provider’s specific situation, tools used, and so on. The idea is that each service provider needs to identify their “things worth managing” and work to keep them in a “green” or “good” state.

Desired states and force field analysis

What is a desired state?

There are two main approaches to managing things worth managing: focusing on desired states (“ends”), or “means”; e.g., seeking to “minimize the business disruption of change, and know what changed” is a desired state or “end”; you might focus on this, or on “means”—e.g., engineering processes, etc.; OSM® describes means (best practices), but focuses on ends.

Many things can be barriers or enablers to achieving and maintaining desired states, e.g., a process or tool can be a means to achieving and maintaining desired states, or it can be a blocker, or some combination thereof, depending on how it was designed, tools used, organizational culture, cadence, etc.

In OSM®, desired states are written from the perspective of the service provider.

At its inception, with Jan Carlzon’s “Moments of Truth”, service management was lightweight, agile, and focused on outcomes, or ends, and interactions among people (“moments of truth”).

And while more traditional ITSM guidance sought to be outcome based, mentioning “What to do and why”, and giving an EXAMPLE of how, which may or may not be fitting for your environment or situation, quite often in practice people would apply this guidance with a focus on a heavy-handed how, layering heavyweight, end to end processes on top of the work, without a call to action for individuals, teams, and the organization to know and drive towards service management outcomes.

OSM instead returns to the roots of service management, and puts its focus squarely on outcomes, on maintain desired states for things worth managing. So for example, “changes” are a “thing worth managing”, with an outcome of, “we minimize the business disruption of change, and can track what changed”; a process could enable—or disable—this desired state.

OSM instead focuses squarely on outcomes, to ensure individuals and teams in organizations are aware of the things worth managing, and their desired states, and are working within their patch to drive to achieve and maintain desired states for things worth managing. They do this by making driving towards the desired state, “how we do things around here”, and by working to remove and reduce barriers and add and amplify enablers to maintaining those desired states.

Desired states – typical rollup states

2Figure 01-02.01 Desired state

In a typical monitoring system, you have four typical states for anything you are monitoring:

  1. Green means good, it’s in the desired state.
  2. Yellow means potentially or actually degraded in some way, for example, disk space is filling up or circuit utilization is high, which may be affecting performance
  3. Red means bad, dead, down, or critical.
  4. Grey means “unknown”—the thing worth managing is in an unknown state.

Think of it this way, if you join or start a service provider organization, and are responsible for managing it, you’ll want to know a couple of things. First, what is “it”? In other words, what are the things worth managing?

Once you know what “it” is, your first concern will be anything that’s red, or critical—how do we get that back online, to green. Next, you’ll want to address anything that’s degraded or potentially degraded—the yellow stuff. And lastly, anything that’s in an unknow state, you’ll want to get to a known state, and the make and reds, then yellows, green.

Force field analysis

Force field analysis, developed by Kurt Lewin, helps identify driving and restraining forces you must amplify and reduce to achieve a desired state. Here’s how: brainstorm enablers (driving forces), and barriers (restraining forces); identify actions to add or amplify enablers / remove or minimize barriers; prioritize based on effort and impact; pick a subset to go after to move towards the desired state.

Force field analysis is a key technique for achieving and maintaining desires states for things worth managing.

So, you’ve got these things worth managing, and they have a desired state that you want to achieve and maintain, sustainably. What’s a simple technique you can use to do that?

The most universally applicable technique is force field analysis. It works like this:

  • You are “here”. You’d like to be somewhere else. To get there, you ask, “what forces can we add or amplify to drive towards our goal?”; “what barriers are between us and our goal, and how do we minimize or eliminate them?”

3Figure 01-02.2 Force field analysis

  • You then look at the barriers and enablers and act to minimize or eliminate barriers, and add or amplify enablers, putting your resources to work on the subset of these that will give you the greatest “bang for your buck”.

When you think about build pipelines and continuous integration and delivery and the like, this is precisely what we are doing. We are removing barriers and amplifying enablers to increase flow. And in today’s organizations, we all do it—we all own the desired state, and we all pull on oars to get there.

Best practices: Deterministic, Adaptive, Emergent, Mode 1 & 2

What are best practices?

Best practices are things people are commonly doing now that work well when aiming to achieve and maintain desired states / desired states for things worthy of managing.

Best practices are not bleeding, or leading-edge practices; they are practices people are currently using that work across multiple organization, and are producing successful results.

Like traditional ITSM guidance, OSM® does not create best practices, but seeks to provide a platform that gives the IT community a reason to compile and maintain a source of current best practices, within a common structure that makes finding, understanding, applying, and improving them easier.

Traditional ITSM frameworks talk about best practices as being commodity practices, not bleeding, or leading edge, which is true; best practices should be common practices.

OSM defines best practices as, “what people are doing now that works”. This is important. Like more traditional ITSM frameworks, OSM compiles, rather than creates, best practice.

Unlike traditional ITSM frameworks, OSM endeavors to do this in an agile way, driven by community contributions, to ensure fresh, relevant content. The basis for this is that nowadays, without this approach, “best practice” guidance devolves into, “what people said they did years ago that worked for an environment that no longer exists”.

Now lets’ talk about the three types, and two modes of best practice OSM defines.

Three types of practices: deterministic, adaptive and emergent

There are three broad categories of practices—deterministic (like McDonalds), adaptive (like Agile / Scrum), and emergent (completely new-to-you, e.g., the first time doing container orchestration—there is no precedent).

All three are valid and can be enablers in some circumstance and barriers in others, or some combination of both; your goal should be to make sure there is a good match between the type of practices and your situation, and to be open to changing based on changing circumstances, e.g., target environment.

Figure 01-03.1 Three broad categories of practices

David Pultorak defines three types of practices: deterministic, adaptive, and emergent. This may sound fancy, but the basic idea is as follows.

First, if you’re going to do something repeatedly, and want consistent results, you’ll want to make it like a machine, or a coocoo clock—wind it up and it always produces the same result—those chicken nuggets always come out in so many seconds, and always look and taste like this. That’s deterministic. It’s appropriate for such situations.

Another situation is where what you will do—the activities you do, in what sequence, with what tools, for what duration, etc.—will change based on feedback loops. This is the domain of Agile Scrum projects. In them, you might have chapters or routines or patterns that you pull from, but precisely what you will do, you will adapt to the situation.

Lastly, you have emergent practices, like when container orchestration is a new thing and it’s the very first time you and others are trying it. There is no precedent, no roadmap, you are literally making it up as you go, with patterns and practices emerging along the way.

Why make these distinctions? Because quite often, in heavyweight implementations of service management, most or all emphasis is put on setting up deterministic, end-to-end processes, with no room left for what is adaptive or emergent.

OSM attempts to correct this by “shifting left” towards innovation and allowing room for all three modes of practice; the bottom line is all three are valid, as driven by the situation.

Two modes of best practices: mode 1 and mode 2

The target environment to be managed in current organizations is typically a hybrid of traditional / on premises IT and cloud. Each has unique and shared practices.

Figure 01-03.2 Two modes of best practices; Source: https://commons.wikimedia.org/wiki/File:Cloud_computing_types.svg

In addition to three types of practices—deterministic, adaptive, and emergent, there are two modes of practices, as driven by the target environment you manage.

Gartner calls these Mode 1 (traditional) and Mode 2 (cloud / mobile); OSM® tags the best practices it compiles as Shared, Mode 1 (traditional) or Mode 2 (cloud), or SH, M1, M2.

5Figure 01-03.3 Mode 1 and mode 2 best practices; Source: https://www.redhat.com/cms/managed-files/Rakesh_Kumar.pdf

“Mode 1” practices are ideally suited to traditional IT environments, things like traditional IT configuration management, where we work hard to have a good logical picture of the components of our environment, along with how they relate to one another.

“Mode 2” practices are ideally suited to cloud / mobile environments, things like infrastructure-as-code and immutable deployments, where the emphasis shifts in configuration management to making sure the code that is used to create things is good, because we know what things look like, as they are uniform (as they are “cattle”, not “pets”, as DevOps practitioners like to say).

Today, the typical IT environment is a hybrid of cloud and mobile; therefore, the typical practices are (or should be) an appropriate blend of the two.

How things worth managing, desired states and best practices relate

6Figure 01-04.1 How things worth managing, desired states and practices relate

So OSM seeks to compile current best practices, both mode 1 and 2. The idea is that you can apply the subset and blend of these that are suited to your environment, as a basis for driving towards and achieving and sustainably maintaining desired states, for things worth managing.

Stakeholders of service management

The four stakeholders of service management

Stakeholders are one of the four, “things worth managing” defined by OSM.

7Figure 01-05.1 Four stakeholders in service management

You should see some similarities and key differences here from traditional ITSM guidance.

First, the similarities: traditional ITSM guidance cites customers, users, and suppliers as stakeholders.

Now for the difference: more traditional ITSM guidance does not include the provider as a stakeholder in service management, perhaps because it is assumed that the provider is THE key stakeholder. Here, in OSM, we list the provider as a stakeholder, as the provider certainly does have a stake in the key outcomes of service management.

Value, value flow and their characteristics

What is value? And where does it reside?

Since value is in the mind of stakeholders, as providers we must influence both the reality of our services and their perception by stakeholders.

What is value flow?

Value flow is good when it proceeds to stakeholders with no undue stoppages, scrap, rework or backflows. Barriers to flow include inconsistency and variation (Mura) and overburden or unreasonableness (Muri). Enablers to flow include just-in-time (JIT) systems and corrections for overburdened and unreasonable practices.

Three other key differences between OSM and more traditional ITSM guidance are:

  1. The emphasis on value flow, in line with agile and lean practices.
  2. Value flow as multi-directional (in more traditional guidance, it flows in one direction, from the provider to the customer)
  3. Value as flowing to all stakeholders, with key stakeholders defined as customers, users, the provider, and suppliers

These differences are important, especially in the cloud portion of today’ typical hybrid environment. Teams are aligned around build pipelines and are working to make value flow unencumbers by inconsistency, variation and overburden. So, they get value flow, and their role in making it happen, and are creating and looking for best practices to help them do it.

Service and its characteristics

What is a service?

Services are one of four key categories of things worth managing in service management

Services can be internal or external, i.e., provided to customers and users in the same business entity as the provider; or to those outside of the provider’s business entity.

8 Figure 01-07.1 Customer and service provider

A service is a means of delivering value to customers by facilitating the desired states customers want to achieve, at (what should be) a lower cost and risk than doing it themselves, or other alternatives, and without the need to pay attention to all the details (or means) of delivering the service. The general idea—and you should be familiar with this because this is why you utilize services instead of simply doing it yourself, or using an alternative—is that you can focus on the ends, or outcomes, instead of the means, and because the service presents a better value in the end than doing it yourself or alternatives.

Services must also provide value to users, and value back to the provider and its suppliers, for services to be sustainable. Not that in this definition, the value flow is multidirectional; also, the nature of value is not just in new services and features, it is multi-dimensional; for example, value can flow back to the provider from customers and users in the form of feedback on services, feature sets, features, and new feature requests.

Services are comprised of three things worth managing: configuration, functionality and qualities.

9Services are comprised of their configuration, functionality and qualities

  1. Configuration (components / what it is made of) that constitute the service.
  2. Functionality (features / what it does) the service provides, including telemetry that facilitates direction and control of the service by the SMS.
  3. Qualities (characteristics / how it behaves) of the service, the non-functional “-ilities” of the service.

Each has a desired state to be achieved and maintained through best practices.

The service continuum – from goods to IT-Led services

A Service is some combination of an idea, physical good, or service a provider provides to customers and users; we are concerned with two types of services, Human-Led and IT-Led; we concerned with goods here only as components of services (e.g., a physical router) or as delivered by a service (e.g., PC install).

10 Figure 01-07.2 The Service Continuum; Source: Adapted from https://www.slideshare.net/vikashkumarbibhakar/godds-services-continuum slide 5

Goods are different in nature from services. For example, a candy bar is different from a haircut, and a Bluetooth speaker is different from Office365. Generally, goods are more tangible, storage, separable, and come in some sort of standard format.

On the other end of the spectrum, IT services tend to be delivered and consumed in the same moment; they are intangible, perishable, inseparable, and, like goods, standardized in quality.

And that’s the point: there’s a spectrum. We all have seen over the years how products have become service-like, and services have taken on product characteristics. It might be better to just call them all serv-octs or prodices, but all kidding aside, that’s what we’ve got on our hands. For example, that piece of software running on your desktop—it’s kind of a product, but now you download it digitally, you get updates, you get new features delivered in streams, you pay for it as a subscription—it’s getting servicy.

OSM is Open Service Management for the sake of simplicity and congruence with what came before, but it recognizes that we deliver value through products and services, and that there is a continuum. This acknowledgement—that we deliver value through products and services, and combinations of the two—is also a key departure from traditional ITSM guidance.

A further departure is that OSM acknowledges two key types of services—again, along a continuum—namely, Human, and IT led. Human-Led services are led by humans, assisted in varying degrees by automation; IT-Led services (like Office365) are primarily represented by the automation, with humans assisting on the back end to varying degrees.

This distinction is important because both Human-Led and IT-Led services are different in nature and have different characteristics to tend to. The lack of this distinction in more traditional ITSM guidance led some practitioner to some degree of confusion with, for example, what to put in their service catalogs.

Services are of two types, Human-Led and IT-Led

Services of two types:

  1. Human-Led Services, performed by humans, e.g., moves, adds and changes; technology may assist / facilitate, but the primary driver is human, and
  2. IT-Led Services, e.g., AD, DNS, etc.; technology is the driver, humans may assist / facilitate.

11Services are of two types, Human-Led and IT-Led

Other characteristics of services

12Figure 01-07.3 Other characteristics of services

Servicers are means for a provider to deliver value to customers and users and return value back to the provider and its suppliers by facilitating desired states customers and users want to achieve and sustainably maintain. Characteristics of services include:

  • Services can be provided in whole or in part by suppliers
  • Service can be fully or partially automated or manual
  • Services can involve the provision of goods, e.g., replacement keyboard
  • End-services are what that the customer recognizes and pay for; they typically include sub-services (e.g., updates, DHCP)
  • Services can be broken down into types, e.g.,
    • Core services (e.g., for mobile phone service, dial tone),
    • Optional services (e.g., data plan), and
    • Supporting services (e.g. backups, update)
  • Services can be stratified in tiers (e.g., gold, silver, bronze level packages)

Service management and its characteristics

What is service management?

In service management, we (the provider), present ourselves to customers and users as a set of services. We align all things—our capabilities, resources, activities, and systems—around this set of services. Our goal is to make sure we provide value consistently and sustainably. To do this, we make sure everything lines up behind the services, that we have, up front, the wherewithal to consistently delivery on service commitments.

Part of this is making explicit, discrete commitments; an important part of this is what we will do, but also, what we won’t do. The general posture towards customers and users should not be, “no”—often, a posture traditional IT shops are accused of—the problem with this is that customers and users don’t’ get the value they need when they need it. It should also not be, “yes”—to everything, another posture many traditional shops have—the problem with this is everything becomes “best effort”—i.e., you literally cannot count on the provider—not a good situation either.

The right posture is, “yes we can do it, and this is what it will cost”. In other words, we insist on having the wherewithal to consistently deliver on our commitments, or adjust what we commit to align to the wherewithal we do have.

In service management, we seek to align all our capabilities around services, including:

  1. Technical systems – equipment, databases, software systems etc.
  2. Managerial systems – for management of operations, including that of technical systems
  3. Learning systems – for the maintenance of personal and team skills and knowledge
  4. Cultural systems – for the regulation of values and norms, i.e., behaviors and objectives

The “bet” is that organizing around and presenting ourselves as a set of services is a superior operating model, that given the same set of resources, we will do better than if we simply organized around caring and feeding technology.

Service management system (SMS) and its characteristics

What is a service management system (SMS)?

The term, “service management system” may sound fancy or complicated, but it’s basically the sum of whatever mechanisms you have in place to make sure you have the right set of services, and that they are valuable.

The SMS must be a dynamic mechanism, because with the passing of time, stakeholder needs change, and new technologies create new possibilities, and so the value equation changes. As a result, we must continuously improve services, by adding or changing services, feature sets and features, and retiring services that no longer add value.

As you can see in the figure, a service management system can be broken down into Design & transition, promotion, support, and delivery. OSM handles these a bit differently than traditional ITSM frameworks, which position these as sequential phases and processes.

13Figure 01-09.1 Service Management System (SMS)

In OSM, these are going on simultaneously, not sequentially. In other words, while of course there is sequence in workflow, it is not helpful to, for example, put incident handling in one “phase” because “that’s where it first becomes important”.

OSM position these elements not as “processes”, but as “things worth managing”—in other words, each represents a key outcome or desired state that we want to achieve and maintain. The focus here is on ends, not means, as we know that a process is just one means to achieve an outcome, and that a broken process (or a focus on process without attention to other enablers), can disable as well as enable sustained achievement of desired outcomes.

Further, in OSM, we seek to focus on outcomes, as opposed to activities, as this is more lightweight, and suited to today’s environment and agile practices.

Open Service Management (OSM), its characteristics and structure

What is Open Service Management?

OSM is brought to you by the OSM Alliance, www.osmalliance.org, a non-profit whose mission it is to promote fresh, community-driven open content that is free for individuals and end user organizations to use and share and contribute to.

OSM is shared under a Creative Commons, Attribution-NonCommercial-ShareAlike, ”some rights reserved” license, which lets individuals and organizations remix, tweak, and build upon it non-commercially.

Licensing is required for commercial use. Commercial rights are reserved by the OSMA for OSM for the sole purpose of funding the OSMA’s operation, and OSM’s development and promotion. Sources of funding for the OSMA include exam fees, Authorized Training Organization (ATO) fees, and Authorized Consulting Organization (ACO) fees, all of which are nominal, as a source of funding for the OSMA’s development, promotion and operation.

The OSM is also funded through OSMA consortium member fees. Consortium member organizations can shape the direction of OSM content.

Importantly, the OSMA also supported by the generous donations of its members, both in terms of monetary donations, which are tax-deductible, and their contributions of the time and subject matter expertise to contribute to improving OSM to the benefit of our community.

All fees other than exam fees are annual.

To find out more about becoming an OSMA ATO, ACO or consortium member, contact the OSMA at [email protected].

14Figure 01-10.1 Open Service Management

This is figure is the Open Service Management (OMS) framework. OSM, and the OSMA, are intended to give today’s IT professionals a reason, and a much easier way to navigate, learn, and contribute to up-to-date, open best practices for managing today’s typical (hybrid Mode 1 / Mode 2, legacy and cloud / mobile) environments. Without a framework with up-to-date best practices, it is incumbent on each IT pro and organization to interpret older best practice guidance for application to their current situation, or to compile best practices from the myriad of emerging best practices, with 100% certainty that what the “roll” will not match what others do. The idea is that snapping to an open framework you can contribute to is a better bet.

Let’s dig in to the framework. As shown in the figure, everything above the line that says, “Things worth managing” are the things worth managing in service management:

  1. Stakeholders; (as you see on the left and right of the diagram, these are providers and suppliers, and customers and users); note two differences from traditional ITSM guidance: providers are considered part of the key stakeholder group
  2. Value flow; note here another difference from traditional guidance: value is show to flow multidirectionally, to all stakeholders, as this is needed to sustain a service
  3. Services; again different from traditional guidance, are subdivided into Human-Led and IT-Led services, and further apportioned into configuration (parts), functionality (features) and qualities (non-functional characteristics), all of which are “things worth managing
  4. The SMS; the mechanisms used to continuously and sustainably provide value to stakeholders over time and changing circumstances. The SMS is partitioned into Design & transition, promotion, support and delivery, which are not phases and processes, but sets of “things worth managing”, each of which has a desired state to be maintained.

At the bottom of the figure you see that the community produces best practices for achieving and maintain desired states for everything above the line, which are things worth managing.

What are Open Service Management’s characteristics?

Open Service Management (OSM) is a new and dramatically different set of best practice guidance for service management.

OSM has a couple of characteristics that make it unique.

First, OSM is strongly aligned to ISO 20000, and traditional ITSM guidance is strongly aligned to ISO 20000, it is compatible with traditional ITSM guidance. Said another way, it can be used alongside traditional ITSM guidance, and understood easily alongside it, as it shares some common framing and terminology.

Secondly, OSM is up-to-date – published in 2018. Traditional ITSM guidance can be over 10 years old, and a lot has changed since then, both in terms of the nature of the target environment that service providers manage, and the best practices—what they do that works—that suit current environments.

What’s more, OSM is meant to be fresh, relevant, community-driven content. This can happen because OSM is free to use for end-user organizations, and open (with some commercial rights reserved as a basis for funding), and uses an agile (think GitHub) method for development, This in turn provides both the ability to contribute, and a reason for doing so, unlike closed, proprietary traditional ITSM guidance.

OSM® is open for end-users, licensed under a Creative Commons Attribution-NonCommercial-ShareAlike “some rights reserved” license; this license lets you remix, tweak, and build upon OSM® non-commercially, if you credit the OSMA and license your new creations under the identical terms. The intention is that all end-users get OSM® for free, and to use it for free, and this freedom give them a reason to contribute to OSM®. OSM® features an open source pull-style mechanism so all IT pros and organizations can contribute.

OSM is also the product of a sustainable not-for-profit. Other traditional ITSM guidance is the product of for-profits; in the case of OSM, our primary driver is not profit, but the betterment of our community through affordable, ubiquitous, fresh, relevant, community-driven practices. O

SM is sustainable because some rights for commercial use are reserved on the license so to provide a revenue source for the non-profit that owns OSM®, the Open Service Management Alliance. The reserved rights include rights for Authorized Training Organizations (RTOs), Authorized Consulting Organizations (ACOs), and Authorized Product Organizations (APOs) to deliver training, consulting and products aligned to OSM®.

OSM is also light-weight. One small volume makes up the core OSM® Foundation body of knowledge (BOK); OSM® Foundation, a compilation of current best practices from, e.g., from Agile, DevOps, and Lean, suited for today’s enterprise, hybrid and cloud environments.

You can start contributing and benefiting from OSM today, by signing up as a member at https://osmalliance.org or contacting us at [email protected]

The OSM training and certification path

The path to OSM® training and certification is straightforward.

The first level is OSM® Foundation training and certification: 14 contact hours of training, followed by a 1-hour, 40-question exam, with 65% (26 of 40) to pass. The OSM Foundation training and exam are available since January 1, 2018. The only prerequisite for the OSM Foundation exam is that you must take the training from an Authorized Training Organization. This helps fund the non-profit OSMA.

The exam is like traditional ITSM exams—one hour, 40 questions, 26 out of 40 to pass, multiple choice. Exam are offered by the OSM Authorized Examination Institute (AEI), Acquiros.com.

For those who’d like to continue, there is OSM® Practitioner training, which has3 types: 1) General, 2) Situational, and 3) Tool-driven

Each practitioner training is a 35 contact-hour course with a 1-hour, 20-question multiple choice exam, with 65% is required to pass, worth 10 points towards Master.

OSM® Masters certification is achieved by any combination of 34 points.

15Figure 01-11.1 OSM® Training and Certification Path

OSM practitioner courses are under development. The idea here with practitioner is to provide content that helps you apply what you learned in foundation generically (practitioner—general application), or to specific situations, like small shops or regulated environments (practitioner—situational application), or with specific tool chains (practitioner—tool-driven application).

If you would like to contribute to these bodies of knowledge, please contact the OSMA at [email protected].

Chapter 1 Summary

Service management is a set of specialized organizational capabilities in the form of a service management system (SMS) for managing the resources required to provide value to customers and users in the form of services.

Things worth managing are the small set of critical things—stakeholders, value flow, services, and the SMS—for which a service provider must aim to achieve and sustainably maintain desired states.

There are four key categories of things worth managing in service management:

Stakeholders, those who have a “stake” in service management desired states: customers, users, providers, and suppliers.

Value flow, which in the multidirectional stream of value through services to stakeholders

Services, means for providers to deliver value to customers and users by facilitating desired states customers and users want to achieve.

Service management system (SMS), a set of interrelated or interacting mechanisms that service providers use to direct and control their service management activities.

A desired state is a state of “goodness” to achieve and maintain, sustainably, for a thing worth managing. It is the continuous “end in mind” for things worth managing.

Best practices are things people are commonly doing now that work well when aiming to achieve and maintain desired states / desired states for things worthy of managing.

Open Service Management (OSM®) is a new and dramatically different set of best practice guidance for service management that is free and open, with a mechanism to keep it fresh and relevant, light-weight, and with two editions, enterprise and cloud.

The basic structure of OSM® consists of “things worth managing” for service providers, in three key categories—stakeholders, value flow, services, and the SMS, for each thing worth managing, OSM® identifies a desired state that the provider must achieve and continuously maintain to sustainably provide value to customers and users; lastly, it provides best practices—things IT pros are doing now that work—for achieving desired states for things worth managing.

OSM® Foundation training is 14 contact hours with a 40 question 1-hour simple multiple choice exam with 65% required to pass, worth 4 points towards master certification.


Chapter 2: Stakeholder Concepts, Desired States and Practices

In this chapter, we will introduce the concept of stakeholders, and their desired states (that is, what “good looks like” for the state of stakeholders, the completion of the statement, “Performance is effective when:” for stakeholders.

We’ll also cover best practices for achieving and maintain desired states for stakeholders, sustainably.

So, let’s get started!

    1. Stakeholders – the four main stakeholders of service management

Stakeholders are one of four key categories of things worth managing in service management; there are four primary stakeholders in service management:

 

16Figure 01-05.1 Four primary stakeholders in service management

You should immediately see some similarities and key differences here in comparison to traditional ITSM guidance.

First, the similarities: traditional ITSM guidance cites customers, users, and suppliers as stakeholders.

Now for the differences: more traditional ITSM guidance does not include the provider as a stakeholder in service management, perhaps because it is assumed that the provider is THE key stakeholder. Here, in OSM, we list the provider as a stakeholder, as the provider certainly does have a stake in the key outcomes of service management.

Stakeholders are people or organizations with a vested interest in their being continual value from a provider’s services over time and through changes, including customers, users, the provider itself, and suppliers.

Providers are people or organizations that manage and deliver services to one or more internal or external customers.

Customers are people or organizations that pay for and receive services and are the primary judge of their value; they may be internal (a person or group in the same business as the provider) or external (a person or business in a separate legal entity from the provider).

Users are people or organizations who use services, including people who use the service but do not pay for it, and customers who pay for the service, in their role as a user of the service; they may be internal or external to the provider.

Suppliers are people or organizations that are 3rd parties, external to providers (not part of the provider’s legal entity) who supply providers with goods or services needed to deliver services to the provider’s customers and users.

The idea here is stakeholder are a key, “thing worth managing”, and when you have a, “thing worth managing”, the thing to do is to get clear on what the desired state is for that thing, which you can do by filling in the blanks on the sentence, “Performance is effective when…”, and then driving towards achieving and maintaining that desired state, over time and changing stakeholder needs and technologies possibilities.

So, let’s have a look at the desired states for stakeholders overall.

Stakeholders – desired states

Performance is effective when:

  • We know who all our stakeholders are, and what their stake in our services is, and we use this information to systematically maintain productive relationships and tailored communications with all key stakeholders, so there are no or few negative surprises
  • We continuously listen to stakeholders and use that listening to “get better reality”—make our stakeholder relationships, service, and service management system better—and “get better perception” – set stakeholder expectations and manage stakeholder perceptions systematically
  • When asked, all stakeholders indicate they are pleased with the value they are getting from our services, or are confident, if there is a gap, that we are working to close it and capable of doing so

Unidentified stakeholders (and therefore, stakeholders where the relationship and value have no chance of being systematically kept in a desired state) represent a risk to the service provider.

The idea is to put mechanisms in place to ensure customers, users, members of the provider organization itself, and suppliers are kept in a desired state of “goodness”.

A lot of this can be accomplished through listening posts and feedback loops.

The desired states stated here may not be precisely right for your situation. The idea with OSM is not to provide a set of desired states, “for all time”, but to provide a structure, and example that you can contribute to, and adapt for your purposes.

Stakeholders – practices

Some of the practices you can use to achieve desired states for stakeholders include:

  • Stakeholder analysis / mapping / management

  • Stakeholder satisficing
  • Moments of Truth
  • Getting better reality (Guy Kawasaki)
  • Tailored, crisp communication (Mary Munter)
  • Feedback loops
  • Satisfaction = Perception – Expectation (David Maister)
  • Conditions of Satisfaction (Winograd & Flores)
  • Customer experience management (CEM)
  • User Experience

Again, as with desired states, the practices we mention here are not meant to be an exhaustive list, valid for all time, and so on. They are meant instead as a starter list, which you can contribute to as part of the community.

We will not, in this volume, describe each practice. What we will do is mention them, to get the conversation going, with the assurance that you know how to use a search engine to find out more, and that if you have a different idea or want to expand on any of these, you can contribute.

Three further points here:

First, the OSM Foundation exam is based on this publication, and so the syllabus does not require you to define each of these best practices, but only to recognize some of them from a list.

Secondly, the practitioner – general application volume will address these in more detail; sign up today at https://osmalliance.org if you’d like to contribute.

Thirdly, what we will do in this publication is to give an example of at least one best practice.

So, with that having been said, here’s one example: Satisfaction = Perception – Expectation (from “Managing the Professional Service Firm”, pg. 71): One of the simplest laws of service delivery is that if a stakeholder’s expectations exceed their perceptions, they will be dissatisfied. This is especially significant because a client’s perceptions and expectations may not necessarily reflect reality. Therefore, the achievement of stakeholder satisfaction requires the management of both stakeholder expectation and perception.

    1. Stakeholder: Customer definition, desired state and practices

Customers – definition and two types: internal and external

Customers are a key stakeholder in service management.

Customers are individuals, organizations, or units within organizations that pay for services, may specify requirements for new services and service improvement, and who are the primary judge of the value of services; they may be internal to the service provider (a person or group within the same legal entity as the provider) or external (a person or business or business unit within a separate legal entity from the provider); customers who pay for services may also be users of those services.

Customers – desired state

Let’s have a look at the desired state for customers.

Performance is effective when:

  • We have a good working relationship with “pay the bills” customers by seeking to both understand and shape customer needs, and by working to ensure those needs are met through the right set of services, which are informed by both changing customer needs and technology possibilities
  • We automate our relationship with customers, and that automation facilitates satisfaction (versus being a blocker to it), e.g., through a portal where they can administer their subscription, make requests, log incidents, etc.
  • We know which services are used by what customers, and to what extent
  • Conflicts with and among customers are rare, but when they do occur, it is easy for the customer to escalate, we handle them promptly and effectively
  • We take the time to understand the value of our services from the customers’ perspective, and not just our own, and use that understanding to manage both the reality and perception of our services
  • Customers are highly satisfied with, and continue to buy services, refer us, rarely complain, are engaged, and when asked, speak positively about us services, and say they meet their requirements and compare well against alternatives, as business conditions and technology and the value equation changes over time

There is a distinct difference between a customer, who pays the bills, and a user of a service, who does not. If you have children, and they have mobile service on your plan, you are the customer, and they are the users. You and your children are in distinctly different roles relative to the service, and the provider, to be successful, must recognize this, and have mechanisms in place to keep each of you in a desired state of happy with their service.

Customers – practices

Some practices that can help you achieve and maintain the desired state for customers include:

  • Customer experience management

  • Business relationship management
  • Self-service portals
  • Public status pages
  • Multi-channel support
  • SERVQUAL
  • Service level management
  • Service catalog management
  • Service portfolio management
  • Service reporting
  • Service reviews
  • Service improvements
  • Service retirement

One example of a practice is public status pages (or transparent uptime).

A public status page gives you a place to transparently show information about the availability and performance of your services. You can post announcements, update current issues, and allow people to opt-in to notifications.

In his blog on transparentuptime.com, Lenny Rachitsky gives four points he recommends as prerequisites for doing public status pages

  1. Admit failure. Really own it.
  2. Sound like a human.
  3. Have a communication channel.
  4. Be authentic.

02-02. Stakeholders – Customers – Definition, desired state, best practices

    1. Stakeholder: User definition, desired states and practices

Another key stakeholder of service management besides customers who pay the bills for services are uses.

Users literally use—interact with your service, product, website or app. You want to make sure these are easy for them to use.

Users – desired state

Performance is effective when:

  • We have a good relationship with users of our services; we seek to understand and shape user needs, and meet those needs through our services.
  • Users say they are highly satisfied with, and continue to use services, refer us to others for services, rarely complain, are engaged, and when asked, speak positively about our services
  • We take the time to understand the value of our services from the users’ perspective, and not just our own, and use that understanding to manage both the reality and perception of our services
  • We automate our relationship with users, and that automation facilitates satisfaction (versus being a blocker to it), e.g., through a portal where they can make requests, log incidents, etc.
  • Users say our services help them meet their objectives, and that they are getting higher value from our services as compared to alternatives, including doing it themselves, at a lower effort and risk

Some additional indicators of effective performance:

  • Users see us as providing the right mix of services, each with the right mix of features and attractive quality
  • Users are happy with the features (including the pace of introduction of new features), performance, service levels and support for our services
  • Users understand the terms of our service and their responsibilities as users of our service(s)
  • This feedback is steady over changing services, time, and circumstance, including fluctuations in user demand for our servicesand changes in the user environment

Users – practices


Some practices that can help you achieve and maintain the desired state for users include:

  • User experience management (UX)
  • Self-service portals
  • Service desk
  • Public status pages
  • Multi-channel support
  • User satisfaction surveys
  • User training
  • User story
  • Continuous Delivery

One example: Continuous Delivery, which enables users to start using new functionality and qualities quickly to realize value and provide feedback sooner.

Continuous Delivery, or CD, is about automated implementation of the application build, deploy, test and release processes meant to ensure performance (fast delivery) and conformance (to requirements), enabling users to start using new functionality and qualities quickly to realize value and provide feedback sooner.

It may be useful to you to differentiate between the different types of users, to ensure the mechanisms you have in place to ensure they are in a “good” state of happiness are differentiated enough based on their roles, needs and expectations.

Users – definition and types: end, super, and admin

There are different types of users; each type must be recognized and systematically “loved” to ensure satisfaction; user types include:

  • End users (whose role is limited to using the service and asking for support or service items they are entitled to)
  • Super users (users who have some level of administrative privilege
  • for other users, e.g., to assign roles within a project system)
  • Admin users (who administer a subscription / service for others, for
  • example, Office365 admin users)

Now let’s have a looks at the next key stakeholder in service management: the provider. OSM’s inclusion of providers as a stakeholder in service management is a departure from traditional ITSM guidance.

    1. Stakeholder: Providers definition, desired states and practices

Stakeholders – Providers – definition

There are several types of provider staff, each of which must be recognized and systematically related to, including:

  • Developers
  • Infrastructure Engineers
  • Support staff
  • Delivery staff
  • Managers

For sustained success at service provision, it is imperative that team members within the provider are satisfied with their work.

https://www.thebalance.com/improve-employee-satisfaction-1917572 indicates this is a function of respectful treatment, fair compensation, benefits, job security, trust, opportunities to use skills and abilities, financial stability of the organization, the employee’s relationship with their immediate manager, feeling safe in the work environment, and the employee’s immediate manager’s respect for their ideas.

Stakeholders – Providers – desired state

Performance is effective when:

  • We maintain a positive, effective and sustainable working relationship among provider staff
  • We get good value out of our providing services, and customers and users and suppliers do as well
  • We automate our relationships internally among different parts of our provider organization, and that automation facilitates satisfaction (versus being a blocker to it), e.g., through a portal where provider staff can make requests, log incidents, etc.
  • We take the time to understand the value of our services from the suppliers’ perspective, and not just our own, and use that understanding to manage both the reality and perception of our services
  • We hire the right people in the first place, and they happy, healthy, and productive, with a service orientation, continuously learning and innovating, rarely complain, are engaged, and when asked, speak positively about their job and our organization

Some additional indicators of effective performance:

  • Our people have the right skills, knowledge, and mindset to succeed, and are good at managing, facilitating meetings, communicating clearly, negotiating and problem solving
  • We make time for continuous learning, development, and improvement, about things:
    • to achieve and maintain the desired state of things worth managing
    • required to understand what makes customers and users successful and how our services contribute to that, including new technologies that provide advantages
  • We have good financial performance
  • We have the resources (money, infrastructure, applications, information, people), capabilities, and authority to succeed
  • We have clear and shared goals and objectives
  • We have capabilities that are hard for competitors or customers to duplicate
  • We manage both the reality and perception of our services
  • We have good financial performance
  • We have satisfied customers
  • Our people are aware of our business objectives and those objectives inform what they do

Providers – practices


Some practices that can help you achieve and maintain the desired state for providers include:

  • Hiring the right people in the first place
  • Employee engagement
  • CAMS
  • OLAs
  • RACI
  • Roles: Process owner, manager, practitioner; service owner
  • Affinity (DevOps)
  • Blameless Culture (DevOps)
  • Collaboration (DevOps)
  • Communication, Osmotic (DevOps)
  • Self-organizing Teams
  • Product Owner (in Agile Scrum)
  • Roles: Service Owner, Scrum Master, Scrum Team, embedded teams
  • Scaling (of DevOps or Agile Scrum)

Best practices must be aimed at the reality and perception of the employee on the following parameters: respectful treatment, fair compensation, benefits, job security, trust, opportunities to use skills and abilities, financial stability of the organization, the employee’s relationship with their immediate manager, feeling safe in the work environment, and the employee’s immediate manager’s respect for their ideas.

One example of a practice for driving towards desired states for the provider is embedded teams. The DevOps practice of embedded teams can help bring down barriers between disparate, siloed teams. An embedded product team consists of all the people and skills needed to independently take product all the way from requirements to delivery. In DevOps, which is Dev + Ops, the place to start is by embedding Dev representatives in Ops teams, and vice versa.

Source: alistair.cockburn.us/Osmotic+communication

Now let’s have a look at the last of four key stakeholder groups that OSM identifies, suppliers.

    1. Stakeholder: Suppliers definition, desired states and practices

Stakeholders – Suppliers – definition

There are many types of suppliers, each of which must be related to systematically, including:

  • Commodity, tactical and strategic suppliers
  • Goods suppliers and service suppliers
  • Transactional suppliers and subscription-based suppliers

Examples of suppliers include:

  • Hardware vendors
  • System software vendors
  • Network vendors
  • Application vendors
  • DBMS vendors
  • Goods vendors
  • Services vendors
  • Hosting companies

Stakeholders – Suppliers – desired state

Performance is effective when:

  • We get good value out of suppliers, and suppliers get good value out of supplying services to us
  • We know who our suppliers are, including contacts, contracts, and historical performance, and we regularly review contracts for suitability / performance
  • Our contracts have the right legal language to protect us and our relationship with the supplier
  • Contractual disputes are rare, but when they do occur, we have an effective process for resolving them
  • We automate our relationship with suppliers, and that automation facilitates satisfaction (versus being a blocker to it), e.g., through a portal where they can view and report performance against contracts, etc.
  • We do not have to deal with the day to day details of the costs or risks associated with the services suppliers provide us
  • We have the right balance between what we do internally and what is outsourced to suppliers

Other indicators of effective performance include:

  • Suppliers consistently meet or exceed our business needs and contractual commitments for the goods and services we depend on from them
  • We have a good relationship with suppliers, and we proactively manage their performance
  • Contract terms with all suppliers are good
  • We are not using expensive / higher risk / custom supplier services and goods where cheap / low risk / commodity services and goods will do
  • Supplier staff know our key business desired states and how their services support them
  • Supplier staff are aware of our patterns of activity, and carry out their activities with this knowledge in mind, avoiding issues
  • Supplier transitions go smoothly
  • When we manage stakeholder relations, services and the SMS, we take into consideration the suppliers’ patterns of business activity
  • We have an effective an efficient process for renewing and terminating contracts
  • We ensure all supplier contracts support business needs and provide value for money
  • We sign up for the right contracts in the first place, with the right commitments in them
  • Suppliers used and the goods and services we acquire from them are aligned to our supplier policies, and are compliant with applicable regulatory requirements
  • We categorize our suppliers from commodity to strategic, based on the value and risk they present to us; we use this information effectively to apportion our time to suppliers in managing their performance appropriately, in proportion to their importance to us
  • Suppliers consistently meet the commitments incorporated in our contracts with them
  • While finance and legal may be involved in ensuring supplier contracts are sound, we take ownership for making sure contracts support services and service level and manage the performance of suppliers to their contractual commitments.

Stakeholders – Suppliers – practices

Some practices that can help you achieve and maintain the desired state for suppliers include:

  • Supplier management – contacts, contracts, performance
  • Vendor value management
  • Contract management
  • Underpinning contracts
  • Supplier categorization
  • Cloud cost containment

One example of a practice is supplier categorization. The Kraljic Portfolio Purchasing Model was created by Peter Kraljic and first appeared in the Harvard Business Review in 1983.

The model involves four steps:

  1. Purchase classification
  2. Market analysis
  3. Strategic positioning
  4. Action planning

You can use this model to classify your suppliers and apportion your time during the year according to whether they are strategic suppliers, commodity suppliers, or somewhere in between.


Chapter 2 Summary

Stakeholders, along with services and the service management system, are one of the four categories of things worth managing in OSM®

There are four primary stakeholders in service management: 1) customers, 2) users, 3) the provider, and 4) suppliers

As providers, we seek to continuously provide value to stakeholders through services over time and through changes by achieving and sustainably maintaining desired state for things worth managing through best practices

For services to be sustainable, value must flow multidirectionally to all stakeholders

There are desired states for each stakeholder; many shared, mode 1, and mode 2 practices exist to help providers achieve and maintain those states.


Chapter 3: Value and Value Flow Concepts, Desired States and Practices

In this chapter, we’ll cover concepts of value and value flow, to help you describe value and value flow in service management, its desired state, and best practices for achieving that desired state, including:

  • 03-01. Define what value is, and its characteristics
  • 03-02. Describe value flow in relation to value
  • 03-03. Define value stream, and describe value stream mapping
  • 03-04. Describe Lean, its relation to value, and the five lean principles
  • 03-05. Describe Agile, its relation to value, and the four agile value statements
  • 03-06. Value flow – Overall definition, desired state, best practices
    1. Value and its characteristics

What is value? And where does it reside?

As you can see from this definition, value is in the mind of stakeholders. That being the case, as providers we must influence both the reality of our services and their perception by stakeholders.

Here again you should see some similarities and differences between OSM’s conception of value, and that of tradition ITSM guidance.

One key difference from traditional ITSM guidance is that while in OSM, the pay-the-bills customer is the PRIMARY arbiter of value (as without them, you have no business), all stakeholders have a stake in value, and a perspective that must be honored for sustainable success.

Another key difference is that in OSM, value must flow multidirectionally, that is, in all directions, among all stakeholders (customers, users, the provider, and suppliers) for a service to be sustainable.

When is a service valuable to stakeholders?

For customers, a service is of value when it is attractive as compared to alternatives, in terms of price, risks, and effort required (including the need to attend to details), and where what is gained exceeds what is lost by using it, and where it helps achieve outcomes whose worth exceeds the service cost.

For users, a service is of value when it helps them achieve a desired outcome without undue effort as compared to alternatives.

For the provider, a service is of value if it results in profits, enhanced market share, competitive advantage, capability, compliance, safety, reputation, goodwill, and learning.

For suppliers, the service is of value if it results in the same outcomes as that of the provider, but for the supplier’s portion of the service, and for the supplier’s business.

So, you see, value is not the same for each stakeholder, because “what you see depends on where you sit.” Each stakeholder has a unique stake, and therefore, each service presents a different value equation for each.

    1. Value flow in relation to value

What is value flow?

Value flow is good when it proceeds to stakeholders with no undue stoppages, scrap, rework or backflows.

Barriers to flow include inconsistency and variation (Mura) and overburden or unreasonableness (Muri); enablers to flow include just-in-time (JIT) systems and corrections for overburdened and unreasonable practices.

You should see three other key differences between OSM and traditional ITSM guidance are when it comes to the subject of value:

First, OSM emphasizes not just value, but also value flow, in line with agile and lean practices.

Secondly, OSM positions value flow as multi-directional, among all stakeholders, defined as customers, users, the provider, and suppliers, as a basis for sustainability, where in traditional ITSM guidance, value flows in one direction, between two stakeholders: from the provider to the customer.

These differences are important, especially in the cloud portion of today’ typical hybrid environment. Teams are aligned around build pipelines and are working to make value flow unencumbers by inconsistency, variation and overburden. So, they get value flow, and their role in making it happen, and are creating and looking for best practices to help them do it.

    1. Value stream and value stream mapping

What is a value stream, and what is value stream mapping?

Value Stream mapping (VSM) is typically described in the following four steps:

  1. Identify the target product, product family, or service.
  2. Draw (preferably by walking on the shop floor or the virtual flow of information) a current state value stream map (CSVSM).
  3. Draw a future state (with waste removed) value stream map (FSVSM).
  4. Develop an action plan to work toward the future state condition, and implement the plan.

Value stream mapping is a critical technique in OSM, because the flow of value through services is critical to success at service management. There are many places to apply VSM. Your build pipeline is a no-brainer to start with if you haven’t already.

But keep in mind that value takes many forms and flow multidirectionally in our conception. So, for example, you can apply VSM to feedback loops between, for example, to amplifying feedback loops; for example, you could instantiate tighter feedback loops between BRM, strategy, continual improvement, and sprint planning and retrospectives. In this example, the core value that flows are knowledge—user and customer feedback, changing technology possibilities, changing business conditions—not code, as in a build pipeline. In general, you should seek shorter cycles and smaller, more frequent increments for all four, and that starts with understanding the value stream.

OSM draws on Lean principles and Agile values as a basis for delivering more value, faster, with quality and continual improvement.

17Figure 03-04.1 Lean and Agile and their relation to value

The five Lean principles are:

  1. Identify value
  2. Map the value stream
  3. Create flow
  4. Establish pull
  5. Seek perfection

The four Agile values are:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

The idea is to keep things lightweight—applying these principles and values to “things worth managing”, focusing on outcomes, not activities—focusing on every understanding and driving towards maintaining desired states, rather than a few engineering and enforcing heavyweight processes.

Let’s have a further look at Lean and Agile, as they are important principles and values for OSM.

    1. Lean, its relation to value and the five lean principles

Lean, its relation to value, and the five lean principles

18Figure 03-04.1 Five Lean Principles

Source: https://www.ame.org/sites/default/files/query_archive_docs/LeanGlossary_01_08_1.pdf, https://www.lean.org/WhatsLean/

The five lean principles as cited by ame.org are:

  1. Identify Value: When a product or service has been perceived or appraised to fulfill a need or desire–as defined by the customer–the product or service may be said to have value or worth. Components of value may include quality, utility, functionality, capacity, aesthetics, timeliness or availability, price, etc.
  2. Map the Value Stream: All the activities (both value-added and non-value added) required within an organization to deliver a specific service; “everything that goes into” creating and delivering the “value to the end-customer.
  3. Create Flow: The progressive achievement of tasks and/or information as it proceeds along the value stream, flow challenges us to reorganize the Value Stream to be continuous… “one by one, non-stop”.
  4. Establish Pull: Principle the no one upstream function or department should produce a good or service until the customer downstream asks for it. Pull is a system of cascading production and delivery instructions from downstream to upstream activities in which nothing is produced by the upstream supplier till the downstream customer signals a need
  5. Seek Perfection: A never ending pursuit of the complete elimination of non-value adding waste so that all activities along a value stream create value; perfection challenges us to also create compelling quality (“defect free”) while also reducing cost (“lowest cost”). Perfection is Complete elimination of waste (Muda) so that all activities along

Lean systems focus on the parts of the system that add value by eliminating waste everywhere else, whether that be overproduction of some parts, defective products that must be rebuilt, or time spent waiting on some other part of the system. Waste to be eliminated in these areas can include unnecessary software features, communication delays, slow application response times, and overbearing bureaucratic processes.

    1. Agile, its relation to value and the four agile statements of value

What is Agile, and what are the four Agile statements of value?

19Figure 03-05.1. The Agile Manifesto

“Agile” (with a capital A) refers to a set of frameworks used for development and management of programs and projects intended to make development quicker and smoother, and to create output that is more satisfying for the customer.

So far, you know that an Agile framework is one that uses an adaptive development lifecycle instead of a predictive one. Agility was around back in the 50s, where it was considered a strange and sometimes anarchistic viewpoint; in a time when the traditional method did not even have a name such as Waterfall, because it was the de-facto way of working.

The term “Agile” has become more and more established and was formalized by a group that prepared and signed a statement of values for Agile projects back in 2001, known as the Agile Manifesto.

Items on the right are obviously important but they are a means to an end. Often peple focus on items on the right, thereby spending energy (and time) on the wrong things. Items on the right are the things that really matter to a (business/customer) organization.

Now that we’ve discussed the nature of value and value flow, and how Lean and Agile principles and values can contribute to acheiving and maintaining them, let’s have a look at the desired state for value flow.

    1. Value flow definition, desired state and practices

Value and value flow – desired state

Performance is effective when:

  • Value flows to all stakeholders (customers, users, us (the provider), and suppliers) multidirectionally and unencumbered, with no undue stoppages, scrap, rework or backflows
  • When asked, stakeholders indicate they are pleased with the value they get from our services, both in terms of what they get, and the pace at which they get it
  • Value flows continually—over time and through changes—from services, to customers and users, and back to the provider and suppliers
  • The value from our services compares favorably to alternatives, because we have taken the time to seek out changing business needs and new technology possibilities, and to incorporate that looking and listening into our service
  • Uptake of services, features and feature sets is widespread in users and they are getting good value out of them

So, you see, performance is effective when value flows multidirectionally, to all stakeholders, and is sufficient for the sustainability of the service, as we change it continuously over time to account for changing stakeholder needs and technology possibilities.

What are value and value flow best practices?


Some practices that can help you achieve and maintain the desired state for value flow include:

  • The five lean principles
  • The four agile values
  • Value attribute tree
  • Value stream mapping
  • Feedback loops
  • Build pipeline
  • Continuous integration
  • Continuous delivery
  • Continuous deployment
  • Blue / Green Deployment

Here is one example: blue / green deployment.

Blue/Green Deployment is supplanting rolling upgrades as a method for releasing software code, where two environments, Blue and Green, are initially configured identically, with one active and the other environment inactive. New code is released to the inactive environment, where it is thoroughly tested; Then the active and inactive environments are switched. If problems are discovered after the switch, traffic can be directed back to the inactive configuration that still runs the original version. Once the new code has proven itself in production, the team updates the code in the inactive environment to match the active environment. The process reverses itself when the next software iteration is ready for release.

This technique eliminates downtime due to application deployment, and reduces risks and dramatically lowers the transaction cost and time required to revert to a prior known, good state; if something unexpected happens with your new version on Green, you can immediately roll back to the last version by switching back to Blue.


Chapter 3 Summary

Value is the worth in the mind of stakeholders, of a product or service.

Value must flow to all stakeholders multidirectionally for a service to be sustainable.

Value flow is the multidirectional stream of value delivered through services to all stakeholders, primarily customers, users, the provider, and suppliers.

Value is created and added through design, transition, promotion, support, and delivery activities (which can be fully or partly automated or manual), as an applied to a service and its associates configuration, features, and qualities.

Lean and Agile principles can help providers deliver value.


Chapter 4: Service Concepts, Desired States and Practices

This is the fourth chapter of the publication, where we focus on services, their constituent components, desired states, and best practices for driving towards desired states.

We’ll start with what a service is and then proceed to discussing its configuration (or parts), then functionality (or features), and qualities (or characteristics / behaviors).


      1. Overall Service definition, desired state, practices

What is a service?

Services are one of four key categories of things worth managing in service management.

Services can be internal or external, i.e., internal services are services provided to customers and users belonging to the same business entity as the provider; external services are provided to individuals and organizations outside of the provider’s business entity.

A service is a means of delivering value to customers by facilitating the desired states customers want to achieve, at (what should be) a lower cost and risk than doing it themselves, or other alternatives, and without the need to pay attention to all the details (or means) of delivering the service. The general idea—and you should be familiar with this because therefore you utilize services instead of simply doing it yourself, or using an alternative—is that you can focus on the ends, or outcomes, instead of the means, and because the service presents a better value in the end than doing it yourself or alternatives.

Services must also provide value to users, and value back to the provider and its suppliers, for services to be sustainable. Not that in this definition, the value flow is multidirectional; also, the nature of value is not just in new services and features, it is multi-dimensional; for example, value can flow back to the provider from customers and users in the form of feedback on services, feature sets, features, and new feature requests.

Services are comprised of three things: their configuration (or parts), their functionality (or features), and their qualities (that is, their non-functional characteristics). All are things worth managing.

What three things are worth managing when it comes to services?

20Figure 04-01-01. Human-Led and IT-Led things worth managing

Each of these “things worth managing”—a service’s configuration, functionality, and qualities—has a desired state to be achieved and maintained through best practices.

Here’s an example that may help clarify the difference between configuration, functionality and qualities, for an IT-Led service (adapted from https://ux.stackexchange.com/questions/47897/what-are-the-differences-between-features-and-components): Take Microsoft Word:

Its components:

  • spell-checker,
  • Page designer,
  • Word art etc.

Its features:

  • can detect your spelling mistake
  • you can customize page-design
  • you can draw simple arts, etc.

Its qualities:

  • Internationalization
  • Accessibility
  • Security, etc.

What are the characteristics of services?

Characteristics of services include:

  • Services can be fully or partially automated or manual
  • Services can involve the provision of goods, e.g., replacement keyboard
  • Services can be internal or external, i.e., internal services are provided to customers and users belonging to the same business entity as the provider; external services are provided to individuals and organizations outside of the provider’s business entity
  • End-services are what that the customer recognizes and pay for; they typically include sub-services (e.g., updates, DHCP); services can be broken down into core services (e.g., for mobile phone service, dial tone), optional services (e.g., data plan), and supporting services (e.g. backups, update); services can be stratified in tiers (e.g., gold, silver, bronze level packages)

In addition to these characteristics, services can be divided into two main types: human-led and IT-led.

What are the two main types of services?

21Figure 04-01-01.2 Human-Led & IT-Led Service Types; Source: Five modes regarding the role of technology in customer contact. Adapted from: Froehle and Roth, 2004, p. 3.

The two main types of services are:

1) Human-Led Services, performed by humans, e.g., moves, adds and changes; technology may be assist / facilitate, but the primary driver is human, and

2) IT-Led Services, e.g., AD, DNS, etc.; technology is the driver, humans may assist / facilitate.

As you can see from the figure, services sit along a continuum from technology to technology generated; we’ve adapted Froehle and Roth’s five modes of human and technology interaction model to help illustrate:

Technology-free customer contact, for example, the face-to-face contact between a psychological therapist and patient. This type of contact does not require the use of technology; thus, it is the most traditional and direct mode of customer contact.

Technology-assisted customer contact, for example, hotel check-in and check-out procedures, transactions conducted over manned bank counters, and passenger check-ins for airline boarding. During these processes, technology (i.e., a computer) is used by the service provider only. However, the customer and service personnel still experience face-to-face contact.

Technology-facilitated customer contact, for example, the use of Microsoft PowerPoint by a financial expert to present and discuss financial plans with customers during a conference. Although technology is used by both parties, face-to-face customer contact still occurs.

Technology-mediated customer contact, for example, telephonic interaction between service personnel and customers and the provision of professional advice by a consulting company using Videoconference technology. In these contexts, a shared technological platform is used by the service personnel and the customer without face-to-face contact.

Technology-generated customer contact, e.g., ATM withdrawals. In these, customers operate the technology without assistance of service personnel, and face-to-screen contact replaces face-to-face contact. Online shopping is an example of this mode.

We add a 6th one here, Human-free, where technology represents both the provider and the consumer of the service, as in EDI.

Let’s have a closer look at human-led and IT-led services.

What are Human-Led services?

22Figure 04-01-01.3 Human-Led Services

Human-led services include a continuum of use of technology, from none to integral, including:

  • Technology-free customer contact, for example, the face-to-face contact between a psychological therapist and patient. This type of contact does not require the use of technology; thus, it is the most traditional and direct mode of customer contact.
  • Technology-assisted customer contact, for example, hotel check-in and check-out procedures, transactions conducted over manned bank counters, and passenger check-ins for airline boarding. During these processes, technology (i.e., a computer) is used by the service personnel only. However, the customer and service personnel still experience face-to-face contact.
  • Technology-facilitated customer contact, for example, the use of Microsoft PowerPoint by a financial expert to present and discuss financial plans with customers during a conference. Although technology is used by both parties, face-to-face customer contact still occurs.

In the end, the defining characteristic of a human-led service is that humans (versus automation) are in the lead, taking the front position, representing the service to stakeholders.

In contrast, IT-lead services are primarily or wholly represented to stakeholders by technology or automation. Let’s have a closer look at these now.

What are IT-Led Services?

23Figure 04-01-01.4 IT-Led Services

IT-Led services include a continuum of technology involvement, from technology in the lead, supported by humans, to total representation of the service by technology. Here are some of the levels:

  • Technology-mediated customer contact, for example, telephonic interaction between service personnel and customers and the provision of professional advice by a consulting company using Videoconference technology. In these contexts, a shared technological platform is used by the service personnel and the customer without face-to-face contact.
  • Technology-generated customer contact, for example, ATM withdrawals, vending machine purchases, or coin-operated automatic photograph booth operations. In these processes, customers operate the technology without the assistance of service personnel, and face-to-screen contact replaces face-to-face customer contact. The recent trend of online shopping is considered an example of this mode.
  • Human-free, where technology represents both the provider and the consumer of the service, as in EDI.

Now that we’ve discussed human-led and IT-led services, it’s time to look at the desired state for services overall.

What is the desired state for services?

Performance is effective when:

  • We have the right mix of IT-Led and Human-Led services, with the right level of automation and human activities in each
  • We have rooted out of IT-Led services any unnecessary complexity, variation, and dependencies and any other factors that slow down stakeholders, services, and the SMS
  • Customers and users are happy with the value they are getting from our services and are sticking with us, because we as time and circumstances change, we listen to how their needs and value equation is changing, and understand and educate them on what new technologies can offer, and bring these two things together to continuously add, change, and remove services so our portfolio is compelling to them
  • We have both “better reality” and “better perception” in our services in the eyes of customers and users

Some additional indicators of effective performance:

  • Customers and users can focus on their “ends-in-mind” because we handle the details of the services we provide, and because we have (and they see we have) the specialized capability to provide the services they value at a lower cost, effort and risk than doing it themselves or as compared to alternatives
  • The provider (us) and our suppliers are happy with the value we are getting from providing services over time and through changes
  • Services are profitable, over time and across changes, because we add, modify, and remove services continuously to achieve and increase value as time passes and circumstances change

Services – practices

For services, overall best practices are divided into Human-Led and IT-Led, and within each, practices to achieve and maintain desired states for configuration, functionality, and qualities, as well as shared, mode 1 and mode 2 best practices suitable for all environments, traditional IT, and cloud environments

24Figure 04-01-01.1 Overall services best practices

04-01-01. Service – Overall definition, desired state, best practices

For services, overall best practices are divided into Human-Led and IT-Led, and within each, practices to achieve and maintain desired states for configuration, functionality, and qualities, as well as shared, mode 1 and mode 2 best practices suitable for all environments, traditional IT, and cloud environments. Configuration is what the service is made up of, it’s parts; functionality is its features / what it does; qualities are its characteristics / how it behaves.

Now, let’s have a look at the specifics for the configuration portion of services.


Introduction 4.1: Service Configuration concepts, desired states and practices

Service configuration definitions, desired states and practices

In this chapter, we’re covering topics that will help you describe the components that make up the configuration of services, their desired states, and best practices for achieving them, including:

  • 04-01-02. Service Configuration
  • 04-01-03. Human-Led Services
  • 04-01-04. IT-Led Services
  • 04-01-05. Software
  • 04-01-06. Applications
  • 04-01-07. Data
  • 04-01-08. Platform
  • 04-01-09. Runtime
  • 04-01-10. Middleware
  • 04-01-11. Operating System
  • 04-01-12. Infrastructure
  • 04-01-13. Virtualization
  • 04-01-14. Server
  • 04-01-15. Storage
  • 04-01-16. Network
  • 04-01-17. Hardware
  • 04-01-18. Facilities

Service configuration definitions, desired states and practices (120m)

To reiterate, in OSM, services are made up of three things: configuration (parts), functionality (features), and qualities (non-functional characteristics, like availability). This is the first section in chapter four, where we focus on definitions, desired states and practices for the configuration portion of services.


      1. Service configuration definition, desired state, practices

Service configuration – definition

25Figure 04-01-02.1 IT-Led and Human-Led services configuration

Source: adapted from https://ux.stackexchange.com/questions/47897/what-are-the-differences-between-features-and-components

An example may help illustrate the configuration component of a service: For a bicycle delivery service in a metropolitan area, the configuration would include the couriers, the fleet of bikes, the repair shop, etc. The features would include different size and type packages that could be dropped off. The qualities would include the delivery area, and so on.

Service configuration example: Human-Led service – Office365

26Figure 04-01-02.3 Human-Led service configuration example – Office365

You should see that the configuration, or parts, are distinct from the functionality, or features, and the qualities, or characteristics.

Each contributes (or takes away from) the value of a service, and as such, each need to be recognized and systematically managed.

Service configuration example: Human-Led service – device bar

26Figure 04-01-02.4 Human-Led service configuration example – device bar

You’ve probably visited the Apple Genius bar or the Microsoft In-Store Answer Desk at one time or another, or perhaps you have concierge-style support locations in you company.

Think about a few specific instances of when this has worked well for you (or not).

Were the positives or negatives driven by the configuration, functionality, or qualities of the service?

Now think about your services, along the same lines—this may give you an idea of where best to focus to improve achieving and maintaining desired states for these things worth managing.

Now let’s have a look at the configuration for human-led services.


      1. Human-Led service configuration

Human-Led service configuration – definition

Figure 04-01-03.1 Human-Led service configuration

Human-Led service components include:

  • People – the roles and individuals and teams that deliver the service and their skills, knowledge and mindset(s)
  • Service IP, kits, collateral—the knowledge and materials teams rely on to deliver services
  • Systems & Tools—for example, a process template for a process engineering engagement
  • Goods—for services where goods are involved, e.g., installing a new physical monitor
  • Facilities—for example, a physical location for concierge-style device support

Examples of human-led services include:

  • Moves, adds and changes
  • New hire setup
  • Legal hold
  • Consulting
  • Auditing practices

For value to be realized by stakeholders of your Human-Led services, you must keep the components of Human-Led services in good repair, so that they contribute to a desired state of being reliable, responsive, trustworthy, empathetic, and with good attractiveness.

You most certainly have been on the receiving end of Human-Led services, like getting your office moved, or using consulting services.

Think about a few specific instances of when this has worked well for you (or not). Were the positives or negatives driven by the configuration, functionality, or qualities of the service?

Now think about your services, along the same lines—this may give you an idea of where best to focus to improve achieving and maintaining desired states for service configuration.

Now let’s have a look at the desired state for service configuration for human-led services.

Human-Led service configuration – desired state

Performance is effective when:

  • People—individuals and teams that deliver the service, are the right people with the knowledge, skills and mindset, and are attractive
  • Service IP, kits, collateral—the knowledge and materials teams rely on to deliver services—is up to date, complete, and easy to locate, navigate and use

Source: https://en.wikipedia.org/wiki/SERVQUAL

“Attractive” in this sense does not mean that all our people are models, that all our facilities are slick, etc. It means at a minimum that they are not off-putting, and are suitable for the purposes of the service and its stakeholders. For example, there is one standard of dress you might expect a dollar store employee to have, and quite another for say, a Nordstrom salesperson. And if the dollar store fixtures were too expensive-looking, you might wonder what you’re getting for your dollar—similarly, if the fixtures in a Nordstrom’s were shoddy or cheap looking, you might be wondering if the t-shirt you’re buying is worth $30.

For value to be realized by stakeholders of your Human-Led services, you must keep the components of Human-Led services in good repair, so that they contribute to a desired state of being reliable, responsive, assurant, empathetic, and with good attractiveness. This means keeping the following in good order:

  • People—the individuals and teams that deliver the service
  • Service IP, kits, collateral—the knowledge and materials teams rely on to deliver services
  • Systems & Tools—for example, a process template for a process engineering engagement
  • Goods—for services where goods are involved, e.g., installing a new physical monitor
  • Facilities—for example, the tangible appearance of a physical service location

Human-Led service configuration – practices

Some practices that can help you achieve and maintain the desired state for value human-led service configuration include:

  • SERVQUAL Valerie Zeithaml and Mary Jo Bitner
  • Service IP, kits, collateral Thomas E. Lah
  • Systems and tools Thomas E. Lah
  • Goods TSIA
  • Facilities Micah Solomon

There isn’t a lot of good writing out there on packaging the parts of Human-Led service kits. One good source is Thomas E. Lah.

Now let’s have a look at IT-led service configuration.


      1. IT-Led service configuration

IT-Led service configuration – definition

Figure 04-01-04.1 IT-Led service configuration

An IT-Led services configuration is comprised of three layers: software, platform and infrastructure. For cloud environments, these are all, “as a service”; for traditional environment, they are not.

IT-Led services are services where IT takes the lead in representing the provider, anything from being an equal partner with humans, up to fully representing the provider to a human, and beyond—where the provider is represented by technology, and the consumer is, too, as in EDI.

IT-Led service configuration – definition

Infrastructure, Software, and Platform or IaaS, SaaS and PaaS

The IT-Led Services stack includes infrastructure, platform, and software components; in traditional IT, you are the provider for the entire stack; in the cloud, “as a service” model, you use an external service provider for:

In traditional IT, the software / platform / infrastructure stack is provided on-prem, and not “as-a-service”. In a cloud environment, each of these layers is provided, “as-a-service.”

The typical environment at the time of this writing is a hybrid of traditional IT and cloud, so it is important to recognize and systematically manage the configuration of both.

IT-Led service configuration – desired state

Performance is effective when:

  • We have the right mix of traditional and cloud-based IT-Led services, or are moving towards that mix at the right pace
  • We know what we have, what we are paying for and using (and we are not paying for stuff we aren’t using)
  • We have a balance of flexibility for choice of services for customers and users, but not such a proliferation of options that the work of customers and users is negatively impacted (learning curve, interoperability issues, etc.)
  • Our IT-Led service configuration “adds up” to consistently and sustainably support the levels of service expected by stakeholders, over time and through changing stakeholder needs and new technology possibilities

Knowing what you have so you can manage it sounds like a basic and expected thing, but the reality, with things like growth through acquisition, and the proliferation of people buying cloud services, is that it “ain’t necessarily so.”

Getting a good handle on what you’ve got out there is step one, both in a traditional and cloud environment. A key next step is extreme standardization on both; if, for example, you know all SQL servers look like so-and-so, and only come in a small, medium or large, it’s easier to grasp and manage the environment.

The same goes for dependencies; you can reduce them with techniques like inversion of control, and use of versioned API and data contracts.

Your enemy is irrational variation and dependencies, so rooting that out should be job one.

Think about how you spend your time each day. Why do you need to meet with others to discuss projects, or changes, or risks, etc.? There are two main drivers: variation, and dependencies. So, root those out relentlessly to reduce the overhead of managing your environment.

IT-Led service configuration – practices

Practices for achieving desired states for IT-led services configuration include:

  • Dependency reduction
  • Inversion of control
  • Versioned APIs
  • Data contracts
  • Microservices architecture / REST
  • Variation reduction
  • Immutable deployment
  • Infrastructure-as-code
  • Service mapping, and
  • Containerization

Knowing what you have so you can manage it sounds like a basic and expected thing, but the reality, with things like growth through acquisition, and the proliferation of people buying cloud services, is that it “ain’t necessarily so.”

Getting a good handle on what you’ve got out there is step one, both in a traditional and cloud environment. A key next step is extreme standardization on both; if, for example, you know all SQL servers look like so-and-so, and only come in a small, medium or large, it’s easier to grasp and manage the environment.

The same goes for dependencies; you can reduce them with techniques like inversion of control, and use of versioned API and data contracts.

Your enemy is irrational variation and dependencies, so rooting that out should be job one.

Think about how you spend your time each day. Why do you need to meet with others to discuss projects, or changes, or risks, etc.? There are two main drivers: variation, and dependencies. So, root those out relentlessly to reduce the overhead of managing your environment.

In the sections that follow, we’ll explore the parts of an IT-led services configuration, their desired states, and practices that can help you achieve and maintain them, starting with Software.


      1. IT-Led service configuration: Software

IT-Led service configuration – Software – definition

04-01-05. service configuration – Software – Definition, desired state, best practices

https://www.techopedia.com/definition/4224/application-software

Whether software is delivered in a traditional manner, or as a service, it must be the right software, fitting for the service(s) it supports.

IT-Led service configuration – Software – desired state

Performance is effective when:

  • We know what software we have, both licensed application software (mode 1) and SaaS (mode 2) and it is being used (we don’t have any application software or SaaS we don’t know about or aren’t using)
  • Software that is part of a service – we control its configuration in a known good state, and its functionality and service qualities meet what is required for the services by customers and users
  • Software includes not just a UI, but an API and command line interface, so that it can be integrated
  • Software is instrumented for direction and control by the SMS

Knowing what you have (software, licenses, etc.) is step one in understanding and managing your software configuration.

IT-Led service configuration – Software – practices

Best practices for software configuration include:

  • License management
  • SaaS software best practices
  • Cloud cost containment

An example: cloud cost containment.

It is typical now to find in organizations lots of unused seats, e.g., for Office365, that sit unused, or environments that were spun up in, e.g., AWS that nobody turned down. The problem is that the meter is running on this unused capability, and the resources going to waste there are typically sorely needed for things that will add value.

As a result, a new role is emerging in organizations for individuals and teams and technologies and policies that help identify dis-used resources and turn them off, and that make sure the organization has visualization into what is getting stood up and down, and used and not used. A further aspect of this role is identifying, from the services and feature sets and features being firehosed at the organization by vendors, what small subset of them are of high value, and therefore should be socialized within the organization to ensure value uptake. Similarly, for organizations that produce services, features, and feature sets and spew them at their own consumers, there is a need for a function in the provider organization to ensure uptake by consumers, to ensure value is as fully realized as possible.


      1. IT-Led service configuration: Applications

IT-Led service configuration – Applications – definition

Typically, at the time of this writing, most organization have a mix of traditional on-prem and locally running apps on devices and hosted or subscription-based apps.

IT-Led service configuration – Applications – desired states

Performance is effective when:

We have the right mix of Mode 1 / purchased applications that run locally on the client device, and Mode 2 / Software as a Service (SaaS applications) that are cloud- and subscription-based where a supplier hosts applications and makes them available to customers over the Internet

  • For applications, we buy or subscribe to, costs are in control, and we do not have an inordinate amount of purchased or subscribed applications that go unused
  • For applications, we buy or subscribe to, we know without undue effort, what new features sets and features are high value, and make sure they are taken up in the organization; for applications we make, we enable our consumers to do the same

Uptake for realization of value is a top concern for both providers of apps and their consumers. Regardless of what functionality an app has, no value is realized if the functionality goes unused. As the pace of feature introduction increases dramatically with Agile and DevOps approaches, ensuring uptake because a key need and skill in provider and consumer organizations.

IT-Led service configuration – Applications – practices

Best practices include:

  • Application Lifecycle Management (ALM)
  • Microservices architecture
  • Software configuration management

      1. IT-Led service configuration: Data

IT-Led service configuration – Data – definition

IT-Led service configuration – Data – desired state

Performance is effective when:

  • Automation

IT-Led service configuration – Data – practices

Best practices include:

  • SaaS data integration
  • Tenancy patterns
  • Sharding
  • Microservices
  • REST

An example: Sharding.

Sharding is a type of database partitioning that separates very large databases the into smaller, faster, more easily managed parts called data shards, where a shard means a smaller part of a whole.


      1. IT-Led service configuration: Platform

IT-Led service configuration – Platform – definition

Source: https://stackoverflow.com/questions/16820336/what-is-saas-paas-and-iaas-with-examples

In Mode 2, PaaS (Platform as a Service), the platforms are cloud- and subscription-based where a supplier hosts the platform and makes it available to customers over the Internet, e.g., AWS Elastic Beanstalk, Windows Azure, Heroku, Force.com, Google App Engine, Apache Stratos.

The platform is the runtime environment for software.

IT-Led service configuration – Platform – desired state

Performance is effective when:

The platform compares well across the following criteria categories:

  1. Characteristics – characteristics (i.e. on-demand self-service, resource pooling, rapid elasticity, and measured service)
  2. Dimensions – how widely the solution can be shared (i.e. private, public, community), who is responsible for environment management (i.e. internal, external), and where the platform is located (i.e. on-prem, outsourced)
  3. Production ready – platform suitability for enterprise, mission critical use
  4. Development activities and lifecycle phases – Measures how to design, build, deploy, and manage applications and services (e.g., with DevOps practices: continuous integration / delivery, automated release, incremental testing)
  5. Architecture – principles, concepts, and patterns enable applications to dynamically execute parallel workloads across a distributed environment
  6. Platform services – how fully the platform satisfies development of complex applications with comprehensive application middleware components, services
  7. Programming model – programming languages and frameworks, which facilitates building applications and services exhibiting the right characteristics

Source: https://wso2.com/wso2_resources/wso2-whitepaper-selecting-a-cloud-platform.pdf

The typical environment at the time of this writing is a hybrid of traditional IT and cloud, so a mix of both kinds of platforms are in evidence.

IT-Led service configuration – Platform – practices

Best practices include:

  • PaaS
  • Cloud
  • PaaS security

An example: PaaS security. The PaaS security link above cites what a PaaS service should be able to do:

  • Scan and analyze mobile applications.
  • Scan web apps on the internet or private networks.
  • Perform static analysis to scan source code for security vulnerabilities.
  • Employ single sign-on capabilities.
  • Drain logs over the syslog, syslog-tls or HTTPS, including all the events related to the application.
  • Distinguish logs from different instances of the same application.
  • Encrypt data at rest.
  • Facilitate secure communication between the application and database instance.

Discover sensitive data and stored procedures for masking sensitive data.


      1. IT-Led service configuration: Runtime

IT-Led service configuration – Runtime – definition

https://techterms.com/definition/rte

https://www.pcmag.com/encyclopedia/term/56079/runtime-engine

Software like Adobe Flash Player provides a runtime environment for its associated file format, allowing, in this case, Flash movies to be run within the player software.

IT-Led service configuration – Runtime – desired state

Performance is effective when:

  • The runtime environment provides an effective means for testing, debugging, and running the application component of a service, including provisions like crash dumps, step execution, and logging and monitoring.

Runtime refers to the runtime environment within which the application component of a service executes, e.g., Java RTE.

IT-Led service configuration – Runtime – practices

Best practices include:

  • Runtime environment

This example, while specific to a specific RTE, provide a good checklist that can be adapted for other RTEs.


      1. IT-Led service configuration: Middleware

IT-Led service configuration – Middleware – definition

https://searchmicroservices.techtarget.com/definition/middleware

https://azure.microsoft.com/en-us/overview/what-is-middleware/

Middleware is the basis for integrating separate applications. For a good list of types of middleware, see https://apprenda.com/library/architecture/types-of-middleware.

IT-Led service configuration – Middleware – desired state

Performance is effective when:

  • We don’t have Developers building our production middleware configuration
  • We have put in place in-depth historical middleware and monitoring
  • We have scripted and versioned installation, configuration and deployment

Source: blogs.oracle.com/emeapartnerweblogic/5-best-practices-for-middleware-operations-teams-by-c2b2

Middleware is the software that serves to “glue together” separate, often complex and already existing, programs. Some software components that are frequently connected with middleware include enterprise applications and web services.

IT-Led service configuration – Middleware – practices

Best practices include:

  • Middleware best practices
  • Middleware checklist

Middleware best practices cover provisioning, monitoring, configuration management, compliance, lifecycle management, and information publishing.


      1. IT-Led service configuration: Operating system

IT-Led service configuration – Operating system – definition

https://www.webopedia.com/TERM/O/operating_system.html

Common operating systems include Windows (in a variety of versions), as well as iOS, Android, Macintosh, Chrome OS.

Containerization is OS virtualization in which the kernel allows the existence of multiple isolated user-space instances, called containers.

IT-Led service configuration – Operating system – desired state

Performance is effective when:

We have practices that work well for deploying and securing the OS, cleaning up unnecessary software, keeping OS instances up-to-date with service packs and patches, group policies, security templates, and configuration baselines.

Source: www.continuum.net/blog/6-important-steps-to-harden-your-clients-operating-systemshttps://en.wikipedia.org/wiki/List_of_system_quality_attributes

As you can see, these are basic hygiene practices that, if ignored, can lead to unwarranted overhead, at a minimum, or worse, a major incident or a disaster, because, e.g., you are not keeping your attack surface to a minimum.

IT-Led service configuration – Operating system – practices

Best practices include:

  • OS hardening
  • Programs clean-up
  • Use of service packs
  • Patches and patch management
  • Group policies
  • Security templates
  • Configuration baselines
  • Containerization

https://www.continuum.net/blog/6-important-steps-to-harden-your-clients-operating-systems

Two best practices for operating systems are OS hardening and containerization.


      1. IT-Led service configuration: Infrastructure

IT-Led service configuration – Infrastructure – definition

Adapted from: https://www.gartner.com/it-glossary/infrastructure-as-a-service-iaas

https://stackoverflow.com/questions/16820336/what-is-saas-paas-and-iaas-with-examples

Your infrastructure underpins your platform and the software you run, whether that infrastructure is traditional / on-premise or in the cloud.

IT-Led service configuration – Infrastructure – desired state

Performance is effective when:

  • We have the level of access we need to our infrastructure
  • We know how much modification our software requires to run on it
  • We know who owns the infrastructure we are paying for
  • We are crystal clear on our (if we host) or the vendor’s monitoring and support process
  • We know our (if we host) or our vendor’s backup plan and have made sure it is in the SLA process
  • We understand the cost (if we host) or vendor’s pricing model and how to control usage
  • We have made sure we (if we host) or the vendor can ensure compliance with regulations

Source: https://www.zdnet.com/article/iaas-checklist-best-practices-for-picking-an-iaas-vendor/

Whether you in-source or outsource your infrastructure, and whether it is traditional or cloud infrastructure, you still need to make sure you have visibility into what it is, that it is monitored, backed up, what SLAs apply to it, what it costs, and whether it is in compliance with relevant regulations.

IT-Led service configuration – Infrastructure – practices

Best practices include:

IaaS

Infrastructure-as-cloud

IaaS security

An example: IaaS security. The source reference above indicates the security controls in an effective IaaS program should include the ability to:

Manage data center identities and access.

Authenticate, authorize and manage users.

Secure and isolate virtual machines (VM).

Patch default images for compliance.

Monitor logs on all resources.

Isolate networks.


      1. IT-Led service configuration: Virtualization

IT-Led service configuration – Virtualization – definition

Source: https://www.gartner.com/it-glossary/virtualization/

Top virtualization platforms as of this writing include Vmware vSphere, Microsoft Hyper-V, Citrix XenServer, and Oracle VM.

IT-Led service configuration – Virtualization – desired state

Performance is effective when:

We know the advantages and disadvantages of virtualization

We know the performance bottlenecks of each system role

We don’t over-prioritize management, patching and security of virtual systems

We don’t treat virtual systems differently than physical systems unless necessary

We backup early, backup often

We are careful when using any “undo” technology

We understand our failover and our scale-up strategy

We control virtual machine proliferation

We centralize our storage

We understand our security perimeter

Source: https://technet.microsoft.com/en-us/library/gg131921.aspx

One key thing here is managing VM proliferation—just like physical server sprawl, it is a must to keep on top of what has been spun up and is not dis-used.

IT-Led service configuration – Virtualization – practices

Best practices include:

Virtualization / Hypervisor

    • Tuning
    • Patching
    • Security
    • Backup
    • Failover
    • Scale-up
    • Controlling proliferation
    • Storage centralization
    • Securing the perimeter

Container management and orchestration

Source: adapted from https://searchitoperations.techtarget.com/definition/container-management-software

Container management is handling tasks associated with the administration of individual containerized applications and application components deployed on individual hosts. Applications are packaged into containers for ease of scaling, duplication and upgrading.

Container orchestration is managing multiple containers deployed on multiple hosts, extending lifecycle management capabilities to complex, multi-container workloads deployed on a cluster of machines.


      1. IT-Led service configuration: Server

IT-Led service configuration – Server – definition

Source: Adapted from https://www.techopedia.com/definition/2282/server

For an example of the different kinds of roles a server can take on, see https://technet.microsoft.com/en-us/library/hh831669(v=ws.11).aspx.

IT-Led service configuration – Server – desired state

Performance is effective when:

We know of (and can quickly and easily visualize) each server that we have, and the configuration of each server, to a level of detail that is useful to us

We maintain strict control over server build templates

We relentlessly root out unnecessary server complexity, variation and dependencies

In general, we want to avoid the situation of “snowflake” servers—where servers are unique—to avoid the overhead associated with variation—in term of the time and effort required to sort out the risks of variations and dependencies when we make changes, and the cost associated with mistakes due to missed variation and dependencies.

IT-Led service configuration – Server – practices

Best practices include:

Server Management

#10. Implement a Regular Maintenance Schedule

#9. Automate Everything + Manage by Exception

#8. Run Weekly Windows Updates + Install All Security Patches

#7. REBOOT

#6. Housekeeping

#5. Diskspace, Defrag and Memory

#4. Inventory of Running Software

#3. Stagger Updates

#2. Run During Weekdays

#1. Report Results

Visible Ops-style change control

Continuous delivery

For example, #9. Automate Everything + Manage by Exception: Almost any task that you run at the server console can be automated and scheduled. If you do any maintenance regularly, or at least four times per year, automate it, for two reasons:

  1. Once automated, it is much less prone to human errors. Human errors or oversights are a big reason why maintenance is not performed, or performed incorrectly.
  2. Automated tasks have much better Run Tracking Logs for history and troubleshooting.

Once these maintenance tasks are automated, you can Manage by Exception and only work on failed server upgrades when, for example, a server does not return to service after a reboot.

What you want with servers is what DevOps practitioners refer to as cattle, not pets. The Visible Ops Handbook, and the book by Jez Humble, Continuous Delivery, both discuss the dangers of snowflakes and how to avoid them, the first in the context of a solid basis for effective change control, the latter as a solid basis for an effective build and delivery process.


      1. IT-Led service configuration: Storage

IT-Led service configuration – Storage – definition

Source: Adapted from https://www.techopedia.com/definition/1115/storage

Storage needs to be managing, just as compute and network, and regardless of if that storage is traditional on-premise storage or in the cloud.

IT-Led service configuration – Storage – desired state

Performance is effective when:

We leverage tiered storage

We analyze application workloads and make educated decisions on where to store data

We consolidate storage pools

We implement staged backup to disk

We employ automated storage management tools

https://esj.com/articles/2009/10/27/best-storage-practices.aspx

IT-Led service configuration – Storage – practices

Storage best practices include:

Tiered storage

Workload analysis

Storage pooling

Staged backup

Automated storage management

Cloud storage best practices

According the link above, cloud storage considerations include:

Getting the degree of redundancy right (multi-site redundancy, single-site redundancy (mirroring, etc.) or none)

Automatic fail-over in case of a disk/server/site failure

Versioning capability, not just storage of the most current version of a file or data object, with the right retention period for deleted files, and a flexible retention policy

Data backup, with the right backup cycle and retention policy, and the right time-to-restore data

An easy-to-use management console that is web-based and can be accessed from any location in case of emergency

A pricing structure that fits your business model? For example, some vendors charge for every file access (read, write, etc.) in addition to per-gigabyte upload and download charges. If you are moving large blocks of data those access charges will be minimal. If you are doing primarily database lookups and updates, however, they can add up quickly.


      1. IT-Led service configuration: Network

IT-Led service configuration – Network – definition

Source: Adapted from https://www.techopedia.com/definition/5537/network

Physical and virtual and cloud networking resources must be known and managed to ensure the services they depend on are as they should be.

IT-Led service configuration – Network – desired state

Performance is effective when:

Our network is made up of components that support the level of, e.g., availability, performance, and security our services require

Networks components must meet the levels of availability, performance, and security services require. This is not possible if the components they are comprised of do not. For example, you will never get 5 nines on a 1 nine network, or a network that lacks redundancies in switches, power supplies, and so on.

IT-Led service configuration – Network – practices

Network configuration management practices include:

Administrator Approval for Changes

Auto Discovery

Automated Software Distribution

Automatic Network Mapping

Backup and Restore

Baseline NRA

Bulk Configuration Changes

Change Management

Compliance Audits/Reports

Configuration Archive

Configuration Compare

Configuration Templates

Copy Configuration

Inventory/Asset Management

Multi-vendor Device Support

Network Provisioning

Pre-Provisioning

Real-time Change Notifications

Remote Configuration

Resource Initialization

Resource Shutdown/Startup

Scheduled Backups

Scheduled Configuration Changes

Scheduled Device Shutdown/Startup

Scheduled Tasks

An example: reducing variation in networking equipment is key. For example, if you have several models of routers or switches, all with different defaults, it will be easy to make a mistake when configuring a device initially. Better to make it all “vanilla”, or whatever flavor you like, to avoid the time it takes to sort out differences and the cost of recovering from mistakes made because of variations.


      1. IT-Led service configuration: Hardware

IT-Led service configuration – Hardware – definition

Source: https://www.techopedia.com/definition/2210/hardware-hw

IT-Led service configuration – Hardware – desired state

Performance is effective when:

We know of all the hardware our services depend on, along with its configuration to a level of detail that is useful to us, and this information is visible and readily accessible

We can track what hardware belongs to which service(s), along with any other relationships and attributes that are useful, e.g., what P.O. introduced it, whether it is under warrantee, whether it is a leased or bought asset, etc.

We introduce new hardware and retire hardware at a pace that matches business needs; we proactively retire hardware before it becomes problematic for us

We perform physical maintenance (e.g., changing filters) on an appropriate schedule to avoid issues

Hardware assets require maintenance that virtual assets do not.

IT-Led service configuration – Hardware – practices

Practices include:

Hardware IT asset management

IT asset management and the cloud

The link above on ITAM and the cloud emphasizes a few open questions that highlight the disruption the cloud is causing in IT asset management processes born into and based on a physical, on-prem situation:

Who is responsible? For deploying servers into the Cloud, monitoring costs in the Cloud, managing the “hardware” specification of servers in the Cloud?

And, “How do we control?”, who can deploy services in the Cloud, the level and size of services deployed in the Cloud, and what licenses are used in the Cloud?


      1. IT-Led service configuration: Facilities

IT-Led service configuration – Facilities – definition

With the cloud and IaaS, facilities management becomes the concern of the host vendor, not the consumer. For any on-prem equipment, including wiring closets, data centers, and so on, this is the concern of the provider.

IT-Led service configuration – Facilities – desired state

Performance is effective when:

Our facilities are constructed of components that “add up” to supporting the right levels of availability, recoverability, performance, and so on, that our services require

Our physical equipment is compatible with our applications

We have a fast refresh schedule and detailed roadmap, and a coordinated equipment refresh process

We have experienced local staff and expert support

We have good management and performance tools

https://searchdatacenter.techtarget.com/tip/A-data-center-checklist-for-facility-design-and-IT-ops

Ignore the physical layer at your peril; hardware needs to operate within set tolerances, and therefore needs power conditioning to avoid over and under-voltage conditions, backup power for emergencies, the right air conditioning and air flow to meet equipment requirements for operating temperatures, and sensors and filters and the like to avoid exposing the equipment to things that would harm it, like airborne contaminants, water, and the like.

IT-Led service configuration – Facilities – practices

Practices include:

Configuration management

Facilities management

https://www.facilitiesnet.com/datacenters/article/8-Ways-To-Bring-Down-Data-Centers–17445 cites 8 ways to bring down datacenters:

  1. A standby/emergency generator fails to start when utility power fails for more than a few seconds, or generator transfer switchgear fails to transfer, or the generator fails to run until utility power is restored.
  2. A UPS system randomly fails even though utility power is good, and then fails to successfully transfer to bypass.
  3. A UPS system or batteries fail when utility power fails, and the generator (if available) has not yet started and run up to speed, or during transfer between generator and utility sources.
  4. Circuit breaker nuisance tripping.
  5. Circuit breakers installed in 24/7 live switchgear that have not been recently cycled (opened and closed) or energized (design voltage applied) or tested can be problems waiting to surface at the worst time
  6. Neutral and grounding issues.
  7. Bypass and transfer mechanisms that have not recently been operated, or operated under load, or operated at all (even many years after installation).
  8. Emergency power off (EPO) circuitry for 24/7 live facilities, which have not been recently tested or where validated (trusted) wiring diagrams are not available.


Chapter Section 4.1 Summary

The configuration of a service is one of three things worth managing, next to service functionality and qualities.

There are two types of services, Human-Led and IT-Led; each has within it a set of components for which we must aim to achieve and maintain a desired state through best practices.

Human-Led service configuration consists of people, service IP, service kits, collateral, systems & tools, goods and facilities.

IT-Led services configuration consists of software, platforms, and infrastructure; for mode 1, these can be on-prem and a combination of physical and virtual; for mode 2, these are, “…as a service”—IaaS, SaaS and PaaS.

Service concepts, desired states and practices – Functionality and Qualities (120m)


Chapter Section 4.2: Service Functionality & Qualities concepts, desired states and practices

In this chapter, we’re covering topics that will help you list and describe the functionality and qualities of services, their desired states, and practices for achieving them, e.g.:

04-02-01. Service Functionality

04-02-02. Service Qualities

04-02-03. Human-Led Service qualities

04-02-04. Reliability

04-02-05. Responsiveness

04-02-06. Trustworthiness

04-02-07. Empathy

04-02-08. Attractiveness

04-02-09. IT-Led Service qualities

04-02-10. Availability

04-02-11. Manageability

04-02-12. Serviceability

04-02-13. Performance

04-02-14. Reliability

04-02-15. Recoverability

04-02-16. Discoverability

04-02-17. Trustworthiness

04-02-18. Security

04-02-19. Integrity

04-02-20. Credibility

04-02-21. Compliance

04-02-22. Usability

04-02-23. Internationalization

04-02-24. Accessibility

04-02-25. Adaptability

04-02-26. Interoperability

04-02-27. Scalability

04-02-28. Elasticity

04-02-29. Portability

04-02-30. Extensibility

This is section two of chapter 4. We’re focused here on the functionality (features) and qualities (what Devs call non-functional requirements, or the “-ilities”—availability, capacity and the like).


      1. IT-Led service configuration: Applications

Service functionality – definition

A service is made up of its component parts, its functionality (or features), and its qualities.

For a Human-Led service, you can think of it this way: Let’s say you have a landscaping service. The configuration of the service is all the moving parts—your van, mower, leaf blower, edger, string trimmer, your clipboard, the phone you use to take payment, and so on. The functionality is the feature set of your service—does it include edging? Do you do weeding, or fertilizing, and so on. The qualities are things like how reliable and responsive you are, as judged by your customers

For IT-Led services, components are things like containers, servers, active directory, etc. Let’s say your service was a financial calculator website—a feature might be a removal calculator, a margin calculator, or a mortgage payment calculator. The service qualities would be things like how available your website is (uptime) and how performant it is (fast or slow).

Service functionality – definition

04-02-01. Service Functionality – Definition, desired state, best practices

So, functionality is the set of features of a service, what it does, independent of how well it performs, how available it is, etc.

There are two types of functionality. First, there is what the user sees and uses, the user functionality. Next, there is the telemetry functionality—the features you bolt on to a service so that you can direct and control it, through whatever service management system it is that you have, for example, if you have a landscaping company, several crews out doing work on a given day, what do you have in place to tell if a crew has a client cancel on them and is available for work so you can re-direct them to another job? If you have a financial calculator website, what have you put in place to tell you if the site is performing slowly, or has an extraordinary number of concurrent users on it, and so on?

Remember, functionality is features, what a service does, and qualities are how a service behaves, like how available it is, how performant it is, and so on. You can also think of service qualities as all service characteristics that are not features or functionality.

Service functionality – desired state

Performance is effective when:

Our services have the user features required by customers and users; where this is not the case, we move quickly and transparently to make it so, or to reset customer and user expectations and perceptions for the service functionality.

Our services have the telemetry needed to direct and control them.

Our services meet the minimally agreed to feature and viability requirements, operates within the principles, governance, and security boundaries of the organization, and are built and maintained by the revenue stream that needs the service, and are constantly evolving using automated testing and delivery techniques, with feature list and prioritization based on direct end-user feedback.

04-02-01. Service Functionality – Definition, desired state, best practices

Both end user functionality, and management functionality (telemetry) are required for a manageable service that is consistently valuable to stakeholders.

Service functionality – practices

Agile requirements modeling

Epics, stories, versions, and sprints

04-02-01. Service Functionality – Definition, desired state, best practices

Whatever the method used, it’s important that the outcome is that customers and users get functionality they value quickly, and with quality.


Chapter Section 4.2.1. Summary

  • The functionality (features, what it does) of a service is one of three things worth managing, next to the service’s configuration (component parts / what it is made of) and its qualities (how it behaves)
  • There are two types of services, Human-Led and IT-Led; each has within it a set of features for which we must aim to achieve and maintain a desired state through best practices
  • A critical part of a service’s functionality is its telemetry embedded for direction and control by the service management system (SMS)

      1. Service Qualities definition, desired states, practices

Service qualities – overall definition

Figure 04-02-02.1 Human-Led & IT-Led Service qualities

In contrast to a service’s functionality, or features, that is, what it does, service qualities are how a service behaves.

As you can see in the figure, both Human-Led and IT-Led services have system qualities, just as they have features.

The Human-Led service quality taxonomy in OSM are adapted from the SERVQUAL model, which is commonly applied to Human-Led services. The IT-Led service quality taxonomy is adapted from the Open Group’s taxonomy of non-functional requirements.

Each of these will be defined in turn as we move through this chapter.

Human-Led and IT-Led services: six modes of human/technology interaction

Five modes regarding the role of technology in customer contact. Adapted from: Froehle and Roth, 2004, p. 3.

Figure 04-02-02.2 Five modes regarding the role of technology in customer contact. Adapted from: Froehle and Roth, 2004, p. 3.

Froehle and Roth identify five modes of human and technology interaction.

  1. Technology-free customer contact, e.g., the face-to-face contact between a psychological therapist and patient. This type of contact does not require the use of technology; thus, it is the most traditional and direct mode of customer contact.
  2. Technology-assisted customer contact, e.g., hotel check-in and check-out procedures, transactions conducted over manned bank counters, and passenger check-ins for airline boarding. In these, technology (i.e., a computer) is used by the service personnel only. However, the customer and service personnel still experience face-to-face contact.
  3. Technology-facilitated customer contact, e.g., the use of Microsoft PowerPoint by a financial expert to present and discuss financial plans with customers during a conference. Although technology is used by both parties, face-to-face customer contact still occurs.
  4. Technology-mediated customer contact, e.g., telephonic interaction between service personnel and customers and the provision of professional advice by a consulting company using Videoconference technology. In these contexts, a shared technological platform is used by the service personnel and the customer without face-to-face contact.
  5. Technology-generated customer contact, e.g., ATM withdrawals, online shopping. In these, customers operate the technology without the assistance of service personnel, and face-to-screen contact replaces face-to-face customer contact. We add a 6th one here, Human-free, where technology represents both the provider and the consumer of the service, as in EDI.

The point here is that services run on a continuum from technology-free to technology generated; Human-Led services begin at the left-hand side of this continuum, up to the point where technology is the primary means of representing the service; IT-Led services start on the right, up to the point where humans are the primary means of representing the service.

Service qualities – overall desired state

Performance is effective when:

  • The service qualities required by customers and users are present in the service; where this is not the case, we move quickly and transparently to make it so, or to reset customer and user expectations and perceptions for the service qualities.

Service qualities have a technical aspect and a qualitative aspect. For example, a service might, for accessibility, be ADA compliant, technically speaking. However, the customer and user are the judge of whether the system is accessible.

Service qualities – overall best practices

Service Level Management

Non-functional requirement framework

Non-functional requirements specifications

Non-function requirements checklist

IT-Led service qualities adapted from: https://publications.opengroup.org/w098

You should notice two major differences here between OSM and traditional ITSM guidance.

The first is that OSM covers Human-Led services, and their non-functional characteristics or qualities, where traditional ITSM guidance does not.

The second is that the list of non-functional requirements (what traditional ITSM guidance calls, “warranty” aspects) is much longer in OSM. Traditional ITSM guidance typically focused on operational qualities, things that went in an SLA, e.g., availability, performance (or capacity), IT service continuity (or disaster recovery), security, and supplier details.

As you can see, OSM’s list of service qualities greatly expands the list to include a “shift-left” to the non-functional qualities developers care about, such as accessibility.

OSM’s list of IT-Led service quality characteristics are adapted from the TOGAF taxonomy of service qualities.


Chapter Section 4.2.3: Human-Led Service Qualities concepts, desired states and practices


      1. Human-Led Service Qualities definition, desired states, practices

Human-Led service qualities – definition

Human-Led services run the gamut from:

  1. Technology-free customer contact, e.g., the face-to-face contact between a psychological therapist and patient. This type of contact does not require the use of technology; thus, it is the most traditional and direct mode of customer contact.
  2. Technology-assisted customer contact, e.g., hotel check-in and check-out procedures, transactions conducted over manned bank counters, and passenger check-ins for airline boarding. During these, technology (i.e., a computer) is used by the service personnel only. However, the customer and service personnel still experience face-to-face contact.
  3. Technology-facilitated customer contact, e.g., the use of Microsoft PowerPoint by a financial expert to present and discuss financial plans with customers during a conference. Although technology is used by both parties, face-to-face customer contact still occurs.

Human-Led service qualities – definition

Examples of Human-Led services

Moves, adds and changes

New hire setup

Legal hold

Consulting

Auditing

Source: Human-Led service qualities in OSM® are adapted from SERVQUAL

Human-Led services are provided primarily by humans, possibly with the assistance of technology, but where the human-to-human interaction is the primary driver. Contrast this with IT-Led Services, where services are provided primary by technology, possibly with the assistance of humans, but where technology-to-technology or technology to human interaction is the primary driver. Human-Led service qualities in OSM are adapted from SERVQUAL.

Key questions for Human-Led service qualities include:

People—the individuals and teams that deliver the service—how reliable and responsive are they? Are they dressed appropriately for what they’re doing, from the perspective of customers and users?

Service IP, kits, collateral—the knowledge and materials teams rely on to deliver services–for example, if you are running workshops as part of the service, are the materials attractive and well-organized, or do you have a lot of bad graphics and spelling errors in them?

Systems & Tools—for example, process mapping software for a process engineering engagement—is the tool easy to use for the facilitator and the customer, or is it clunky and error-prone?

Goods—for services where goods are involved, e.g., installing a new physical monitor—is your packaging for goods neat and complete, or do goods show up dented or broken or in the wrong place because of shoddy addressing?

Facilities—is your service location neat, organized, appealing, or shoddy / off-putting?

Human-Led service quality – desired state

Performance is effective when:

Stakeholders see us and our services as reliable, responsive, trustworthy, empathetic, and attractive

People—the individuals and teams that deliver the service, have the knowledge, skills and mindset required

Service IP, kits, collateral—the knowledge and materials teams rely on to deliver services—is up to date and easy to location

Systems & Tools—for example, a process template for a process engineering engagement—exist and are good enough to ensure successful delivery

Goods—for services with goods involved, e.g., installing a new physical monitor—we manage inventory to meet demand

Facilities—are physically appealing, and strongly support the conduct of the service

Source: https://en.wikipedia.org/wiki/SERVQUAL

“Attractive” as used here does not mean that all our people are supermodels, that all our facilities are slick, etc. It means at a minimum that they are not off-putting, and are suitable for the purposes of the service and its stakeholders. For example, there is one standard of dress you might expect a dollar store employee to have, and quite another for say, a Nordstrom salesperson. And if the dollar store fixtures were too expensive-looking, you might wonder what you’re getting for your dollar—similarly, if the fixtures in a Nordstrom’s were shoddy or cheap looking, you might be wondering if the t-shirt you’re buying is worth $30.

Human-Led service quality – practices

Valerie Zeithaml and Mary Jo Bitner created the most widely used and accepted model for professional service quality, in 5 dimensions:

Figure 04-02-03.1 Human-Led service qualities; Source: Adapted from SERVQUAL

Valerie Zeithaml and Mary Jo Bitner created the most widely used and accepted model for professional service quality, in 5 dimensions shown here. OSM adopts and adapts this model, renaming “Assurance” trustworthiness, and “Tangibles” attractiveness.

As you can see, Human-Led service qualities are in some cases the same (reliability, responsiveness, trustworthiness, and attractiveness) as many of the qualities we seek in an IT-Led services. If for example, you are using an online banking service, you’ll want it to be reliable, responsive, trustworthy, and attractive enough. And while an online banking service can’t necessarily exhibit empathy per se, the empathy of its designers for you as the customer or user should shine through in its design.

Human-Led service quality – practices

SERVQUAL Valerie Zeithaml and Mary Jo Bitner

The Nordstrom Way

How to Buy/Sell Services HBR

People (David Maister)

Facilities Micah Solomon

An example: Anything by David Maister is great advice for managing Human-Led services. While most of it is pointed towards consulting firms, the advice is sound and impactful nonetheless. Here are two classics:

  • Maister, David H. Managing the Professional Service Firm. (New York: Free Press, 1993.) Maister is a former Harvard Business School professor and is currently a consultant to the world’s top professional firms. He is recognized as the foremost expert in professional service firm management and this is the first comprehensive text on the managerial problems of professional firms. Maister explores a wide range of topics including marketing, staffing, service quality, and personal development. The book is full of insightful and practical advice.
  • Maister, David H. True Professionalism: The Courage to Care About Your People, Your Clients, and Your Career. (New York: Free Press, 1997.) In this follow-on to Managing the Professional Service Firm, Maister discusses his definition of “true professionalism”–a personal commitment to self-betterment and a dedication to providing excellence and efficiency in client service. He also strongly emphasizes the importance of ethical behavior as the primary means to commercial success. Maister examines these subjects at both the individual level and the firm level and includes excellent recommendations.

Another worth of mention is, Wittreich, Warren J. “How to Buy/Sell Professional Services.” (Harvard Business Review, March-April 1966.) The author explores the complexity of buying and selling professional services and provides guidance to both buyers and sellers. Among Wittreich’s key ideas are that the selling and rendering of a service can seldom be separated and that most of the “sale” occurs in delivering on the initial promise made when the engagement was initiated.


      1. Human-Led service quality: Reliability

Human-Led service quality – Reliability – definition

Source: Adapted from SERVQUAL

Your Human-Led services have the quality of being reliable to the extent that customers and users perceive them as being so; this perception comes from either a demonstrated capacity to do so, or through a track record of doing so, in either case directly or by a trusted reference.

Human-Led service quality – Reliability – desired state

Performance is effective when:

We commit to deliver something by a certain time and follow through on that commitment, both in terms of what is delivered, and when

We perform services right the first time

Service providers provide the service at the time they commit to doing so

Service providers keep error-free records

The service we provide is consistently as it should be, regardless of variable such as the time of day it is delivered, or by what person or team

Adapted from: https://www.ermt.net/docs/papers/Volume_6/1_January2017/V6N1-132.pdf and www.ec.tuwien.ac.at/~dorn/Courses/SDMC/RATER%20Questionnaire.pdf

One good way to think about what your customers and users look for in the qualities of your services is to think through some good and bad service experiences you have had, and to write down what was good and bad about them, then ask yourself, “how would my customers and users say my services compare along these lines?”

Human-Led service qualities – Reliability – practices

SERVQUAL Valerie Zeithaml and Mary Jo Bitner

How to Buy/Sell Services HBR

Trusted Advisor (David Maister)

The 7 Habits of Highly Effective People

TSIA

Being a more reliable professional

Being reliable is about being true to your word, confronting mistakes, making sure service is done right the first time, and ultimately, consistently under-promising and over-delivering.

The key ingredient here is a service mindset and an understanding of how to execute on it. Some things that help include:

Scheduling systems

Committing to wait time

Record keeping and review, and

Performance reviews

David Maister’s book, The Trusted Advisor, is an excellent reference, as is Stephen Covey’s 7 Habits of Highly Effective People. While the first focuses on consulting firms and the latter on individual behaviors, the advice in both cases applies very much to organizations as providers of services.


      1. Human-Led service quality: Responsiveness

Human-Led service quality – Responsiveness – definition

Source: Adapted from SERVQUAL

Customers and users see our Human-Led services as responsive when we do things like getting back to them quickly when they make a request, and providing prompt service.

Human-Led service quality – Responsiveness – desired state

Performance is effective when:

We get back to customers and user quickly, acknowledging them when they make a request

We tell customers and users up front, exactly when services will be executed

We fulfill services to customers and user’s stakeholders promptly

When there is an issue with our service, we handle that promptly, too

We are always willing to provide prompt service and answer customer and user questions

We are never too busy to respond to stakeholder requests

Public situations are treated with care and seriousness

Customers and users find it easy to talk to a knowledgeable service member when they have a request or issue

Customers and users find it easy to reach the right service provider in person, by telephone, or email or chat, or by whatever channel we have provided and that they find convenient

Customers and users say that service access points for our services are conveniently located

Adapted from: https://www.ermt.net/docs/papers/Volume_6/1_January2017/V6N1-132.pdf and www.ec.tuwien.ac.at/~dorn/Courses/SDMC/RATER%20Questionnaire.pdf

When you look at this list, you should see that good performance here needs to be underpinned by things like:

Good tools, for example, for scheduling

Good processes and procedures, e.g., for exception handling

Well-trained service personnel, with the right skills, knowledge and mindset

The right service culture and rewards

The right services in the first place, and the right mechanisms for setting expectations and perceptions

Human-Led service quality – Responsiveness – practices

Hire the right people in the first place

Moments of Truth

SERVQUAL Valerie Zeithaml and Mary Jo Bitner

The Nordstrom Way

People (David Maister)

When you look at this list, you should see that good performance here needs to be underpinned by things like:

The right, well-trained service personnel, with the right skills, knowledge and mindset

Good tools, for example, for scheduling

Good processes and procedures, e.g., for exception handling

The right service culture and rewards

The right services in the first place, and the right mechanisms for setting expectations and perceptions

The first item on this list is most important. Everything starts and ends with hiring the right people in the first place. In practice, other than by parents, instilling a service mindset in a person who just doesn’t have that mindset is an exercise in futility.

Another key element is making sure you are focusing on making “moments of truth” shine—Jan Carlzon’s book is the classic on such matters, and is a cornerstone book in the birth of service management. While later iterations of traditional ITSM guidance features some over-pivot on process reengineering, it is refreshing to recall the roots of service management, lightweight, agile, and focused on people and individual interactions, and making them better.


      1. Human-Led service quality: Trustworthiness

Human-Led service quality – Trustworthiness – definition

  • Typically achieved through knowledge and courtesy of employees

Source: Adapted from SERVQUAL

As a consumer, you use many services. You get haircuts, you use a mobile phone service, and so on. How can you trust that you’ll get what you’re paying for, that the results will be satisfactory?

If it’s the first time you’re getting you haircut at a place, you’d look for evidence that it’s the place for you, that they’ll do a good job. For example, you’ll check out how people walking out look—how’s their hair? If it’s not good, you’ll move on and find another place. You might also ask a friend for a referral. So, in new-to-you situations, you’ll look for evidence or trustworthiness.

If you’ve been using a service for a while, trust is built through repeated delivery on commitments—in this case, a long track record of good haircuts. Should personnel or other factors change, results might change, and trust might be broken after a bad result.

So, flip this situation around and apply it to how you assure trust in your services.

Human-Led service quality – Trustworthiness – desired state

Performance is effective when:

Our behavior instills confidence in customers and users, so they feel safe in transactions with us, and with our premises and equipment, and they see us as courteous and competent

We have, and demonstrate that we have, the skills, knowledge and mindset to do the service well and address customer / user needs

Materials we provide with the service are appropriate / up-to-date

Customers and users say we use technology to perform the service quickly and skillfully and appear to know what we are doing and that they are confident that we have and will perform services correctly

We have a good reputation with customers and users

We do not pressure customers and users

We respond accurately and consistently to customer / user inquiries

We guarantee our services

We store customer and user documents, records and other data secure from unauthorized use

Adapted from: https://www.ermt.net/docs/papers/Volume_6/1_January2017/V6N1-132.pdf andwww.ec.tuwien.ac.at/~dorn/Courses/SDMC/RATER%20Questionnaire.pdf

Some things that contribute to these desired states:

Communications, especially keeping confidentiality

Soft-skills training (courteousness)

Knowledge/skills/technical training

Material review and updated regularly

Guarantee policies

Safety ensured

Security

Record keeping

Human-Led service quality – Trustworthiness – practices

SERVQUAL Valerie Zeithaml and Mary Jo Bitner

People (David Maister)

Trusted Advisor (David Maister)

The 7 Habits of Highly Effective People

David Maister’s book, The Trusted Advisor, is an excellent reference, as is Stephen Covey’s 7 Habits of Highly Effective People. While the first focuses on consulting firms and the latter on individual behaviors, the advice in both cases applies very much to organizations as providers of services.

Other practices that can contribute to trustworthiness as a service provider include:

Staff training: trusted advisor skills, service provision skills, knowledge and mindset—consistent across staff

Safety and security for transactions, data, premises, and equipment

Mechanisms to ensure service materials are appropriate and current

Demonstration of competence, e.g., displaying of certifications, endorsements


      1. Human-Led service quality: Empathy

Human-Led service quality – Empathy – definition

Source: Adapted from SERVQUAL

Think about service situations you’ve had recently—maybe it was rescheduling a flight with an airline, perhaps working with a bank on an online banking issues for your checking account. Or maybe you had an appliance break down and you were calling the manufacturer.

Did you feel the person on the other end of the phone or chat was just going through the motions, or were they really trying to listen and understand what your situation was, and what you needed? In other words, was their posture, “I am here to help you with your problem”?

Now flip that around for the services you provide. What do your customers and users think of you? Do you know if they find you empathetic? You may be good to go, or you may have some work to do in this area—the first step is knowing their perceptions and expectations.

Human-Led service quality – Empathy – desired state

Performance is effective when:

We give customers / users individualized attention, convenient hours

Customers and users say we have their best interest at heart and work to understand their specific needs and objectives

We recognize each regular customer / user and address them by name

Our level and cost of service is consistent with what customers and users need and can afford

We are polite, respectful, considerate and friendly, with a pleasant demeanor, and refrain from acting busy or being rude, and respond politely and with consideration when customers / users ask questions

We listen to customer and users and show understanding and concern

We can explain clearly various options available to a query

We avoid using technical jargon when speaking with customers / users

We contact customers / users if we will miss a scheduled appointment

Adapted from: https://www.ermt.net/docs/papers/Volume_6/1_January2017/V6N1-132.pdf and www.ec.tuwien.ac.at/~dorn/Courses/SDMC/RATER%20Questionnaire.pdf

Empathy can be summed up as the feeling that the service provider has the attitude, “I am here to help you with your request or issue”. It’s about listening, and social and customer service skills as much as anything else. The opposite of an empathetic person is one who give off the attitude, “I am here to demonstrate my technical skills—bow down, you’re not worthy!”.

As with other Human-Led service qualities, it’s important to understand how the quality of empathy is perceived by your customers and users—it’s not what you think that counts.

Human-Led service quality – Empathy – practices

SERVQUAL Valerie Zeithaml and Mary Jo Bitner

The Nordstrom Way

Developing Empathy

The 7 Habits of Highly Effective People

https://www.mindtools.com/pages/article/EmpathyatWork.htm

You can avoid a lot of hassles with services staff by hiring people with a service orientation in the first place. Yes, they must have technical skills to succeed, but without an attitude of, “I am here to help you with your request or issue”, all will be lost.

Some people contend that you can train people into a service mindset. This may be so, but often it seems that the only ones that can do that is a person’s parents. By the time they get to the workplace, it may be an intractable situation for some people, so it’s best to hire for a service skill and mindset from the start.

The 7 Habits, especially, “see first to understand, then to be understood”, are an excellent place to start in developing empathy.

Some other ways to developing or showing empathy include:

Training for customer service skills, knowledge and mindset, including other-centered listening and communication skills

Using customers’ and users’ names when dealing with them

Acting on, or forwarding along for action, customer and user feedback


      1. Human-Led service quality: Attractiveness

Human-Led service qualities – Attractiveness – definition

Source: Adapted from SERVQUAL

Think about the last time you were put off by some aspect of the appearance of a service provider. Maybe you were in a restaurant and the windows and tabletops and restrooms were dirty looking. Maybe you were at a mobile phone shop and the store looked out of date, shopworn, with some broken shelves, chipped paint here and there, and boxes and merchandise kind of messily lying about. Or maybe it was the person helping you—she had pizza stains on her shirt, or was disheveled in her appearance.

These may seem like little things, but they can add up quickly to a customer or user going “tilt”, so it’s important to pay attention to them.

So, flip this around and think about this for your services. If you provide deskside support, are your personnel neatly dressed, or are they the crew that can’t show up with an unwrinkled shirt, or can’t keep their pants tucked in? If you provide, for example, concierge repair and update services for client devices at a physical location, how does it look? You may be good to go, or you may have some work to do. Be honest, and make sure you’re ship shape.

Human-Led service quality – Attractiveness – desired state

Performance is effective when:

The tangible aspects of our services—what customers and users can see and touch—are pleasing to customers and users

Customers and users find our materials associated with the service (pamphlets or statements) visually pleasing and easy to understand

Customers and user find appearance of service providers pleasing; we dress appropriately and have good hygiene

Customers and users find our physical facilities / fixtures pleasing

Customers and users say our technology/equipment looks modern

Adapted from: https://www.ermt.net/docs/papers/Volume_6/1_January2017/V6N1-132.pdf and www.ec.tuwien.ac.at/~dorn/Courses/SDMC/RATER%20Questionnaire.pdf

So, when asked, what do customers and users say about the tangible aspects of our services? Do they see them as appealing? Off-putting? We need to know, or we risk losing customers and users, or at least losing points with customer and user satisfaction.

Human-Led service quality – Attractiveness – practices

SERVQUAL Valerie Zeithaml and Mary Jo Bitner

The Nordstrom Way

Facilities Micah Solomon

The Nordstrom Way

Customer Experience Management (CXM)

User Experience Management (UXM)

Micah Solomon’s writing on retail facilities are a good place to start on understanding the impact of the tangible on customer and user perceptions.

Think about a time where you were super-pleased with a service encounter in a physical space—what made it great?

Now think of another encounter where you were not happy—what made it lousy for you?

Lastly, think about your services and their tangible aspects. How do they compare against these two scenarios?

You may have this covered, or you may have some work to do.

Attention needs to be paid here to:

Physical facilities and fixtures

Product and material appearance, layout and organization

Staff appearance—dress and hygiene

Technology appearance

CXM, an emerging field for IT-Led systems, and UXM, are in some ways the parallel best practices for attractiveness in Human-Led systems, and can be food for thought for the physical experience.


Chapter Section 4.2.9: IT-Led Service Qualities concepts, desired states and practices


      1. IT-Led Service Qualities definition, desired states, practices

IT-Led service quality – definition

Figure 04-02-09.1 IT-Led service qualities

IT-Led service qualities include:

Availability

Manageability

Serviceability

Performance

Reliability

Recoverability

Discoverability

Trustworthiness

Security

Integrity

Credibility

Compliance

Usability

Internationalization

Accessibility

Adaptability

Interoperability

Scalability

Elasticity

Portability

Extensibility

While this is a long list, it is by no means comprehensive or final. IT-Led service qualities are basically any non-functional characteristic of a service.

IT-Led service quality – desired state

Performance is effective when:

Customers and users and other stakeholder (e.g., those concerned with governance / regulatory compliance, or accessibility, or security, or internationalization, disaster recovery, and so on), say our services have the right set of qualities, including availability, manageability, serviceability, performance, reliability, recoverability, discoverability, trustworthiness, security, integrity, credibility, compliance, usability, internationalization, accessibility, adaptability, interoperability, scalability, elasticity, portability, and extensibility)

When you look at this list of qualities, you should see a number that pop out as important to customers and users.

The same goes for the provider.

Suppliers, also, are stakeholders in this, for the IT-Led services they provide and contribute to.

And besides the four primary stakeholders of service management—customers, users, the provider, and supplier—there are others that have a stake in these qualities. Those that own regulatory compliance will be concerned about ensuring compliance with, e.g., PCI, Sox, Basel 2, and SAS 70, or whatever regulations are pertinent. Those that own security will want to make sure the services are secure. And those concerned with uptake of the service will want to make sure perhaps that it is 401 compliant for accessibility, or supports French, Dutch, Spanish, etc. where those languages are needed.

IT-Led service quality – practices

Service Leve Management

Service Level / Operational Level Agreements

Underpinning Contracts

Non-functional requirements

Two additional sources of best practice are:

https://dalbanger.wordpress.com/2014/01/08/a-basic-non-functional-requirements-checklist/, and

carrotschool.com/blog/the-definitive-non-functional-requirements-checklist


      1. IT-Led service quality: Availability

IT-Led service quality – Availability – definition

  • Reliability & Maintainability – see definitions here https://www.iso.org/obp/ui/#iso:std:iso-iec:2382:-14:ed-2:v1:en
  • Reliability measured by MTBF; maintainability by MTTR

Source: ISO/IEC 20000-1:2011(E) 3 Terms and definitions

Availability is percentage of time within the agreed or committed window a service is up. It’s made up of reliability, which is the “keep it up and running part”, as measured by meant time between failures or MTBF, and maintainability, an engineering term that means the ease with which a service which has failed can be returned to working order, which is measured by mean time to repair, or MTTR.

It’s important to note that availability is the quality related to NORMAL operating conditions, e.g., it’s a regular Tuesday here at XYZ corporation, whereas Recoverability is the quality related to the ABNORMAL situation of being out of business—and regaining availability of services in priority order to get back into business. While measures taken for the one can benefit the other, and vice versa, they are two distinct domains and qualities of services.

IT-Led service quality – Availability – desired state

Performance is effective when:

  • We ensure availability of services in normal business operations by designing and managing services to keep them up and running. Should they go down, get them up quickly within specified service levels and costs
  • We develop services for the required levels of availability in the first place, with some “wiggle room” so that we can consistently hit targets; this includes design for reliability (keep thing up and running, measured by MTBF), maintainability (if they go down, get them up quick, measured by MTTR)
  • Services provide us with easily accessible, accurate data on their availability
  • We work to take measures and choose platforms that provide the levels of automated failover and recovery our stakeholders need; to the extent possible on the platforms we are on, we automate failover and recovery

Design for both reliability and maintainability are required to promote the right levels of availability; one or the other does not cut it. Some IT service provider shops are very engineering oriented towards reliability, and stumble when things go down because they don’t usually go down. Others are good at getting things back up and running, because they have a lot of practice, because the engineering for reliability just isn’t there. Balance is needed here.

IT-Led service quality – Availability – practices

  • Design for reliability – Building Dependable Systems
  • Design for maintainability Michael Tortorella
  • Cloud reliability – Simian Army / Antifragility
  • Cloud maintainability
  • Availability management
  • Availability levels
  • Public status pages / transparent uptime
  • Incident Command System (ICS)
  • Kepner Tregoe problem analysis

For reliability, even though it’s ancient (1994), the Digital Equipment Corporation publication, “Building Dependable Systems” remains a very clear and well written guide that can be applied to any service.

A key part of availability is getting availability levels right, because each involve a price / performance tradeoff. These levels include:

  • High availability. The service is available during specified operating hours with no unplanned outages.
  • Continuous operations. The service is available 24 hours a day, 7 days a week, with no scheduled outages.
  • Continuous availability. The service is available 24 hours a day, 7 days a week, with no planned or unplanned outages, for example, like amazon.com.

Public status pages are a great way to build confidence in you “skin in the game” on availability.

And while it’s really a way of handling major incidents, ICS deserves mention here because of it’s potential for reducing MTTR in reactive situations. The same goes for KT analysis.


      1. IT-Led service quality: Manageability

IT-Led service quality – Manageability – definition

  • Manageability is largely a function of the quality and extent of service instrumentation, telemetry and logging, and automation for remedial action.

Source: www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Instrumentation refers to an ability to monitor or measure the level of a service’s performance, to diagnose errors and to write trace information. Developers implement instrumentation in the form of code instructions that monitor specific components in a service (for example, instructions may output logging information to appear on screen). When a service contains instrumentation code, it can be managed using a management tool. Instrumentation is necessary to review the performance of the service. Source: adapted from https://en.wikipedia.org/wiki/Instrumentation_(computer_programming)

Telemetry is a term for technologies that accommodate collecting information in the form of measurements or statistical data, and forward it to IT systems in a remote location. This term can be used about many different types of systems, such as wireless systems using radio, ultrasonic or infrared technologies, or some types of systems operating over telephone or computer networks. Others may use different strategies like SMS messaging. Source: https://www.techopedia.com/definition/14853/telemetry

IT-Led service quality – Manageability – desired state

Performance is effective when:

  • We can easily and automatically gather information on the state of all things worth managing—stakeholders, services, and the SMS—compare it to desired states, and act where there is a gap
  • We generally don’t have gaps in manageability, but when we do, we close them quickly and permanently

Manageability must be designed for and continuously improved for it to be effective for services. Instrumentation, telemetry, and logging and monitoring functionality don’t just appear out of nowhere—a proper health model should ship with a service, as part of the design.

IT-Led service quality – Manageability – practices

  • Making it manageable fuel Palo Alto
  • Instrumentation / Telemetry
  • Monitoring
  • Cloud Monitoring / Telemetry
  • Logging / Instrumentation
  • Logging cheat sheet
  • Event management

While event management / service monitoring and control are part of the service management system, they are joined at the hip with the quality of manageability, so they are mentioned here. In the end, manageability is about putting hooks into services so they can be monitored and controlled.


      1. IT-Led service quality: Serviceability

IT-Led service quality – Serviceability – definition

  • Services are serviceable to the extent that, in a repair, maintenance, or restocking situations, what to do, where, and how and so on is readily apprehended and easily reached

Source: www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

https://en.wikipedia.org/wiki/Serviceability_(computer)

One difference between OSM and traditional ITSM guidance should be clear here. Traditional ITSM guidance uses the term, “serviceability” in a way that is out of step with the industry, attaching it to a supplier’s contribution to the uptime or downtime of a service or one of its components. The typical definition, which is taken up here by the Open Group, is basically—how easy is it to service?

IT-Led service quality – Serviceability – desired state

Performance is effective when:

  • Our services are designed to help identify problems and take corrective action, such as to repair or upgrade to a service or one of its components
  • In repair, maintenance, and restocking situations, what to do, where, and how and so on is readily apprehended and easily reached

www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

For example, if I am to work on an office printer / copier / scanner with a tray feeding system, how hard or easy is it to clear jams, to figure out which tray is what, and so on, while trying to service the unit? How hard or easy is maintenance, or to replenish the paper or toner? Is it ready to hand? That is the quality of being serviceable. It requires design for serviceability, as it’s much harder and costlier to try to “bolt it on” later.

IT-Led service quality – Serviceability – practices

  • Design for serviceability NDP
  • Design for serviceability Guy Carafone
  • Design for supportability

NDP lists he key design for serviceability guidelines as:

  • Simplification
  • Standardization
  • Access
  • Ergonomics
  • Safety
  • Disconnecting/Reconnecting
  • Unfastening/Refastening
  • Part Handling
  • Location and Insertion, and
  • Mistake-Proofing

      1. IT-Led service quality: Performance

IT-Led service quality – Performance – definition

Performance, or throughput, is a function of capacity, of, e.g., storage, compute, and network.

Traditional ITSM guidance focuses on capacity, which is a means to the end; the end is performance. OSM focuses on performance.

IT-Led service quality – Performance – desired state

Performance is effective when:

  • Performance meets committed rates for our services
  • We ensure capacity matches demand at the right time and at the right cost by seeking to understand current and future demand and capacity, and delivering the right resources, at the right time and at the right cost. We understand and influence demand, and avoid excess and insufficient capacity and associated costs and service impact.
  • We design services for required performance levels up front, with “wiggle room” so we consistently hit targets; this includes design and automation for elasticity—scaling to meet demand, and with easily accessible, accurate performance data
  • When we size services, we factor in consumers’ patterns of business activity where possible

This article https://en.wikipedia.org/wiki/Computer_performance does a good job of laying out aspects of performance for computers that can apply also to networks, virtual machines, etc.

IT-Led service quality – Performance – practices

  • Capacity management

  • Demand management
  • Load balancing
  • Network performance management
  • Database performance management SQL
  • Autoscale scale up/down in/out
  • Elasticity

There are many more areas of performance management, this is just a sampling. Some other practices to enhance performance include:

  • Automation
  • Trend analysis
  • Tuning
  • Influencing demand (e.g., by differential charging)
  • Workload analysis
  • Performance analysis / benchmarking

      1. IT-Led service quality: Reliability

IT-Led service quality – Reliability – definition

Source: Adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Reliability is the extent to which a service stays up and running, and is measure by mean time between failures (MTBF).

IT-Led service quality – Reliability – desired state

Performance is effective when:

Generally, services don’t fail, because of how we plan, build, deploy, test and release them

Should services fail, we find out why and harden the service(s) so failure does not re-occur

As with many similar qualities, reliability must be designed into a service up front, and continually improved, in this case to support service objectives or commitments for uptime.

IT-Led service quality – Reliability – practices

  • Design for reliability – Building Dependable Systems
  • Design for reliability – DFR including FMEA
  • Fault tree analysis
  • Cloud reliability – Simian Army / Antifragility
  • Availability management
  • Availability levels’
  • Server hardening

Many techniques are available for designing more reliable systems, including Failure Modes and Effect Analysis (FMEA) is a step-by-step approach for identifying all possible ways, or modes, in which a service might fail, and the effects of each failure, as a basis for prioritizing hardening activities.


      1. IT-Led service quality: Recoverability

IT-Led service quality – Recoverability – definition

Source: adapted from opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Recoverability requires a restore point—something to rely on to go back to a known good state. It could be, for example, that you’re using immutable deployment, where all components are “vanilla”, and you simply replace rather than repair or change to restore a known good state. Or, for example, you could use a VM baseline image and apply a snapshot to restore it to what it looked like when the snapshot was taken.

Ensuring you have a good restore point for key components of services should start in design. At what interval will you snapshot? Will you simply record basic information with which you can recreate a component, or a full image? These decisions belong in design. Without them, you’ll be left with a need to restore and no way to get back to that known, good, state.

IT-Led service quality – Recoverability – desired state

Performance is effective when:

  • We design for recoverability
  • We capture known good recovery points for our services and their components, at an interval, and with a technique suitable for restoring services and their component to a known good state in a timely fashion, e.g., through backups, baselines, snapshots, records and code through which known good states can be restored, and redundant failover equipment, etc.
  • We test our recovery capability for services thoroughly enough and at a frequent enough interval, and make improvements based on those tests, such that we are confident in the ability to recover quickly and completely should failures occur

Good recovery capability requires design up front, ongoing execution of restore point captures, including deltas, and frequent and thorough enough testing and improvement to ensure recovery capability is sufficient.

IT-Led service quality – Recoverability – practices

  • Availability Management
  • Backup and recovery
  • Backups (website)
  • Backups (VMs, Hyper-V)

The general idea here is to capture points you can restore to, in a format that restores the service or component in a timely enough fashion for the situation at hand.


      1. IT-Led service quality: Discoverability

IT-Led service quality – Discoverability – definition

Source: adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm 04-

Services need to be locatable when needed. This is key in service-oriented architecture, where an instance goes away, and is replaced by another in a recovery or scaling situation.

IT-Led service quality – Discoverability – desired state

Performance is effective when:

  • Services can be easily located when needed

In a relatively static system, discovery can almost be an afterthought. But in a dynamic environment, as in today’s cloud platforms, it is an essential part of locating changing components that provide the same functionality, as they are needed.

IT-Led service quality – Discoverability – practices

  • Service Discovery (microservices architecture)
  • Service Discovery (and dependency injection)
  • Service Discovery (REST API)
  • Service Discovery (service oriented architecture)

Service discovery allow us to not have to know up front, in a static way, where the services that do functions x, y, and z that they depend on are located up front; such a static mapping would create an unnecessary dependency, and quickly breaks down in a dynamic environment.


      1. IT-Led service quality: Trustworthiness

IT-Led service quality – Trustworthiness – definition

Another aspect of trustworthiness is availability, which is one of the three primary tenets of information security, and in this context, means that information assets are available to those that are authorized to use them, that is, there is no denial of service to authorized users.

IT-Led service quality – Trustworthiness – desired state

Performance is effective when:

  • Services and their data can be and have been tested continuously to demonstrate that they have required levels of:
  • Security: information assets are protected from unauthorized access
  • Integrity: assurance that information assets have not been corrupted
  • Credibility: the level of trust in the integrity of the information assets is high
  • Compliance: it is compliant with all relevant regulatory requirement

See whatis.techtarget.com/definition/Confidentiality-integrity-and-availability-CIA for a good discussion of the CIA triad, or the three primary tenets of information security.

IT-Led service quality – Trustworthiness – practices

  • Trustworthy computing
  • Trustworthy cloud computing

Services and their data can be and have been tested continuously to demonstrate that they have required levels of:

  • Security: information assets are protected from unauthorized access
  • Integrity: assurance that information assets have not been corrupted
  • Credibility: the level of trust in the integrity of the information assets is high
  • Compliance: it is compliant with all relevant regulatory requirements

      1. IT-Led service quality: Security

IT-Led service quality – Security – definition

IT-Led service quality – Security – desired state

Performance is effective when:

We align IT security with business security and ensure security is effectively managed in all service and Service activities and provide a focus for all IT security issues and activities.

We design services that ensure the confidentiality, integrity, and availability of assets, information, data, and IT services

Access to services and the service management system are provided only to authorized users

We monitory security and automate security contingencies where possible and useful for faster response to security situations

Security must be agile to keep up with the number and variety of threats and vulnerabilities in IT today.

IT-Led service quality – Security – practices

  • Information Security Management
  • Three primary tenets of information security—confidentiality, integrity, and availability (CIA)
  • Identify management
  • Security policies
  • Security controls
  • Security and penetration testing
  • Security, governance, validation
  • Security automation

The three primary tenets of information security are confidentiality, integrity, and availability (CIA):

  1. Confidentiality – information is available to only those with a right to it, and kept private from those who do not have a right to it
  2. Integrity – information is complete, accurate and free from unauthorized modification
  3. Availability – information can be accessed by those with a right to it when required (there is no denial of service)

      1. IT-Led service quality: Integrity

IT-Led service quality – Integrity – definition

Source: www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Integrity is the quality of information assets, in this case, the data associated with services, where it is assured to be complete, accurate and free from unauthorized modification.

IT-Led service quality – Integrity – desired state

Performance is effective when:

  • We can continuously demonstrate that services and their data have not been corrupted
  • Data is typically not corrupted; in the rare event that it becomes corrupted, we are okay, because we have taken precautions and can restore to a known good state; we also learn how it became corrupted and take steps to learn and improve so that the corruption does not reoccur

Services and their data can become corrupted through:

  • Power-related issues
  • Improper shutdowns / dismounts
  • Hardware issues
  • Software issues
  • Transmission issues
  • Faulty updates, and
  • Hacking, including data breaches caused by malware, viruses or malicious internal or external attacks.

IT-Led service quality – Integrity – practices

  • Admin, physical, and technical security
  • Data integrity

Services and their data can be protected from corruption through:

  • Power conditioning and backup
  • Proper shutdowns / dismounts
  • Hardware, software and transmission assurance
  • Integrity checks after updates, and
  • Mitigations and contingencies against malware, viruses or malicious internal or external attacks.

      1. IT-Led service quality: Credibility

IT-Led service quality – Credibility – definition

Source: www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

IT-Led service quality – Credibility – desired state

Performance is effective when:

  • Stakeholders have a well-founded trust in the level of integrity of services and their data, because we take a proactive approach of demonstrating trustworthy data, and provide evidence of our activities and results of doing so

Credibility is the ability to ensure the level of trust in the integrity of the service and its data.

IT-Led service quality – Credibility – practices

  • Data integrity

See https://www.fda.gov/downloads/drugs/guidancecomplianceregulatoryinformation/guidances/ucm495891.pdf for an example of data integrity guidance.


      1. IT-Led service quality: Compliance

IT-Led service quality – Compliance – definition

Common regulations for compliance, for example in data centers include:

  • HIPPA
  • PCI DSS
  • SAS 70
  • SSAE
  • SOC 1/2/3
  • EU-U.S. Privacy Shield

Governance, Risk and Compliance, or GRC for short, refers to a company’s coordinated strategy for managing the broad issues of corporate governance, enterprise risk management (ERM) and corporate compliance regarding regulatory requirements. Source: https://www.webopedia.com/TERM/G/grc-governance-risk-compliance.html

IT-Led service quality – Compliance – desired state

Performance is effective when:

  • Services conform to all applicable legislative and regulatory requirements
  • We are good at determining the cost of compliance for stakeholders, services, and the SMS, including money and resources, and advocating for those costs, and building them in to our services and SMS
  • We work proactively to have efficient and effective compliance, to reduce the cost and effort to maintain compliance
  • Stakeholders, services, and the SMS are all in compliance with policies and laws, e.g., software licenses

Governance – The effective, ethical management of a company by its executives and managerial levels.

Risk – The ability to effectively and cost-efficiently mitigate risks that can hinder an organization’s operations or ability to remain competitive in its market.

Compliance – A company’s conformance with regulatory requirements for business operations, data retention and other business practices

Source: https://www.webopedia.com/TERM/G/grc-governance-risk-compliance.html

IT-Led service quality – Compliance – practices

  • Governance, Risk and Compliance (GRC)

ISACA, with their product, COBIT, is an excellent source of information on GRC.


      1. IT-Led service quality: Usability

IT-Led service quality – Usability – definition

Source: Adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Services can run the gamut from “one size fits all”, to supporting multiple languages, to supporting people with low or no vision, or hearing, and so on.

IT-Led service quality – Usability – desired state

Performance is effective when:

  • All users indicate our services and the service management system are easy to operate
  • Are services meeting regulatory requirements and the needs of our users, including multi-language capability and the capability to support, for example, users with low or no vision or hearing.

See https://www.ada.gov/pcatoolkit/chap5toolkit.htm for some examples of ADA compliant websites.

IT-Led service quality – Usability – practices

  • User Experience (UX)
  • Usability (website)
  • Usability (mobile app)
  • Internationalization and localization
  • Accessibility (website)
  • Accessibility (mobile app)

Internationalization and localization includes support for different languages, but also currencies, VAT, and so on.


      1. IT-Led service quality: Internationalization

IT-Led service quality – Internationalization – definition

Source: Adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Here’s a good list of multi-cultural considerations – www.webanddesigners.com/multicultural-web-design/. It includes things like data and time formats, time zones, languages, currency, and colors with cultural significance to avoid or use.

IT-Led service quality – Internationalization – desired state

Performance is effective when:

  • For the services and service management system components that require it, support for multi-lingual and multi-cultural requirements is available in our services and the SMS, and stakeholders are pleased with its qualities

Obviously, if you do not have a presence, say, in Canada or the UK, you may not have to be concerned with these issues. But if you plan such growth, better to set your systems up (and choose platforms) that support it, then to have to later retool to do so—it can be very painful.

IT-Led service quality – Internationalization – practices

  • Internationalization and localization (website)
  • Internationalization and localization (mobile apps)

Internationalization is the quality of being easily adaptable for multiple languages, regions and cultures, through things like using Unicode character sets, using text labels that can be translated instead of text embedded in graphics, leaving space in layouts for different languages, avoiding local jargon or colloquialisms in written text, using or avoiding colors, etc. with specific cultural meaning, accommodating different time and date layouts and time zones, as well as different currencies, and so forth.

Localization is the process of adapting a service to a language, region or culture.


      1. IT-Led service quality: Accessibility

IT-Led service quality – Accessibility – definition

Source: Adapted from en.wikipedia.org/wiki/Computer_accessibility

Access to services for the impaired can be facilitate through specialized hardware and software, but services and their components must have the quality of accessibility to support that access.

For example, if a person with low vision has a screen reader device, the service or its components must support use of such device. So, for example, PDF files can be read with a screen reader, but if the PDF files don’t’ have transcripts for videos, or text labels behind graphics and buttons, a low vision person cannot “see” this information—in other words, for this scenario, the system lacks the quality of accessibility.

IT-Led service quality – Accessibility – desired state

Performance is effective when:

  • For the services and service management system components that require it, support for accessibility is available in our services as required by customer and user needs and applicable standards and regulations, including, where applicable, support for specialized hardware and software for accessibility, and support for access by users with disabilities, such as visual, hearing, physical or cognitive impairments, for example, color blindness or Dyslexia.

For internationalization and accessibility, as well as for things like security and compliance, there are a lot of considerations. Often, the levels of expertise required in just one of these areas are well beyond what some individuals and businesses have or can afford in-house. That is another reason why SaaS, PaaS and IaaS offerings have grown in popularity—they have the wherewithal to build things like compliance and internationalization into their offerings, so you don’t have to keep up on the latest requirements and needs and capabilities, you just need to use the capabilities of the offering.

IT-Led service quality – Accessibility – practices

  • ADA compliance (for websites)
  • ADA compliance (for mobile apps)
  • ADA compliance (for software)
  • Specialized HW/SW for accessibility

There is even a browser extension that helps color blind persons better see the web; see https://www.pcworld.com/article/2919980/this-chrome-extension-helps-color-blind-users-see-the-web.html


      1. IT-Led service quality: Adaptability

IT-Led service quality – Adaptability – definition

Source: Adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

One key criteria for DevOps tool chains is that they have an API and a command line interface, and not just a UI, so you can string them together into something that adds value, sometimes in high-value, unanticipated ways, as in ChatOps. So, tools that are UI-only could be said to have low adaptability, and those with an API and command line interface, high adaptability.

IT-Led service quality – Adaptability – desired state

Performance is effective when:

  • It is not impossible or hard to adapt services or the service management system over time and as circumstances change
  • Our services and SMS have the right level of adaptability, including interoperability, scalability, portability, extensibility, and the ability to accept new functionality, and the ability to offer access to services in new paradigms, such as ChatOps and microservices architecture.

Adaptability is a matter of degree, and the right balance that is cost-effective. Some platforms and systems are inherently more interoperable, scalable, portable, and extensible than others, and we should look to these qualities when we evaluate what goes into our service components and into our tool chains.

IT-Led service quality – Adaptability – practices

  • API and CL interface, not just UI
  • ChatOps

https://docs.stackstorm.com/chatops/chatops.html defines ChatOps as bringing work that is already happening in the background today into a common chatroom. By doing this, you are unifying the communication about what work should get done with the actual history of the work being done (both manually and through automation, including timestamps). Things like deploying code from Chat, viewing graphs from a TSDB or logging tool, or creating new Jira tickets…these are examples of tasks that can be done via ChatOps. Besides enhancing collaboration, ChatOps provides a timestamped record of who did what, when, useful as input to blameless postmortems.


      1. IT-Led service quality: Interoperability

IT-Led service quality – Interoperability – definition

Source: Adapted from https://en.wikipedia.org/wiki/Interoperability

Systems that have the quality of being interoperable can be strung together to add more value. So, for example, a CRM system may integrate with a system that provides data on businesses, so that contact information, and other vital statistics for each system are auto populated into CRM.

IT-Led service quality – Interoperability – desired state

Performance is effective when:

  • It is possible and easy for all services and SMS components to communicate, exchange data, and work with all other services and SMS components, to the extent that it is useful and cost-effective to have this capability, without any special effort required to do so.

One key thing about interoperability is that if a system has it as a quality, it requires no special effort to integrate it with another compatible system. So, for example, google Chrome extensions just snap right into the browser, boom, you’re done. You plug an HDMI cable into an HDMI port, and it just works, no special effort.

Often, interoperability is supported by standards like TCP/IP, HTML, and so on, as well as hardware interface standards.

IT-Led service quality – Interoperability – practices

  • Achieving interoperability

According to https://en.wikipedia.org/wiki/Interoperability#Achieving_software_interoperability, software interoperability can be achieved in five ways:

  1. Product testing
  2. Product engineering
  3. Industry/community partnership
  4. Common technology and IP, and
  5. Standard implementation

      1. IT-Led service quality: Scalability

IT-Led service quality – Scalability – definition

Source: adapted from: www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

IT-Led service quality – Scalability – desired state

Performance is effective when:

  • Our services (and the service management system) can scale up / down and out / in, as needed, at a rate of speed and cost that meets our needs, in proportion to the demands placed on them by the environment within which they operate, and to the extent that the level of scalability is cost-effective.

The ability to grow or shrink in capacity or performance appropriately in proportion to demands of the environment in which it operates

Source: adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

IT-Led service quality – Scalability – practices

  • Scale up / down, or scale out / in
  • Elasticity and scaling differences (cloud)
  • Scaling (cloud)

Scaling can be vertical (up and down) or horizontal (in or out).


      1. IT-Led service quality: Elasticity

IT-Led service quality – Elasticity – definition

Source: Adapted from en.wikipedia.org/wiki/Elasticity_(cloud_computing)

https://www.stratoscale.com/blog/cloud/difference-between-elasticity-and-scalability-in-cloud-computing/ points out that scalability and elasticity are not the same, as scalability can be accomplished by simply over-provisioning resources statically. In elasticity, we scale dynamically, up and down, through automation, so that capacity meets demand.

IT-Led service quality – Elasticity – desired state

Performance is effective when:

  • Services (and the SMS) can adapt automatically to workload changes by provisioning and de-provisioning resources in an autonomic manner, such that at each point in time available resources match current demand as closely as possible.

https://en.wikipedia.org/wiki/Elasticity_(cloud_computing) provides an example of elasticity, as follows: say a service provider wants to run a website on an IaaS cloud. At moment, the website is unpopular and a single machine (most commonly a virtual machine) is sufficient to serve all web users. Suddenly, the website becomes popular, for example, because of a flash crowd, and a single machine is no longer sufficient to serve all users. Based on the number of web users simultaneously accessing the website and the resource requirements of the web server, it might be that ten machines are needed. An elastic system should immediately detect this condition and provision nine additional machines from the cloud, to serve all web users responsively. Now let’s say the website becomes unpopular again. The ten machines that are currently allocated to the website are mostly idle and a single machine would be sufficient to serve the few users who are accessing the website. An elastic system should immediately detect this condition and deprovision nine machines and release them to the cloud.

IT-Led service quality – Elasticity – practices

  • Auto scaling AWS
  • Auto scaling Azure

Autoscaling is the process of dynamically allocating resources to match demand to meet performance requirements.


      1. IT-Led service quality: Portability

IT-Led service quality – Portability – definition

Source: Adapted from www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

For example, software that is portable could be moved from one machine platform to another, say, a VM that could move from Hyper-V to a Vmware environment and vice versa.

IT-Led service quality – Portability – desired state

Performance is effective when:

  • Services and their components and the SMS and its components can be moved or copied from one environment to another, including data, people, applications and components, without inordinate time or special effort being required

Portability can also be due to using a standard format, as when a .JPEG file can be sent to and viewed on say, a Windows or Mac device, or an iOS or Android phone.

IT-Led service quality – Portability – practices

  • Portability (Software)
  • Portability (Cloud)
  • Portability (Mobile Apps)
  • Portability (VMs and Containers)

The quality of portability can apply, in a greater or lesser degree, to all elements that make up a service, for software, to cloud resources, to mobile apps, VMs, and containers.


      1. IT-Led service quality: Extensibility

IT-Led service quality – Extensibility – definition

Source: www.opengroup.org/public/arch/p3/trm/tx/tx_quals.htm

Extensibility is different from scalability; scalability means a service has the quality of being able to accommodate growth (with elasticity, this scaling can be automated); generally, when you scale, the unit you scale with is uniform, e.g., you are scaling storage, compute, network, or some other uniform resource.

In contrast, extensibility means you can add something new to the system, something that is not “more of the same”, so it doesn’t have to be growth-related. For example, you might extend a CRM system by adding a component that auto-populates Hoovers information into the records for each customer and prospect.

IT-Led service quality – Extensibility – desired state

Performance is effective when:

  • Services and their components (and the SMS and its components) can accept new functionality without inordinate time and special effort being required to do so.

Some services and their components lend themselves to extension, some do not. Those that do have the quality of extensibility.

IT-Led service quality – Extensibility – practices

  • Extensibility (GitHub)
  • Extensibility (XML)

Some language development packages allow for extensibility, but it’s difficult to understand and implement, so this is yet another factor to consider in choosing a development environment.


Chapter 4 Summary

Chapter summary

  • Service qualities are the “-ilities” that are how a service behaves, what developers refer to as the non-functional requirements of the service (versus service configuration which is what components a service is made up of, and service features which are what a service does)
  • Both Human-Led and IT-Led services have qualities

    • OSM®’s list of Human-Led service quality characteristics is adopted from Valerie Zeithaml and Mary Jo Bitner’s SERVQUAL
    • OSM®’s list of IT-Led qualities is adapted from the TOGAF taxonomy of service qualities
  • Each of these service qualities has a desired state that, for relevant qualities for a service, must be achieved and maintained continuously over time and through changing circumstances to ensure value is continuous

Chapter 5

Service Management System (SMS) concepts, desired states and practices (300m)

What is a service management system? What does it look like when it is in its desired state? What are some best practices for getting it there, and keeping it there? We’ll cover that here in this chapter.

OSM® Foundation Course Agenda

Chapter Objectives

Service management system – overall definition

The service management system or SMS may sound fancy, but it’s basically whatever mechanisms you have in place to direct and control services so that they achieve and sustainably maintain the desired state of providing value for stakeholders.

Generally, such mechanisms can be said to fall into four groups of related activities:

  1. Design & transition – where we figure out what to add, change, or retire—either entire services, features, or feature sets, based on our strategy and what we have learned, especially about changes in stakeholder needs and opportunities and what new technology makes possible.
  2. Promotional activities—activities that create uptake of our services, features set and features.
  3. Support – whatever we do to capture and resolve the issues and to fulfill the requests of stakeholders
  4. Delivery – the business operations functions of administering services, Provisioning, metering & billing, budgeting for, and accounting for services.

Service management system – overall desired state

Performance is effective when:

  • We continuously and sustainably provide value to stakeholders through services, over time and changing customer and user needs and technology capabilities
  • We are achieving and maintaining the desired state for all things worth managing—stakeholders, value flow, services, and the SMS itself
  • We continuously improve all aspects of our SMS capabilities, e.g., management, organization, practices, people (skills, knowledge, mindset) policies, objectives, procedures, tools, documents, and resources
  • We continuously improve how we to direct and control services, including how services are planned, designed, developed, implemented, deployed, delivered, monitored, measured, reviewed, maintained, and improved

There are some key differences between the SMS as specified in ISO 20000-1 and the guidance contained in OSM, just as there are key difference between ISO’s conception of the SMS and traditional ITSM guidance. Some key differences are:

  1. ISO emphasizes management’s responsibility; OSM positions the outcomes of service management as everyone’s job—individuals, teams, and the organization as whole.
  2. ISO positions the components of the SMS as processes; OSM positions them as “things worth managing” with desired states to be achieved and maintained; the difference is between a focus on ends (outcomes, or desired states) and means (a process is a potential means).
  3. ISO categories by design, delivery, relationship, resolution and control processes; OSM breaks it down into Design & transition, promote, support, and delivery things worth managing with outcomes or desired states.
  4. Value flows from the provider to the customer through services as controlled by the SMS in ISO; OSM is similar, except value flows multi-directionally from and to providers and suppliers, customers and users.

Service management system – overall best practices

Design & transition

  • Strategy & GRC
  • Learning & improvement
  • Development
  • Release & deployment
  • Change & configuration
  • Uptake

Promotion

  • Marketing
  • Advertising

Support

  • Event handling
  • Incident handling
  • Major incident & disaster handling
  • Problem handling
  • Request handling

Delivery

Stakeholder relations

Administration

Provisioning, metering & billing

Budgeting & accounting

Chapter 5:

As you can see in the figure, a service management system can be broken down into Design & transition, promotion, support, and delivery. OSM handles these a bit differently than traditional ITSM frameworks, which position these as sequential phases and processes.

In OSM, these are going on simultaneously, not sequentially. In other words, while of course there is sequence in workflow, it is not helpful to, for example, put incident handling in one “phase” because “that’s where it first becomes important”.

OSM position these elements not as “processes”, but as “things worth managing”—in other words, each represents a key outcome or desired state that we want to achieve and maintain. The focus here is on ends, not means, as we know that a process is just one means to achieve an outcome, and that a broken process (or a focus on process without attention to other enablers), can disable as well as enable sustained achievement of desired outcomes.

Further, in OSM, we seek to focus on outcomes, as opposed to activities, as this is more lightweight, and suited to today’s environment and agile practices.


Chapter 5: Service Management System (SMS) Concepts, Desired States and Practices


Introduction 5.1: SMS concepts, desired states and practices


      1. SMS definition, desired states, practices

Chapter 5

Chapter Section 1

SMS – Design & transition (90m)

05-02-01. SMS – Design & transition

05-02-02. Strategy & GRC

05-02-03. Learning & improvement

05-02-04. Development

05-02-05. Release & deployment

05-02-06. Change & configuration

In this section, we cover the Design & transition group of activities of the SMS.


Chapter Section 5.2: SMS Design & transition concepts, desired states and practices


      1. SMS Design & transition overall definition, desired state, practices

SMS – Design & transition – definition

In this section, we cover the Design & transition group of activities of the SMS.

Recall that the purpose of your SMS is to direct and control services so the continuously deliver value to stakeholders, sustainably, over time and through changing circumstances.

This will not happen if you don’t have the right strategy for services in the first place, aligned gyroscopically to changes in what stakeholders value and what new technology makes possible, including ensuring they meet any regulatory compliance requirements. This is the strategic learning and improvement loop of the SMS, Strategy & GRC.

Strategy and designs need to be fed through learning loops, and in a dynamic environment, continual improvement is necessary to ensure all things worth managing are as they should be, and if not, are moving gyroscopically towards that desired state—this is the operational and tactical feedback loop of the SMS, Learning & improvement.

The SMS activity group of Development is just what is sounds like—the planning and building of new or changed services, feature sets, and features, qualities (such as availability), and service configuration components, e.g., infrastructure for the service.

Release & deployment is the set of activities within the Design & transition activity group that ensures a quick and quality introduction of new or changed services, features, features sets, qualities, and configuration components. Release & deployment also includes activities for the removal of the same.

Change & configuration is the set of activities that ensures any changes to services are done quickly, with quality, that “what changed?” can be tracked, and that at any time, we have ready visualization everything that constitutes the services we manage.

SMS – Design & transition – desired state

Performance is effective when:

  • We have the right services, over time and as stakeholder value and technology possibilities change, because we have strategic feedback loops that we use to gyroscopically align our services, features, qualities and configuration to what is valued, over time and through changes in stakeholder needs and technology possibilities
  • We have smooth, unencumbered, automated value
  • flow in our Release & deployment and change &
  • configuration activities, because we all continuously
  • work towards fast time-to-value, with quality and
  • continuous improvement

Recall that the purpose of your SMS is to direct and control services so the continuously deliver value to stakeholders, sustainably, over time and through changing circumstances.

This will not happen if you don’t have the right strategy for services in the first place, aligned gyroscopically to changes in what stakeholders value and what new technology makes possible, including ensuring they meet any regulatory compliance requirements. This is the strategic learning and improvement loop of the SMS, Strategy & GRC.

Strategy and designs need to be fed through learning loops, and in a dynamic environment, continual improvement is necessary to ensure all things worth managing are as they should be, and if not, are moving gyroscopically towards that desired state—this is the operational and tactical feedback loop of the SMS, Learning & improvement.

The SMS activity group of Development is just what is sounds like—the planning and building of new or changed services, feature sets, and features, qualities (such as availability), and service configuration components, e.g., infrastructure for the service.

Release & deployment is the set of activities within the Design & transition activity group that ensures a quick and quality introduction of new or changed services, features, features sets, qualities, and configuration components. Release & deployment also includes activities for the removal of the same.

Change and configuration is the set of activities that ensures any changes to services are done quickly, with quality, that “what changed?” can be tracked, and that at any time, we have ready visualization everything that constitutes the services we manage.

SMS – Design & transition – practices

M1

  • Business Relationship Management
  • Strategy Management
  • Service Portfolio Management
  • Knowledge Management
  • Continual Improvement
  • Release and Deployment Management
  • Change Management
  • (Production) Configuration Management

M2

  • The Three Ways (feedback loops)
  • Sprint Planning, Sprint Review
  • CAMS
  • Blameless postmortems
  • Governance, Risk and Compliance
  • Visible Ops-Style Change Control
  • Pets versus Cattle
  • Immutable Deployment
  • Infrastructure Automation
  • Site Reliability Engineering
  • Continuous Integration
  • Continuous Delivery
  • Continuous Deployment
  • Blue/green deployment

Traditional ITSM guidance somehow leaves out GRC as a process, and positions BRM, strategy, and portfolio management as processes in a strategy phase.

OSM combines strategy and GRC into one “thing worth managing”, because both are “north star” considerations that should inform all planning and decisions and actions in organizations.


      1. SMS Design & transition: Strategy & GRC definition, desired state, practices

SMS – Design & transition – Strategy & GRC – definition

Strategy cannot be decided in a vacuum, it must be informed by constraints; chief among these are governance, risk and compliance considerations.

SMS – Design & transition – Strategy & GRC – desired state

Performance is effective when:

  • We have the right strategy at any given time, which is adjusted continually as stakeholder needs and technology possibilities change, and that strategy is in action in our organization; the strategy includes a strategy for stakeholders: how to keep them in a desired state; for services: which services to offer, and to whom, and which to add, change, or decommission, as well as a strategy for the SMS: for what we need to add, change, or decommission to properly direct and control services
  • Our stakeholders, services, and service management
  • system follows all applicable regulatory
  • and legislative requirements, as well as internal standards
  • and policies; we have the right set of effective policies,
  • controls and required documentation in place to maintain
  • a state of compliance, including regulatory compliance,
  • standards, and security policies

      1. SMS Design & transition: Learning & improvement

Strategy is the practice of defining key objective and a direction, allocating resources to pursuing that direction, and putting mechanisms in place to guide the achievement of key objectives. GRC is made up of 1) Governance, which describes the leadership, decision-making structure, processes, and accountability that determine how an organization gets work done, 2) Risk, which is helping to achieve objectives by managing risk through internal controls, and 3) Compliance, or ensuring conformance with company policies, governmental regulations, and industry-specific laws.

SMS – Design & transition – Strategy & GRC – practices

M1

  • Business Relationship Management
  • Strategy Management
  • Service Portfolio Management

M2

  • The Three Ways (feedback loops)
  • Sprint Planning, Sprint Review
  • CAMS
  • Governance, Risk and Compliance

With the M2 SMS, you’ll need to put in place more, faster, and tighter feedback loops between BRM, strategy, knowledge management, continual improvement and sprint planning and reviews than in traditional ITSM. You should expect shorter roadmaps, and for the typical unit of work to shift from entire services to feature sets and individual features, and for the whole thing to happen much faster. A core part of strategy will also have to be figuring out what you will do to ensure uptake of new features and feature sets, so that value is realized by consumers; as you ratchet up the pace of deployment, it becomes more difficult for consumers to take up what you are putting down—you’ll need a strategy to ensure they do.

You’ll also need to integrate GRC in with strategy, which was missing in some traditional ITSM models. As for change control, for Visible Ops-style is recommended. There is a shift-left in configuration management, from managing the logical picture of your configuration, to managing the scripts and templates that create it. Immutable deployment and blue/green deployment have a profound effect on release and change, as do continuous integration, deployment, and delivery.

SMS – Design & transition – Learning & improvement – definition

Learning & improvement is the set of practices roughly analogous to traditional ITSM’s service strategy and continual service improvement phases; OSM combines strategy, compliance and improvement into one set of practices for the following reasons:

  • Both consider the same topic: give our situation, constraints (including regulatory) and scarce resources, where should we invest?
  • As the cadence for introducing new services and SMS components and changes and improvements to them increases, as it tends to in more modern IT environments, the utility of separating out this work into two phases decreases, and in fact, the separation may become a blocker

OSM concentrates the Learning & improvement mechanisms that traditional ITSM separates out by process into the Learning & improvement component of the service management system.

SMS – Design & transition – Learning & improvement – desired state

Performance is effective when:

  • We are continually learning about and improving aspects of stakeholders, services (both IT-Led and Human-Led, including their configuration, functionality and qualities), and the SMS, taking changing stakeholder needs and new technology possibilities into account
  • Stakeholders can freely share and access knowledge when it is needed; Because of this, we make better quality decisions and can move faster with less risk
  • We review all services, at least annually, after major changes, and three months after the introduction of a new service, and reflect the health of the service and improvement actions back to stakeholders

Other indicators of effective performance include:

  • We work to understanding of patterns of business activity and forecast demand and build those understandings into the service improvements we make
  • We have built effective and efficient mechanisms and feedback loops into our practices, services, and service management system that result in the right actions being taken at the right pace and in the right order to ensure we have the right mix of services, by helping us decide which services and SMS components to add, change, or remove, and that those services and the SMS components are of higher value than alternatives to stakeholders as business circumstances change and new technologies create new possibilities
  • We have a continuously evolving vision for what we want to be as a provider, and that vision aligns with stakeholder values, and our portfolio of services aligns with that vision, and where it does not, we have a strategy and action to close the gap by adding, changing, or retiring services and service management system components
  • Improvements to services and the SMS are continual, and at the right pace and priority, given available resources
  • We have the right set of services in the first place, and where that is not the case, we are working quickly to close the gap by adding, modifying, or removing services, features, quality, and pricing models
  • We are continuously aware of how our services stack up against alternatives in terms of price, features, and quality, and where we are not, we move quickly to close the gap; based on this knowledge, we are acting to close the gap in differentiation by adding, modifying, or removing services, features, quality, and pricing models

SMS – Design & transition – Learning & improvement – practices

M1

  • Knowledge Management

  • Continual Improvement
  • Plan-Do-Check-Act (PDCA)
  • CSFs and KPIs
  • Service reviews
  • Post-implementation reviews
  • Trend analysis

M2

  • The Three Ways (feedback loops)
  • Sprint Planning, Sprint Review
  • CAMS
  • Blameless postmortems

The Deming cycle, is also known as the PDCA or plan-do-check-act cycle.

Conduct blameless postmortems, e.g., after a major incident, problem, disaster, or failed change or release.


      1. SMS Design & transition: Development

SMS – Design & transition – Development – definition

So, you can see from this definition that development’s scope in OSM is not just applications, but stakeholder mechanisms, services (including their configuration, functionality, and qualities), and the SMS.

SMS – Design & transition – Development – desired state

Performance is effective when:

  • We develop stakeholder mechanisms, and the SMS, and not just services; when we develop services, we get the configuration, functionality, and qualities right
  • We continuously listen and improve what and how we Design & transition, with more, faster, and tighter feedback loops between stakeholders, demand and capacity and financial data, strategy & GRC, knowledge management, continual improvement and sprint planning and reviews, shorter roadmaps, and smaller work packages
  • We automate and provide self-service for development resources and activities well, for faster time-to-value with quality from our build pipeline

There are of course many aspects to development, more than can be incorporated within this space and within the scope of a service management foundation course. Having said this, it’s important to note what we are developing—not just services, but stakeholder mechanisms and the SMS; that we have a “smaller + faster = better” approach, with a focus on automation and self-service in the build pipeline.

SMS – Design & transition – Development – practices

M1

  • Design Coordination
  • Service Catalog Management
  • Service Level Management
  • Capacity Management
  • Availability Management
  • IT Service Continuity Management
  • Information Security Management
  • Supplier Management

M2

  • The Three Ways (feedback loops)
  • Sprint Planning, Sprint Review
  • CAMS
  • Blameless postmortems
  • Infrastructure Automation
  • Site Reliability Engineering
  • Continuous Integration
  • Continuous Delivery
  • Continuous Deployment
  • Lean and Agile Practices
  • Application Lifecycle Management
  • Test-Driven Development
  • User Stories

Some definitions:

Continuous Delivery

Automated implementation of the application build, deploy, test and release processes meant to ensure performance (fast delivery) and conformance (to requirements), enabling users to start using new functionality and qualities quickly to realize value and provide feedback sooner.

Application Lifecycle Management (ALM)

The supervision of, and documentation and tracking of changes to a software application from its initial planning through removal. Source: searchsoftwarequality.techtarget.com/definition/application-lifecycle-management-ALM


      1. SMS Design & transition: Release & deployment

SMS – Design & transition – Release & deployment – definition

A release is a set of related components and changes that we manage as a set, because it makes sense to do so; for example, we could roll out SAP as 5700 changes, one at a time, but it makes more sense to manage it as a release—to put a team on it, to make sure the live environment is ready for the releases, to make sure the release itself is good, and the plan and mechanism to deploy it and back it out if necessary are good, and so on. Each individual change associated with a release still needs to be managed through change control, it’s just that it makes sense to also manage at the “zoom level” of a release.

SMS – Design & transition – Release & deployment – desired state

Performance is effective when:

  • Stakeholders realize value quickly, with quality, from new or changed services, feature sets, features, and qualities, which are released quickly and with quality, through a pipeline whose flow we automate and continuously improve
  • We’ve put mechanisms in place that make it easy to try new services, feature sets, and features, and roll them back where necessary and useful
  • We do a good job at making sure we have the right resources and enough of them when we release and deploy new or changed services, especially when there are concurrent releases and deployments, and resolving schedule and resource conflicts
  • when they do arise
  • We have consistency across releases and deployments, no
  • irrational variation
  • Cost, schedule, and resource estimates are sufficiently accurate
  • We have good feedback loops from stakeholders back to
  • Release & deployment

With release and deployment management, we are working to get customers and users the services, feature sets, and features and qualities they need, quickly, with quality, and with continuous improvement, both of services and the build pipeline.

SMS – Design & transition – Release & deployment – practices

M1

  • Release and deployment
  • Release policy
  • Definitive Media Library

M2

  • Continuous Delivery
  • Blue/green deployment
  • CAMS
  • Immutable deployment

A definition:

Continuous Delivery

Automated implementation of the application build, deploy, test and release processes meant to ensure performance (fast delivery) and conformance (to requirements), enabling users to start using new functionality and qualities quickly to realize value and provide feedback sooner.


      1. SMS Design & transition: Change & configuration

SMS – Design & transition – Change & configuration – definition

Change and configuration are tied at the hip; change is make the actual changes well, and configuration is making sure that we have a good logical picture of what we have out there, and for each component of our configuration, know what it looks like, to a level of detail that is useful to us, and how it relates to other things we have out there.

SMS – Design & transition – Change & configuration – desired state

Performance is effective when:

  • We get stakeholders the changes they need quickly and with quality, so they can start realizing value as soon as possible.
  • We minimize disruptions due to changes, and can track, “what changed?” precisely enough; and we don’t have a lot of backed out changes, but when we must, we can back out easily.
  • The reality and how stakeholders see it, is how we handle changes as not as slowing down needed changes, but as helping those making changes move quickly, taking appropriate risks and facilitating speed with quality
  • We ensure a logical model of IT Services, Assets and IT
  • Components needed is defined, controlled, maintained and kept accurate and detailed enough as a source of information for fact-based management of IT services and to comply with corporate governance requirements.

Some other indicators of effective performance include:

We minimize the number of eyeballs that need to be on changes, and work relentlessly to root out unnecessary complexity, variation, and dependencies, so that fewer stakeholders must be involved in looking at few changes, and can focus on the ones that really need their attention

We know, precisely enough, what configuration items we have, how they relate to one another and to relevant classes or groups, and what their configuration is to a sufficient level of detail and accuracy to do the work that we do well, and all stakeholders who need the information have easy access to this information when they need it, e.g., when troubleshooting or planning; this includes configuration items that are internal to us as the provider, and external to us, where they are components of our stakeholders, services, and the SMS; this goes for production and pre-production configuration items

We build out configuration items that make up components of stakeholders, services, and the SMS from known good sources and keep them in a known good state.

We have a baseline of configuration items as a reference point and all the snapshots we need for reference and to be able to restore to a prior state, or for other purpose we have

We can tell multiple versions of the same configuration items apart easily, and can easy compare and see how they are the same and different

We can produce accurate information on stakeholder, service, and SMS components and their configuration, versions, and relationship among components easily, e.g., for audits.

Our configuration is under control—it is always the case that the components, versions, and relations between components of stakeholders, services and the SMS are in a known and controlled state, with demonstrable integrity. And we have visualization into current state, planned state, and past state for all configuration items when we need it

SMS – Design & transition – Change & configuration – practices

M1

  • Change management
  • Configuration management
  • Baselining and snapshotting
  • CMDB

M2

  • Microservices architecture / REST
  • Variation reduction
  • Immutable deployment
  • Infrastructure-as-code
  • Service Discovery
  • Cloud
  • Standardizing resource configurations
  • Software configuration management

The general shift from traditional ITSM practices is due to a shift from traditional to cloud/mobile environments. For cloud/mobile, suitable practices are needed to fit the target environment to be managed.

Chapter Section summary

A Service management system (SMS) is a set of specialized organizational capabilities (management, organization, processes, knowledge, people (experience, skills, relationships)) and interrelated or interacting elements (including policies, objectives, procedures, tools, documents, and resources) service providers use to direct and control services, including how services are planned, designed, developed, implemented, deployed, delivered, monitored, measured, reviewed, maintained, and improved. The aim of the SMS is to achieve and sustainably maintain the desired state of providing value to customers and users in the form of services.

Chapter Section summary

  • Design & transition are the set of SMS practice areas concerned with:
  • Strategy & GRC — ensuring there is a strategy and governance and compliance mechanisms, and that services are continually aligned to it
  • Learning & improvement of services—ensuring the set of services is continuously aligned to stakeholder needs over time and through changing circumstances; this includes knowledge management, and continuous improvement
  • Development of services—the initial planning and building of services
  • Release & deployment — the initial release and deployment of services
  • Change & configuration of services — changes to services and
  • subsequent releases and deployments, through the lifecycle
  • of the service, including removal
  • Each of these practice areas has a desired state that must be
  • achieved and maintained continuously over time and through
  • changing circumstances to ensure value continually flows to
  • all stakeholders; these desired states can be achieved and
  • maintained through best practices


Chapter Section 5.3: SMS Promotion concepts, desired states and practices


      1. SMS Promotion overall definition, desired states and practices

SMS concepts, desired states and practices – Promotion (30m)

Promotion

In this chapter, we’re covering topics that will help you describe what a service management system is, its typical components, their desired states, and best practices for achieving them, including the following SMS components in the category Promotion.

SMS – Promotion – overall definition

Source: adapted from www.ama.org/aboutama/pages/definition-of-marketing.aspx

Both internal and external services need to be taken up for value to be realized. Externally, to external customers, this is marketing, advertising, and sales. For internal customers, it’s internal marketing and “selling”. Once services are subscribed to, either internally or externally, it is vital that they get used (the pejorative term for software that is paid for but not used is “shelfware”) for value to be realized fully by stakeholders.

SMS – Promotion – Desired state

Performance is effective when:

  • New customers are buying our services, and referring others to buy our services in numbers meeting or exceeding our revenue and profit requirements
  • Existing customers are staying with us and referring others to buy our services
  • New users are using our services, including existing, new and changing services and new and changing service functionality and qualities, and referring others to use them in numbers meeting or exceeding our requirements
  • Existing users are staying with us and referring others to use our services

SMS – Promotion – practices

M1

  • Service catalog

M2

  • Lead generation and Enrollment
  • Driving uptake

Some best practices for human-led services promotion:

Delivery is a services firm’s most valuable sales tool. (“The PSF 50”, pg. 156, “How to Buy/Sell Professional Services”) A services firm’s ability to sell begins and ends with the ability of its consultants to deliver. A sale does not end when an engagement begins—the only thing a client has at the beginning of an engagement is the promise of results. A sale ends when all results have been achieved to the client’s satisfaction.

Existing clients are our highest probability prospects. (“Managing the Professional Service Firm”, pg. 97) Existing clients are a services firm’s best source of new business. When dealing with existing clients, services firms have already earned their trust and confidence, they often understand other aspects of the sales process important to the final decision, and there is often little or no competition, especially in cases where the firm discovers the need.

The best way to sell is to care. (“Managing the Professional Service Firm”, pp. 71, 120) The essential nature of services revolves around relationships, not technical matters. Clients shop for trust, confidence, and peace of mind as much as they do technical expertise. They respond most favorably to consultants with an interest in their problems and a sincere desire to help. Therefore, the best means of attracting clients is to care about helping clients succeed.

The marketing of services must be a seduction, not an assault. (“Managing the Professional Service Firm”, pg. 122) Marketing services is most effective when it demonstrates competence, not when it asserts it. Successful marketing of services is ultimately about attracting clients in a manner that they want to take the next step in the relationship.

The goal of marketing is to create face-to-face interaction. (“Managing the Professional Service Firm”, pg. 121) The goal of all marketing efforts in a services firm is to generate face-to-face dialogues with prospects. Individualized content delivered through face-to-face interaction is much more effective than general messages broadcast to large audiences.


Chapter Section 5.3 Summary

Services must be purchased and used for all stakeholders (customers, users, the provider, and supplier) to realize value

Value is a function of uptake of services, including existing, new, and changing functionality and service qualities; the goal of the provider is to have the right services and functionality and service qualities in the first place, and as time passes and customer and user circumstances and technology possibilities change, to add, modify, and remove services, functionality, and qualities to ensure services continuously provide value; but this is not enough; providers must ensure uptake of services, including existing and new and changing functionality and service qualities, to ensure customers and users fully realize value

The promotion practice area of the service management system is aimed at ensuring uptake of services through marketing, advertising, and sales of external services to external customers and users, or the equivalent activities for internal services for internal customers and users

The promotion practice area has a desired state that must be achieved and maintained continuously over time and through changing circumstances to ensure value continually flows to all stakeholders; this desired state can be achieved and maintained through best practices


Chapter Section 5.4: SMS Support concepts, desired states and practices


      1. SMS Support overall definition, desired state, practices

SMS concepts, desired states and practices – Support (90m)

Support

05-04-01. SMS – Support

05-04-02. Event handling

05-04-03. Incident handling

05-04-04. Request handling

05-04-05. Problem handling

05-04-06. Major incident & disaster handling

In this chapter, we’re covering topics that will help you list and describe the what a service management system is, its typical components, their desired states, and best practices for achieving them, including the following SMS components in the category Support.

SMS – Support – overall definition

We want to detect events related to services must be detected and notifications sent out, so that desired control actions (either automated or manual) can be taken, including triggering incident handling for exceptions we have trapped. We also want to make sure all transactions that come in from our users, either through the portal or some other channel, get handled—both requests and incidents, either through automation, or by human intervention, or by some combination of the two. Lastly, we want to make sure major incidents (which lie somewhere between a regular incident and an all-out disaster, and which, if left alone, tend to become disasters) and disasters get handled properly. Handling in all these cases includes both proactive provisions for these transactions and scenarios, as well as the reactive dispatching of them when they do occur.

SMS – Support – desired state

Performance is effective when:

  • Stakeholders typically do not require support, because our services just work and are easy to grasp and use; in the rare occasion that they do require support, stakeholders are satisfied with the level of support they receive, both with the result they get and with the interaction / experience of support
  • Stakeholders indicate that we detect all events (informational, warning, or exception) related to services that are worth knowing about and managing, and send out notifications so that desired control actions (either automated or manual) can be taken, including triggering incident handling for exceptions
  • Stakeholders indicate that all requests and incidents that come in from users, either through the portal or another channel, get handled, through automation, human intervention, or some combination of the two.
  • Stakeholders agree that we make sure major incidents (which lie somewhere between a regular incident and an all-out disaster, and which, if
  • left alone, tend to become disasters) and disasters get handled properly, including both proactive provisions for these transactions and scenarios, and reactive dispatching when they do occur
  • We automate and continuously improve to reduce support cost, timescales and effort

In the end, we want to provide responsive support at the right cost.

SMS – Support – practices

M1

  • Event handling
  • Incident handling
  • Major incident & disaster handling
  • Disaster handling
  • Request handling
  • Problem handling
  • Self-service portal

M2

  • Event handling
  • Monitoring and logging
  • Incident handling
  • Multi-channel service
  • Major incident & disaster handling
  • Incident Command System (ICS)
  • Infrastructure Automation
  • Request handling
  • CAMS (for automation)
  • Problem handling

Traditional ITSM guidance positions the handling events, incident, major incidents, problems and requests as processes in an operations phase of a lifecycle. OSM positions them as “things worth managing” with desired states to be achieved and maintained. The difference in positioning is the difference in a means (process) versus end (outcome or desired state) model. Traditional ITSM guidance positions disaster handling in a service design phase. OSM places it in line with other support and response processes here; note that the service quality of recoverability associated with disaster preparedness is covered in the service qualities portion of the OSM model.

One example here of a mode 2 practice: Infrastructure automation is based on the cloud-based reality that infrastructure components can and should be treated like code. System specs should be checked into source control, go through a code review whether a build, an automated test. Then you can automatically create uniform instances from the spec and to manage them programmatically. There are so many ITIL challenges you can overcome by infrastructure automation. For example, we can start by applying the DevOps method of infrastructure automation to your ITIL-driven IT Service Continuity, or disaster recovery process. We used to talk a lot about design for availability and a DR site and hardware in another city, keeping two data centers in sync; now because I can script my infrastructure deployment I can just grab my script, point it at the other datacenter, run it and bam, I’ve got another instance of my infrastructure. Some organizations I work with have gone beyond infrastructure as code, to operations a code (automating every ITIL process with code); alerts, incidents, problems, provisioning, capacity, demand, availability, performance, everything can be reduced to automation through code.


      1. SMS Support: Event handling

SMS – Support – Event handling – definition

SMS – Support – Event handling – desired state

Performance is effective when:

  • We have the right set of event detection and alert notification mechanisms set up, so that we can detect all changes of state in stakeholders, services, and the SMS that are significant and may require a control response; These include normal situations, e.g., informational “chron job just ended”, to warning “you set a threshold of 15% utilization on this storage array and told me to tell you when it happened; I am telling you”; to exception / abnormal situations “server down”; we have these set up to monitor for all quality of all services, including financials, service levels, continuity, availability, throughput, configuration, security, and compliance, as well as the components of services, including environment

(E.g., temperature, fire, water detection), hardware, system software, networks, applications, and DBMS

Event management in OSM is not just about capturing infrastructure or application events, but capturing and notifying about all “things worth managing”.

SMS – Support – Event handling – practices

M1

  • Event handling

M2

  • Instrumentation / Telemetry
  • Monitoring
  • Cloud Monitoring / Telemetry
  • Logging / Instrumentation
  • Logging cheat sheet
  • API and CL interface, not just UI
  • ChatOps

The general trend is to take point solutions with an API and a command line interface, and string them together to create a toolchain, rather than seeking monolithic solutions. Part of the interesting shift in recent year has been that tools that were built assuming a physical on-prem environment haven’t necessarily made it over to the cloud, because their core model is so different, and cloud solutions are being produced more through iteration (leading initially to smaller, more point solution offerings), which seems to have led to this trend.


      1. SMS Support: Incident handling

SMS – Support – Incident handling – definition

With an incident, something is broken. It could be an error trapped in the infrastructure, or a user who is “broken”, i.e., cannot work.

SMS – Support – Incident handling – desired state

Performance is effective when:

  • Incidents are handled within service level targets, and stakeholders are satisfied with the professionalism and speed with which we handle incidents
  • Incidents are handled effectively and efficiently, while minimizing disruption on stakeholders, services, and the SMS
  • Feedback to Learning & improvement for improving both services and the service management system to better handle similar situations going forward
  • We employ automation in the handling of incidents
  • Incidents are resolved within agree service level targets, including incidents concerning quality of a service, including financials, service levels, continuity, availability, throughput, configuration, security, compliance; in addition to resolving incidents, we analyze cycle time components to see how we can
  • crash MTTR/MTTRS, by taking time out of the cycle,
  • e.g., time to record, respond, resolve,
  • repair/replace, recover

We work to prevent incidents in the first place, and should they occur, we work to resolve incidents as quickly as possible, certainly within service level targets for MTTR / MTTRS; further, we work to proactively crash the cycle time for incidents through analysis, action, and automation by analyzing where time is spent in the cycle, e.g., time to record, respond, resolve, repair / replace, recover

SMS – Support – Incident handling – practices

M1

  • Incident management
  • Service desk

M2

  • Public status pages
  • Multi-channel support
  • ChatOps
  • Devs on Call

The DevOps practice Putting Devs On Call for the services they create is based on the golden idea of, “you dealt it, you deal with it”—the idea that Devs will take more care of the quality of what they produce if the will must suffer the pain of dealing with it later, and not just chucking it over the fence for somebody else to test. The Devs on Call DevOps practice has the greatest impact on traditional ITSM-driven Application Management, Service Desk, and IT Operations functions.

You put Devs on call for the service they create to create a fast feedback loop that helps rapidly improve logging and deployment, and more quickly resolve application issues.


      1. SMS Support: Request handling

SMS – Support – Request handling – definition

Note here that requests can be self-service. They can be requested and fulfilled totally manually, or totally automated, on both sides of the equation. Also, note that requestors in this model are not just customers and users. For example, self-service and requests are part of the normal fabric of working within a build pipeline, by provider staff and suppliers.

SMS – Support – Request handling – desired state

Performance is effective when:

  • Requests are handled within service level objectives or targets, and stakeholders are satisfied with the professionalism and speed with which their request are handled

  • Feedback to Learning & improvement for improving both services and the service management system to better handle similar situations going forward
  • We support all request channels stakeholders are inclined to make most use of
  • We automate and continuously improve request handling, to reduce time-to-value and irrational variation and the costs and effort that come with it
  • We have a graceful method for rejecting service requests where the requestor is not entitled to what has been requested

When rejecting a request for which the requestor is not entitled, we must always provide the reason to the requestor in a graceful way.

SMS – Support – Request handling – practices

M1

  • Request handling
  • Self-service portal

M2

  • Request handling
  • Multi-channel service
  • CAMS (for automation)

The key idea here is providing channels to stakeholders that stakeholder want to use, that make making requests “ready-to-hand”, easy to get to, easy to do, just easy. And further, to automate, automate, automate, with self-service on the front-end, and scripted fulfillment on the back end.

SMS – Support – Problem handling – definition


      1. SMS Support: Problem handling

A problem is the root cause, the unknown, underlying of one or more incidents. What capability do we have to handle problems?

SMS – Support – Problem handling – desired state

Performance is effective when:

  • At any given time, we can list the top ‘n’ problems we’re working on, what we’ve done so far, and what we’re going to do next
  • We work proactively to prevent problems up front, and to prevent them from reoccurring; when a problem is live, we work to minimize the disruption the problem causes, through workarounds and crisp communication and action
  • We have effective shared root cause analysis in “muscle memory”, that multiply our capability to solve problems as a group
  • Feedback to Learning & improvement for improving both services and the service management system to better handle similar situations going forward
  • We practice blameless postmortems to review problems, which focus on learning and improvement, and are fact-driven and
  • action-oriented, balancing accountability with a
  • safe environment to share failures
  • We arm problem solvers with the right skillset
  • and authorization to handle problems

While traditional ITSM guidance describes problem handling as a process, and while you could draw a process map for it, there wouldn’t be much to it. In the end, problem management is the sum of your application of shared techniques for preventing and solving problems, techniques like Kepner-Tregoe problem analysis.

SMS – Support – Problem handling – practices

M1

  • Problem handling

M2

  • Problem handling
  • Site Reliability Engineering
  • Blameless postmortems

Site reliability engineering (or SRE), is defined by Ben Treynor, founder of Google’s Site Reliability Team, as, “what happens when a software engineer is tasked with what used to be called operations”. 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. SRE focuses on engineering continuous operations at the point of customer consumption.

The largest impact of SRE on traditional ITSM-driven shops is that the SRE is an entirely new role in many shops. Part systems administrator, part second tier support and part developer, SREs ask questions, acquire new skills and knowledge, and embrace automation, and have the coding skills to solve problems and ensure the highest levels of reliability and availability. SREs are involved in the handling and management of late-night incidents, escalations, root cause analysis, service level objectives, availability and performance metrics, and other ITIL-driven practices. SREs provide a basis for instilling agility into many ITIL processes to meet changing demands brought about by the march to the cloud and DevOps, Lean and Agile practices.


      1. SMS Support: Major incident & disaster handling

SMS – Support – Major incident & disaster handling – definition

You can think of a major incident as an incident that is much more significant than the average incident, that, if left untended, can become a disaster.

Traditional ITSM guidance places major incident management under incident management as a process, and refers to disaster handling as continuity management, which it places in a service design phase. OSM see major incidents and disasters as things worth managing, to a desired state. Note that some of the service qualities in the OSM model directly correspond to these two “things worth managing”—for example, supportability and recoverability. In OSM, these are not processes, but qualities built into services that must be kept in a desired state.

SMS – Support – Major incident & disaster handling – desired state

Performance is effective when:

  • Major incidents and disasters are handled effectively and efficiently, within service level objectives or targets agreed with stakeholders
  • Feedback to Learning & improvement for improving both services and the service management system to better handle similar situations going forward, and we’ve applied learning and automation to improve recoverability capability and speed by design up front and continual improvement
  • We work proactively to prevent major incidents and disasters, and to prevent their reoccurrence; when a major incident or disaster is living, we work to minimize the disruption it causes, through workarounds, crisp communication and action
  • We have effective shared major incident and disaster command systems in “muscle memory”, that multiply our capability to solve problems as a group
  • We practice blameless postmortems to review problems, which focus on learning and improvement, and are fact-driven and action-oriented, balancing accountability with a safe environment to share failures

SMS – Support – Major incident & disaster handling – practices

M1

  • Major incident & disaster handling
  • Disaster handling

M2

  • Public status pages / transparent uptime
  • Incident Command System (ICS)

Incident Command System is applicable to both major incidents and disasters, as it is a method of scaling up or down with self-similar teams.


Chapter Section 5.4 Summary

  • Support is the practice area of the SMS that directs, controls and executes the day-to-day support of services, including handling events, requests, incidents, problems, major incidents and disasters. Contrast support with delivery, which is the component of the SMS that directs, controls and executes the day-to-day operation of services, including stakeholder relations, administration, provisioning, metering, and billing, and budgeting and accounting. Support is characterized by handling of customer and user requests within a timeline set in an SLA, as well as major incidents, problems, and disasters; while there are reactive aspects of the delivery components of the SMS, they are primarily characterized by planned activities on a set schedule, whereas support is primarily characterized by responding to customer and user requests, as well as problems, major incidents and disasters, with proactive aspects being important, but less frequent, than those that are unplanned.

  • Each of these practice areas has a desired state that must be achieved and maintained continuously over time and through changing circumstances to ensure value continually flows to all stakeholders; these desired states can be achieved and maintained through best practices


Chapter Section 5.5: SMS Delivery concepts, desired states and practices


      1. SMS Delivery overall definition, desired states, practices

SMS concepts, desired states and practices – Delivery (90m)

Delivery

05-05-01. SMS – Delivery

05-05-02. Stakeholder relations

05-05-03. Administration

05-05-04. Provisioning, metering & billing

05-05-05. Budgeting & accounting

SMS – Delivery – overall definition

Stakeholder relations is a “thing worth managing” in OSM, related to BRM in traditional ITSM guidance, but extending the idea to all stakeholders—customers, users, provider staff, and suppliers, and substituting a desired state (end-in-mind) for a process (means).

Administration consists of adding, modifying and deleting service subscriptions, add-ins and integrations, licenses, users, groups, resources, account and billing settings; getting sysadmin-level support for subscribed services; reviewing reports on usage, security and compliance; monitoring service health.

Provisioning, metering, and billing is concerned with initial set up of services for customers, monitoring their usage, and charging customers for the services they use. It also covers related items like handling upgrades, downgrade and cancellations that affect billing. In organizations where chargeback is not used, this area is concerned with showback.

Lastly, being able to budget and account for IT services is a “thing worth managing” that is part of the delivery of services.

You may see a departure here form some traditional ITSM guidance, that positions “delivery” as such things as service level, availability, capacity, continuity, and financial management. As you can see, OSM includes only financial management (budgeting & accounting) is service delivery. In OSM, availability, capacity (performance) and continuity (recoverability) are not processes, as in traditional ITSM, but qualities of IT-led services.

SMS – Delivery – overall desired state

Performance is effective when:

  • Stakeholders are satisfied with the delivery of our services, as time passes and stakeholder and overall industry circumstances change, as new technologies and possibilities emerge, and as our services change, including:
  • Stakeholders feel listened to, and feel we are adapting to new possibilities and changing circumstances appropriately and quickly, so that our services and their functionality and qualities reflect their feedback and needs
  • Stakeholders feel administrative transactions are quick and easy to administer, and that that there is an appropriate level of automation and self-service to them
  • Stakeholders feel that the process of provisioning services is quick and painless, that how services are metered is easy to understand up front and transparent, and that the billing or showback process is quick and easy and has the right options to meet their needs
  • Services are budgeted for accurately, so there are no unpleasant surprises like cost over-runs, and accounted for accurately, so there are no surprises as to costs, expenses, or profits
  • Stakeholders feel both planned and unplanned delivery activities are handled well

These desired states are for the “things worth managing” in service delivery, which is the day-to-day administrative operations of services, including:

  • Stakeholder Relations
  • Administration
  • Provisioning, metering & billing
  • Budgeting & Accounting

SMS – Delivery – practices

M1

Business Relationship Management

Financial Management

M2

Stakeholder relations

  • Customer relations
  • User relations
  • Provider relations
  • Supplier relations

Administration

Provisioning, metering, and billing

Budgeting & accounting

Best practices are what people do now that works to help them achieve and maintain desired states for things worth managing like stakeholders, day-to-day administration, provisioning, metering, and billing, and budgeting and accounting.


      1. SMS Delivery: Stakeholder relations

SMS – Delivery – Stakeholder relations – definition

You should see the difference here between stakeholder relations and BRM. BRM is a traditional ITSM process; the outcome of BRM is valid, and included in stakeholder relations in OSM, but extended to apply to all stakeholders, including provider staff.

SMS – Delivery – Stakeholder relations – desired state

Performance is effective when:

  • Customers are satisfied both with the value of our services and with how we engage with them as time passes and circumstances change and as we adapt our services to those changes; our relationship with customers is constructive, productive and mutually beneficial, and characterized by our service portfolio continuously being adapted based on a combination of continuous customer listening and our bringing forward the possibilities new technologies and changing business circumstances bring
  • Users are satisfied both with the use of our services and with how we engage with them as time passes and circumstances change and as we adapt our services to those changes; we have a constructive, productive and mutually beneficial relationship with users characterized by providing value in every interaction.
  • Suppliers are satisfied with the value they get from our constructive, productive and mutually beneficial relationship; they consistently meet or exceed their commitments to us, and strive to bring more to the table than simply fulfilling them obligations
  • We, the provider staff, are satisfied with our work, over time and through change

In the end, what we are aiming for is a sustainable situation where all key stakeholders are satisfied. This is a dynamic system, since what will satisfy stakeholders will change, as will the means, e.g., the technology possibilities. Note here that satisfying stakeholders is not meant to mean everyone is obliviously happy and gets everything they want, like a parent giving a child ice cream for breakfast, lunch and dinner. Relationships take work, sometimes hard, and educational conversations in both directions about what is needed, what is possible, and what wherewithal is required to deliver it consistently.

SMS – Delivery – Stakeholder relations – practices

Stakeholder relations

  • Customer relations
  • M1
  • Business Relationship Management
  • Service Level Management
  • User relations
  • M1
  • Service Desk
  • Provider relations
  • Supplier relations

In OSM, service level management is accomplished by making sure the service has the right configuration, features (including instrumentation), and qualities (which are the things like availability and performance (capacity) that go into a service level agreement, and making sure these “things worth managing” are kept in a desired state, over time and through changing circumstances.


      1. SMS Delivery: Administration

SMS – Delivery – Administration – definition

In delivery of services, someone’s got to do the day to day sysadmin tasks, and they need to be done right—accurately, and in a timely manner.

SMS – Delivery – Administration – desired state

Performance is effective when:

  • Stakeholders are pleased with responsiveness and quality of our conduct of technical (sysadmin) tasks associated with adding, modifying and deleting service subscriptions, add-ins and integrations, licenses, users, groups, resources, account and billing settings
  • Stakeholders are pleased with the responsiveness and quality of our sysadmin-level support for subscribed services
  • We review reports on usage, security and compliance, and monitoring service health, to avoid issues and outages
  • Wherever possible and cost-effective, we automate sysadmin tasks to reduce time-to-value, as well as unnecessary variation and its associated costs

Automating sysadmin tasks is a key part of this, and the SRE role can be a key part of this.

SMS – Delivery – Administration – practices

M1

  • Sysadmin

M2

  • Site Reliability Engineering

Site Reliability Engineering, which is described as “what happens when a software engineer is tasked with what used to be called operations”, is a discipline that incorporates aspects of software engineering and applies them to IT operations problems, with the aim of creating ultra-scalable and highly reliable software systems.


      1. SMS Delivery: Provisioning, metering & billing

SMS – Delivery – Provisioning, metering & billing – definition

Provisioning, metering and billing is the set of activities required to bill customers for services they consume (or, if you don’t do chargeback, at least showback). It requires sound IT accounting practices and systems, and includes a periodic negotiation cycle to set (usually annually) pricing policy and price lists, monthly compiling and issuing of bills (either charge- or show-back).

SMS – Delivery – Provisioning, metering & billing – desired state

Performance is effective when:

  • Stakeholders are satisfied both with the efficiency and results of provisioning (including initial setup and later, decommissioning) as well as with the engagement / interaction itself
  • Stakeholders are satisfied with the accuracy of metering and billing (whether it is chargeback or showback), including the transparency of algorithms for both, and the provisions we make to allow them to influence their usage and costs to their advantage
  • If we charge back, our charging model is transparent and communicated up front so there are no negative surprises to customers, and it is easy for customers to pay and for us to collect payment; we are also clear on our goal for charging (e.g., loss leader, break even, profit) and our algorithms

Chargeback is providing pay-the-bills customers with an analysis of the provider service costs on, for example, a monthly basis, and charging them for those costs. Showback (also known as memo billing), is providing the same analysis, but without charging them for those costs. The idea with showback is to provide information to drive the right behaviors. Showback is like the note you get from your insurance provider for a medical procedure you have had that is fully covered—this is what it would have cost you, etc.

Some other indicators of performance include:

  • Customers can easily determine what services have and will costs, and can easily manage their subscription through a portal
  • Stakeholders see Total Cost of Ownership (TCO) for services as reasonable

SMS – Delivery – Provisioning, metering & billing – practices

M1

  • Financial Management

M2

Provisioning, metering, and billing

  • Consumptive billing model
  • Chargeback and showback
  • Provisioning (User)

We can be doing well as a provider in a lot of areas, but screwing up on “the last mile”—on things that touch the client directly and greatly impact their preferences and perceptions—is something we cannot afford to do. Provisioning, metering and billing are part of that last mile.


      1. SMS Delivery: Budgeting & accounting

SMS – Delivery – Budgeting & accounting – definition

Source: www.accountingtools.com/dictionary-budget,

www.accountingtools.com/questions-and-answers/what-is-accounting.html

It is important that budgeting and accounting systems be set up with a chart of accounts, reports, etc. that can record and show, e.g., budget versus actual, by services.

SMS – Delivery – Budgeting & accounting – desired state

Performance is effective when:

  • We accurately account for IT costs, map cost data back to categories and services, and use that data for investment and budgeting decisions.
  • Whether we offer services to make a profit or offer services at no profit, our services and the SMS have a sustainable funding model
  • We can easily determine and communicates the full cost of providing services and the SMS and revenue and profit, and we are proactively managing costs down and revenue and profit and value to stakeholders up
  • We can quantify the value of each service we provide, and of the SMS
  • We operate in line with our organization’s financial policies
  • Expenses are the same or less, and revenues and profits are the same or higher than projected for services

ISO/IEC 20000-1:2011(E) 6.4 Budgeting and accounting for services indicates that there must be policies and documented procedures for

  1. budgeting and accounting for service components including at least

1) assets — including licenses — used to provide the services,

2) shared resources,

3) overheads,

4) capital and operating expenses,

5) externally supplied services,

6) personnel, and

7) facilities

  1. apportioning indirect costs and allocating direct costs to services, to provide an overall cost for each service
  2. effective financial control and approval.

SMS – Delivery – Budgeting & accounting – practices

  • Budgeting & accounting

One key best practice here is to set up your chart of accounts and reports to be able to budget, account, and report on the planned and actual expenses and revenues, by service.


Chapter 5 Summary

  • Delivery is the practice area within the SMS that covers:

  • Stakeholder relations – ensuring the relationship between the provider and customers, users and suppliers is good
  • Administration – ensuring administration of services is easy for all stakeholders
  • Provisioning, metering, and billing—setting up (and later, decommissioning) services and service components; tracking and reporting on usage; invoicing customers.
  • Budgeting & Accounting—preparing budgets for services and accounting for expense and revenue
  • Each of these practice areas has a desired state that must be achieved and maintained continuously over time and through changing circumstances to ensure value continually flows to all stakeholders; these desired states can be achieved and maintained through best practices


Chapter 6: Getting Started with Open Service Management

We’ve covered a lot here! What services and service management are, and what Open Service Management is. Things worth managing, desired states and practices for stakeholders, value and value flow, human-led and IT-led services and their configurations, functionality, and qualities, and the service management system.

These are the foundational concepts covered in the OSM Foundation exam.

To get started with OSM, you can begin by taking a course from an Authorized Training Organization (or ATO), as a course from an ATO is required to register for the exam.

Take the sample exams, which should be included in your courseware, and review your results. Make sure you understand the rationale for the book answer for any questions you did not get right.

Then sign up for the actual exam and take it to earn the certification and demonstrate your knowledge.

Let’s have a look at its format.

Format of the OSM Foundation Examination

You must achieve a passing score in the Foundation Exam to gain the OSM Foundation Certificate in IT Service Management.

Tips for Taking the OSM® Foundation Exam

Here are some tips for taking the exam:

  • Attempt all 40 questions; if you don’t know the answer, guess and mark for review
  • There are no trick questions or patterns in how the answers are laid out
  • Mark all answers on the paper answer sheet (or if taken online, on the web page)
  • Skip and go back to a question you can’t answer right away
  • Don’t forget to use the process of elimination
  • Skip the preamble; it might be a misdirection, go right to the question; only read the preamble if it is necessary to answer the question
  • Watch for absolutes, for example, “always”, and “guarantees”
  • If stuck between choices ask, “What is this, and who owns it?”
  • Read questions carefully—don’t miss the word “NOT”!
  • For testing purposes, take the book view, rather than your own

Besides getting certified, and more importantly, you can get started by taking what you’ve learned and applying it back on the job. You don’t have to do it all, but you should be able to cherry pick a couple of things that have obvious value for you, like a best practice you haven’t tried, or a desired state you know needs work and that you can contribute to, as an individual, or within your team or entire organization.

You can also learn more about IT Service Management and OSM® by visiting https://osmalliance.org.

If you are a consultant or trainer, or part of a consulting or training organization, consider signing up as an Authorized Training Organization (ATO) or Authorized Consulting Organization (ACO).

If you are part of an end-user organization or vendor, please consider joining our consortium. We all win if we have an open standard we can snap to.

Please also consider contributing to OSM® as an individual, team, or organization. There are lots of ways—you can contribute to content, to the community, or the consortium, with your talent and treasure. You can help by writing or reviewing content based on your subject matter expertise. You can sign up as a forum moderator for the community. Or you can help with promotion and marketing, or website stuff, if that’s where your talents lie. And you can help with the consortium. And you can always help with your tax-deductible contribution to [email protected]

We started this initiative not because we had all the answers, and everything we needed to succeed out of the gate, but because we thought that if we could get started with the right idea, people who cared about our industry would bring their time and treasure and talent and help us all pull ourselves up by our bootstraps. Let’s do this thing!

Sign up today at osmalliance.org, or contact us at [email protected]. Thank you for taking the time to help your brothers and sisters and be part of something good and bigger than all of us.