August 9, 2010 3:45 AM
Posted by: Doug Mueller
When looking at transforming the way IT works using a Business Service Management strategy, a big part of the discussion is around the word service. It is used in many different discussions and there is a lot of casual use of the term for different meanings. One of the biggest areas of confusion is around the use of the term Service Catalog. Commonly, I hear the term used in the context “I need a service catalog to show my users and allow them to make choices”. However, this is really a discussion of a service request catalog rather than a service catalog. The two are definitely related but they are quite different things.
So, is there one thing or two? Is there really a difference? If so, is it important? What are they really all about?
A service catalog is a list of all the services that are offered by/available in the organization. These can be business services or technical services or personal services. You can monitor them and measure them. They are linked to applications and infrastructure that provides support for them. They are key things supplied by your business. Together, all the services are your business.
Let’s say the business is about retail. Some services this business may define include Consumer Accounts, Web Site Ordering, Retail Stores, Distribution, Vendor Management, and many others. These are all examples of business services that are key to your business. Internally, there may be services related to Employee Communication, Order to Cash, Payroll, and many others. These are all internal services that are key to your business.
All of these things are collections of processes and procedures that allow you to accomplish some key aspect of your business. Knowing they exist, their health, how they are performing, what in your environment affects them (and how much), and that they are available are all important to being able to understand the health of your business.
Service Request Catalog
A Service Request catalog is a list of anything you can ask or ask for within the organization. They can be simple requests for information or requests for some action. You can measure and monitor the response to a request but you don’t measure the request itself. Service Requests are tied to services — they are what you use to cause something to happen within a service.
Again, assume the business is about retail. Some service requests might be Open an Account (tied to the Customer Account service), Close an Account (again, tied to the Customer Account service), Add a server to the web site server farm (tied to the Web Site Ordering service), or Check Payroll status (tied to the Payroll service).
All of these are a request to do something. Take some action within the context of a service (or set of services) to accomplish some goal. Run through some set of steps to cause some result.
So Why is the Distinction Important?
It may at first seem that all this is no big deal. So what, service or service request, they are close enough. But, the distinction is critical.
When you are talking about a service catalog, you are talking about the services your organization offers. You need to know how they are connected, what things are related to them, what things depend on them, what they depend on. You need to know if your business is running — and you know that by whether the services of the business are running. You don’t ask for a Consumer Accounts or an Order to Cash; but you do ask how they are doing and are they available.
When you are talking about a service request catalog, you are talking about that catalog of things that people can ask for. The specific operations that request some kind of action. You need to know what questions to ask someone who requests something, you need to know whether approvals are needed, you need to have the steps to take defined, and you need to orchestrate those steps to complete whatever the request is that has been made. It is all about performing an operation to completion and the management of that operation.
In general, if you want to see your service catalog, you go to the CMDB and look for things of type Service. Then, you can see how they are connected and how things affect each other. Now, you should also be able to see the requests (requestable offerings) that are related to the services as part of the configuration data that is available.
If you want to see your service request catalog, you generally go to a Service Request Management (SRM) system. This is the catalog that allows you to see what you can ask for (or order, or request, or whatever term you may want to use) and then track the delivery throughout the process. All users will interact with the service request catalog to get things done.
Most of the confusion around these two terms comes with the user of service catalog when service request catalog is really intended. When this happens, there is a lot of confusion about what a service means and how it is used and how it is part of the new way that IT is being managed. Just remember, is it a business capability, a service, or something you ask for, a service request. Keeping the two terms clearly defined and separate simplifies the thinking and the work involved around a service-oriented approach to your business.
July 23, 2010 3:46 PM
Posted by: Doug Mueller
Business Service Management, BSM, is at its essence a way of planning and structuring how an organization performs its job. It is about understanding that the reason that the organization exists is to work with the business to accomplish its goals. Note that there is an important distinction between being a support organization and an organization that supports the business to do better business.
So, what does that mean? This just seems like two different ways to say the same thing. In a way, it is, but the reality is that the thinking that goes on in the two cases is different. The distinction is a small but critical shift of thinking.
Assume I am on the IT staff for a bank. If I am a support organization, my thinking would be “I am an IT person and I have to run an efficient IT shop so I can supply good IT capabilities”. A valuable and laudable goal. However, wouldn’t it be more compelling for the business if instead I thought of myself as an organization that supports the business to do better business. In this case, my thinking would be “I am a banker and my goal is to do better banking. My role in supporting that goal is to be on the IT staff supplying IT capabilities. But, what I am trying to accomplish in everything I do is how to do better banking”.
A subtle but significant difference in attitude. Is my job IT or am I a banker? Am I just trying to do better IT with the expectation that it will help my customer or am I trying to do better banking and using my skills in IT to deliver better banking capabilities? At first, this can be a hard distinction to grasp. But, once that distinction is clear, it opens the way to really thinking differently about your role and about how work should be done.
Once you take a step back from technology issues and stop thinking about individual processes and activities, this is the essence of BSM. It is a fundamental shift of model. It is a new way of approaching the problem. If everyone in the organization is focused on the same goals — doing whatever it is your organization is responsible for — there is no need to discuss alignment or interfacing or any of a dozen other such activities between a team and the business. The alignment or interfacing is inherent because everyone is oriented on the same focus already. Yes, people still need to talk and share data; but, it is now a discussion of a group with all the same understanding and goals rather than the formal summit between opposing forces (sometimes with different agendas) it often is today.
You can notice the change when IT is part of the discussion and decision making of the business rather than just getting requirements and directives. IT is at the table working with other parts of the business to make decisions about the business and the direction that the business should be taking.
The idea here is not restricted to IT. Every organization in the company should be thinking this way. In some cases, that is automatic. A sales team is focused on what the business does because that is what they are selling so no big shift for their thinking. But, organizations like HR or facilities or any of the other support teams being focused on what the end business is about adds value to the overall delivery of the business.
July 8, 2010 5:49 PM
Posted by: Doug Mueller
Over the past few months, I have been involved in a number of discussions about whether the CMDB is relevant in a given context.
The first involved a discussion of why bother with a CMDB, my team knows where things are and they know how things are connected so why bother with a CMDB. Well, the CMDB is where you have data about what you have and how things are connected and how they connect to the business. So, if that information is gathered together and available, you have a CMDB. At that point, we are just arguing implementation details. There is a “CMDB”, it is just in peoples heads.
Of course, the risk with this approach is accuracy (how do they find out about things they don’t know about), availability (folks do occasionally take time off and may not be available), permanency (sometimes people move on to new jobs), and many other issues. The argument is that things are going OK so why do I need to change? Well, things are often not really going OK even though it seems like they are.
Other discussions revolved around the CMDB in the context of the Cloud. Things are changing too dynamically. Why do I care where things are running and how they are connected — that is the job of the Cloud? How can it keep up with the different definitions needed in the space? How can it scale? How does it in fact find out about some of the detail?
These arguments emphasize the increased requirement for the CMDB in the Cloud. Without a formal mechanism to record your environment, what it really looks like, and how it is connected, how can you possibly effectively manage your environment? How can you keep track of what is affecting your business and whether all your business services are up and available?
Discussions like these just emphasize how important it is to keep focus on what is important and not get stuck in the details. It can distract you from the goal — to be able to manage your environment more effectively and efficiently.
The CMDB is all about
- Knowing what you have
- Knowing how things are related
- Knowing how it is connected to the business
and having that data available to anyone (or any process) who needs it at any time.
This data is critical for you to be effective at running and managing your business. Without it, you are wandering in the dark, struggling to solve problems, and making decisions without complete understanding of ramifications. This is why the CMDB is one of the two anchors of Business Service Management.
Let’s return to one of my favorite analogies for the CMDB — the card catalog in the library. When you use the library, where do you go to find something? The card catalog. Where do you go to find related things? The card catalog. How the catalog is built, maintained, managed, defined, or loaded is not the issue (not to say it is not important or not something for whoever is creating the catalog to worry about). The concept of that card catalog existing and what its role and purpose is in the library is the issue. Think about what you would do if you wandered in and needed to find something and found that the card catalog wasn’t there? At least in a library there is some order to the madness so you could start hunting; but if you don’t find it is it because it isn’t there, it is checked out temporarily, or they don’t have it? In the world of business, things aren’t in orderly rows with some level of organization that you can easily go and hunt for them.
Now, there should be discussions around what capabilities a CMDB has and how it is implemented. There should be pressure put on vendors who are offering CMDB solutions to make sure that the functionality is keeping pace with what is needed. If the CMDB is not able to keep up with its role, that means the implementation is not working in the context not that the idea of a CMDB is not relevant in the context. Don’t confuse the tool with the concept or the value of the concept.
The Cloud does not change the fact that you need to understand your environment. In fact, it means you need to understand it even more completely and fully because you are making more automated and faster decisions on configuration within your environment than ever before.
So, is a CMDB relevant in the Cloud (or anywhere else you are trying to manage)? Absolutely.
June 29, 2010 2:44 PM
Posted by: Doug Mueller
There are many tools and technologies and bits and pieces laying around that are all important to an organization that is looking at moving down the Business Service Management (BSM) path. However, there are two parts that are the key anchors to any BSM strategy. These are the two pieces that you build everything else around and that provide the anchor points for your BSM strategy. They are
- CMDB (Configuration Management Database)
- SRM (Service Request Management)
First, the CMDB. This is what you have, where it is, how it is related to other things, how it is tied to the business, and what are the impacts of things on each other. In other words, it is all the things — physical, logical, conceptual that are available to you and that you are responsible for and that you need to know about. These are things within IT or outside IT within the business as a whole. But, all things that are important and relevant to your business.
It includes the services for your business and provides the link across your processes as they tie to services they are operating for. And, since it is all about the business, everything you are doing is for some business purpose and so is tied to a service that is being offered to or by the business and so is tied to the CMDB. It does not mean that every application must be rewritten to use the CMDB as its primary data store — that in fact would be a bad decision for most applications. It does mean that all your processes should be CMDB aware in terms of linking to or being linked to by the CMDB.
Then, SRM. This is what you allow people to request and how to deliver those requests in as efficient and clean way possible. It is demand management to allow you to understand what is being asked for and how delivery is going. Done properly, it is the initiation point for all work done within your environment. It is also the definition of how those requests are delivered. One place to record how to deliver requests so that there is a consistent delivery of the requests. One definition to maintain. One place to go to optimize and automate. One place to understand what delivery processes are costing and the time they are taking.
SRM is the one place for people to go. It includes everything that they are allowed to ask for based on contracts/agreements (formal or informal). It includes entitlement capability to restrict requests that are only available to certain people. It includes an orchestration capability to allow calling one or more other applications or systems to perform the actual work to execute the request. SRM itself should not try and do work, you have systems out there that do that. SRM is a coordinator and controller of the work to do by interacting with other systems and processes to have them perform their operation and report back on the result.
At the end of the day, these are the key to success in BSM. All other processes — and there are many of them and they are important processes — are tied into these anchors. All tools within the system either feed or are called by processes, so again, the tools are tied into these anchors. Once you get over the initial reaction that it is all about two parts of the system and think about what you are trying to accomplish, it makes sense. Your goal is to run your business (in as efficient and effective way possible) and to do that you need to know what you have, where is it, what it does, how it is important, what you can do to it, how it is done, and coordinating all of this. This is what the CMDB and SRM do and it is what all the other processes and tools within your environment support.
June 25, 2010 12:17 PM
Posted by: Doug Mueller
In many different conversations I have had with companies around the world, it has become clear to me that embarking down the path of Business Service Management is really embarking down the path of a fundamental transformation in the way IT works. Just like occurred in other segments of the business in the past — whether it be finance with ERP or HR with the tools there — it is time for IT to mature. The key is to do this transition effectively and efficiently and improve how IT works without disrupting the business.
Traditionally, IT has worked in a model where it is IT doing its job, sometimes with conversations with the business, but in general, pretty isolated. There are lots of tools around to help IT do its job but not enough control and process to do the job effectively and efficiently. There is a lot of data stored in many different stores but often there is little information available to management about what is really going on within the business.
Then, there are the challenges of knowing what you have, where it is, how it interacts, what it is used for and how to fix it if there are problems. Often, this has been handled rather informally. IT has relied on the “hero” culture where if there is need for data or an action to be taken, the answer is “Find Sally, she understands how that area works”.
There are more and more technologies showing up within IT. Those technologies are more dynamic and make changes to the environment more rapidly. This means that there needs to be a more accurate and more complete understanding of the environment and a more organized process for managing the environment to be effective at managing IT. There is no option to slow the pace of technology or to abandon older technologies. That is simply not realistic. IT needs to keep managing all the old technology and deal with the new technologies and do it with decreased budgets and higher expectations.
At the same time, IT needs to change the way it is thinking. It is not about IT, it is about the business. Everyone in the IT department should be thinking about how they are solving business problems and making the business run better.
Business Service Management is about changing the way IT does business. It is about focusing on the business rather than focusing on IT. It is about building a process-centric culture rather than a tool-centric culture. It is about reorienting from hero-centric execution to standard process and automated execution. This is a transition that is long overdue. IT has spent time over the past 10 years helping other teams transform themselves and do business in new and better ways. It is time for IT to spend some time helping themselves transform the way they work to do things in new and better ways.
June 22, 2010 5:24 PM
Posted by: Doug Mueller
First, I want to extend a welcome to all who stumble across this blog. Although I have been involved in mailing lists and writing white papers and papers in journals, this is my first stab at using a blog for sharing ideas. So, we will see how this goes.
My goal is to have an open forum for the discussion of topics around the general theme of Business Service Management. There is a lot of confusion and misunderstanding of this topic in the industry although there is also a lot of discussion and hype around it. I hope to bring some ideas and examples to share with you about what I am hearing and seeing in the industry and from customers and where current and future thinking is about various topics around this topic. I firmly believe that this is the future direction for IT and in fact for managing the business in general outside of IT as well. Without a change, IT does not have a prayer of keeping up with changing technologies and with the increasing complexity of environments.
The goal of the discussion is not to push a given product or solution or company but to have a discussion about the topic in general regardless of what product you are using or you aim to use. Yes, I have a history (doesn’t everyone) and I will share that below in this introduction, but the goal of the discussion is to be discussing the topics around Business Service Management and not about a specific solution.
I expect topics to be wide-ranging. They will be everything from business level discussions around IT transformation to discussions about key technologies such as the CMDB, Request Management, and various other ITIL processes to stories about customers who have embarked on this journey to best practices (and some worst practices too). All will have a tie to the broader topic of Business Service Management.
There are some topics I will drive, but I want to make this blog interactive and encourage your participation. If there are topics you have question about, please ask or suggest an area for discussion. If you agree or especially if you disagree with a position, please comment so that we can have a discussion and share that discussion with others. Often times those types of discussions are amongst the most enlightening information. If you have examples of good or bad practices, please share them so everyone can benefit from the learning.
One thing I am sure of is that coming up with a constant flow of topics is often the hardest thing about a successful, long-term discussion and interaction about any topic. I can use all the assistance I can get from your participation.
Finally, a bit about myself. My name is Doug Mueller and I am currently working as a Corporate Architect at BMC Software where I am responsible for the architecture and directions of the Service Management process solutions and the Atrium (shared components) products. I joined BMC Software when Remedy Corporation was acquired by BMC in 2002. At Remedy Corporation, I was a co-founder and technical lead of the engineering team starting from the end of 1990. Before Remedy Corporation, I worked at Hewlett-Packard where I worked on a variety of network management products ending with the initial release of the HP OpenView product. I have a BS degree in Computer Science from California Polytechnic State University at San Luis Obispo.
So, a history of working in the system and network management space and a lot of exposure to the trends in the industry over that time and to working with customers — especially over the past 10 years — on what they need and see happening in the space.
I hope to be able to provide some useful information and that we can have a healthy and productive interaction.