[Music] thanks scott i wanted to talk a little bit about today the technical services and how important those are and how those kind of play within our platform and the way they work with regards to the dynamics group and the application services great just to kind of add some color i'm finding this to be a really important step for folks i know we have it on our craw walk run fly methodology and when we talk about the the crawl part i think people mostly get this most the folks are are just moving the discoverable application into the right tables at the business app level establishing app services for the first time potentially but they're just getting the conceptual logical physical tier of the model kind of straightened out when we get to the technical services what i find is that there's a couple things with regards to defining these technical services the offerings in the dynamic ci group and how those relate to the underlying discoverable piece part so it's pretty important and very i would say foundational for how customers need to think about and evolve their their services portfolio which is now also an option agreed i also think it's the easiest introduction of identifying what the services are inside of an organization especially when we talk to i.t people and we ask what are the the services that you care about usually those it people start talking about it services and specifically the people that are responsible for for providing in the care and feeding of the technology so this becomes simpler services to start to build out and understand yeah and i've also hired them called shared services or foundational services i.t services there's a bunch of names that are used typically but that's kind of what we're talking about here right correct okay so in here we've got three different types of technical services in our diagram and i want to just take a moment and just clarify what we mean by all three because they're here of course we need to cover the bases when we're talking technical services so why don't you provide me a quick overview sure we'll start at the top so i think one of the simplest ones to focus on is the application service order so that would be the various teams that are responsible for the applications and the instances of those applications that are deployed inside of an organization and so whether or not that's a team that oversees multiple applications and their implementations or if it's a team that's focused on one particular application that just becomes essentially what are those teams i like to tell folks when they get started is think about where you have support groups set up for your various applications whether you have a handful of support groups or a lot of them based off of individual application services the instances that helps you to determine your technical service offerings because that's really what what's the team that's responsible for this particular instance or instances of an application and so that becomes the the quantity approximately of what you need for technical services and that again is specific to the folks that take care of the applications or the platforms that are in an environment we want to make sure we we talk about the platforms as well especially from a shared service perspective because the platform is just as important as the applications that run on or within those particular platforms yeah i often think about these guys as really the building blocks right they understand an application and they're providing services which other folks will consume more in a technical manner right it's especially like the platform right a platform by itself doesn't do anything you have to get to configure stuff or deploy things on the platform and that's more of less of a technology consumer and by having that technical service offering for that application team they then have an object that is theirs and then everything that is related to it all those application service becomes the objects that they have responsibility to and it's easier to manage all of the information about that team as well as any sort of kpis associated to their services on that one record as opposed to trying to manage it uniquely on multiple cis inside of the instance okay so your team basically has a new home they can define their technical service the offerings sla ola commitments and then what instances of their apps or application services or and we sometimes also call them systems that they are responsible for is that correct that is correct one nuance in this space in the application service space is that technical service offering for applications you might have two pieces to those technical service offerings and i say that because of any sort of commitments or any sort of criticality that you put on that service offering and that relates to the environments of applications so you might have a different criticality for the prod instances that you take care of different from dev and qa so that way you might have a technical service offering say the team that takes care of servicenow you would have a technical service offering for the prod instance of servicenow and all of the criticality and slas associated with that or slos and then separately a technical service offering for the non-prods whatever they are not saying one for each type of environment for but one that encompasses all of the the non-production instances so you still know who's responsible for those particular instances and that helps you to kind of micromanage the performance and the kpis associated with those various services right so anything fails right they'll they'll be informed up through this route basically correct i like to call those that section of the managed technical services the people who provide and maintain the technology in this layer focused on the applications right and you don't need a business service these are mutual exclusive you can define this and not this or the other way around as well especially when we start talking about a shared service so for example a platform that is shared between multiple applications those applications might have a business service that uses it but the platform it runs on isn't necessarily business facing it's just a shared service that's provided inside of the technology environment so there's no requirement that an application service has to directly have a link to a business service it could just be through a hierarchy eventually gets there yeah so so there could be app services on top of this that depend on this common platform platform itself doesn't provide a business service but the app services on top of it do correct yeah and another example of that we'll just use servicenow servicenow as a platform yet the functionality of performing hr inside of the platform you would have two different application services one for the platform and one for hr and that way hr would be pointing to its business services but hr runs on the platform of servicenow and so it wouldn't have a direct business yeah yeah so hr would sit on top of the common platform and this this is one of the examples that we talk about we'll put a link in here as well so folks can get to those examples excellent so that kind of covers the first level right so we kind of covered off of this one now what about the second one here where we have the dynamic ci group involved so we like to call this the infrastructure and the infrastructure isn't just hardware this is also the middleware and from a cloud perspective it's also your cloud instances so for those application services or systems to function they are connected and hosted in some manner so it's all of those pieces from that connection standpoint the hosting standpoint as well as the network that get identified as the various layers that exist in order for that application service or system to exist if we look at each of those layers stratify those out chances are we've got teams that are responsible for those various layers and let's just assume in the application layer we might have a database and so in that layer we want to make sure we identify who's the team responsible for that or those databases it could be the entire oracle team or the entire microsoft sql team or a team that's responsible for the oracle databases in a particular region however it's broken up again looking at the support groups that are responsible for managing and maintaining the databases let's create a technical service offering that's for those groupings in this example databases and and make sure that we have that view for for what they are responsible for and that team then has an object to identify what are all the pieces i'm responsible for and how are we performing how many outages or incidents or changes do we perform how is my overall kpis and then other teams get to look and see what services they rely on and so from the top section the application team can know hey i'm relying on a database service this is the specific database and then this is the service team that's responsible for providing it and so you get more details to the stratification the various layers of technology that exist in order to provide that application so the database layer the hosting layer whether it's on-prem or in the cloud who's responsible for that hosting any sort of networking that's associated to it things that would normally be found from a service mapping and discovery perspective are those layers that we want to make sure we identify none of the infrastructure in a perfect scenario should exist without knowing who's responsible for providing it and maintaining it and those those layers are the technical service offerings who provides it and maintains it yeah there's a couple things that really kind of uh i find resonates for folks one of the things that it's really powerful is there's a query here and and so you can query all the network gear or say you know only the network gear in this data center is uh kind of going to this group which is different than the one that manages a different data center so you can kind of set up that query to match up with what they particularly own in that offering anything that we can use as a data element to query we can use then to group cis and then in that grouping of cis in that dynamic query perspective then we can tie it to that technical service offering in the old days we had to manually do all those relationships and no one ever enjoyed doing that so now by using the queries we make this so much easier yeah yeah and sometimes i know that some folks will use a different uh product that might do it at the ci class owner level yeah you know any words about you know the class ownership versus the query approach because i find queries a little bit more flexible really they're and they're designed to be more flexible from a class perspective the goal was just to be able to do a default so from a class perspective let's identify the responsibility and and where that management should be but that was just so that if something gets discovered brand new we at least had a name or a group to associate to that new object that was discovered as opposed to having nothing so it's kind of the backup default of what can be identified just through an overall class view but what we ultimately get to as soon as we start moving into that walk stage is really getting into the identification of the teams that are responsible and giving them a technical service offering object that represents them and expectations so that we can then associate those pieces that allows us to as you said use queries to break that down even further and it's actually designed in a manner to override the generic view from a class perspective so it becomes layering if there's nothing known from a technical service offering it and a dynamic query then at a minimum we'll go with the class view of ownership but if we do know based off of that query who the owner is because it made it into one of those dynamic queries and then can be tied to a technical service offering then of course we want to be more finite and i understand exactly who's responsible as opposed to more generic for an entire class yeah so i can put some catch-alls at the class level so if a new thing shows up that we've never seen before as long as it's classified as hardware for example you'll get some ownership that can look at it right and if these queries need to be adjusted of course then they can start accounting for this new thing that shows up and ownership is never something you can easily discover so we've always had that ask whenever we went in and worked with customers about fixing data one of the top pieces is they don't know who owns the data this allows us to at least categorize the data and put some ownership based off of categorizations and classes as a stop cap yeah so i'm going to switch gears for real quick and i'm just going to show what this looks like in the service builder so just coming back to how we do this within the platform this is the nice new service builder that came out in rome to create a a business service and or a technical service and define some of those things that we're talking about in a nice you know methodic way including the offering a lot of folks say well how do i create an offering well it's just part of the service builder if you use it there you go there's your offering you're going to define it and then you're going to have that as part of the process and the thing i like about this is that you don't have to worry about what relationships you're dealing with you just go down through the raw the process uh and just a quick word on service classification will you because i know that that does show up here and there i know that we want to get away from it so what's your take on that and what should people do so this is a legacy piece where on the course service table is the service classification and this is back in the days where all services shared the same table inside of servicenow over the past few years we've started to take what we identify as the classifications and made them extended tables dedicated tables so we have a dedicated technical service table we now have a dedicated business service table so the need for that service classification is going away it's not all being shared in the same table now they're living in their own table and the name and function of that table is at that classification so that is the the history and the legacy of the attribute but not all customers have migrated into the new tables yet many of them are still in the same shared table at the the core of services so this is an attribute that although his legacy is going to stick around a little bit longer until we get everyone migrated into the new system of dedicated services and then we won't have to have this particular service classification anymore there is a piece that would exist from a service offering view but we're looking at ways of deprecating that need as well yeah yeah and the thing that i noticed too by using this user experience it automatically sets everything up so you don't have to worry about you know doing the right classification i mean you don't have to be an expert in the data yes well our goal scott is to hide that complexity right people should never have to learn the data model it just happens i would love to have not had to memorize every aspect of the data model yes but uh okay so when you're defining the service you have certain elements you can define in terms of ownership but we don't have support group here and that's we get to in the offering definition as you continue down this path you deal with performance you set up your kpis associated with this at the service level you manage the offerings you create the offerings so it's creating these objects in the background i don't have to think about it when i create it the right relationship is set up the right offering type what the technical service classification is set up and you can give it its your own unique name as part of the service and the reason why the technical service was automatically filled in is because this offering is tied to a service which was previously classified as a technical service so the assumption is that the offerings of a service need to be the same classification you wouldn't suddenly have a business service offering hanging off of a technical service so that's why it fills in for you based off of the type of service you started out with so it keeps you in line you can't make a mistake correct and so we have uh things like business criticality on the offering and things like this the team this is where we define things like the support group and you want to talk a little bit about the support group manage my group and that's right yeah so we wanted to make sure we had consistency as to the various groups that we reference and in the past we haven't had that consistency there's been some group attributes that depending on the customer or depending on the scenario might be used in different manners but we wanted to drive consistency so that we can then have the right data at the right time for all the various products using the platform so support group is intended to be used for incident so it is who we would do the routing for in case of an incident so for a particular ci identifying who is responsible for the care and feeding is the support group and primarily to be used inside of the incident process so this this will be late used later on when incidents are created for anything that is underneath this offering right anything related to it so that was the other benefit by managing this at the service offering level then the assumption that we enforce is that that's the same support group for all of the cis that this offering is is taken care of and so taking the value that's entered here under support group and essentially synchronizing it down onto all of those cis that they oversee making it simpler to manage the cmdb and the ci's in the seem to be less manual more automation yeah but we're what we're saying is that we're adding that value at the offering level right and then it will get propagated down this level as we had highlighted before correct and that's probably one of the the top asks because again anyone who's managed to cmdb and especially the ones that that fail it's because there's too much manual activity to maintain a cmdb so the more automation we can do with data then the easier it is to maintain those objects so that's really where the concept of a technical service offering came from there was a european business that decided that they didn't want any infrastructure ci to exist without it being identified to a technical service offering that that showed who was responsible for it and they made that a company-wide mandate in their servicenow implementation and it worked it worked extremely well and so we've adopted that as a consistent best practice yeah so the goal is every ci here will be related to one and no more than one really uh offering because then you would have multiple owners or multiple slas what do you do correct excellent now this overall system of creating a service i mean compare this to the old days so mark you and i in the old uh knowledge labs manually go in and create an individual ci and there's requirements of creating a parent ci make sure you create that and then select the proper relationship being able to just come in here and use this wizard to set everything up so much easier than trying to be an expert in the same db and the data model and knowing where things have to exist this just takes care of it for you absolutely and you know one of the things that's really great about some of our other product teams is like they're listening because now that i've defined the offering what is the next thing i need to define oh well it's the dynamic ci group it's the application service so that would be nice to add as another step here and i think you know the teams here are willing to listen and add those things as we uh as we mature the use of csdm is the model to go to agree and then the time to value just is improved across the board yeah i mean this is a breeze right i mean you could federate the ownership and the responsibility to the folks that own these services right you don't have to do it for them so so now that we can easily define these two levels right next thing we need to understand is sort of how to set up that dynamic ci group and this is another hot topic it's very powerful with that query that we're just going to walk through what i find is that folks don't know how easy it is to set these up so we have dynamics gui groups okay so i want to talk a little about the dynamic ci group itself and what folks need to go through to to do this because i find that you know people aren't aware of them i know we've got some tutorials out there here and there but it's pretty easy to set up and i know we can set up some other metadata on the dynamic ci group but i've noticed this is used also to define some application services as well yeah there's two matters of having a dynamic ci group and it goes back to a service classification yeah is this going to be used for technology and infrastructure or is this going to be used as an application so it becomes another method of identifying what cis are representative of this application instance or system and so instead of having service mapping if that's not available or instead of having tag-based mapping if that's not available you can just use a query and so based off of having a query and what falls into that query everything that then falls into that query becomes part of of this and it will act as an application service but uses a query to create all of its objects right right more flexibility and how you actually populate that app service right think of it as the replacement for spreadsheets so those those scenarios where hey i have an application and we use a spreadsheet that says these 10 servers are part of it well instead of having the spreadsheet let's create a query that either specifically identifies those 10 servers or if there's some data element that allows us to use a query to get to those 10 servers let's do that instead and now it lives inside of servicenow and we can get rid of those spreadsheets yep yep and there's only a few steps you got i like to start here with the dynamics ci group itself uh we also have to define a cmdb group which is i guess legacy right this has been around a long time it is but it's being used in multiple places so it's where queries are stored from the query builder and so we use it in other areas inside the platform so instead of recreating this inside of dynamics ci group let's just utilize what already exists right so i can create my new group and define sort of what it does after i submit this i can kind of services your one yeah okay so my new group there it is so we come back here and then we can go into the particular record and look at the cmd group define sort of its contents through cmdb you know create a new ad query encoded query or just manually add items so that was that reference where you can just pull existing ci's to say they're part of it so that replaces your spreadsheet or as i mentioned create a query to get to those same objects yeah of course there's some limitations on this kind of query this is the cmdb query you're sort of limited to ten 000 records is that right that's by default yes yeah you can work through moving beyond that but beyond that's where you start impacting performance on the platform so it's not that forever and always it can only be ten thousand but anything beyond that we want to essentially review and make sure we're not impacting the performance if we move beyond that number yeah if you do like a simple class-based query then it shouldn't be too bad correct yeah it's more complex queries that you run into issues and then of course you can do it just a normal encoded query uh which is your old style queries so that's kind of how you create those dynamics ca groups to be able to connect uh the dots all the way down into the underlying sea ice it's not the only favorite yeah now now once you get this connected right this is where the magic can happen i wanted to share a little bit about what happens in the background once this is connected so let me uh jump to doc site so one of the my favorite things is you got this new feature synchronizing group assignments attributes and you can kind of do it like we talked about through the ci class and technical service offering and then of course if you do it through the technical service offering it's going to leverage what we just set up and this kind of talks a little bit about how to set those dynamic cia groups up but i think there's a couple of interesting things here so these are the three groups that are propagated right is that that's correct the support for the which is used for incident change group which is used for change and then manage by group which essentially we identify as the group that's responsible for that ci and the data on that ci yeah now some folks ask me about whether they can customize that can they add more not at this time again there is a hit to the platform to properly take this data and propagate it and synchronize it down to the the cis but even more than that is making sure that we have the right data at the right moment so if a ci is no longer part of a particular dynamic ci group then that data is removed and if there's any data such as the manage by group identified at the class level then the class level data overrides that individual data element so there's a lot of other material that's going on in the background to make sure that the data is accurate not just the one-time synchronization when you initially set it up but it remains accurate ongoing and for that reason a lot of the activity that is done isn't able to be easily added to yeah yeah the good thing is it kind of hits on that you know you can immediately go to the navigator and kick off the actual data sync job to see the results right that'll kick it off in the background and make fill it in yeah there's multiple layers that are going on in the background to make sure that the data gets synchronized at all the proper levels or unsynchronized depending on the scenario and of course people need to enable that scheduled job is that enabled by default it is not enabled by default so you do have to turn on okay scott well i think we kind of covered the use case for the infrastructure level uh technical services is really good so we've kind of kind of done these two what's the last one what do we have here so that's a good question this is where we get a lot of questions obviously the pieces above is where we've got actual technology involved with a dependency i'm either taking care of applications or i'm taking care of infrastructure so there's something tied to that technical service offering that you're responsible for from a support perspective in this scenario there's nothing tied to it so you're not responsible for an application you're not responsible for any sort of infrastructure instead you're truly providing a delivery service one of the scenarios as documented from the various standards is for example hey i need help with the creation of an application they're not going to be responsible for maintaining it but they can provide services to help create things and so in the i t space where do you have teams that are responsible to help others and and deliver assistance but they aren't the ones that are dependent on or providing particular infrastructure so that's where this comes into play it's not that it's exceptionally common but we just wanted to make sure we had that scenario of what about those it teams that provide a service but they don't take care of any technology it's more or less labor they're doing a job and we're accounting for it but it doesn't necessarily connect to something there's a cost associated to that labor so we want to know that we provide that service and that we know that can be requested from a catalog perspective but there isn't actually any technology that comes with it yeah it's interesting because we have this term you know digital service these are digital services these are manual ones right you said manual labor doing all the work versus there i'm giving you something digital at the end of the day of course they're all connected to the service offering with one of the things we didn't look at in the offering definition is what catalog item they connect to i think that's really important too from a self-service point of view that way from a service ownership perspective you start to see where the demand is for the various services and see that demand over time and understand where you may or may not have demand for the various services so tying those two catalog items which then are inside of the the service catalog that can be requestable that helps you just tie those pieces together as opposed to having to to build this all separate and one can't speak to the other this actually pulls the data in so you can view it from a service ownership perspective yeah and what i've also been able to describe is the fact that somebody might expose a catalog item to add let's say a new server and so going through that process the process kicks off maybe it's even completely automated from a virtual containers virtual server perspective it gets added as a new ci and because the query is there it automatically gets picked up and it's related to the right group and everything and then these guys can start to use their new server and have support for it already kind of set up and the other value of that because of that query is you don't have to write into that workflow exactly where ownership goes in the future you let the query take care of that for you yeah i think that's the perfect thing because you know these are what we call standard services or stand you know standard changes where we have a known set of support organizations to do things and everything's sort of tied in once it's been delivered and it takes the manual intervention away from that workflow to determine where that needs to relate in the future when we implemented those in the field they're always difficult to implement any manual workflow is difficult so the more automation we can do here the better yeah so they can you basically use our standard catalog features to find these items associated with the offerings automate whatever the process is you know or have approvals or whatever it is everything's tied together we used to call this request to fulfill by the way it's a request and then fulfill and the automation comes in and of course i know what i fulfilled well thanks scott thanks for tackling the technical services area this is a hot topic with all the things and the level of detail we kind of covered to help products support this i'm sure we'll be back and cover another topic next always happy to help