Configuration Management - The most Critical yet most Avoided Processes
January 11, 2017
Matt Hooper | ITSM Evangelist | Ivanti
Organizational improvements leveraging ITSM best practices require the understanding of business process and asset relationships. Assignment of tasks, understanding of risk, tracing fault and instability within the infrastructure all require accurate and up to date information about changes to the systems configuration and the way the business utilizes these technology assets. Why then have so many organizations delayed, failed or neglected all together to implement a proper configuration management strategy? Frankly, it's just plain hard. In this webinar we will walk you through how to approach a Configuration Management implementation, how to sell it as a business project and not an IT project, and what mistakes to avoid to establish an initial working phase that you can build on for success.
Melanie: Hello, and welcome to the Ivanti webinar, Configuration Management: The Most Critical Yet Most Avoided Processes. My name is Melanie Karunaratne. I'm the host for this particular webinar, but with me today, and more importantly, is Matt Hooper, our ITSM Evangelist for Ivanti. He'll be presenting, for the most part, this presentation, but we will be taking questions on Chat, so please refer to myself, as the host, or Matt, who will be presenting, and I will be monitoring throughout. All of the phone lines have been muted, so you will not be able to use your phone to ask questions, so please do use Chat.
For those of you who find this webinar interesting or think it will be interesting for colleagues, we are recording this presentation. It will be available to download from the Ivanti website, and it will be sent to you in a couple of days by email, so watch for that.
Without further ado, Matt, I'm going to turn the presentation over to you so that you can get started.
Matt: Great, thank you, Melanie. Welcome, everybody. We appreciate you joining us today to consider configuration management. It’s a topic that has come up a lot recently with our clients. I have spent time with some of our customers going through the challenges of configuration management—getting started, looking at asset management and understanding the relationship between those two things. As a result, we thought it would be appropriate to put together a webinar highlighting some of the best practices and some of the guidance we've been able to learn in the industry and through past experience to really help us move forward.
For our agenda today, what we want to do is get into some of the definitions and terms around configuration management, around CMDB. We want to discuss some of the perspectives of what a CMDB is, why it's going to help us be more agile as an IT organization, how it helps us create better decision-making, and how it provides us the foundations for answering good questions in and around IT service management. We'll consider some of those questions and how a CMDB and configuration management answer those questions.
We'll also get into some of the understanding of systems of records; what that means; how we document things into our systems so that we can have living, breathing systems that help us make faster decisions; how we allow the systems to help us through the process of changing and releasing assets and purchasing; and we’ll look at the functionality of our systems and how they support business functions.
We'll talk about common mistakes that are made in the deployment of configuration management, some of the tools, some of the challenges organizations have had, the thoughts they’ve had, why they thought something would be a good idea but what it really ended up being.
We'll go into some guidance on approaching your CMDB and configuration management initiatives in the right way, both from a justification internally to get the spend to acquire the tools and training and put the right people in place, and making it an initiative you can direct forward to build value within the organization.
Why is configuration management necessary?
To get us started, what I always like to do is get back to some of the Whys. Configuration management is the most critical area of focus for any IT organization, yet it's one of the areas of IT that we typically avoid the most. If you talk to a lot of organizations about their configuration management database, many of them say, "Well, we have some things in an asset repository" or "We started down that journey, but it didn't really work so well" or "We tried that and it failed for us" or "We're going to do that later. We want to get incident change and problem kind of working first."
The reality is, when you look at the situation in IT, what we have is a lot of moving parts, so we have to ask ourselves certain questions. We have to be exceptionally inquisitive. By way of example, look at the picture of the spilled wine with the car turned, and try to picture the scenario. What just happened here? Did someone roll the car and knock over the wine glass? Did someone step on the car, fall, and spill the wine? Was a child playing with the car, knocked over the wine glass, and left the car there to get some paper towels and clean it up? Was somebody bringing the car to a child while holding the wine glass, saw something catastrophic happening, and dropped them both? There are a lot of things you can build into the story. Without context, it's always hard to get a clear understanding of what happened.
If we look at that from an IT perspective: many times we’re fixing incidents or trying to build knowledge or trying to purchase new equipment or software or responding to a request from the business. In such instances, we really can't set the expectations of "This is how fast we can fix that" or "This is what happened" or "This is how much capacity we have" or "This is why that service went down" or "This is why we had that business function have an impact" because we don't have the context.
We're not able to give clear information about our activities, all of our ITSM activities, e.g., projects, requests for new equipment, repairing things, predicting resources and turn-around time on fulfillment of things, or about our assets—the hardware and software we have, how much we paid for it, how it's supporting things, what's installed where, how much we've effectively used a license we have. There are many questions that come up, but we don't have the context in place to answer them.
Configuration Items within a CMDB
Configuration management can really give us a foundation for that contextual information, because configuration management helps us focus on relationships. These relationships are stored in what's called a configuration management database. You may have heard the term CMDB, particularly in our industry. For the most part, a best practice is to have multiple configuration management databases, because we have multiple asset types that have information about them. For example, your Windows information usually has a bunch of elements in your active directory for Microsoft, stored in the Windows Management Interface (WMI), where information is polled and you can see how things relate to each other. We put these things in a collective place, and we sometimes hear it referred to as a configuration management system. This was a term introduced, but frankly, it's really not used very much. When you hear CMS, typically in IT it's an abbreviation that stands for content management system. So CMS hasn't really taken off. CMDB seems to be more what you hear across the industry—configuration management system or CMDB. When you hear CMDB, it's usually multiple CMDBs.
What is in the configuration management database? Well, what we have in the configuration management database is a bunch of objects. We call these objects “configuration items.” In simple terms, they are containers that hold information about a particular thing—attributes of that thing and the relationship of it to other things. For example, you might have a host name, a server such as Boston Web 01 Fraud. That's the host name, and there are a bunch of attributes for it. It's an HP DL580, it has 560 gigs of disc drive, it has a whole bunch of memory in it. It has all this configuration and attribute information, and where is it installed? Well, it's installed in this rack, in this data center, and it supports these business functions. So you have all these different types of configuration information you're trying to track. They can, again, be software, hardware, even policies like Sarbanes-Oxley or FDA regulations. If, say, you have systems that support drug manufacturing, and you have to do things that support CFR 21 Part 11, which is an FDA regulation around two-phase authentication for drug administration and protection around clinical data, those systems might have a relationship back to that. If you want to change something, you know you have to follow that regulation. So it's just a way for us to build context. All of these things are represented here within the CMDB.
We also have assets. Assets are things we purchase. They're something of value. They don't necessarily have to be tangible. Software licenses are not tangible really, they're digital, But they are something of value. We want to see what those things are—how much did we pay for it? And they have relationships, as well. They have relationships to contracts. They have relationships to vendors. What we do is compile these things together, put these configuration items together, and group them together logically in some context of the system. For instance, email is a system. You might incorrectly hear that in the industry of ITSM, it’s a service. It's not a service, it's a system. It provides communication services. As a system, you will have many parts to email. You’ll have email storage, where emails are kept for different users. This is how one email system talks to another email system across the Internet and communicates and exchanges back and forth. You'll have firewalls. You'll have what's called DNS, Domain Name System lookup, which lets you know that at Ivanti.com, where does [email protected] go? What message system should I send it to, and how do I exchange that with a message record? All these things are logical pieces of an email system that allow us to see what makes up the ability to deliver a business function.
We mentioned messaging communications is a business service, and that would be a service model on how we communicate. If you're in Office 365, that's your system for providing some messaging, but you may also have Lync or Skype for Business as part of that messaging communication system. They are other pieces of the system that allow you to accomplish a business function. We'll get into some details about what a service model and vital business functions look like, but vital business functions, again, are those activities we have to do to operate our business. It may be something around giving someone a quote for a new customer. It may be a customer inquiry and how they can look up the status of their policy or their account—things like that. We'll talk about some details and give you some examples of those things.
So these are some general definitions that we're going to use, and we'll try to build some clarity around these as we get into some further conversation. But at a very high level, a configuration management system, as I mentioned, compiles these CIs, these containers. And these containers are not just limited to devices. It could be your laptop, it could be a phone, it could be the software on your phone, and it could be information or documentation related to that. But the purpose of it, again, is to help us understand how technology supports our business outcomes.
Determining CMDB Containers
We may want to list as containers who our customers are, or who our channel for generating revenue is. It's always a great place to start. If we understand how our technology generates revenue or generates our ability to execute in the business market, this creates a direct line of sight that adds a lot of value to the context of the technology we have. So if we have containers for agents—say we're an insurance company with agents and customers—what do they do? Well, they generate quotes, they look for quotes to get new insurance coverage, they may have policies that are part of their coverage, or in this case, maybe subscriptions. If we look at that, we see there's a bunch of vital business functions that are reporting each of those business services of quoting and subscription. But they really are supported by systems. We have a quoting system and accounts payable, a member system that fits on some kind of subsystem such as our Web farm or Web cluster, things like that, which are then supported by actual assets such as Web servers or database servers.
As you can see, there's kind of a hierarchy of configuration types. When we talk about these things, we may have systems CIs, or services CIs, or business function CIs, or team CIs. Because number two, we want to know who owns these. Those might be attributes, or it might be relationships to a group, so we can say, "Well, who are the owners of these containers?" We want to be able to see that relationship. And we'll talk about some of the things that they answer. An important note here is these items are not to scale. This is not how we see the world. We're looking at the ability here, with our configuration management database, to see if we can isolate down to a subset of assets. Another important note here is when you look at CMDBs and why they might have failed, it’s often because they've brought in so much information, and it's not contextualized. It's more functionally oriented, "What exists on this network?" Well, that might be important for a particular project, but sometimes you can simply query information in real time. You can go out and scan what's on the network to figure it out, and then take the action you need to take. That's not necessarily the value of a system of record, and I think that's where people get a little bit lost. So let's talk about what a CMDB perspective is really all about.
The Importance of Relationships
Hopefully we understand by now, the “why” configuration management? is that we want contextual information. What would some of that contextual information be? Well, we want relationships. The number one driver for our configuration management system is we need to see how things are interrelated. If I'm going to take down a piece of hardware in my data center, say a network switch, I want to know where that network switch is. I want to know who the owner is. I want to know how it's being utilized. I want to know if this is an audited piece of equipment, and do I have to log the shutting down of that piece of equipment? If I'm going to make a change to it, I want to know if I have to log that change. If I take that piece of equipment down, what is the business impact? What business functions are operating on top of that network switch, or what other assets are on top of that network switch? So we can see that one of the primary drivers is relationship context.
Another piece we want to utilize the CMDB for is the analysis of that switch over time. I want to know that network switch. I want to monitor all changes to that switch to see how much maintenance I have to perform on it or how much total cost of ownership I have in regard to it. I also want to have those changes authorized, approved, and logged so I can see if it was an intended change or an unintended change. If it’s an unintended change, then I have an issue here. Either I have a training issue, or I might have a security breach, so that could be a problem. How many times do people access the console of that switch and logging that from a security perspective. How many failures did I have? What's the performance or capacity of the switch? Keeping this kind of context is important as well, because this lets me know if I have fragility. This could support the foundations of problem management. Doing root-cause isolation is one part, but seeing the trend and knowing the frequency of impact is also a part.
The integrity of our systems and our assets is also important, and we really want to leverage that to communicate effectively. We want to build knowledge. We want to be able to report on things. We want to see these trends and the actions we have to take. Did I have to release new patches to that switch? How many times did I have to release new patches? How many vulnerabilities are there within that network switch at this point in time? How many times do I have to send it in for repair? All those answers help support things such as supplier management or strategic decisions around "Do I have infrastructure that’s too costly to operate or support?" This, then, supports decisions around an asset from a financial perspective. What is the total cost of ownership? Do I have the right contracts in place? What are the financial impacts? Have I fully depreciated this? Do I have enough support and justification to dispose of and replace this asset? There are a lot of perspectives CMDB brings to the table to allow us to make a good decision.
Build more than one CMDB
The problem is it could become overwhelming if we try to make a monolithic configuration management database. If we try to pour everything into one database, it becomes this elephant. Getting that elephant off the ground and trying to ride that elephant is really, really hard, almost impossible, because there is too much data that’s not really answering questions. You'll hear a term in the industry called the “federated CMDB.” What that usually means is we are pushing information out or leveraging information stored in different places. It’s the performance of a server: how much memory it might have been using over time, what the CPU utilization is, how frequently it maxes out, and what the disc capacity is. We may not want to, and probably shouldn't, pump all that into one large CMDB. That’s especially true if it can be queried in real time, if we know it can maintain its own system of record, whether on the server or in a monitoring tool or some other place that we can get access to that data.
We want to think about how to approach this and interact with configuration management data appropriately. How do we do that? How do we bring data into our configuration management system? How do we associate it and maintain certain activities? One of the first things that's really important is that you have a good service model in place. If you have a good service model in place where you understand why you’re making changes to configuration information, why you’re adding new information to your CMDB, or why you're updating or deleting information in your CMDB, you can start to look at the triggers.
One of the big inputs is usually projects. When you have a project, there's a lot of new software and hardware you have to acquire that usually requires you to go to asset management and acquire those new licenses. Next, you have to deploy them as part of the project. It's through that deployment and release process that you're actually building the need for this new container within your CMDB to hold the information, so the creates, updates, and deletes are good triggers. Source those back. Did the asset come from your self-service request catalog? Did it come from a problem management process that was requiring improvement? Was it from a project? As we change existing CIs, how are we handling this? Change is going to be one of the big integrated processes.
Configuration Management Requires Change Management
It amazes me how many organizations do change management without configuration management. In other words, they're authorizing and approving changes, but they don't have configuration items associated to those changes, either at a system level or at a very specific configuration item level. Think about that for a second. What change are you authorizing? What is its current state? What state will it reach? What risk does it introduce to the environment? As you can see, we might not have all the information we need to make any kind of effective, managed decision around that change, so it's not really change management. It's simply change scheduling. It’s only the exchange of some cursory information, or maybe a rigorous approval process that makes us feel like we’re reducing risk but probably aren’t.
We want to change our configuration items from the state they're in. We want to move that forward. Typically, this can be done through our change process as a request. Analysts or end users or discovery tools can actually update configuration items as they fulfill the request they're making. They can do that through self-service. If they order a new laptop, the auto provision goes out and acquires a new laptop, and they get sent the new laptop from a distributor. The configuration information is updated automatically. We don't need a human to do that for us. If it's a preapproved change, it can be a preapproved update, which can be trusted as a source of record for that type of information. And it's probably not high risk anyway.
Standard changes may go through a more formal change process, but they can usually be done by functional managers. If an IOS switch for a network needs updating, for example, a network manager can handle that. If a Windows service needs updating with patches, the Windows manager can usually authorize that, and as things get patched and things get released, we can also update the CMDB we're looking for.
Major change is where it gets a little more complex. That's where you usually have multiple configuration items, and where a good service model and system mapping really makes sense. That will give the information to the steering committee that's needed to evaluate those things. This should be something we're looking at. How do we modify the attributes that exist on a configuration item? That's the change we’re looking for. Why? So we can report on it. We come back to this system as a system of record. What would be ideal, as part of the release, is to include the configuration items, the system, and the changes we want to make. We make those changes, and it updates. "Yes, here's the state of that information now. Here's the new configuration."
As we enter a DevOps-type world where changes are being done to systems through a declarative language, that is, we have a software-defined infrastructure and a network change or a hardware change or an operating system change done by a developer with code, it's a great way for the change to be submitted. Through the approval process, we can then accept the change and automatically update the configuration management database. The system's updating itself, and we always have a good, solid state and the records we need to audit them. Row back becomes easier, and decision-making becomes easier. If the system is integrated with processes such as management change and release configuration, this will help keep the system real time and updated. Why is that important? Because if the attributes do not accurately describe the information we need, and it's not up-to-date, the system has no value.
The Y2K Dilemma
For those of you who have been in IT for a while, like myself, you may have gone through a project in the late ’90s that we called the Y2K project. In the late ’90s, it was discovered that certain computer systems would fail because they did not have the four-digit date for the year— we went from 99 to now it had to be 00—that would cause lots of problems. We had to go to the year 2000. If we look at what we did during that project, we went to all of our business partners and asked them questions like "What are the most critical things you need to have running to keep the doors open?" We backed out from there to what technology stacks supported those business functions. Then we went and discovered all the assets that supported them. We even looked at all the vendors who supported them. We built these massive spreadsheets and tables and access databases to create all the relationships and information. The problem was, because we didn't have it integrated with change, we didn't have the right attributes for the activities we wanted to support. By January 5, 2000, all the work we did was obsolete. And so, sometimes, we compare a CMDB effort to a Y2K database if it doesn't have the right attributes. We didn't approach it the right way to keep it up-to-date, and thus, we weren't really making good decisions from that data, we couldn't trust it, and we weren't maintaining it.
When we are interacting with configuration data, we always want to think, "How do we keep that system up-to-date?" The more manual processes you have, the less likely it is to stay up-to-date and the less likely it is to be trusted and invested in.
When we have a system that can be trusted and invested in, it’s really powerful. We can answer important questions such as "I'm going to make a change to this asset” or “I'm deploying this new asset, what business service does it impact?" This allows us to better handle communications. We can support notification of that change to the business-line owners. We can better partner with that business. We can better set expectations. We can figure out who needs to authorize this, and that allows us to coordinate and schedule better. It allows us to look at the impact of that change. We can see what other configuration items are dependent on the item we’re about to change.
Benefits of Configuration Management
If I'm taking out this network switch, is the database backup running across this network switch? Is that the same time the database folks also want to make a major change to their database? Of course, they wouldn’t make a major database change without backing it up. It might corrupt their backup if I take the network switch out, so that's a conflict in our assets. This is a conflict that would be very transparent with solid configuration management. We could look at the schedules. We could see what systems are being changed at the same time. Where are the dependencies upon systems? What are the risk levels? As we know, when something breaks, one of the first questions asked is, "What recently changed?" So it supports troubleshooting.
It also supports knowledge management. If we have a knowledge article about Oracle Forms version 4 support, but the person we’re talking to is on version 5 and we don’t know that because we don't have the inventory of their system, we might give them wrong information. That's where knowledge management backfires if it doesn't have configuration associated with it. If we're not tying knowledge articles to our configuration items, it's hard to expire things when we move those configuration items. For example, if we had an old SharePoint system we used for a document management repository, and we sunsetted some side of that technology but didn't remove all the knowledge articles, someone might go in there and find stuff that's irrelevant. That's frustrating, and it reduces value. If we had built relationships between our configuration items in those knowledge articles, we could have automatically triggered some kind of retirement process.
It also helps with audits and reporting. Here's a piece of technology that supports financials, here's a piece of technology that supports patient records, here's a piece of technology that supports our drug and clinical data. How many times did it change? Who changed it? When was it changed? These are things auditors ask for, and it usually requires an extensive amount of going back and doing data calls. We have to go back and grab all that data. Whereas, if we maintain that current state in a system along with our other processes, this becomes a right-click functionality. You can simply right click and say, “Generate a report” or “Let me see the audit bill” or “Let me see the functionality history.”
Another thing configuration management answers for us is what are the levels of responsibility? Those of you in ITSM might be familiar with the RACI model—responsible, accountable, consulted, and informed. This is how we handle communications, so if I'm making that change to the network switch, who's accountable for that switch being up and running? Who has ultimate authority over it? Who has to approve the changes to it? Who's responsible for actually making the changes? The network director might be accountable for it and might have to communicate network outages or network upgrades to support PNL for a certain line of business or for budget purposes, e.g., the spend on replacement hardware or upgrades, so the network director might be accountable, but who is responsible for it? That's actually the network engineer. He or she is handling the response to the outage notification or resolving the incident for performance or capacity, so if I'm making a change request, who do I need to go to? The accountable person's an attribute inside that CI, so I already know. Your service desk assigning something and getting it to the right person can be automated. Say it's an outage, not a change. Who do I go to? The responsible person. But he or she may want to send a notification to the informed person or the consulted person as a way to let him or her help us or let him or her know about it. That can all be automated. The CMDB has a lot of power for automation.
If I want to do things fast, make decisions quickly, communicate effectively, and get feedback loops, do I want to compile emails? Do I want to compile manual reports and post them to some SharePoint site? Probably not. It's not effective. That's not digital transformation. Digital transformation is when we have an autonomous system that can learn, based on its contextual information, what it's supposed to do and how it's supposed to do it. That's when things change.
A CMDB Scenario
Let’s walk through a real scenario here about how well these pieces come together because configuration management touches every aspect of IT operations—planning, deployment, vendor and supplier management, assets, people, equipment, documentation, policies, processes, regulations, planned strategies. And all of this needs a contextual relationship. Let's see how this all works together. We have an environment here where we've acquired certain assets. We've acquired Office 2013, Oracle Forms, Windows 8, and the necessary licenses. This is software that is either shipped to us on DVDs or that we download digitally. We have a license key. We have contracts for support and for license usage. We have financial information about how much we paid and how we're going to depreciate these things. We have vendors and suppliers—Oracle and Microsoft. The asset management database itself is like a CMDB, except it's more focused on the financial aspects and the vendor and supplier aspects. Each of these will have their own lifecycle and relationships.
We take those software packages, and we create an image that is deployed to desktops. That image would make a great configuration item. We don't need to move Office 2013, Oracle Forms, and Windows 8 to our CMDB. There's no real value in maintaining duplicate information. We have it in the asset management database. We can simply point to it. We can have relationships, and we can create the image that will be deployed and released. This gives us one container with many attributes, such as "When did we create this image? What is it for?" We can include what hardware it's built for, who created it, who made changes to it, so there are relationships out to other things that allow us to query.
Now that we have a configuration item, what does this allow us to do? Let's say an end user has an incident and is going to make a request for a peer. In IT speak, a request for a peer is an incident that we can associate or tag a configuration item to. If multiple people have incidents against this, what would this tell us? It would tell us "Hey, something's going on with that image" or "Something is going on with this particular configuration." Not all users are having a problem, only this subset of users, and it seems they're having a problem with Oracle 4.5. Because we monitor traffic and changes against this image, we notice that we made patch updates to Windows 8.1 on those machines. When we put on that patch, we introduced a problem. Oracle 4.5 doesn't run properly on that version of Windows 8.1 with these patches. Through problem management, we investigate to find out "What's up with these assets? What are their states?" We would use our vendor and supplier relationships to contact them and get some additional support.
It turns out we need to get Oracle Forms 5.0. That's the fix to our problem. What do we do? We open up a change request, which is like a mini project. From here, the change request would request a purchase order inside the asset management database. So in our IT service management solution, we now have records for incidents, records in our CMDB for the image, the association relationship between those incidents and the configuration item. We now have a relationship in the problem ticket we opened against our configuration item, and we have a change in our IT service management solution that also has a relationship to that configuration item. We're now, from change, actually issuing the request. Why are we tracking the request? Because it's workload on our team, and we want to measure and manage that. That request opens a PO. We acquire the PO. We now establish a new asset in our asset management database called Oracle Forms 5.0.
We then need to do what? Well, we need to build a new image. So through release management, we're going to update our configuration management database. We create a new configuration item, a new container that has pointers to the right assets. We deploy that and update the users, and we update their configuration items, their laptops or desktops, with the new image, and we've updated our system of record to know that these users now have the new image, image 02, and not image 01.
What if this was a project base? Say we don't want Windows 8, we want Windows 10. Very similarly, the project is in your ITSM solution. We make the request, the request becomes a PO, and the PO gets the acquisition of the Windows 10 licenses. We would then build a container through change and release to create a new image. Through deployment, we push that image out to our end users.
Importance of Maintaining the CMDB
You can start to see the entry relationship of our everyday activities with good processes, with the thinking of "How do I keep the CMDB up-to-date? How do I keep configuration management up-to-date? What is my system of records?" This allows you to maintain a trustworthy system, and allows the system to live and breath and stay current. It gets really exciting when you start to mature your configuration management system enough to reach certain levels of decision-making. One of those is the audit trail for compliance. How frustrating is it when you do a bunch of projects during the year and, in September, you get audited and have to go back and pull out all the data and relook up all the logs, changes, and work you did? Why couldn't you have built traceability along the way?
Not every change needs a rigorous audit trail. Let's say this Oracle Forms 4.5 is actually for financial records, and because of that, it has a Sarbanes-Oxley policy associated with it. That may change our process. It might change the workflow of how we acquire the new asset, how we make updates to the image, and the logging traceability we put in place. Again, this could be done automatically. There's a lot of value. The system's helping us make faster and better decisions. This is where true agility happens. Sometimes, you might think "Configuration management is overbearing, too much work, too hard to keep up-to-date." But if we think about this properly, if we think about a good, solid approach to this, it can actually make us faster. It also helps us improve communications. There could be a network change. For example, we want to change this Cisco device. How do we handle that? By adding the configuration items to the request for change, we're building traceability. Instead of just replacing the device as part of the project, we are able to see the impact and the risk. What is the relationship between that Cisco switch, the load balancer and the add services we have supported by Add Server 01? We can make the change, and we can communicate it through the attributes of accountability, responsibility, consulted, and informed.
If we're going to put a virtual IP on this configuration item, we're updating it, we know who's done it and when it happened. That's true traceability. If we're swapping out the equipment, say we're going from a hardware to a virtual stack, by having the relationship, we look at the configuration items, and assess which change to make. We dispose of the old assets from the asset management database. The configuration item, though, doesn't go away. It gets updated. It points now to the new assets. We can update this appropriately and see in real time what the risks and impacts are. We have an audit trail of when this was changed and who changed it. We can fully close out the project.
You can see that as things change within an asset, it doesn't necessarily change in the containers of the configuration items. It only means your pointers might change or your attributes might change. Sometimes we need to create a new configuration item, a new container, but the services might not change. We see that instead of being supported internally on physical hardware, then deployed on virtual hardware, it is now being completely outsourced. So you might think "What does this relationship have to do with anything if we're going to the Cloud?" Well, your Cloud still has an asset. You still have contracts there, and it's still providing a particular sort of functionality. And that functionality is supporting a business function, a system, and a business service.
So you might outsource the ownership of the virtual infrastructure or the physical infrastructure by going to a third-party supplier or a Cloud functionality, but you don't outsource the outcome. You still have to maintain support of your business needs and the risk and the assessment of the risk. In this relationship, we don't have as much data we have to manage in our AMDB and our CMDB, but we still have the relationships to manage. We have to look at how we're migrating these services as part of our projects and our rollouts. We know what was supported by Add Services.
Where do I start?
So let's get into some of these things now and take a quick, high-level look at "I understand I need a configuration management system. Where do I start? How do I get my head around this?" It's really, really important that you take a business-centric view of this. Start from the business services down. Understand your line of businesses. Understand the business services that support them, and then start to map that out to vital business functions. Where can you get started? I'll give you a really great hint. After this webinar, go to your company's website and go “/services.” When I was doing consulting work at New York Presbyterian, we talked about this, and we asked, "How do we know what services we should list here?" We went to nyp.org/services, and there were all the services the hospital offered.
You may find your organization has already done this. That's a great place to start. Your marketing team, your chief financial officer, your chief operating officer have all collaborated and worked together to find what the business offerings and service offerings are. They've already mapped that out, so leverage that. Start there. Build those containers into your CMDB, then map them to vital business functions, and then map these to systems. As you map them to systems, understand that sometimes there will be a complex set of systems, and sometimes there will be maybe one server or one piece of software that make the logical relationship.
Work within a price architecture. If you are the enterprise architect, think through what makes logical sense and physical sense to see the relationships. Once you do, you start to get a service model that looks something like this. Here's Bank Byte[LA1] , our fictitious bank. There's online banking, personal checking, and personal savings. Personal checking has some systems that run, but savings has a lot of subsystems, and there are assets that support those subsystems. It gets a little complex here, because you’ll notice that network services and data center services are shared services, so how do they view? Again, it's about relationship. We're not trying to solve the problem of detail, we're solving the problem of decision-making. What we may want to do is have a relationship for calls out or hotline, if your technology supports that, into that information so you can find it.
The CMDB doesn't have to have the detail, it has to have the relationship. Your network services might have their own configuration management system, where they track vendors and suppliers, and their own asset management system, where they track contracts and costs. That's fine. Let's just have pointers, let's just have relationships. That's really the key, because what we're trying to do is navigate these decisions. We're trying to answer, "I want to make a change, but I don't want to hurt the business. When can I make the change?” That should be an attribute of your configuration item, system, or business function. For example, you could say, "For these vital business functions, changes can be made to assets and systems that support them on Saturday night from 7 to 9 pm only." If that's what you've agreed with your business partners, then all the assets have to fall under the same realm. The relationship helps answer the question "When can I change this? What's impacted when I change this? Who authorized the changes?" It's all about navigating the decision process.
Common CMBD Mistakes
What are some of the big mistakes organizations have made when deploying their CMDB? The largest one by far is not properly defining scope. Simply put, not all assets are configuration items. I sit here in front of you today, in beautiful Tampa, Florida, where it's not snowing. I have my MacBook Pro, a Mac mouse, and a headset attached. These are all assets, and they have a relationship to each other. My headset's plugged into my MacBook. My mouse is connected via Bluetooth. Do I really care? Maybe I care about how much I spend on Bluetooth mice, but you can track a lot of that in your asset management database. It's not going to answer any significant question for me. Does mouse and keyboard matter? It might matter in your data center where you have a keyboard video and mouse switch that aggregates 42 different servers to one keyboard mouse and video. You might want that relationship mapped so you know what button to click to get on which server so you don't accidentally reboot the wrong server. Engineer the value. Think about the context. Start with "What am I trying to solve? What am I trying to accomplish?" Get the right scope. So not all assets are CIs, nor should they be. If they can stay in the asset management database, let them stay in the asset management database. Use pointers, use relationships.
Also, discovery is not how you populate the configuration management database. It's how you populate your discovery database. You can point your CMDB to your discovered data. You can build automatic relationships from CIs to discovered data to look at changes that happened. Did a configuration change happen? Was there a request for change associated with that CI? If not, maybe I have a security breach or a training issue. That's great stuff to do, but don't bring all that data into your CMDB. That's not going to work well. It never has. A discovery tool is great for validation or initial assessment. Discovery really is your alternative to doing physical inventory. Use it to look across the network to find out what bits and bytes are happening, who's out there, what kind of conversations are happening, and who's talking on the network. Use it to validate your architectural and logical assumptions.
A last point here—where people fall short is when they try to build a monolithic CMDB. It fails every time. You have to take the systems approach. You have to determine the starting point for information. I would highly recommend that anyone who's embarking on an ITSM journey or refresh start with configuration management. Start at the business service level or business function level and the key systems level. Forget the details of the assets at that point, just start. Then apply change management to it. Through your process of assessing and approving changes, then doing releases, you can then update the CMDB.
Focus on assets that are in flight, which simply means think about the things you’re changing and repairing and building knowledge around. This is a great place to start. Again, it's not about building a database and getting everything in there, it's about making good decisions. Define your scope: "What problems am I trying to solve? Am I trying to do a Windows 10 rollout?" If so, you need to know where all your devices are and what version of Windows they're using. If you're trying to fix a security problem, you need to understand where all your points of entry are and what the relationships are and you need to understand who has access to the systems and who communicates to them.
A CMDB Needs Buy-in from Everyone
CMDB can help you solve many of these questions, but it's only going to solve and answer the questions it has data for. Bringing this project together really requires executive decision and support. I have an expression I've used for many years when consulting on configuration management: “If you want to cleanse the pond, you must cleanse the stream that feeds it.” If developers are not on board with how they're building out their developed applications and configuration changes, you will muddy the waters very quickly. If purchasing is not on board, if lines of business to support BYOD are not on board, if lines of business that are bringing Cloud services are not on board, you're going to muddy the water very quickly.
It takes what I call an hourglass approach. Yes, you need to go to the business and build that business perspective. Build out the business functions and the business services according to your business, then take it from the asset up and meet in the middle. Build the relationship and the context. Bridge that gap. As IT, that's your job. Your line-of-business partners are supposed to figure out which business functions are important. Your vendors and suppliers are supposed to tell you what the state of your hardware is, but you're supposed to bridge the gap.
Define what you need to do and what you’re trying to solve. Determine the most important thing you’re trying to solve. Build scope to find the configuration items and get them into play, and then build on it. Operationalize that configuration information. Operationalize that CI data, and then you'll see what questions you can't answer. The reality is, as you embark down this road, it’s a heavy project. It’s costly, but it will build enterprise agility for you. You're going to have to dodge a lot of bullets. You're going to have to recognize that people are going to want to put data in there they shouldn't have in there. They're going to want to reconcile information that you're not going to be able to reconcile. They're going to want you to answer questions you're not prepared to answer yet. You have to architect the data flow appropriately.
Think about how you’ll get self-service requests into your configuration management system automatically, so you can request new assets and get those new assets without having to have someone go back and update the configuration management system. You’ve built a system that allows someone to get new software on their desktop automatically through a self-service request, so you don’t want someone to have to go back and do an audit log and update. That wouldn’t make sense. Think about the data flow and how you're going to architect and build into it.
I wish you the absolute best on your configuration management journey. As always, I'm here to help. My email is [email protected] I'm on twitter @VigilantGuy. Melanie, I think we have about five minutes for some questions if any have come through.
Melanie: Thanks, Matt. Thanks for a great presentation. If anyone has questions, please use the chat facility or the Q&A facility, and those questions will come through to myself or Matt. We don't have any currently, but we have a couple of minutes if you'd like to put a question through. While we're waiting for those to come through, I want to remind those of you who are regulars to our weekly webinars that once we've held the webinar, we put it on demand on our website at ivanti.com/webinar. If you want to hear more from Matt, his past recordings are up on our website, so please go along and take a look.
In addition, future events beyond our webinar: We’ll be at Pink in Las Vegas in February, and those of you who also have an interest in security, our security team will be at RSA, also in February. Finally, I must mention our interchange conference, which is in May, and that spans all of our IT operations disciplines from service management to asset management, security, and more.
Let's just check the Q&A again. No, I'm not seeing anything come through. Matt, you've clearly done a very good job.
As Matt mentioned, if you have any further questions after the webinar finishes or that you didn't get round to asking, either contact Ivanti directly, contact us ivanti.com, use the Twitter hashtag, use Matt's email, [email protected], or his @VigilantGuy Twitter. Or you can contact him on Facebook or YouTube. Alternately, we will be sending an email with the recording link, and if you think of questions then, please do respond to us. Thank you to all of you who have been on this session. So unless I hear in the next minute, I will call this a wrap and let you all get on with your day.
Oh, hold on one moment. Now they're coming through. Okay, very quickly, Matt. I don't know if you can answer this. From Bobby Finch, we have "Management Suite and Service Desk, what would be used in which systems to build our CMDB?"
Matt: The configuration management system is actually spread across both Management Suite and Service Desk. Service Desk is where your CMDB is going to be, which is the contextual relationships in those configuration items, so you would want to have those containers there. But Management Suite has so much detailed attribute data that what you want to do is have the relationships built. Fortunately, we do a lot of that for you, so I would reach out to support, Bobby, or to your SE who can help guide you a little bit on where we provide that out-of-the box integration. But some of this other stuff you can build your relationships on top of, so the very detailed data is going to be in Management Suite, like What was on that on laptop? How was it frequently used? What was the last deploy? What patch update?
The laptop relationship to the end user is also going to be something that's in the configuration management database, so that as you're pulling up a ticket and opening it up for this new user, you just type their name and immediately see all the information about their laptop or their desktop. There is that contextual information that helps us answer questions like “What version operating system are you on? When is the last time you had a patch update?” All that can be queried through Service Desk into Management Suite in real time.
Melanie: Great. Thanks for that, Matt. And I think we are on time. So once again, for those…a few of you have popped on late. Just a reminder, we have recorded this. We will send this out. Or please pop onto our website in a few days, and we'll upload that recording for you. Without further ado, I'd like to say thanks very much to Matt for another great webinar, and thank you to everyone for joining.
Matt: Thank you, Melanie. Thanks, everybody.
Melanie: Thanks. Bye.