so press record now well hello everyone my name is charles rayburn i am a customer success advocate here senior manager because customer success for the success advocates here at servicenow uh this is our office hour number 26. it's all about csdm best practices this is a continuation from the office hour we had last year i think it was around the december time frame we had invited scott lim one of our senior subject matter experts on csdm he's uh done hosted a whole bunch of customer conversations as well as labs and other things with our knowledge we're really excited to have him here for this hour for those who are just uh dialing in and listening to the recording definitely if you have any questions that you want to ask please feel free to send them to myself charles rayburn or your customer success advocate we'll filter those and send them over to scott and get some good answers but i'm definitely looking forward to this without further ado uh scott uh the floor is yours thank you so let's start just by baselining so again discussion here is common service data model what i ultimately want to get into are some examples we put together quite a few examples towards the end of last year and it's slowly making its way onto the now learning for everyone to see those but i want to walk through those here today so you get some visibility into them and ask some questions around them and then time permitting will be able to show you some forward view elements that we're working on in rome and beyond so again baselining common service data model many of you are familiar with the common service data model with that making sure that we're identifying from a seem to be perspective what are the the best practices or the standards around creating an effective seem to be framework and how we pull those pieces and parts together so that we get the value we expect to see in all the various products that base themselves off of the overall the overall data inside of the cmdb so we want to make sure that we're looking at that repository effectively obviously there are hundreds of tables that exist inside of the cmdb and in the new world as we move forward it's not just the cmdb that we've always thought of where we're focused on the infrastructure pieces of applications and what we have from a hosting or middleware perspective it's really expanded much more beyond that taking visibility into our design objects and our we're soon to release our build objects and then managing things that aren't just i t so let's start to look into the iot the ot those types of elements as we move beyond just again a traditional cmdb so i want to talk about time service data model is it exists today 3.0 is our current version we will be updating this to 4.0 in the rom time frame so that's going to be towards the end of this year and we'll allude to some of those new things that are coming in the future as well as it exists today we break the service data model into four domains we introduced the foundation domain in the 3.0 so it's really talking about critical referential data and the key here is referential data at this time what you see here none of those objects are configuration items in the seem to be they're quite often the reference data that we have as attributes on many of our cis in the future we're going to add business process that's that gaping hole in the upper left in the gray section here that is a ci but it's still going to be referential it's going to identify what are all of the various pieces and parts that make up that process and they aren't just ci's that make up that process it could be locations it can be people it can be documents so that's gonna be something for the future but at this time we're focused on what's the core data what's our org structure and making sure we have that set up properly company business unit and if necessary department understanding locations and managing those those data elements effectively inside of the repository groups and users seem to be group becomes extremely important we'll be referencing that shortly and often both what we have currently available associated to a dynamic ci group as well as development we're working on right now to manage data inside of the cmdb product models have always been an element that we reference on every single ci just hasn't been prevalent throughout the cmdb that's going to become much more prevalent especially as we expand the design domain to include build functions and then contracts are referenced in multiple areas inside the platform now so we just want to make sure we have consistency in the use of those contracts so we're not just looking at them through a single lens of a single product on the platform so that becomes the foundational data obviously you're going to have a process owner that will be responsible for the processes that exist the steward of the overall data product owners as we we show more around product models and then folks that manage contracts so that becomes a foundational piece but now if we should start flowing the story so we'll have business units this is one of the reasons for the foundation to exist identifying our business units and what applications do those business units have responsibility of what do they care about what's important for that business unit to function then they have in essence ownership of the business applications that provide specific capabilities inside of the business so the design view is really identifying what are those capabilities so we can rationalize our business applications our portfolio of applications that exist inside of our organization also identifying the types of data that could exist inside of that application in the future being able to manage that data and so that you know exactly where sensitive data as an example might be used how it's used and audit those functionalities from a governance and risk perspective the business application really is that portfolio it's version agnostic so we're not trying to say exactly every single thing that we have out there that's primarily focused on the data center the cloud environments those things that we spend lots of money on not so much the desktop software and what what is this the essentially the view the portfolio that we have of all these applications as you deploy them we move down the orange section we've got the application service identifying what our unique instances are of those business applications and then all of the middleware hosting environment that exists for those applications the rest of these pieces are who's responsible for managing and maintaining those applications and as we introduced in paris the dynamic ci group moving towards automation the last thing we want you to have to do is to maintain your cmdb manually end-to-end so with that we introduced the dynamic ci group which was actually a pre-existing table we just kind of took it over and renamed it it acts as a grouping mechanism of cis and it's actually referencing a same db group cmdb group is an object that's been in the platform for a while it's a place to store for example queries from query builder so you can have a query of cis which result obviously in a group of of cis this cmdb group is not a cmdci table so what we do is we now have a dynamic ci group which is a cmdbci table that's going to reference seem to be group that could have multiple queries associated to it so now that we can identify a collection of cis for example if i wanted to create a dynamic ci group that said give me all my linux servers or give me all my windows servers that are in the emea region now i'm starting to create through automation a collection of cis that i can then reference to a technical service offering to say these are the ci's i oversee and are responsible for or you can use that dynamic ci group for patch management these are all the ci's that i'm going to be patching put that dynamic ci group as the configuration item in change and today you'll have to create your own business rules to then populate the affected ci's with all of the ci's that are part of that dynamic ci group but one of the elements itsm is working on for the rome releases to have that out of box so you'll be able to use dynamic ci group in incident change and then also identify all the ci's that are part of that dynamic ti group automated as part of that that change process that's a piece being worked out in rome but now that we have that means that we can now create functionality such as that in our quebec release which is released here soon we've added synchronization capability so on that technical service offering which is again identifying who's responsible for managing and maintaining we can have populated our our manage by group our support group our change group and we're synchronizing that onto the dynamic ci group and then on all the ci's that are part of that dynamic ci group what does that give us well now you go out you discover a new server do you discover who owns it do you discover who supports it no that's impossible but so long as you have your dynamic ci groups your your queries established that new server that might be discovered can be automatically associated runs daily to a different group which then automatically is going to gain that manual metadata and put it onto that ci so we're starting to introduce that automation as opposed to the old days of managing everything manually on every single ci we're making it more simple so this orange section is really about what do we have it's deployed technology and who's responsible for managing it and maintaining it as we move into the green section this really becomes who consumes or uses that technology this becomes the business what do they use that technology for what is impacted in the business if that technology has an issue so we're really separating the the functions here of the people who are responsible for providing it so we can do rapid routing of our incidents and work through our changes then also understand what is impacted and who uses it on a service offering being able to identify the subscribe by the users or locations that might use it or companies that might use it so you understand who is impacted and not just what is impacted so this becomes the common service data model as a whole and it will expand as i mentioned there's a piece that we're working on for the 4.0 model there's somewhat of a gap if we go from a design function of hey as an architect i have these portfolio over applications and then i have a bunch of stuff deployed in between there is where you build it where you develop it and a business application could be made up of multiple components so what's actually deployed isn't a single application service for an instance but multiple application services it might be from a micro service perspective where you've got multiple pieces that are being deployed so what we're working on right now in rome and will be an update to the common search data model is an object we'll put in between here which may becomes the components of a business application and that way you can identify those pieces and parts of the business applications maybe the microservices the api whatever those elements are and then what those individual installations of code become as application services so that we can now get a better visibility into all of those pieces and parts so that's something on the horizon for everyone to look forward to until then let's look at examples of what we can do today the traditional example that we've always showed off inside of our examples is what we have for servicenow so assuming since we're talking servicenow on the call you have service now what would that look like built out and servicenow really is a platform application which means we've got the platform and we have multiple applications that run on that platform so in this scenario we've got our business application of servicenow as the platform host an on business application is an attribute called architecture type where you can identify that that's the platform host or it's a platform app that runs on that host so if we look at various platform apps it could be the mid server it could be servicenow change it could be service now hr all of those are platform apps that are part of that overall host so you can start to build that hierarchy of modules etc from a platforming perspective each of these will have their own deployments so from an hr perspective i got my deployment of hr servicenow paris hr prod that depends on the overall platform so the platform has its own instance so it's not a paris prod so you start to identify kind of a hierarchy of your deployment pieces so that if that platform is down or having issues then your platform app is impacted so you start to see those pieces you also notice that we want to identify every instance so dev qa prod obviously at a minimum we want to identify prod but for many organizations we have the ability to identify the other instances as well when we start talking about who's responsible for managing or maintaining these pieces that jumps over again into those technical service offerings where we identify the manage by group the support group change group et cetera as well as its criticality and slas that are associated to it at the application service layer it is likely that you would have two technical service offerings one to identify the team that takes care of the production instances and then the other that is taking care of the non-production instances it might be the same team but they're going to have different criticalities obviously you're going to have much faster response time on the production instances than you're going to have on the non-prod instances so having two technical service offerings in the space becomes valuable because if you start to look at the data to validate if any any sort of sla was breached or ola was breached that's the data that's going to be kept on that technical service offering to know did you respond in the appropriate time for these particular applications now do we usually care about that internally as much as we care about that when vendors provide it these technical service offerings can also identify that the vendors providing that service so did they respond as quickly as they are are contractually obligated to perform so that's where you start to break up kind of a pride versus non-prod view of the management of our applications but as we break down the lower layers of the middleware and the the hosting environment it's likely to have just a single grouping of the for example the middleware management team that takes care of all those applications regardless if it's prod or non-prod or the windows management team it takes care of all of the windows servers regardless if it's broad or non-prod so those layers become much easier to to validate and again the goal here is let's manage the manual metadata on that service offering and transfer those onto those cis as well as how you expect that service to keep important as we move up in the green section as we build out for paris servicenow paris hr prod then we've got what is the business that utilizes that so we've got mobile onboarding enterprise onboarding part of overall onboarding which is part of new employee and human resources as you see here in the green section we're not actually referencing technology so about the technology is really the people providing it and the green from the business services is really how does the business use that technology because it might be serviced now hr today but heaven forbid next year it might be a different application that you use for that so now you can start to swap things out and what you have from a business dependency remains ultimately the same so this becomes that platform view into the environment as organizations build out their applications using the common service data model the first application you build out is never just a single application and the reason for that is you often have dependencies on other pieces so if we look at shared technical services then we have that piece where you actually end up having no green whatsoever because it's essentially technology for the sake of supporting technology in this scenario we've got active directory so microsoft active directory we've got our deployment of active directory we've got all the middleware pieces the hosting the teams are responsible for the various areas but instead of a green section of the business that depends on it instead we've got other applications that depend on it so building out our shared technical services become an important element because if any of those shared technical services go down what other technologies are impacted by it so what we get out of here again is who's responsible for maintaining that technology and then what is impacted if that technology is having an issue so this becomes the value of the common service data model how can i consistently build these pieces out so as our products that are built on top of the platform utilize the data they have the data in a consistent spot and it can provide value to you based off of that data other examples to jump into i want to touch on microservices because it's probably one of them that we hear a lot and so how do we build out microservices in the environment and this really depends on what we're talking about with microservices so i'm not going to get into this whole kubernetes piece because it's already discovered in part of of the itom space but for those that aren't in in a managed system and instead are being independently developed it really comes down to being two types a standalone microservice that other pieces are going to reference a lot or a microservice that's really part of multiple microservices that are part of a single application so the first one i want to show is the standalone and in this scenario what we have is to build all these out what we have is a microservice that we really know we're creating that other applications are going to be referencing over and over again so we're really treating it just as a regular application we're going to have in this scenario it as a business application in this scenario we call it tax calculation and then we're going to have a deployment of it which is it's very specific version in production and other applications are going to depend on it and hit on it and use it and that's it so we're treating that microservice when it's a standalone just as if it's any other application out there where things get a little more different is when you've got multiple microservices part of a single application so let's show that example in this scenario build this out so we have an application called online sales management and it ends up being deployed as online order management version 5 production but it's actually made up of multiple microservices to be able to provide that application so what we're really seeing in those scenarios is it's fine to have a hierarchy of application services this deployment of this application service is actually made up of multiple pieces and parts of which our micro services or apis or other elements that will come together you don't necessarily have to have a unique business application for all of those individual microservices if they exist only under the umbrella of a single application so this is where we start moving into how would we manage these pieces moving forward to understand how would we model out a microservice now in the future we're going to add a piece into this equation so we can start to get some visibility into the design view so we'll actually be able to identify at the business application through what's being done in build what are the components of the business application and then tie those individual micro services to each of those components so that's a quick view of some examples so not to take too much time on cisdm i want to show a few examples and then make sure that we can answer some questions and depending on questions and i can get into some forward thinking pieces so if acceptable i'll pause now for questions and start working through them hi scott this is uh kevin from kaplan um i have a question about your servicenow example uh in the servicenow platform i started looking at the business application and poking around like how does how does the sm change run the business application s and change run on the business application service now because it runs on the platform that it is servicenow that's how you would connect it in in the record business application but for an application when you do the mapping uh you have your dotted lines can you explain the dotted lines and what and what i need to relate them somehow in the relationship table so in a dotted line scenario like this um because the mapping doesn't automatically occur because some change runs on the application that is serviced now it doesn't create the mapping so we have to go create it so let's pull up so everyone sees what you're talking about so out of box as soon as you identify that something is a platform application we then have an attribute so that a reference can be made to that platform host so your question going back to the design it's a dotted line because it's a reference as opposed to a relationship correct that's correct and so is what you're getting at you want to be able to see that in a dependency view correct so somebody uh has an issue with the uh application service and the module that's having the issue is change not incident or hr we need to know that what is what is connected to this application via that dotted line okay but you're not using these objects in incident and change right you're not using a business application as the configuration item in incident or change are you uh at the moment we haven't defined that but i i'm pretty sure that i might get asked that question like if this a module of the application is actually having an issue the platform app is related to the the host i i'm pretty sure i'm going to get asked that question what is uh what is related to that okay two topics i wanna work through first off never ever ever use these blue objects in incident and change as the configuration item reason for that is these are not operational cis they don't give you the detail of how it's been deployed or configured or who's responsible to support it or who's responsible from a change perspective this is more from a portfolio planning perspective that's what these objects are meant to be so they're not meant to be used operationally it doesn't have that operational data detail that operational data detail lives down in the actual deployment so we know exactly where that instance is if i select just servicenow hr okay i could have four different instances which one am i having an issue with and i could have four different prod instances which one am i having an issue with it doesn't give the detail of the actual deployed operational object that's what exists down in application service so application service always should be what's utilized as the configuration item on an incident and change that's not to say that you couldn't utilize the business application attribute on an incident to narrow down what cis to choose so if you were to say hey i'm having trouble with hr i choose it as my business application it then filters down the configuration items to only show the hr application services so you can choose which one is the configuration item that's perfectly acceptable but the actual configuration item should never be any of the objects from the blue correct scenario is you really can show these these references in the dependency view and we went through that in our k20 lab yeah i would say it relies on the application that would be the one that i would choose um you don't create any relationship because you don't have to what you have in dependency views is map related items so i'm going to leave this object go into map related items map related items allows us to identify where we can show references in addition to relationships so in here identifying if i have a referenced from a business application to a business application using the attribute of what we're just on that attribute that gets selected as soon as you say you have a a platform app then it will be able to show in the dependency view those pieces that are dotted line to each other not just full relationships so this already exists this is out of box you'll see some of them that exist out of box will make sure in the future that we make we have business application gets updated in that list as well but just as you would see references of the objects that exist to a server then it's the same scenario you can show in the dependency view reference pieces not just full relationships so we don't want you to create a relationship when you don't have to we just have to add an entry here into the map related items okay yeah that that answers that then just follow up so business applications mapping with other business applications should be done as references rather than relationships when it's a platform yes thank you yep great thanks deb uh kevin and doug uh other questions from uh customers out there feel free to ask i'm patrick from fx uh my question is more i work more on the itbm side atm and uh who do you see uh being responsible for and how do you manage that relationship between the business application and the application service who's responsible for maintaining that relationship that's a very very good question so it's different for different organizations there are some organizations that function in what we call a team view where the team is responsible for everything related to that application so in that view it's not just the business application they're responsible for their they are also responsible for the development of that application and the operational view so they have the whole stack so to speak from business application to all the design components and then into the application service and how it's being managed there that team view isn't effectively represented in any sort of attributes today in the platform one of the things we're designing in rome is that team view it's going to be a related list on the business application some other objects it's going to at a minimum initially synchronize with the attributes contact attributes that we already have on the ci who's the support group who's the change group who's the owner but it'll offer the opportunity to add additional team members so what's my level one two three who's my security person or team that i need to focus on assisting with this particular application anyone and everyone that could be involved with that business application becomes an optional element that you could identify in that team's view it's a piece that we've had requested for quite a while and that's one of the solutions we're going to be releasing hopefully here in rome and that will solve a lot of those those use cases outside of a team view who's responsible for those pieces when we don't necessarily have a team but we do have defined layers well the application owner is responsible for that business application and that could be an enterprise architect it could just be an application owner but they're responsible for that object and how it's being designed they may not be responsible for its deployments but they're at least needing to be understanding in the visibility of those deployments one of the pieces we added in paris was the application service kind of a wizard in the creation so that in that application service we could identify what is the business application so we end up making this more of a two-way street so let me show that piece if you haven't seen it let me jump to another instance so when i go to generate a new application service we actually have a new environment to help create that application service with that so i'm going to be creating a new application service i don't necessarily have it deployed yet so let's assume this from a manual perspective and i'm going to just give it a name what environment so knowing this is dev qa prod etc is going to be important this one's going to just be development for now i'd give a version to it i can reference this back to a model number of what was being generated and this is down below set relationships so whether it's a business application i can identify okay this is actually part of a specific business application i have one in here as i work through this process this will automatically generate that relationship for me so every application service should have some relationship back to a business application and that's critical that's actually one of our defining pieces in the common service data model so this helps us to make sure moving forward as i create an application service i'm actually identifying what is that business application also if i already know who's responsible for taking care of it if i had objects already identified i could identify the technical service offering i can identify the business service offering that this is providing opportunities for in a patch update that we'll have for this in the near future we'll be able to do hierarchies for that application service is this application service actually not directly related to a business application is it actually instead a child of another application service similar to what we're showing with micro services so that piece is going to be made available shortly in a patch update so those are the types of scenarios where we start to make it easier to manage that data but back to your question of who should be responsible if you're an owner of an application you should have visibility and understanding of how and where that's being deployed if you're managing applications that are deployed you should have an understanding of what that's based off of from a design perspective so we're trying to make that visibility both ways so it would be yeah so it would be that application owner once he sees a deployment that would be responsible for going and creating that relationship or is it at deployment that you see the technical side deploy and go through the other side right they create the application service just like you showed and related back to the business application so so today we're going to go in and create those whether it's coming from the business application perspective or the application service the application services obviously makes that a bit easier tomorrow when i say tomorrow these are things that we're working on for rome and beyond we're taking care of that for you so if we consider this a process we've got the data objects we've got the tables of where data should be what we've been working on in in our efforts and development is to now automate that stuff for you the last thing i want you to do and trust me you go bald like i am you do not want to manually maintain all of these objects so what we're designing is in conjunction with devops tying the business application to a devops object as devops does their stuff and does a release it's automatically creating the application service as it does its release if it's not already there and creating the relationships so you don't have to so that's those are the type of pieces that we are creating now we don't want to create more objects in the repository if we're not automating the the maintenance and management of it that's good news great questions very great questions john did you have a question uh john miller uh yes i i did and it may be a kind of like a foundational one so i apologize if it's very very basic um we're a very immature organization so a lot of the relationships we haven't even kind of built into our ci yet i've made the decision that we do not include any um applications as business applications if they don't have a business owner and they're not directly used by the business just because that's where the value is so you use an example of a d as a business application i don't define a d as a business application i don't define any of the kind of what i consider the it infrastructure as a business application am i thinking about that wrong is is what is your definition of a business application that would include things like ad or um other it tools well first off my definition of business application is anything from a data center or a cloud perspective so nothing that is desktop don't worry about managing desktop in business applications that's good i did make that delineation i'd definitely differentiate between application and software which would be on a desktop from there it's really what are you willing to maintain or need to maintain if you need to have visibility into the fact that a shared technical service could be impacting your application then certainly go ahead and build it out if you don't need to have that visibility then don't build it out i'm of the type where i don't want to boil the ocean because the more data i put in there means the more data i have to manage and maintain so slowly growing into it perfectly acceptable take care of your critical applications first that you really care about and if you need to get to further layers as you do those management efforts effectively well you're creating the proper processes and the culture to manage and maintain those so as you add more into it it's not as as hectic to maintain more ci's so your approach isn't wrong but in the long run you might find that you need to have those objects in there when you're ready to maintain all of them okay good now that's that's helpful um i will kind of continue my path at the moment but i will keep my mind open to when we reach that point where it may make more sense to um increase the scope okay thank you hopefully it doesn't get to the point where the active directory does cause an issue and now someone says why weren't we maintaining it so you want to do it just before that okay gotcha okay i'd like to follow up on that question before uh i i really appreciate your your uh guidance on being flexible and uh in the context of creating severity ones this i always struggle with this uh we want to effectively communicate to our organization the status of our systems where would you advise to focus on that what would we create the outages on business application application service uh if you could give some guidance there i'm struggling with that right now so specifically focused on outages yeah specifically focused on outages being able to keep the uh we use a subscriptions so people subscribe to things for notification right what i need to expose our common service data model to our customers as well i want to make it digestible for them so you referenced outages and so that always kind of tweaks my my interest because it's a very specific technical capability inside of the platform so for specifically referencing outages at this time the value of outages has to be at the service offering layer so though you and i can agree that it could be the server that is causing the outage and we want to make sure that we identify that that server has an outage the capability that we provide and depend on at this time is at the service offering layer so there's nothing to keep you from putting that outage on the server or on the application service but ultimately it has to get associated to the service offering or any of the data roll-ups will not function and i say at this time because the functionality of outage that exists today in the platform has not been updated since it was originally created and i've been around service now for eight years i started in the the aspen berlin days and i do not think that has been updated since then now as i mentioned the scenario of really we're talking about that application is having the outage or the server or the network well i was always taught network never has an outage so we'll ignore that layer but from that perspective you want to get as close to the item that's causing the outage as possible but in servicenow all of the functionality is focused on the service offering so you're going to have to do it in two layers at this time but we are fixing it we have that on a road map that we're identifying where we can improve upon what outage is and what is outage because outage doesn't necessarily have to be a hundred percent it can be where something is impacted but not completely out so we're doing layers to all of that so really improving to what outage always should have been but that's taking a little bit of time but today with outage you can identify an individual ci but you ultimately need to get it to that service offering and then the data roll-ups on that service offering you start to identify what is that how is that performing and if you don't mind i can show you real quick how that starts to look i don't know if anyone has been to the sketch holder that is also one of the next questions is being able to report our uptime of our services to our internal and external customers ah you're gonna love this then we'll go with intro we're starting out okay so i don't know if you have seen service owner workspace this was introduced in the new york release it's part of itsm pro and that's where service portfolio management lies is in the itsm space so i'm actually in their demo instance because it needs a little more data than i have on my personal instances and so they have this service owner workspace and that service owner workspace as i start walking through the hierarchy real quick just so you start to understand it's based off of having a service portfolio so i have my services but then they're in a hierarchy of a portfolio and that's where this data starts to lie as i'm going to start building into this view of the service portfolio and my business services and my business service offerings so that's the area i'm going to be focused on right now so i'm in i've got service owner workspace i open that up gotta log in of course and this view that you're going to see this workspace view that is the user experience that much of our platform is migrating to right now you're going to see a similar environment released for cmdb management in our in our rome time frame so this view that you see here so this first off i'm having a hierarchy this is that service portfolio hierarchy first i've got amias i've got i've got sorry i got america's i got emias i'm going to go to all services and emeas these are all of those you start to see some data roll-ups based off of that hierarchy i'm going to go into hardware support this is one of those nodes in that service portfolio service portfolio are not cis this is an spm thing but we force them to make it out of box so that everyone can use it this becomes a rollup so this is a node hardware support is one of the nodes in the the hierarchy in service portfolio and you start to see you've got an owner at this particular node level you've got a rollup of the spend and performance of however all the various nodes coming together start to operate there's more nodes so again this is a hierarchy i'm going to go into print scan fax again this is a node and service portfolio i'm not yet to a ci but here i can start to see my first ci so this is a business service of printing services i could have multiple business services here that are part of this particular node in this scenario i just have one but i've got a node owner at this level that's in charge of print scan fax and start to see some roll ups but now i can get into my first ci so i'm going to click on that and this is a business service unlike form views today which are static and and not pretty this becomes the view of the future so when i say a workspace what we're working on in cmdb is our very first landing page for seem to be using this workspace type of view so this is going to be the future here and then we'll move into even better user experiences after that so this is a business service and so as you see i've got details analytics about the business service not just attributes on the ci how is this business service performing and as you see over here outages because it's looking at the outages of the service offerings and rolling it up to assume how my overall business service is performing based off of outages on those service offerings so this data that i'm seeing is really a roll up from my service offerings of how we're overall performing but i can go into an individual service offering to see how it is performing but these information elements that you're starting to see here what are the trends you start to see elements over time relationships this is actually the piece i like a lot what do i depend on and what pieces depend on me and so having that view becomes extremely important and again this is at the business service level so if you think about your your customers or your executives where they want to see their pieces and how they're performing they get to see their view here not the customers but the the folks that own these services and run these services back to the overview i'm going to go into the business service offering so this is a layer deep in that hierarchy we're now at the service offering and again these are the outages i've got nine recent outages that's probably not good and currently have one that that's working through so you start to see the view of outages which give you your availability so this is that piece that outages as they're designed today are based to give you visibility and value at the offering layer so you're not going to have availability at the server layer you're not going to have the availability at the application service ci instead it's going to show at the service offering as of today but this so long as you have those service offerings whether it's from a technical perspective or a business perspective you can use this availability to see how it's performing so that's that piece i want to tie in i also just wanted to show you workspace so that you understood this is the direction of our user experience and not the lists and forms that we have known in the seem to be since the dawn of time does that help actually you did say something critical business services are not cis right business services rcis it's service portfolios are not cis service portfolios thank you yeah so when we go back to the model we see service portfolio here those aren't actually cis business services can be business services rcis yep yeah there seem to be underscore ci underscore service they're extended off of the course assume to bci so they are cis and service offerings are cis basically in the blue orange green sections the only things that are not cis request catalog items are obviously not cis that's part of request in catalog and the service portfolio is not aci what would you recommend for someone that doesn't have this uh currently implemented in a crawl scenario great question so let me get to that we put that together there's two views really when you start thinking about how do i implement and based off of i was in professional services for many years i've i've managed my own cmdbs and implemented many of them around the world and there's really two views and not that i want to say maturity because people don't want to be called immature but it's where is your perspective and visibility most organizations especially from an i t perspective have visibility into their applications and they consider their world revolves around the applications and not necessarily what their business services are most it shops don't know what the business services are so from that view we look at this from an application focus perspective and so from there again with our cstm3 we introduce foundations let's make sure we get our foundational data set up right and if you're a large organization with many locations you understand the criticality of making sure that core data is set up properly because locations are probably the most duplicated entities in the core data when we've got the same location listed multiple times but with different labels so again foundation is important crawl is really about that start of the application world what's my portfolio of business applications where do i have them deployed and assuming i have some sort of automation discovery or service mapping what are all the pieces and parts of what's been deployed that's crawl and that's where you start so you just start out what are my portfolio of applications a question earlier what do i consider a business application start out with your critical applications the one that you care about the most if there's an issue with them once you move past those then where the next level of applications that you care about focused on the pieces that are data center oriented not your pc software so that becomes your path in building out crawl and what applications to focus on and start to understand where are they deployed where's your production instances at a minimum and if desired and needed where are your subprime instances and identify what those objects are and then start tying everything that you can find in discovery to those pieces that's crawl that's how to get started in an application focus from there immediately and as quickly as possible who's responsible for all these things as i have my deployments in that application who do i need to go to if i have an incident who do i need to go to that's going to perform the change at all of those layers whether it's at the application service layer or the database or the host whatever those are who do i go to you now have the foundational information to create a technical service offering which is the object that says these are the folks responsible for taking care of these things so you'll quickly move from crawl to walk just by identifying who's responsible for it and grouping it together now the reason for grouping this together and i'm going to give a shout out to to novartis who did this first and i thought it was a really good idea and that's why we latched on to it managing all of that manual metadata on all those individual ci's especially discoverable ones is frustrating you'll you'll go paul like me just trying to manage all that but if i can identify for example the team that's responsible for all my windows servers and identify their support group their criticality and the change team and now i can reference all of those cis that are part of that team's efforts now i'm not having to micromanage hundreds or thousands of ci's individually instead i'm managing one and synchronizing that data onto all of them so that becomes the the reason to quickly get to walk as quickly as possible so that you can easily manage these cis because you don't want to do it manually how quickly you get to run and know what your business services are you know that that's the baby steps some organizations can get it done in six months some organizations it takes years uh canadian national rail before they came to servicenow they spent two and a half years just trying to figure out what their business services were one of the reasons why they chose servicenow was because we had a capability to understand services and layers of services and how they offer and support the environment and it allowed them to slowly grow into it and they spent approximately two to three weeks trying to understand what their services were in relation to how we identify them in service now and they had a partner help them and they had tbm as a foundational element to look at but they spent two to three weeks previously they spent two years so having a structure that has you slowly move into it rather than trying to boil the ocean to do it all at once is extremely helpful and they were able to implement in six months so think of it as let's focus on the technology first my applications where they're at and what makes up the pieces and parts of them and who hosts them then who's responsible for maintaining them and then how does the business actually use it and then you'll slowly move into cstm in a more effective manner again this is focused on an application view it could be a service view you could know what your services are and this is few and far between it's usually the regulated industries and i'll be honest europe that is more more effective at doing this but it might be that instead i'm building out my services first and then identifying what my applications are in the infrastructure and tying it all together so those are our different views on how to put that together does that help out yeah that was amazing explanation thank you i'm glad that i got that recorded um what time for one final question patrick did you have one i was just gonna say if i have follow up on that i i usually uh tell them that my the business services they don't need to be all at the same maturity stage would you agree with that i could have like printing is very mature in the same enterprise or same organization but not uh you know web hosting doesn't have to be at the same maturity yeah perfectly acceptable again similar to the earlier question it's all about what you're comfortable doing don't feel you have to have every single answer out of the gate once you get started i found once you get a few of them built the folks that aren't as mature or aren't as confident in their data they look at that as the example and say oh oh i could do this this and this and oh what about this and now your view of the scene to be starts to explode because people are understanding it and then they're getting excited about it so you got to start somewhere don't feel that you have to do all of it at once so totally great all right well i appreciate you all thank you guys so much thank you scott kevin did you have one more question are you guys good i'm good because it's this is perfect this came up today because we're starting this exercise this afternoon go for it yeah all right well um i just released a poll into the uh the chat window um definitely feel free to fill that out before you guys head out this is a means to get us some good feedback so we can help and improve these office hours thank you as always scott um i can just tell you by all the different types of feedback we always receive it's just a pleasure having you on these and the amount of information you relay is just really great so thank you for that thank you customers for joining as soon as you guys fill out that poll uh have a great rest of your friday and weekend and for those who are listening to the recording definitely continue to watch and look forward to new office hours so one more big item we do have the office hours hosted now on our community page so i'm going to show my screen give me one quick minute and a link i'll put inside the chat window uh let's see here okay i'm sure my screen if oh here we go all right can you guys see my screen okay uh here we have it on our itbm community site the link is here i'm gonna post this into the chat window it's communityservicenow.com community and you're going to look up for the itbm and inpound office hours but that's where we're going to have all the recordings for these moving forward so i won't be sending out the recording like i typically do um on the email invite rather we'll just be posting them and as you can see we have all of the office hours that are upcoming so you can register for those here by clicking on the link as well as access to all the older recordings of any previous office hours that we have so scenario planning was the one that we had in january 29th the office our recording is there and as soon as it's available here from zoom we'll have the one from scott lim as well uh posted up there so thank you all so much um put that into the chat window let me know if you guys have any other questions but have a great uh friday and the rest of your weekend great thank you great session thank you you