http://www.itsmwatch.com/itil/article.php/3782211/On-Demand-Data-and-the-CMDB.htm
Back to Article
|
|
|
|
By Rob England Oct 31, 2008 Consider the option of on-demand operational data, and a specialist team to provide it. I want to propose the idea of on-demand operational data. I’ll discuss it in the context of Configuration Management and CMDB but it applies just as much to any data requirements. Within the audience reading this, that would also include areas like service level reporting, capacity trending, support responsiveness, and many others. I’ll start with CMDB. Instead of chasing the rainbow of building a consolidated, federated, integrated, reconciled CMDB, we could assemble the configuration data on demand in response to a requirement. Let me say from the outset that this is an idea rather than proven practice, but then ITIL v3 includes relatively untested ideas like the SKMS so I am in good company. The idea of on-demand data first came to me in the satirical book Introduction to Real ITSM: “Known elsewhere as “assets” or “configuration”, real ITSM manages stuff. Records should be kept of all stuff except where records are not kept … Management or auditors will periodically demand lists of stuff. Given that their requirements are entirely random and unpredictable, the most efficient way to deal with this is to respond on an ad-hoc basis by reallocating staff to collate the data. This is known as on-demand processing. The technology of choice is MS-Excel.” That proposition was made tongue-in-cheek, but let us consider it seriously. Does this scenarios sound familiar? The Service Desk and Support staff just will not record incidents in the correct category. Incidents get left in the first category chosen even when it emerges they were actually something quite different. There are multiple categories being used for the same thing depending on who you ask. The taxonomy is so complex that new staff use “Other” for weeks while they come to grips with the job before they are pressured into learning the proper categorisations. Level 2 insist on using their own subset of categories. And the external service providers never specify category at all. The Incident manager spends hours every week trying to keep it clean. Every few months there is a housekeeping sweep to fix it all up. It comes up at every service desk team meeting, over and over, but the message never seems to get through. Or this one? The Security Manager wants to introduce an authentication “dongle” that plugs into the USB port. He wants to know how many desktops have a USB port accessible on the front. But there is no record of which desktops have a spare USB port at all, let alone on the front. This identifies a deficiency in the asset database, so a new field is added and a project launched to go capture the information from thousands of desktops and laptops across the organisation. Here is a hypothetical future scenario for the real geeks reading this: The grid computing network reconfigures itself under load, but because the network is in mid-reconfiguration when the updates get sent to the CMDB and because the updates are not two-phase-commit (there is no multi-phase commit in the CMDB architecture), the updates keep getting lost and the vendors seem incapable of adding store-and-forward to the update mechanism. So we never really know in real-time which servers are running which services. In all three of those scenarios, consider if we created the configuration data when we needed it in response to some particular situation instead of trying to maintain it all the time in a CMDB. Formalising What We Do Anyway This is nothing new—it is what we do now. We create data ad-hoc anyway when we have to. If the data is not there or not right and management wants the report, we gather it up and clean it up and present it just in time, trying not to look hot and bothered in the process. How much better would it be if we had a team, expert in producing on-demand configuration information? They would have formal written procedures for accessing, compiling, cleaning and verifying data, which they would practice and test. They would have tools on the ready and be trained in using them. Most of all they would “have the CMDB in their heads”, e.g., they would know where to go and who to ask to find the answers. They would have prior experience in how to do that and what to watch out for. So instead of ad-hoc amateurs responding to a crisis, experts would assemble on-demand data as a business-as-usual process. When management wants a report on the distribution of categories of incidents, they would sample a few hundred incidents, categorise them properly according to what the requirements are this time (after all how often does an existing taxonomy meet the needs of a new management query anyway?) and respond accordingly. They would be an on-call team, responsive to emergency queries. “The grid computing system has died and the following servers are not dynamically reconfiguring. Which services are impacted and which business owners do we call on a Saturday?” They may not know the answers off the top of their heads but they will know, better than just about anyone, where and how to look—and, just as importantly, how long that is going to take. Consider the option of on-demand operational data, and a specialist team to provide it. I want to propose the idea of on-demand operational data. I’ll discuss it in the context of Configuration Management and CMDB but it applies just as much to any data requirements. Within the audience reading this, that would also include areas like service level reporting, capacity trending, support responsiveness, and many others. I’ll start with CMDB. Instead of chasing the rainbow of building a consolidated, federated, integrated, reconciled CMDB, we could assemble the configuration data on demand in response to a requirement. Let me say from the outset that this is an idea rather than proven practice, but then ITIL v3 includes relatively untested ideas like the SKMS so I am in good company. The idea of on-demand data first came to me in the satirical book Introduction to Real ITSM: “Known elsewhere as “assets” or “configuration”, real ITSM manages stuff. Records should be kept of all stuff except where records are not kept … Management or auditors will periodically demand lists of stuff. Given that their requirements are entirely random and unpredictable, the most efficient way to deal with this is to respond on an ad-hoc basis by reallocating staff to collate the data. This is known as on-demand processing. The technology of choice is MS-Excel.” That proposition was made tongue-in-cheek, but let us consider it seriously. Does this scenarios sound familiar? The Service Desk and Support staff just will not record incidents in the correct category. Incidents get left in the first category chosen even when it emerges they were actually something quite different. There are multiple categories being used for the same thing depending on who you ask. The taxonomy is so complex that new staff use “Other” for weeks while they come to grips with the job before they are pressured into learning the proper categorisations. Level 2 insist on using their own subset of categories. And the external service providers never specify category at all. The Incident manager spends hours every week trying to keep it clean. Every few months there is a housekeeping sweep to fix it all up. It comes up at every service desk team meeting, over and over, but the message never seems to get through. Or this one? The Security Manager wants to introduce an authentication “dongle” that plugs into the USB port. He wants to know how many desktops have a USB port accessible on the front. But there is no record of which desktops have a spare USB port at all, let alone on the front. This identifies a deficiency in the asset database, so a new field is added and a project launched to go capture the information from thousands of desktops and laptops across the organisation. Here is a hypothetical future scenario for the real geeks reading this: The grid computing network reconfigures itself under load, but because the network is in mid-reconfiguration when the updates get sent to the CMDB and because the updates are not two-phase-commit (there is no multi-phase commit in the CMDB architecture), the updates keep getting lost and the vendors seem incapable of adding store-and-forward to the update mechanism. So we never really know in real-time which servers are running which services. In all three of those scenarios, consider if we created the configuration data when we needed it in response to some particular situation instead of trying to maintain it all the time in a CMDB. Formalising What We Do Anyway This is nothing new—it is what we do now. We create data ad-hoc anyway when we have to. If the data is not there or not right and management wants the report, we gather it up and clean it up and present it just in time, trying not to look hot and bothered in the process. How much better would it be if we had a team, expert in producing on-demand configuration information? They would have formal written procedures for accessing, compiling, cleaning and verifying data, which they would practice and test. They would have tools on the ready and be trained in using them. Most of all they would “have the CMDB in their heads”, e.g., they would know where to go and who to ask to find the answers. They would have prior experience in how to do that and what to watch out for. So instead of ad-hoc amateurs responding to a crisis, experts would assemble on-demand data as a business-as-usual process. When management wants a report on the distribution of categories of incidents, they would sample a few hundred incidents, categorise them properly according to what the requirements are this time (after all how often does an existing taxonomy meet the needs of a new management query anyway?) and respond accordingly. They would be an on-call team, responsive to emergency queries. “The grid computing system has died and the following servers are not dynamically reconfiguring. Which services are impacted and which business owners do we call on a Saturday?” They may not know the answers off the top of their heads but they will know, better than just about anyone, where and how to look—and, just as importantly, how long that is going to take. Consider the option of on-demand operational data, and a specialist team to provide it. I want to propose the idea of on-demand operational data. I’ll discuss it in the context of Configuration Management and CMDB but it applies just as much to any data requirements. Within the audience reading this, that would also include areas like service level reporting, capacity trending, support responsiveness, and many others. I’ll start with CMDB. Instead of chasing the rainbow of building a consolidated, federated, integrated, reconciled CMDB, we could assemble the configuration data on demand in response to a requirement. Let me say from the outset that this is an idea rather than proven practice, but then ITIL v3 includes relatively untested ideas like the SKMS so I am in good company. The idea of on-demand data first came to me in the satirical book Introduction to Real ITSM: “Known elsewhere as “assets” or “configuration”, real ITSM manages stuff. Records should be kept of all stuff except where records are not kept … Management or auditors will periodically demand lists of stuff. Given that their requirements are entirely random and unpredictable, the most efficient way to deal with this is to respond on an ad-hoc basis by reallocating staff to collate the data. This is known as on-demand processing. The technology of choice is MS-Excel.” That proposition was made tongue-in-cheek, but let us consider it seriously. Does this scenarios sound familiar? The Service Desk and Support staff just will not record incidents in the correct category. Incidents get left in the first category chosen even when it emerges they were actually something quite different. There are multiple categories being used for the same thing depending on who you ask. The taxonomy is so complex that new staff use “Other” for weeks while they come to grips with the job before they are pressured into learning the proper categorisations. Level 2 insist on using their own subset of categories. And the external service providers never specify category at all. The Incident manager spends hours every week trying to keep it clean. Every few months there is a housekeeping sweep to fix it all up. It comes up at every service desk team meeting, over and over, but the message never seems to get through. Or this one? The Security Manager wants to introduce an authentication “dongle” that plugs into the USB port. He wants to know how many desktops have a USB port accessible on the front. But there is no record of which desktops have a spare USB port at all, let alone on the front. This identifies a deficiency in the asset database, so a new field is added and a project launched to go capture the information from thousands of desktops and laptops across the organisation. Here is a hypothetical future scenario for the real geeks reading this: The grid computing network reconfigures itself under load, but because the network is in mid-reconfiguration when the updates get sent to the CMDB and because the updates are not two-phase-commit (there is no multi-phase commit in the CMDB architecture), the updates keep getting lost and the vendors seem incapable of adding store-and-forward to the update mechanism. So we never really know in real-time which servers are running which services. In all three of those scenarios, consider if we created the configuration data when we needed it in response to some particular situation instead of trying to maintain it all the time in a CMDB. Formalising What We Do Anyway This is nothing new—it is what we do now. We create data ad-hoc anyway when we have to. If the data is not there or not right and management wants the report, we gather it up and clean it up and present it just in time, trying not to look hot and bothered in the process. How much better would it be if we had a team, expert in producing on-demand configuration information? They would have formal written procedures for accessing, compiling, cleaning and verifying data, which they would practice and test. They would have tools on the ready and be trained in using them. Most of all they would “have the CMDB in their heads”, e.g., they would know where to go and who to ask to find the answers. They would have prior experience in how to do that and what to watch out for. So instead of ad-hoc amateurs responding to a crisis, experts would assemble on-demand data as a business-as-usual process. When management wants a report on the distribution of categories of incidents, they would sample a few hundred incidents, categorise them properly according to what the requirements are this time (after all how often does an existing taxonomy meet the needs of a new management query anyway?) and respond accordingly. They would be an on-call team, responsive to emergency queries. “The grid computing system has died and the following servers are not dynamically reconfiguring. Which services are impacted and which business owners do we call on a Saturday?” They may not know the answers off the top of their heads but they will know, better than just about anyone, where and how to look—and, just as importantly, how long that is going to take. Certainly we would need some basic CMDB data kept continually. This would be the stuff we discover auto-magically already, such as procurement-driven asset databases, or discovered network topologies and desktop inventories, or the transactional information captured by the service desk. Add to that the stuff we document on paper already (or ought to), the service catalogue, phone lists, contracts and so on. The savings in not trying to go beyond that base CMDB data would be great. The price paid for those savings would be that “on-demand” does not mean “instantaneous”. It might mean hours or days or even weeks to respond to the demand. So a business analysis needs to be done to find out how current the data really needs to be (as compared to what the technical perfectionists say). In some organisations the criticality demands instant data and they need to trudge off down the CMDB path. But for the majority of organisations this just isn’t so. The original premise was in jest but I believe it raises a serious idea worth considering. As a vocal critic of CMDB I am sometimes asked, “Well, what then?”, and the idea of on-demand configuration data goes some way towards answering that. More Than Configuration Nor is this idea limited to CMDB of course. As we mentioned at the start, service levels could be more efficiently reported using sampling techniques and manual collation than by implementing some huge automated service level reporting system. Any system needs to be dynamic; the business’s demands for service level reporting are often changing. An expert ad-hoc reporter is more dynamic than service-level-tracking software. Likewise much of the operational data which we track, such as performance and capacity, could be on-demand. Rather than implement a big historical database, get the on-demand team to dip as needed into the streams of out of the box data coming from storage managers, operating systems, databases, and event monitors. The IT industry is prone to fads, especially anything that involves a revolutionary new way to do something and “doubly especially” if it involves a technological solution to a people or process problem. So much effort and expense would be saved and disruption avoided if we looked first to formalise and optimise the way we do things now before launching off into the wild blue yonder, usually following some vendor’s promise of a better place. Before we build a technology solution, look at whether existing process can be tightened up and improved to achieve the same result for less. Cultural Change The challenge will be overcoming two things: excessive technical fastidiousness (the geeks’ compulsion to do everything “right”) and that “be prepared” ethic. Remember the fable of the grasshopper and the ant? The ant slaves away all summer storing food while the grasshopper plays around, then come winter the ant is well fed while the grasshopper starves. It is obviously not true. The world is full of grasshoppers. They are more resourceful than that. They work something out. There are many organisations and societies who understand that effectively and efficiently dealing with the things that happen, and not wasting time and money preparing for the things that don’t happen, is in fact a net saving in effort. In this case, instead of building infrastructure to continually record data we might one day need we can quickly gather only the data we do need in reaction to a requirement. There is some linkage here with the concepts of Lean IT. Something to consider—especially when you look at that expensive CMDB project. Rob England is an IT industry commentator and consultant, and nascent internet entrepreneur, best known for his blog The IT Skeptic. |
