[Music] this is pretty much the topic here of today and first of all i would just like to extend my deepest gratitude to all of you who take off an entire hour of your time to learn about the indeed very exciting topic about service mapping and the title here demystified it sounds very mysterious indeed but essentially this is what we're going to speak about today we have one hour together um that is not a lot of time for such a huge topic so we will do our best to try and cover it all i guess um but let's see here for those of you who have not heard about us before then perhaps i should start with introducing myself my name is alexander i am originally swedish but these days i live here in amsterdam so actually i'm in my house boat now um and yeah i am very very passionate about it operations currently i am the managing director of adrm partners where we are focusing on iot operations strategy and in the past i was actually working in the service mapping team at servicenow now that was many years ago but for you let's say all schoolers out there you might recognize the word service watch and that's really where where my journey with service mapping started so i am super excited to share kind of my input and my lessons here today but luckily i have my good friend with me so who are you fabian thank you my name is fabian kudzke i'm also equally excited about today i'm also very passionate about the itunes topic because i from my point of view it oftentimes is a topic that gets over complicated a lot of times and and it loses the beauty of it um and then i set myself the goal to essentially beautify it make it make it a yeah make it the flower that it's supposed to be and for me the topic of today is especially exciting because service mapping is one of the examples where that actually happens which is also why we came up with that name because service mapping is in fact sometimes a bit of a mysterious um yeah word or slang so to say and it doesn't have to be that way and we hopefully managed to do exactly that demystifying what is behind that uh word essentially or the two words of service mapping right yeah maybe we should mention here fabian that first of all for all of you on the webinar this is being recorded um so you will be able to access this in in retrospect and but more importantly um if you stay to the end you will actually get kind of an opportunity let's say an invitation to speak with me and fabian personally meaning you can book a one-hour free meeting with any one of us um no strings attached but the reason we're doing that is because we know that there might come questions that we are not able to answer here so you will get some some links and instructions in the end of the webinar of yeah essentially how you can continue a conversation with us um and i think that that's it in terms of information right fabian then what are we actually going to cover today maybe you could take this part yeah let's hop right into it so you should also see my presentation now no you don't now you do yeah i do yeah if you go to the next slide right so these are the the four yeah no go ahead go ahead okay thank you uh always good to have some uh someone who can tell you that you're actually showing the correct slide so what we are going to look at today um is from is basically the idea behind service mapping right so we thought of structuring the next hour essentially the same way as a classical service mapping project or multiple projects would go so we're starting off with the topic of initiating service mapping right so what does that mean we will focus there on kicking off service mapping bringing the idea into the organization and what that actually means and why it is important we will then cover the step of preparing and planning such a project which is oftentimes the most important part of service mapping projects and then we will cover the implementation aspect a short yeah message at that point is within the implementation aspect we won't go too deep into the technical details because we want to focus more on the overlying aspect of the part that actually needs demystifying at the moment and the technical aspect has been very clear so far and also we need to yeah cover a lot of topics in just an hour so we decided to leave the technicalities out a bit again at the end of the presentation you will get all webinar you will get the opportunity to talk to us directly where we then also can dive a bit deeper if you want into these technical aspects and then the last part will just be a bit of a review to give you some ideas on how other projects with service mapping have been successful and to maybe give you a bit of a hint or an idea for your own company okay how can we actually get there how can we get uh to where we want to go essentially and those four points will be the points of today again in order of how a project might look like in that way and kicking it off i would actually hand it back to you again um with the yeah with the organization's aspect so with basically how can we as an organization um interact with service mapping sure then um yeah like fabian said we you know we're not gonna reiterate product documentation here so if if you guys have not like um read a lot about service mapping before um yeah there will be parts we deliberately leave out and then as farming also mentioned in the end we have actually done benchmarks um yeah throughout throughout our career careers so we have like 15 service mapping implementations where we can give some good and solid benchmarks to give just indications of yeah of a service mapping project however before we start with that we just need to get to the basic so why getting the organization on board is crucial so this is called boarding the ship and service mapping is a technical topic however i would like to make the statement here that more than anything and this is so so important service mapping is a political battle and i don't think everyone truly appreciates the let's say political battlefield behind service mapping because what is going on when you start with service mapping so the product is meant for mapping i.t services or application services hence the name service mapping and what i have seen in the past based on my experience in the beginning when i started with service mapping then many many projects basically came to a halt so they stopped outright and it wasn't really because of technical issues or technical difficulties but it was always due to the human factor so what does that actually mean with a political battle always when i say this then i always hear from people like but alex what wait what what do you mean with this political battle and there are four let's say very important elements here of this political battlefield because imagine that when you do service mapping you essentially engages the entire itu organization and what that practically means is that you will be speaking to service owners or application owners you will be speaking to various infrastructure teams there will be security into the picture and there might be enterprise architects into the picture there might be consultants such as me and fabian in the picture and so forth and so on now granted this is true for a lot of different transformation projects that you engage you know a large part of the organization but it is especially true for service mapping so first of all security often what we hear when we start with service mapping is that no whale will give access um please go somewhere else so being able to leverage the security discussions with security teams as you are mapping services is super super important um different teams and stakeholders that is exactly what i mentioned and what we often find out is that because service mapping mapping haven't existed in the past you will find different teams who have kind of tried to make their own way of service mapping and it could be like visual diagrams it could be excel sheets whatever it is but the problem with that is that these people then get very very protective of these little babies that that they have created which contains a lot of um i.t information and dependencies and topologies and so forth and that is usually what we also see that that these individuals are very protective of this data um and then you yeah you always have different teams into into the play here now if you are a global organization there might also be regional differences so if you are speaking to one region they will prefer one tool compared to service mapping and in another region they have a different tool maybe or they have a different opinion so regional differences especially in in global rollouts can really really be a factor because every region have an opinion on how i.t services should be mapped and then finally what we often see is resistance like if i had a dollar for every time i heard i've never seen a successful mapping like i wouldn't need to have the job that i'm having now and what i mean with that is so often do i encounter people that and i understand them i understand their perspective based on previous experiences they've never seen like a truly successful automated way of mapping i.t services so they really then become like a stop let's say um so these four elements is the first thing that i want to start off with when i speak about service mapping it is not the technical dependencies it is not you know the the granularity of the i.t services or how they should be mapped from a technical point of view it is to appreciate just how much coordination and politics go into a service mapping project so i just wanted to make this clear and set the stage with this already from the start um and i i think that was pretty much what i wanted to start off with right fabian would you have anything to add there or what would you say yeah just for for the for the stakeholders and uh if you just go back one slide i think what's really important to understand is also why the resistance is there right because usually when when i have service mapping projects the biggest resistance isn't always from a management level or from a support view but it's oftentimes from the people who are very knowledgeable about their administrative work in network environments for example so they know that there isn't a magical way that all of this happens right there has to be some work put in at some spots and sometimes it can happen that the idea of service mapping being that magical tool that just is one click and then everything works that that alone right can lead to the resistance and what can help is integrating these people into the project making them to stakeholders right finding use cases and that will be the part that i will continue in a second now finding use cases that actually helps them to work with service map and give them a reason to be part of the project to then let them actually see how service mapping works instead of just talking about it because it's a big difference if you talk about something or if you show something right because if you can show it and if you get them involved then it's not a thing that they need to talk about but it's their thing that they work with and then really have a lot of this today if i'm not mistaken maybe you could take it off from here because i think this is an excellent entry point to your part here so why don't you yeah i will do so so next part setting the stage so after we looked at the organizational part which is a super important topic i want to continue with the in my point of view the next part where you basically decide if this project is going to be successful or not and that's setting the stage the preparation phase because what i've found is that a lot of service mapping projects and in general other item projects as well live under the big advantage of being iterative projects what does that mean that means that you can start with something that focuses on one use case and then you iterate over it and extend it to grow on a very natural way sometimes what that can lead to is the thought process of oh well we have an iterative approach so if we notice that something doesn't work we can then work on it to make it work and it leads to a discussion where you start to reduce the planning and the preparation to a minimum for service mapping the exact opposite is true so if you go through the preparation exceptionally well your actual implementation will benefit a lot and this is something that i want to focus on in in the next few uh minutes here so these are the four points that i want to talk about starting off with a use case i'm a huge fan and people that work with me know that i'm a huge fan of storylines which is a it's a fancier word for connecting use cases so use case is just a part of a storyline but if i have a storyline it's an example on how a use case actually helps right so last time we talked about discovery where i essentially said instead of just saying okay let's discover all the windows servers make a storyline out of it find the one windows server that doesn't match the configuration it should have right now you have a storyline and the same approach is true for service mapping before you think about what services do i want to map get the use case down i have a reason of why you want to do all of this why do you want to invest the time what is the problem that you want to solve with service mapping grab a pen and a piece of paper write it down it doesn't have to be something complicated right to give you an example let's say you want to do a service mapping approach or a service mapping project to improve your root cause analysis in the cloud environment space that can be your use case but now that you have a use case everything else that follows in the preparation step can be laser focused on that use case right the use case is more important than the service list because from that use case we can now go into the portfolio and we can say okay if we have our use case which are the services that we are actually interested in right so again with that example of actually uh having a root cause on digits for all of our cloud infrastructure services we now know everything that isn't cloud infrastructure everything that has nothing to do with impact root cause analysis right so that isn't in a productive environment maybe everything that is well basically outside of what we would use maybe customer side we don't care about now this is a very harsh thing to do right it can be you can basically sorry impart my english there but you can look like an if you set up a project like that and the first thing you do is actually tell everyone what you're not doing but in service mapping that is super important because what you end up with otherwise is a project that goes over the same thing the same service map over and over and over again because you missed one small little part that someone thinks is important and it might be and this is where the iterative aspect comes in so if you have a use case the portfolio you want to focus on is laser focused on that use case and it means that you one have a list of services that are included for that use case and connected to that use case but you also have a list of services that are explicitly not we will see that picture quite a lot in the other parts as well that are upcoming that it's really important to also define what is not part of your project what you do not care about at the moment if you have such a list yeah to jump in here could could you give a good example here like in a concrete way are you saying then that for example we will only focus on production environments but not on development and keyway environments is that correct right um other other example if you are uh focused on actually just your cloud infrastructure right you would for example leave something out that is not connected to your cloud page so maybe your uh dmz for one customer it could mean okay we are not discovering our um our uh main main server centers for other customers you have a self-hosted cloud environment it could mean that we are including that right yeah makes total sense yeah okay thanks yeah thank you for for the question um okay now that we're done to the services now you have a list of services connected to use case and you also have a a scope of what is uh basically the thing that you need to fulfill your use case and you also know what is outside of it from a service point of view now the next thing is for each of these services and i like to call it the pen and paper approach i don't know about you alex but i've seen some service mapping projects where people are starting the project off with taking a lot of time going into a vizio document and starting to very detailed set up their service picture right and i always thought of that to be kind of ridiculous because you are doing a service mapping project to get that picture so why should you spend a load of time to get to that picture for me personally what is important is and that's why i call it a pen and paper approach is actually grab a pattern grab a piece of paper grab a cup of coffee and maybe your service owner and outline what your service looks like what are the components right you don't need to put in the work to actually get all of the load balancers in it's enough if you just say okay these are our load balancers that's a component of our service and with the width you wanna you wanna determine how wide you wanna go with your service picture so what that means is actually it comes down to the exact example that you just that you just threw in uh alex we have to decide what part of the service tree we eventually just leave out because it's no longer interesting to to us it might have something to do with the service yeah but it's not catering towards our use case to give you an example if we have an application service that i don't know gives us um additional data for our service in the cloud infrastructure example right but it doesn't help us as a root cause analysis part right it doesn't actually impact um in in our upwards view of it then we can leave that out that's the width part right and what we are left then with is a service tree where we know what components we have right and the key part is for that approach we now have all of our components also assigned to our use case so we know that if we successfully map these components into the tree we carry two outs to our use case so after the project we can measure exactly that with our finished mapping have we fulfilled our use case and that brings us to one last part that actually for me per is really interesting and it's the depth part the quality how much do i really want to know about each component and to stick with the example of having a service mapping for our cloud infrastructure um custom advising so productive cloud infrastructure environment if i have the focus on an impact or a root cause analysis all that i need to know or the most important thing that i need to know is that i uniquely identify each component right so that i know which component is uh well is connected to which service i don't necessarily need to know all of the details of that component i don't need to know how much ram is in there i don't need to know how much oh what what operating system it is running at the moment for our use case of having a root cause analysis based on the infrastructure cloud infrastructure i just need to be able to uniquely identify that cloud infrastructure which means that as similar to the width part in the depth i can define for each component what do i want to know right yeah and the interesting part there is oftentimes in these uh root cause uh on a losses part and also the other way around right if you're doing in service mapping for impact analysis the most important information is uniquely identifying something and then having meta data so who's responsible for it whose support who's doing support for it maybe what are the knowledge articles those things oftentimes are more important than the technical aspects but what you are left with after doing that so after first writing down the use cases then selecting your portfolio then pinning the service tree in painting it on an on a piece of paper and framing it putting it on the side of your wall and then defining a depth for each of these components what you're left with are two things and these are really important um and i will explain why the first thing is you immediately get a bigger picture right so instead of just knowing what kind of business services you have your business services are now connected to use cases they are connected to people these business service information is roughly um drawn up it it is a very yeah it's not the clearest picture right now maybe because you have an ugly handwriting or something like that it's not the clearest picture but you have a big picture of your service or infrastructure you know where this project is supposed to be heading you have an outline of what the exact map is and that's really important because the review step within your service mapping project right so after you did the implementation and you now want to see is is this map somewhat right you can now compare that to what you actually set yourself as a target to you essentially what you drew on a piece of paper and the other part is you also have a cut-off point you prevent your project in the planning phase already you prevent your project from running endlessly because you know where you want to go right i would just like to jump in here fabulous because first of all the audience and we're getting some questions here and one of the questions is is it possible to ask questions yes it is you can write questions in the q a and about this bigger picture thing i i find that so important because um like like you mentioned typically seen i.t services doesn't just float isolated by themselves but they are you know connected to something so for some people here maybe it can be a little bit um not maybe not confusing but when they hear business services what does that actually mean well it just means if i understand you correctly here fabian that whatever you know this this application or i.t service is must be doing something it it it doesn't exist in a vacuum is that the correct understanding yeah that's the idea behind the use case um right correct right and i see here um another very interesting question here we only have 30 minutes left ish a little bit more but i really think we should mention this out loud because the question here comes from nikolai um and he is asking essentially what do you do if you don't have architects who can help you kind of map the needed nodes and so on that's a very good question it's it's a very good question because it leads to my next point right the next result which is essentially the brick layer it goes essentially exactly to that part of um [Music] of a component aspect right so for each component you should have something what i like to call a wanted poster where you describe this is the component and then you have the details for it you might you also write down what kind of information you still need so uh nikolai the output of that planning can also be that you are still missing some information the worst thing that you can do at that point is um essentially saying that you're ready if you if you go at this approach and you see okay we have a service but we don't know anything about that map yet then you first before you start off to actually implement service mapping you should take the stakeholders and yeah sit them together in a room maybe a virtual room at the moment and try to get the best possible idea of what you need to know about the service mapping or the service map at that point because if you do not have that picture to start off with you do not know when you are actually finished with your service map right even if you just have a rough picture a rough list of components it will help you because if you have the components down you know who are the stakeholders who is responsible for that component what kind of information do i need for that component um what technical aspect do i need to know and that is the important part to to really have a good planning strategy behind it it also can mean that you say okay we're not gonna focus on the service right now because we're missing too much information i hope that answers the question there are a lot of questions again yeah exactly we're getting a lot of questions here um and i think one i want to pick one under here we have to be a little bit disciplined about the question so we will get back to some of you personally um but one of the questions is hey why do we need to draw things isn't that the purpose of service mapping yes yeah you are right about that however in order to map a service we need to at least have a basic fundamental understanding of the most basic components of that service and what does that mean practically well for example this service we know uses a load balancer this service we know is is a web service so it uses apache it uses this this service we know is also relying on on databases let's say a msequel cluster or something like that you don't necessarily need to draw in detail how the service tree looks but you must have an awareness of what are the components from a high level perspective of the different services because otherwise it's it's very difficult to reach any sort of target or level of completion if you don't have that at least fundamental basic yeah awareness at least that is that is my take on it yes fully agree um there are some questions regarding csdm and also timeline and i i think we at this point i would because timeline is something that you will cover in the next uh chapter i think um i would say that we continue i would take some time to just look at the questions and then come back to the questions uh afterwards um maybe if they fit in well but to complete this point right the result too for the components and the brick layer what you end up with now is instead of having a list of services that you want to go through that you have a rough idea of you now have a component where you can rate the complexity based on the level of standards in standardization for example so are you using uh components that servicenow already has a mapping pattern for uh is it some industry-wide standardized platform setup or are you using a very individualized software is it maybe your own software that you have programmed or something like that so you can rate a component based on its complexity you can assign stakeholders to your component you can have a priority for your components right because one component can appear in multiple services so you can also see how one component might be important to map first compared to another one and you also know how long you will probably take to map that component based on these other factors and that allows you to plan the timeline based on these component aspects alex i would hand it over to you with the actual implementation approach uh exactly because i think let's go through some of the questions by the side yeah um can you see my screen i presume right i can see it again okay good um let's just look at some benchmark guys and we will get into you know these questions and i didn't expect as many questions there is clearly an interest in in the best practices around yeah um but here are some benchmarks um and you know i i know there's a lot of things here on the screen but what i want you to do right now first to be aware of is on the upper right side here um i we we have categorized here service mapping scopes in three different categories below 20 applications keep in mind here one application can have you know many different application services and then we have 20 to 50 applications and then the bigger scope of over 50 applications um so that is what we have to work with now here we have two axes the first one is the complexity and what do we mean with complexity we mean pretty much how complex are the topologies is the service spread out in different data center a mixture of on-prem versus cloud you know what is the level of standardization of the technology are we using normal ms equal things microsoft technologies oracle etc or are we doing something completely customized which you know is is kind of an off bet so that that is what we mean with complexity if you have high complexity then you know the the application landscape is also very scattered and complex then of course the duration i don't need to speak about the duration we all know what the duration is um there's a lot of dots on the screen here right now and i realize you know you probably are looking everywhere around so i'm gonna remove some of them for you and what i want to emphasize here are two interesting data points so starting with these two how come that sometimes mapping over 50 applications with actually a higher complexity than what mapping below 20 applications is with a lower complexity can take almost the same amount of time and by the way this date this data here is real data it's not just invented data but um we we have actually benchmarked 15 service mapping rollouts in six different industries and here is another very good example which is this one here we can see a clear distinction of a high complexity case where yet again the volume of services is higher versus a very low complexity with a few services so how come that duration is so impacted here and what is the correlation this is kind of what i have been scratching my head with a lot when i have worked with service mapping and keep in mind like in the beginning when i started with service mapping then things took time so why is that well it all comes down to the modes of mapping all right so there is not one single truth here all right sometimes one mode make more sense than the other and you know there is it's not a black and white world but there are ways and i think fabian touched upon it a little bit what are central components for example and other things so there are ways of just making this type more efficient because it is about having a structured approach when we target and map services so the traditional one when i started with service mapping it was called service watch this was like six seven years ago you mapped service by service in average a service maybe took yeah let's say three four days it doesn't sound that bad but keep in mind here a service just think of a service as an instance of an application all right so what do we mean with that well there is an instance like a production instance a dev instance q a instance and so forth and so on and obviously if it takes three four days per instance or per application service and if you're a big big company so you might have three 400 application services it is madness to invest 800 days of work on mapping services so more efficient ways had to be developed um but this is the traditional mapping approach where you do service by service and sometimes this is a necessity especially if if the services are fairly unique in nature i often see that for example for sap systems sap systems tend to be quite unique they look very special so then you need to approach it on a service per service approach but the other mode of mapping and this is where it gets interesting and a little bit unorthodox i would say let's look at some service trees here there are patterns that we can see in how a service tree looks so for example if we have 50 services we know that maybe 20 of them starts with a load balancer then maybe 15 of them all have a web server component so the services are actually web services like a website that an employee is visiting or an external website that a customer is visiting but it is some sort of web layer like a web application think apache or tomcat etc and then maybe there is another pattern that 20 of the these topologies they are running some sort of containerized docker solution and then we of course have you know pretty much 100 but a large majority running a database layer so i'm saying this because we can actually split up and look not at individual services by services but we zoom the picture out and try to look for similarities between different services so as i mentioned for example load balancers web apps docker databases so why are we doing this well first of all it goes faster to map because we know that if we succeed in mapping the load balancer for one of these service services let's say an f5 load balancer it is likely to work on other ones as well and the same goes for the web apps and so forth and so on so pretty much it's a matter here of with the least amount of effort getting the maximum amount of results okay but perhaps more importantly this allows you to engage with the different teams way way more careful and strategically because if you do service by service every day you're gonna have to call the database guys every day you're gonna have to call you know the the people that are taking care of the load balancers and there's gonna be so much ping pong game between you that it's not feasible but doing it this way you can actually reach out to the database team and tell them that hey guys we are now down on the database layer for 40 of our services we need to plan one or two weeks of your time where we really target the databases um in our service topologies so that is kind of the gist of this um and i always like to make the comparison that when you do with this approach instead of getting one or two services really perfected you will get a lot of services let's say less perfected but with more data in it so to give like just a practical example it's almost like in the beginning the picture is a little bit blurry and then after a while it becomes more and more clear so pretty much you you reach here a completion of maybe 60 or 70 percent on a lot of services rather than 90 or 100 completion on a few services and once you have that kind of bulk approach then you can start approaching service by services and refine them further this is from my experience yeah the way to go i don't know what would you say fabel yeah it it goes hand in hand with what essentially is the output of the planning right because if you have these overviews and you have these components you can actually group them and now you i think the most important part is actually being respectful of the stakeholders we have a question here from from stefan who said that it almost sounds like enterprise architect related tasks and that's absolutely true and this is why you have to be so respectful about that you have these like oftentimes enterprise architecture people they don't have a lot of time right but these are the important people to get them on board so the more structured your approach is the yeah the better you can get them on board again right so i like this approach so much because it goes hand in hand with what we have just talked about in the first and the second chapter of getting your organization on board and that means to actually yeah be respectful with the time that they spend and try to get it down to efficiency of their time so this approach allows you to essentially have a deck of cards with the components and approach them in in a more efficient way um yeah and i hope that answers the question for for stefan i just wanted to jump and what you say here about being respectful of people's time like if we're looking at a service mapping projects for the people on the webinar um most of the time is spent on internal coordination it is spent speaking to application owners to enterprise architects to different teams and so forth actually a relative small amount of time and investment ideally would be spent on like consulting for example yes you need maybe consultants in the beginning to kick things off in the right direction and so forth but the majority of the time and investment from a budget um and duration perspective is internal so therefore you really need to be kind of clever and structured with how you approach the different teams because if you're gonna ask really busy people for their time then yeah you better be friends with them first yeah you better come around with a cup of coffee yeah exactly and another problem that i often see is that when service mapping happens i've sometimes seen that the rate of adaption is low and what do i mean with that it means that i have seen fantastic services mapped but no one is using them and that is madness so i've been thinking a lot about this how can we ensure that adaption of these services actually takes place so it's not just a project you know for for it department and they map some services but we truly see this being widespread and used and secondly like i said we need to have an implementation approach that allows for smart resource allocation by both parties and what i mean with that i mean consultants and i mean the internal parties at whatever company you're working at so this is a simplified approach here um but what i want to emphasize is on the left side we have something what is called service mapping what so that means that the awareness of service mapping is low the involvement of service mapping is low in the organization people barely don't know about it they maybe don't even care about it um and then oppositely on the right hand side it is when you really kind of create an enthusiasm around the you know service mapping and people start seeing the value and that's when different teams and different service owners starts asking like oh this was really cool can we also get this in service mapping can we also do that so it's really a matter here of creating a culture around mapping services and this always starts like fabian has explained a lot with analyzing something so you analyze the components you analyze topology layers you analyze the type of services the teams whatever it might be you do your homework a little bit and then here is the preparation part yet again which fabian mentioned so this is a long preparation part and i am aware of this it's a bit unorthodox but i call it setting the stage the purpose of setting the stage is to reach out to stakeholders to show them service mapping what it is about how it will help them exactly what you need from them how much time they need to invest and what they get out of it so it's essentially a way of for you to be kind of a diplomat about service mapping and show it to the organization all right because here it's important to include people at an early stage why is that well because when you include people at an early stage they feel part of the process and if you are part of a process if you are part of shaping the future you are more likely to use that process and to be happy about that future if you just approach a team and say hey we're now going to map your services we need the credentials and access or we're going to map your components or whatever then yeah you're not really creating friends you're creating resistance yeah but setting the stage here um it's a variable component so for some services and and for some type of you know teams or technologies it might take shorter time and for other services it takes longer time and then of course we have the actual mapping part i don't gonna go into that and finally embedding so this is when you take those teams those stakeholders that you spoke to in the beginning and you show them the maps and they start using the maps root cause analysis impact analysis they use it in change management they maybe use it in incident management whatever it is auditing etc etc because it would be crazy if you do all of these efforts and map everything but like i said nobody's using it so the embedding part is so so critical to not forget about um so removing the analysis from the picture and now just looking at the blocks we have in front of us this is a modular approach to implementing service mapping it is a repeatable approach which goes through regardless of what it is you want to map or how you want to map it do you do it service by service technology by technology shared components central components it doesn't matter but follow this approach because that is what i have as most success with with and and this is how i've actually seen service mapping truly being used and embedded in the dna of the itu organization and that is super important um so i know i talked a lot right now and i hope i didn't like overwhelm people but what would you say fabian do you agree yeah i actually want to use that exact part to maybe go into another question where someone was asking if if you have a like large trees service trees um is it a viable option to just start with a low approach is i think the question or i would translate that to is it an option to start with a subtree of a bigger business service for example yeah for sure yeah yeah exactly it is it fully is if it caters a use case and you're actually doing something with it you can start with a tree as small as like three ci's right if you for example have event management and all you want to do is check if your applications are running um it could be that you literally just have your application layer and your virtualization layer in there so if you have a use case that you are catering with that approach go for it i highly highly entice it um again because because if you if you do it it's not something you're going to throw out once you start with the bigger bigger trees because at the end of the day if you started off with that um as soon as you come uh and redo it maybe with the bigger tree you don't actually have to revisit that part uh you should review it of course if it still is true but um you can just use it as the foundation and build every other part on top of it so yeah if you if you have an option to do it and you actually use it go for a low approach for this report i would use fabian because i often hear this that well service mapping doesn't provide any value if it's not 100 complete and i say that is false because what actually what service mapping is about it's just tying infrastructure to the application layer right like in a nutshell that is what it's about so even if you just manage to map seventy percent what that actually means is that seventy percent of the sea ice when you raise a change or an incident you see what services they impact so i fully agree it makes sense yeah for me what i like to answer that is another question is the question of why we do i.t service management in general right because it's a bit of a misunderstanding in my point of view uh the hundred percent often times refers to we have a business service and everything dependent to that business service is fully mapped now but that's not i.t service management in a nutshell yes it has something to do with business services but i.t service management also focus around the service management of maybe just one application service that another team is using right so mapping just a part of it can already give you a lot of benefits for example if you if you know what kind of databases are running on your sql server you can also like that connection that's a one level connection right we're not talking about something big but if you have that you also know who to call if you want to change something in that sql server configuration and that already can help you massively in the change management so yeah don't fear of taking a service mapping life that isn't a hundred percent because you if if you started off with a use case it could be that maybe just 10 of the full tree already solves that problem that you want to solve you don't need to be on a full mapped approach on that level yeah i love how you put that because i think it's so true um we all have like eight minutes left so like but i realize that you know there's a lot to unpack here and there's so much about service mapping we haven't spoken about we haven't gone into how you know from a technical perspective you actually have services and whatever but you can reach out to us and we can explain this or you can check the documentation website but what i'd like to do now together with you fabian here is quickly speak about two success stories that that i have been working on and also in your fabian so let's go for it the first one um this was uh one customer case here and they approached service mapping based on the infrastructure types so pretty much here um the challenge was that they had a mixture of cloud and on-prem fairly devops focused um you know kubernetes docker azure devops you know the usual stuff quite a lot of operations partners so that adds to complexity in the political battle right because you need to be able to map services at different i you know outsourcing partners and then they had a central i t so these guys here three months start to finish roughly speaking not necessarily a hundred percent but enough to provide value and the scope was really kind of platform as a service and on-prem services so the things they had like in azure and some of the on-prem stuff um they started off or we started off setting up a core team so a limited proof of concept selecting a subset of services to map then what actually they did was in order to determine what would be the driver for mapping they analyzed high ticket volumes so what type of services are generating most noise because that is obviously where we should you know direct our initial focus so it was really having data-driven decisions here um then they mapped based on the infra types okay so the infrastructure types that i that i spoke about before so you know the component layers like databases web apps whatever it might be in combination with these high ticket volumes so pretty much the amount of noise and the amount of problems that determine the list of priority and they combined it with having this kind of bulk mapping approach and and that really created a momentum for them and after that only then did they add important metadata so what does metadata mean here well it is what does this service exchange data with other services and so forth and they integrated it with like fab and explain the bigger picture and as they were doing that they they were also allowed to phase out an old legacy tool which basically was service mapping but manual customer case 2 that is i found this rather interesting because this was a roll out strategy which was more regionally based and in the end they wanted to create an opt-in program for service owners so there was a global organization that i worked with and a lot of local i.t teams and each it team had a great autonomous so they were allowed to decide a lot by themselves the service owners were allowed to decide by themselves and of course a big variation in buy-in and they also had kind of a driver here a data center consolidation but it doesn't really matter and the scope is what's important they focused on core i.t services and their production environments so first thing they did what is the feasibility small proof of value we measure them the time to map certain things and an end to end flow and what we mean with that is how does the entire flow works between service owners to people that maps the enterprise architects you know how feasible is this and then it started rolling out you know we did some assessment here we did some some tweaks and benchmarks but then we started rolling out service mapping for the core it services and these were central i.t services by the way in a production environments so the most critical services that the entire company was using and their production environments then this is what i like we actually created an opt-in program for service owners so it was kind of a way to approach service owners and say hey if you want a certain maturity if you want you know if you want to reach here we have a program for you and i call it here the illusion of choice because the kicker here was that the service owners were allowed to go with another solution if they could prove that it was more cost efficient and faster however in 99 of the cases that wasn't that wasn't the case so that's why i call it an illusion of choice pretty much they always ended up with choosing then service mapping because that was the sensible decision and then finally what these guys also did was that they connected event and monitoring data to these maps as a second step so this is just some examples of how one might be able to approach service mapping in a real kind of customer based case um and with that being said i think we only have two three minutes left here so yeah what would you say yeah i i just wanted to um be because of of the time i think i uh i won't go through any more questions at this point especially because one of or some of the questions are actually good good for a whole white paper so we'll be or another webinar in itself um so two things at this point um what i really liked especially on the last example was just showing okay there is a way that you can involve your organization in a in a natural growing way right and this is when it comes back to the user stories and what i think is underutilized a lot of the times if you have a marketing team or even if you yourself like to write like some newspaper articles take that ability and write a newspaper article about how the one project the service map that you just mapped how it fulfilled it show a use case how you can now get more efficient right make the transparency because item is something that very quickly can sell by itself by just selling a storyline telling the storyline and i think the last example just shows that very well at that point by the way because i see we only have one minute left and i want to be respectful of people's time and i hate to just kind of quickly end the webinar but there are a lot of questions there's a lot to unpack here this is just scratching the surface but please reach out to us and we really mean this like we're we're not gonna do this from a sales perspective or anything so no strings attached type of thing either scan the qr code right now for fabian or head to another partner slash book and you will directly be able to book a one hour just a conversation session with either me or fabian that's actually half an hour for me okay yeah maybe an hour for me too discuss this more right fabian yeah uh and of course uh one important question that i definitely need to answer is there will be the recording will be available with a presentation and a short summary um i hope in the next few days so either tomorrow or monday um so you will be notified about that because i just saw the the question we will again share as the last time we will share all of the material for the webinar with you right right yeah super cool um yeah i think we did pretty well um i'm packing a lot of things here probably pandora's box so thank you so much everyone for your time it's super super cool sitting here together with you so much fun always as always yeah and by the way stay up to date with with more webinars from us follow itsm group on linkedin or inline partners on linkedin and yeah you will just be in the loop for for more of these type of sessions so truly appreciate it guys thanks a lot thank you a lot guys you