logo

NJP

ITOM Masterclass: Scaling CMDB Governance (ServiceNow)

Einar & Partners · Mar 07, 2023 · video

[Music] thank you very warm welcome indeed to the First masterclass of the Year by anaran Partners um quite exciting um this is a topic which we've seen been growing more and more also lately and something that we have been very busy with so for the upcoming one hour here we will speak about what it really means to scale cmdb governance and how that ties into the culture of a cmdb so it's quite the Deep time masterclass and as I said before we have quite a lot of material to go through but for those of you who don't really know um who I am and who I am who is speaking right now my name is Alexander I am the managing director at nnn partners and as I explained this is a topic which is very very close to my heart because I've been working with cmdb these for for over 12 years now and for me fundamentally the cmdb is more than anything about the human aspects and that's why I'm so excited to speak about this topic and to share some of the insights that I have seen um in my career so far however I'm not just alone today I have another co-host with me so Joshua who are you so I'm Joshua so hi everyone I'm actually a recent import to Europe so I am originally from New Zealand um spent about five and a half years there digging into servicenow as a consultant and then yeah I thought what Aina and partners are doing are really cool so about six months ago I basically traveled halfway across the world and have arrived here and been working with owner and partners since so yeah my main areas of um interests are more along the item side of course being with entering partners and so I've also worked a lot with the cmdb in the past as well yeah yeah I think it's fantastic such a journey all the way from New Zealand to to get all the way to Luxembourg the small town to relax and very super cool all right man so we have a lot to go through today indeed and this just to set the stage a little bit for those of you who are dropping in and joining right now what you can expect today and what you will learn from this masterclass is first of all how do we Define cmdb governance uh it sounds pretty basic maybe but trust me there is a lot of different interpretations of what is cmdb governance um another thing that we will be speaking very heavily about is how do you really create that cmdb dream team I believe you Joshua have quite quite some insights to share there as well um and fundamentally as well what we often see is that one thing which is very important for cmbds is to create that so-called organic buy-in so the cmdb really becomes a phenomena with people who want to use the cmdb so how do we create that buy-in is something that we will touch upon briefly and last but not least we will try here um during the session as well to speak a little bit about common pitfalls and failures so to speak that we have seen when it comes to the area of the cmdb governance um just a little bit of housekeeping before we jump into it so um there is a q a chat box which you should be able to use which means that you can ask questions to us directly we either will answer it on the spot or we will answer it at the end of the masterclass or if it's a to a complex question or we don't have the time we'll get back to you personally afterwards also this session is being recorded so you will be able to find it on YouTube and we will send you all the recording afterwards and third but not least if you're wondering well um what who are nrm partners and why do we speak about cmdb governance we are a specialized firm when it comes to cmdb and it operations and I would say that with the past two years have been exposed to and worked on almost 50 cmdbs so it's definitely something which is very close to our heart um with that being said then just to set some expectations um because of course some of you who are sitting here today you might already have been worked working with cmdbs for a long time maybe or a configuration manager Etc but just a few bullet points here so first of all um what we're speaking about is platform independent it means that hopefully regardless of whatever platform you are using when it comes to a cmdb you can translate this knowledge secondly we're mainly focusing on the infrastructure side of things when we speak about governance we don't explicitly Focus so much on the service layers so like Business Services I.T Services Etc reason for that is it would probably require a separate multi-class in of itself um and then last but not least this webinar targets organizations and individuals really all the way from if you've never really worked uh or you know if you if your organization don't have a cmdb all the way to if you already have quite a mature cmdd regardless of where in that Spectrum you find yourself um we hope that you can take some key lessons out of this um there is one caveat we do assume that the audience knows at least the very basics of a configuration management things like what is a configuration item what is a CI class for example or a CI type um so I hope that sounds fair and square and with that being said let's get into it a little bit um now I always like to do a bit of Storytelling so first of all let's start with some of the common challenges we see and what is the basis of us creating this masterclass setting the stage a little bit um unfortunately cmdbs tend to have a poor reputation you got to keep in mind that we encounter a lot of different organizations with a lot of different maturities and what we often hear is that come on Alex haven't we been speaking about configuration management for 20 years already there are so many examples of failed cmdbs and this is basically what we live to change a little bit um so it's quite common with the mindset to have things like hearing the cmdb feels quite stiff and it just focuses on traditional infrastructure there's too much data and there's no point on keeping track of it all does it really provide any value or things like well isn't seem maybe really an old ideal concept does it really belong in the modern world of I.T um fundamentally I think this deserves to the cmdb deserves to be looked at a little bit differently the year 2023 because a modern cmdb it should be able to support cloud on-prem microservices and business layers so it's not that old concept anymore um regards of the data and this is what we'll be speaking a lot today about the cmdb can either be very minimalistic or it can be super granular down to the bits and bytes levels so it's not black or white um and last but not least then the cmdb is yes an old concept which was created 20 years ago but a modern cmdb we have seen plenty examples of how that can integrate with cicd pipelines Azure devops infrastructure as code all of these things so I just wanted to call out the elephant in the room a little bit that the cmdb tends to have a little poor reputation sometimes and this is something that we often encounter would you say that you agree upon these things is this something that you've heard yourself in your career so far I would agree yeah um but for the most part I would say a lot of customers also do really understand the need for a cndb because you know they've been in a situation where they perhaps don't have it seem to be and they see the real you know uh drawbacks of that consequence so yeah this this definitely still is in the mind of some out there but also a lot do really appreciate the need for a seem to be as well right right so why don't you take us through some of the common challenges that we've been observing so far both of them Partners but also previously in your career yeah yeah so that's a bit of a funny observance that I made because I thought you know moving to Europe I might see um you know pretty different uh behaviors and organizations but actually uh you know we're all human and you know everything kind of affects us the same so you know what I've noticed with uh configuration management both here and back home is that um all of these three common challenges apply so the first I want to talk about is we tend to underestimate the effort it takes to maintain a cmdb so often you know most businesses they might undergo a project to implement a cmdb for example because you know a lot of them might organically grow and they might realize that I'll seem to be is not to scratch so we need to you know give that up to speed so they'll do that they'll Implement some nice new cmdb new processes Etc but then they might underestimate the effort it takes to maintain that state of this NDB um so one thing I often see is you know customers and organizations they might have dedicated roles for the cmdb but eventually over time they'll think oh you know they seem to be fine as it is let's just have this one role take on a little bit of responsibility over here so then they've got less time to spend on this MDB and of course there seemed to be the nature of it is that it's not going to fall apart as soon as you start paying attention to it right right so it is very easy for us to you know simply ignore it for a little bit of time um as it slowly degrades and we can't really appreciate how that affects the rest of the business so that's one common challenge that we see because eventually um you know it'll get so bad that the rest of the business loses confidence in it and yeah that's just not a situation you want to be in so that's probably probably the core um challenge that I often see the next one is that they seem to be is built but not used so you know we'll make a new shiny seem to be but we won't uh maybe organizations don't fully appreciate how it would actually be used by the business or they don't often get feedback from the rest of the business in terms of how can they easily use CNB and yeah how can I serve them and lastly too much data but little value so this really depends on your organization because you know as you said before some um you know cmdb can be very granular or it can be very less granular let's say so depending on the needs of the organization uh some might need a specific amount of data some might not need that much and it can be easy to get a bit carried away you know especially when we're implementing Discovery tools that we just want everything right right we might not think about how do we maintain all of that everything that we take in and are we kind of drowning out with noise the actual valuable data that we want yeah yeah I I think it's it's excellent points and this is obviously something that well I've been observing myself before especially around this this last point of um yeah so many times there hasn't always been like clear use cases defined as he has been like oh this is cool we can integrate lots of data Etc but yeah um that's obviously what we're going to speak about a little bit today not so much the use cases but more like governance around all of this so um yeah thanks a lot for that Joshua um now let's get into a little bit of the actual governance part of a cmbd so what do we really mean when we say cmdb governance um I'd like to first of all demystify this concept a little bit so what most people are used to like regardless of which platform you're working with what most people are used to when it comes to the cmdb it's things like a process diagram what you see in front to be here I'm not going to go through it but basically what you're seeing is the cmdb in the middle and then you have all sorts of interactions with other processes how do we load the data so this you can find plenty of you can find it in ITIL you can find it at different vendors like BMC servicenow you name it tons and tons of process diagrams but that's not really what we're speaking about today so I'd like to show here our interpretation of cmbd governance in its most basic form so when it comes to cmdb governance then we have some core elements on cmdb governance and it doesn't really matter how big your organization is in our experience then whatever it comes to when it is in governance most of those things can be tied to these three main elements so it's either about the roles so who are involved in the cmdb who are the consumers of the cmdd who is allowed to design the cmdb for example then it is the responsibilities and tasks so essentially there what is expected from me um when I'm working with the cmdd um I'm getting a lot of sun in my face there it's a very sunny day um and then last but not least maintaining the data in various ways um so these tends to be the core elements of cmdb governance now if we do this well then we also make sure that the cmdb generates value and let me explain what I mean with this so let's say if you are a configuration manager then probably you are focusing on that the cmdb should deliver value to the business for example um just as an example meanwhile if you're working in the network infrastructure team probably you are maintaining data and you have thoughts and responsibilities to make sure that the data in the cmdb generates value for the network team and people who are dependent on that data so I guess what I'm saying is that these three things combined that is good governance and if we do these things well we also make sure that cmdb really generate that value and that is tangible values that people really feel and can understand and as a result of that if we have values which are being proven of the cmbd it also starts creating a culture so it's a little bit different than a process diagram it's a little bit more abstract but I just wanted to throw out this definition here what do we mean when we speak about cmdd governance it's more on the people side of things how we generate value how we create that culture around the cmdb rather than the process of configuration management yeah and I I see some of our um uh some of the questions and answers just really talking about you know when you talk about creating culture that really drives us forward I would also say that the opposite is true right if you don't make sure that we're maintaining and have those responsibilities and tasks in place you can create a culture that doesn't value the scene to be and doesn't want you know to deal with it so that's also something we need to be careful about and I see yeah some questions answers coming through about that okay yeah very interesting very interesting um so we've been able to observe uh some of the characteristics of let's say good cmdb governance and again you can probably find more points here and this is just some of the the main highlights that we have been able to find but if we speak about good cmdb governance again it's about values that can be demonstrated I'm not speaking about values written down near here in in a paper somewhere or in some obscure wiki page in the internal intranet no no I'm speaking about real values where one team is doing their job better than another team why because they are using the cmdb and they are maintaining the cmdb and they're really taking it seriously um another problem is often the why so why should I work with all of this data why should I maintain all of this data good cmdb governance it answers the fundamental concepts of what's in it for me and what's in it for others if I do all of this why should I invest the time basically um but fundamentally good cmdb governance is also repeatable and scalable what I mean with that is a good cmdb governance it's a framework so you can easily add more people to it you can increase the size you can increase the team that maintains the cmdb you can increase the size of the cmdb the data we should include etc etc so good cmdb governance shouldn't have to be redesigned over and over again but it should be fairly repeatable and scalable so basically cmdb governance is not just a document but really this is the cultural Foundation that makes or breaks a cmdb um now with that being said let's get in to creating the cmdb Dream Team a little bit so Joshua why don't you take over from here and if you share your screen give us some highlights on this topic I see you're still on mute by the way classic thank you sorry that would have called me off guard thank you for that so yes chapter three let's get into it shall we so let's first talk about the sizing and involved roles of the soon to be Dream Team so when we look at this we we often think about well different organizations of course they'll have different sizes of their cmdb different sizes of the cmdb require different expertise difference yeah teams essentially so most organizations we interact with will be small and medium where the smaller uh small teams will only consist of the configuration manager and see our class owners and we'll talk about what exactly these roles are a bit later with medium-sized uh organizations you'll also additionally have a cmdb process owner now this this is not to say that you know for a small team you don't have a process owner but typically that is encapsulated by the configuration manager so with a medium size we typically see that we separate out those roles and make sure they have a dedicated resource for each of those and finally for large organizations and this is you know quite large we even see the addition of a cmdb board um which is I would say pretty similar to the likes of a change board if you're used to that concept where they're really responsible for making sure that the configuration sorry that seem to be is really aligned to the business values and any changes that may be made to the overall process or the cmdb kind of goes through that board and make sure that it's all aligned to the businesses uh goals yeah yeah I I would just like to add there most times I've seen that has been an absolutely enormous organizations like big Banks and you know that sort of thing like the cmdv board is you know it belongs to the few far and few in between let's say that we are working with at least yeah yeah so that's good point so because of that because um the vast majority of people are likely only with the smaller medium that is what we're going to focus on today so we won't really talk about that 70 board more in depth right um so let's talk about watch each role does so again we've got the cmdb process owner config manager and CI class owners so I'll just briefly talk about the primary goal of each uh role so it seem to be process owner they're the one who owns their process so their main concern is ensuring that the process in place is appropriate for the organization and make sure that it meets the business goals of the organization next we've got the configuration manager who are mainly concerned with ensuring that they seem to be itself has quality data and that it is able to deliver what the organization needs in terms of uh you know are we serving our users when their users seem to be can they effectively use it or are we able to produce the reports that we expect and lastly we have the CI class owners so these are the people who are responsible for the CIS um so things like devices you can think of a server they're responsible for owning that and making sure that it is all up to date and they can often work with the configuration manager to make sure that that is accurately represented in the cmdb and as I mentioned before with uh small organizations often seem to be process owner and the configuration manager that role is typically done by just the single resource yeah again simply because it's so easy yeah and maybe to add to this here Joshua is um of course if you go out there and you find like um descriptions role descriptions etc for like conflict managers there will be a way way longer list of different tasks and responsibilities Etc but this is like we've obviously boiled it down here to the main points um so like hence the simplified version of each role here but yeah I agree like these are the most common that we see and like you said like the cmdb process owner and confident manager especially in the beginning phases of a cmdb tends to sometimes be the same person basically wearing two hats It's Not Unusual at least right right yeah yeah that's my expectation all right so let's talk a bit about more about how do the roles interact I touched upon this a little bit but um here we've got a nice graphical representation of this so typically the cmdb process owner and the configuration manager will often work closely because of course the configuration manager is using the cmdb process so they might communicate about you know how can we ensure that the process is more optimized what makes it easier how can I better deliver value things like that and the configuration manager will also interact with not only the CI owners but also other consumers of the cmdb so again they'll get feedback they'll often work with the ca owners to make sure that their CIS are accurately reflected and they seem to be as well as ensuring that the likes of the service desk can effectively use the cmdb to perform their tasks so for example you can think of when we deal with incidents or change requests how easy is it for me to find the CIS that I need to for example and often that can involve other roles but the confeder very good pattern the configuration manager plays a role there as well yeah yeah I see we also received a comment here from from someone of the participants that they are indeed both a configuration manager and a CME process owner at the same time so indeed quite common yeah yeah next I want to talk about concept of centralized versus decentralized teams when it comes to the cmdb Dream Team um and also the other interacting roles so first there is a concept of a centralized uh team where the cmdb team itself they will take sole responsibility of ensuring that uh how would you say like the say the things like mandatory Fields how they seem to be is built what um auditing compliances there are that is what the cdb team in a centralized manner how they will administer they seem to be so we see this most commonly in highly regulated Industries where you know the likes of you know storage teams network teams people who contribute and consume the cmdb they need to adhere to certain you know um audit regulations things like that so they must obey kind of the rules set out by the central seem to be team yeah the next is a decentralized concept so this is actually where those uh consumers and contributors to this seem to be actually have a bit more control about what they can do so this is where they can set their own rules kind of uh think about okay well actually I want this data source to populate for my CIS so they can take on um their responsibility in that role a bit and they can help Drive the business to move in a way that supports what they want to see in their cmdb so they have a little bit more autonomy um versus the centralized concept as well and that's what I would say is that this does require as we note down the bottom this does require more active education because you need to consider that uh you know how well do these teams know they seem to be uh the are there proposals you know do they make sense in The Wider picture things like that yeah and I think this is so instrumental to the topic of governance because imagine you're an organization which embarks on a journey of creating a cmdb it can be a global log or a smaller organization it doesn't really matter but fundamentally you always have these different teams within the I.T Department Cloud team storage Team Network team the Windows Server team whatever it might be so the question is should these teams be allowed the autonomy to take decisions and design their own part of the cmdb to update things there to to have you know a saying when it comes again to the design of things how should we load the data what is important for us should we grant them that autonomy of course still following best practices still having you know um following all the all the rules or should it be a central team where all of those decisions are made for them so this is something which tends to be underestimated I would say when it comes to the topic of governance how much autonomy do we allow these different teams to have of their part of the CMD and there's nothing really right or wrong here but at least based on on my experience what I have the most commonly is like a hybrid model where there tends to be some sort of central governance but then you know you still have that um autonomy for the individual teams that they have a saying at least on this is how we want to design this part of the cmdb um yeah yeah really interesting really interesting um so we have spoken quite a lot about the config configuration manager CI class owners Etc and I'd like to share the screen here now hijack the screen share a little bit and let's speak about the config manager because um the conflict manager is perhaps the most misunderstood yet most important role I would say within a successful cmbb governance model so in my experience then the optimal config manager that is essentially a person who will ensure that the cmdb really gets used keep in mind it's often a large investment we don't build a cmdb you know in a day or two but it's a huge often organizational undertaking so to really make sure that the cmdb gets used given that large investment super super critical um the conflict manager ideally should also derive the development for what um so it's not just a person who is having a list of of tasks and this is what I should do every day but ideally this is also a person who thinks ahead a little bit and like okay how can we use this cmdb to continue to drive development to improve things to help other processes etc etc um so essentially what we're saying is ideally the config manager should be a little bit of a diplomat who can also generate that internal buy-in and excitement for the topic of cmdb um what we often see is and not often but sometimes what we see is that there tends to be a poor assignment or a conflict manager so for example it's just a hat without a meaning um this person X is now a conflict manager good luck um or that it tends to sometimes be treated as very mechanical work where there is very very little autonomy that here is a again list of tasks do these things make sure that these reports are working have fun and also the third point is something also very common is that the config manager don't receive that formal commitment from the organization to really work with configuration management and governance so if you don't have that formal commitment very difficult to drive Innovation then so ideally how we see it is that the conflict manager should really be that go-to person for multiple teams that people keep on referring to and this person made sure that the config management as well as the governance of it really becomes the Beating Heart of the IIT organization and sometimes even beyond the it organization so don't underestimate the importance of a good content manager now I probably know I probably understand what you're thinking now hey Alex how can we find a person like this the market is already tough as it is you know um so what do we do if we don't have this strong Diplomat profile this business savvy person who can forecast thing and you know drive this development well don't worry about it um you can still have good cmdb governance it just means that you probably need to enforce things by policy a bit more and what I mean with that is if you don't have an ambassador and Diplomat well then people probably are not gonna be very willing and understand why they should be working with the cnbd so in that case you probably need to have stronger policy dictated that you have to work with these things um and on that topic if you don't have that sort of Ambassador then management buy-in or having that sort of executive sponsorship it becomes even more critical than um because yeah otherwise if you have a really good company manager who are the Diplomat you can actually have you know fairly lukewarm executive sponsorship but that person is still someone who excites other teams and makes sure that the cmdb is requested um now about this sort of team setup I'm not going to go through the following slide in depth detail for those who are interested we can send out this one later but we've created a little bit of a resource Matrix um for how you can plan the cmdb Dream Team and um we have based this actually on 22 organizations that we have worked with and we have looked at how they have set up their cmdb and you know we have obviously helped them with coaching when it comes to the cmbb so the first thing is the cmdb complexity and what we're looking at when we say complexity are things like how big is the cmdb what is the size of the cmdb how many processes is the CMD be integrated with are we using only infrastructure layers or also service layers what are the compliance requirements that for example Joshua were referring to before so those things together they constitute the complexity of the cmdd and here you see examples of low medium to high um and we can actually see here I'm not going to go through everything but the most common team setup if you have a fairly low complex complexity of the cmdb so maybe just ACG infrastructure maybe some integration to itsm maybe some reporting and that's it is typically the config manager is around 0.4 to 0.7 FTE so um also we here have a CI class owners which are various teams and those teams tends to spend around 8 to 16 hours per month per infrastructure team so what is interesting here is that we see that there is the roles of process owner and configuration manager like we discussed but in a CMB they are a bit lower complexity they tend to be combined into one role basically um now for medium complexity there we start seeing that all of a sudden um there is actually a dedicated cmbb process owner and what we have seen is very common is that often um when a cmbb grows to higher complexity than the previous configuration manager basically takes ownership of the process and then a dedicated new hire is done to hire a dedicated conflict manager basically um then after that on very highly complex cmbbs again speaking Global organizations Banks Etc then we tend to see a more complex setup with for example one full-time configuration manager and then what we call a configuration analyst which we haven't really discussed today but basically the right hand of the config manager a little bit and then a cmdb process owner who is working you know half time only to improve the process and then quite a lot of commitment from CI class owners um of course this resource Matrix is not perfect it doesn't include things like service owners application owners Etc but it's just to give an indicative idea um and at least based on our experience I would say that 80 of organizations they will be able to survive very very long on one FTE as a config manager and maybe also the cmbd process owner it's quite rare or you know it requires quite large cmdbs and organizations to go to go above one dedicated FTE for a company manager basically um again just to give some inspiration there so some final advice here when it comes to this team setup one start small and expand the team gradually and what I think is really important here is to have the use cases dictating the team setup and let me explain what I mean with that so it's very easy to look at the cmbb and look at all the data and think whoa there's so much data So based on the amount of data it should dictate how big and complex the team should be but that's not really true because you can have a lot of data but if you have no use cases and the data is not used well then it doesn't really matter you don't need to maintain it because you don't use the data so if you have a lot of use cases then probably you want to have a little bit bigger team a little bit more activity but if you only have a few use cases like change management Incident Management some basic reporting maybe then you can start really really small um again think about that centralized versus decentralized concept when it comes to the cmdb governance are we going to allow autonomy to various teams is it going to be a hybrid model or are we going to strictly enforce the design and the policies of the cmdb that you know all the different teams simply have to adhere to um be intentional about that conflict manager like I explained before super important often it tends to be more successful to have more of a people person than a highly technical person when it comes to Conflict Management because ultimately a good conflict manager should ideally work on creating relationships and being an ambassador a little bit um also very common is to underestimate the formal commitment so make sure you don't do that when it comes to config managers CI class owners there's always people who need to provide input then yeah it's very difficult to add any sort of value if you don't really have time freed up to create good designs and really think about the team and how would you design the cmdb um so again these are some general advice that we have seen when it comes to creating this successful cmdb team but yeah I hope that it's useful okay um let's make them a little bit more about the governance models and buy-in so you know so far we've spoken about the team setup um we've spoken about you know how many ftes or full-time employees should we have um is it the company manager and process owner the same person what is a cmdb governance but let's speak then a little bit about how do we really generate that buy-in okay so the cmdb is one thing from a technical perspective but how do we spread it culturally and how do we design good governance so let's start with mapping the RC situation so for those of you on the call who maybe are about in an organization to build the you know first cmdb ever or if you already have a cmdb organization but you're suffering from low buy-in so people don't use it people don't take it seriously etc etc then I think this is going to be applicable for both of you it doesn't really matter where you are here I hope you can take some key lessons out of it but there are a few key pillars that at least I've been able to observe in my career when it comes to organic buy-in so the key here is we want people to look at the cmdb and think oh snap I also want this like it's not just about enforcing that you have to do these things but we actively want people to request the cmdb and like okay this really would be helpful now how do we get there first of all define tangible values and use cases sounds really really basic but this is often missed and of course that's you know quite an internal job you can use Consultants Etc to find these use cases but otherwise you know don't do that mistake of building an entire cmdb and then ask yourself like how are we going to use this um because there is always use cases out there there's always values out there of the cmdb but then it becomes so important to really write that down and have it formalized because then you really have something you can measure towards you have things that you can speak about towards other teams when you're gonna generate this buy-in um another quite common thing is one mistake is not including teams early enough in the cmdb build process and it doesn't matter if you build a cmbb from scratch or if you're going to expand your existing cmdb um the mistake or not including teams is what we see being repeated over and over again because think about it if you are not included early enough in the process you are way way less likely to actually use the things but if you are part of building you know good governance you are part of building the future then you are way way more inclined to actually use that as well and speak good about it in the organization and towards other teams um also when you speak two different teams let's say you're a config manager or some someone else who wants to spread the uh the gossip um of you know the cmdb then make sure to find Champions and what I mean with that is in the network team in the storage team in the cloud team there will always be at least one person who is like oh yeah Alex this is exactly what we needed that person who gets it so finding and identifying those Champions and keeping them close to you super important because again they will be your ambassadors a little bit so these are the three let's say key pillars that we have been able to identify when it comes to organic biome um now how do we do this then how do we create that buy-in I mean the pillars are one thing but um how do we actually achieve that organic buy-in well first of all have a stepped approach and a common fallacy that at least I've been exposed to a lot and I'm not sure about you you're sure but I could imagine the same is that something that I often hear is well the cmdb is useless if we don't have everything in it so if we don't have all the relationship all the data and all the context then it doesn't mean anything for us but that's not true I I think that's absolutely not true yeah and I mean that really ties into one of the common challenges that we raised before in terms of some organizations they can't really recognize what the data they need and what they don't but yeah I I do certainly see this a lot where yeah they just want to consume everything without really taking a step back and thinking well hang on do we really need this exactly exactly and also that sort of mindset of it's everything or nothing either we have the perfect cmdb or it's worthless and we shouldn't have a cmbb at all so that's a very common follows him and um there is always value even in the most minimalistic version of a cmbb if you compare it to nothing um but the reason for this stepped approach is that all of these different teams they already have their own tools so they are using a CCM or they're using Cisco ACI or whatever it might be and the idea is not that we're going to compete with them and sort of phase them out um but this is about creating friendships this is about really working smart politically so how do we do that well first of all there is some internal work that you likely want to do first before you even start speaking to Consultants or anything like that and namely one include these key team members early to provide input on the cmdb the creation of it or if you're going to expand it discover those real use cases as early as possible so what can be achieved with the minimum amount of data you know there's always stuff that can be done better and you don't need that perfect world that I explained before um also super important having that sort of long-term vision and being able to explain that super important and being able to create that long-term Mission together with these initial Champions that you have been able to find of like okay well the first step of cmdb the first step of CMD governance the people involved the way we're going to work with it it's gonna look this way but one year later it might look differently because we're going to expand it in the following ways and that's going to put the following requirements on the organization um and also their executive buy-in it's not I would say a lot of people would say that this is critical I have seen organizations where you don't have the executive buy-in but you can still create like a good CMD EB simply because the people on the floor needs it and they understand it um but it it sure makes things easier if you do um okay now after this how do we go on about promoting the cmdb governance then well three main points that we have been seeing here first of all make it super accessible and simple and I'm gonna get back to this in a bit but don't over complicate things with governance it shouldn't have to take like five pages of a Confluence uh site somewhere to understand just the basics of how I maintain data Etc but make it simple have nice dashboards have nice tools make it very accessible for people to work with their data to certify their data whatever it is user friendliness is key because if you're gonna promote cmbb governance then yeah it needs to look a bit sexy it needs to look a bit easier basically um also show that you can integrate the cmdb in other processes as soon as possible so um nobody wants to build a cmdb and work on governance if it takes one or two years before they see any value so really try and identify how we can integrate this into the different teams almost from day one um another aspect work on the internal Communications as well as soon as possible make some promotions about the cmdb about the governance why it is important um and you know really have the organization participate in this because otherwise you're a one-man Army and it's difficult to promote governance if you know you're by yourself basically um and last but not least again these are the basic things so when it comes to governing the cmdb um assign ownerships early so um just having that sense of ownership of the cmdb the earlier you can establish that in different teams the earlier you can establish those ownerships and it doesn't really matter what it is if it is infrastructure owners if it is application owners but ownerships super super important and a lot of organizations struggle there um also listen to feedback from the teams make improvements make it a priority make sure that you really hear them and that you're addressing the concerns or the the optimizations or whatever it might be and also the governance models that you're building and I'm going to speak about that just in a second here do it with teams not just for teams so really make it a co-creation effort to like okay well how do we want to maintain this how should we maintain it why should we maintain it what values does it give or do that together with the teams don't just come up with them with a big list of things and say this is now what you have to do basically um so some advice here on um governance models especially because again it ties into this thing that everybody wants everything from day one um number one when it comes to format and shape of a governance model don't over engineer governance especially not in the beginning I've seen so many times governance you know documents being like 200 pages long and you know it's the most dry and boring thing ever don't over engineer governance there is Beauty in the Simplicity um and also don't confuse the CMD be designed with governance and what I mean with that is we have often seen in governance models that it mentions these are the CI classes we're having this is how the cmdb is structured Etc that really has no place in governance governance should rather answer how do we add new CI classes to the cmdb how do we expand the cmdb what are the policies for it etc etc um and also be a bit creative with the formats of governance it doesn't just have to be one document as I said um something very successful that we have seen is create instructional videos um create small video Snippets for how people create reports how do they find the data how do they maintain the data the more creative you can be with formats the easier it is to consume the governance basically now last but not least when you develop a governance model what we have seen rather successful is do it in MVP versions what I mean with that is don't try to have everything in the governance model from day one but split it up maybe the first governance model is something simple as well this is the security requirements we have these are the basic ownerships and these are the processes it integrates with maybe the second version is this is how vendors are integrating with the cmdb um etc etc so shop up the elephant basically now a lot of talking there and we're reaching almost the end and I see there's been quite a lot of questions coming in I haven't really been reading them have have you been looking into them you're sure yeah just a little bit I think some of them we want to actually answer you know um talking so yeah and I would like to get some of your input as well on some of these questions so sure sure so let's then end off with just um these three common pitfalls we have observed and I think you we spoke yesterday Josh about the first point and you had some some inputs there about this quality that the grades over time could you care to explain a bit more yeah it's kind of like the um I'm not sure if people really uh familiar with this analogy of the Frog and boiling water you know right it's kind of the seemed to be as I mentioned before as it degrades it's really slow so it can be very difficult to really appreciate uh just how much effort it takes to maintain and so if you don't put that maintenance in place slowly over time it degrades um I've seen organizations that you know they allow that to happen and then suddenly they're having to invest in another new project where they have to re-implement their Discovery tools Etc because they just let things go kind of that far along and they didn't have you know those Champions um to really drive that so yeah that's something that I see quite a lot of that I'm uh yeah quite passionate about that's what I see as like the main one of the main uh pitfalls um yeah yeah well another thing that I've been seeing is um you know minimalists in the cmdb governance it's often neglected so what I mean with that is um again it ties into what I said before but there is built in minimalism when it comes to cmdb governance and this tends to sometimes be neglected in favor of over engineering governance models you know people for some reason admires complexity um but really the key often when it comes to governance is Simplicity Simplicity simplicity at least in the beginning then you can gradually expand on it and third but not least another common Pitfall that I've been able to observe is again not making the governance user friendly enough so um if it's super difficult to understand it if it takes a lot of clicking around on some intranet page Etc then yeah it shouldn't take two months to onboard someone to yeah work with the cmdb again make it user friendly whatever it comes to if it's videos that explaining things if it's nice is dashboards but put the key focus on the user friendliness and yeah you will create a lot of friends now we're coming here now to the end of the master class um I'm just gonna scroll through some of the questions here um yeah there are some um there are some questions here we'll get a recording for the session absolutely um did we consider the remote to Source system to feed on cmdb for our resource planning Matrix and can you please share the slide to the audience for the meeting um so yes multi-source systems has been considered the only thing which it does not address is obviously if you do things manually updated then yeah that resource planning Matrix can pretty much be thrown out the window you have to add a few FTS to it but otherwise yes multi-source um in the sense of um you know not only using Discovery but Integrations but there is one caveat to this resource planning Matrix which is it only speaks about the configuration management it only speaks about the CI class owners it does not look at owners for Integrations or the discovery administrator for example that's a separate topic this just looks at um yeah the config management governance in of itself now do we have some more here um we get a question from ingamar um who's writing um I'm wondering about required and the recommended training for cmdb managers CI owners config managers Etc do you have other recommendations for trainings um it's a very interesting topic we are the interim Partners have actually created this is closed training material for some of our clients um I will get back to you on that personally because maybe the rest of the audience could also find it useful um I don't know Joshua do you when it comes to training you know the tasks in the cmdb ETC is that something you've been exposed to I haven't found any courses myself that I can you know recommend on the top of my head unfortunately no typically in the past when I've done training it's always kind of tailored to the organization and they seem to be in place that's typically how I've done it yeah yeah um okay there are a few more questions but I want to be mindful and respectful of people's time and given the fact that we only have one minute left so um thanks so much for participating um it was great to see so many people having joined if you're interested more in the topic of cmdb governance as mentioned you can always go back to this video recording later but if you want no strings attached you can also use this QR code or this URL here another partner slash book and you can then get a completely for free it operation strategy session um with me and with Joshua and we can pick this apart and also don't forget to follow in and on Partners on LinkedIn we have much much more master classes coming up make sure to follow our YouTube channel and as always if you have more questions then you're always welcome to reach out [Music]

View original source

https://www.youtube.com/watch?v=G4qKCMzRm4w