[Music] in this session we're going to cover what's new in the cmdb and cstm for the san diego release on this we're going to cover the product evolution the overview of major new features major new enhancements and minor enhancements and features from a cmdb point of view we've been at it for quite some time and in san diego what we're covering today we've got some new items as well i'll go over in detail so today we're going to cover some major enhancements mostly on the dynamic rules capability that we added to ire we're going to cover the cmdb workspace version 2 which is available in the store as well but in the san diego release we will be shipping the cmdb workspace as well a new version version 2. and the cmdb data manager we will be talking about a new feature for dependent ci processing we're going to be covering service graph connectors update in this session i just want to note that the service graph connector program has new things being added all the time plus there are changes to the roadmap based on the availability of vendor assistance and also testing we'll be covering the ira domain separation support which has been improved in this release iatl additional features some csdm product model population capabilities which are to really set us up for product-centric management of it within the next year or so and the new application service type called calculated which has been added in the user experience for application services in san diego so first we'll cover the new features so the major new feature that we added is a dynamic ier e rules which basically decides what value to choose when importing data from multiple sources based on the value itself and so when you're creating a new rule you will see a new option to create dynamic reconciliation rules and you'll see on the right when you select that option and you set that up ire will choose from the data source based on its value so the re first reported value is an option most reported so i like that one because if you have let's say four sources with the same kind of attribute you can say hey let's use the one that everybody reports on the most so three out of four will win the last reported largest value or smallest value so now we're investigating exactly what the data values are to choose which source to use in each attribute so there's nothing new you need to do all you have to do is basically install san diego and when you get that you'll now have these new dynamic conciliation rules to choose from next we're going to cover some major enhancements the first major enhancement is the cmwb workspace version two this is in the store but it's also shipped in san diego in the san diego release we are going to be supporting the new user experience that the platform is seeing and we're getting great reviews on that platform update things like dark mode are enabled and the user experience really looks great in dark mode we're always making improvements in how the experience works for all of our customers and all the different personas and this one of course we're addressing the personas of the cmdb the next major enhancement that we have is in the cmdb data manager the cmdb data manager is relatively new we introduced it in rome and we now have the ability to set up identification rules within the ci class manager so when you go in there you can basically set up the identification rule on whether something is a independent ci or it is a dependent ci so what you're able to see here is that when you set it up as an independent ci that exists on its own and it has no repercussion from anything else being created or deleted so it will exist on its own it has its own life cycle however now we have a a dependent ci and this is a case where we have a memory module the memory module exists as part of a piece of hardware in this case and so what you see here is it's dependent on its hardware if the hardware that that memory module is in goes away then the dependent ci will also go away and the way we set that up is that the dependent relationships which tie these two together to say that memory modules are dependent on their hardware that is set up also in the ci class manager now the neat thing about this is that this feature will work across anything that you already have set up appropriately in this way and historically we didn't really have the ability to process those dependent cis in this release we do now the dmdb data manager does this for two of the three different types of rules you can set up in data manager it sets it up for the deletion and archive rule only now if you have those retirement we don't process it for retirements yet it will be added as a feature in a future release so just keep that in mind retirement doesn't necessarily mark retirement for all the dependent ci's at this moment this is something that automatically is there i would encourage you to look at your dependency rules and when you're upgrading and setting up cmdb data manager just note that those dependencies will start being processed this will eliminate a lot of the problems that customers had with orphan ci's the computer might have been deleted or archived but maybe the memory modules had not and so that problem will be addressed going forward so on the different types of service graph connectors we see i'll start out with the cloud one we're implementing a number of different cloud service graph connectors here aws is the first one that's coming out and it's currently in early access so we plan to release that soon so stay tuned to the store and if you need access yeah please let us know and you can gain access the next step we have is the google cloud and azure which are planned for later this year we're working with customers and with those vendors to ensure that we actually implement them based on best practices the next area is software server and networking information we will plan to come out with a new connector for apogee palo alto networks cisco thousand eyes and com and the observability monitoring area we have app dynamics already in early access and beta and we also have light step that which is also early access light step is available already in the store if you do have light step you can go ahead and try that out with your light step deployment planned is the elastic as well as new relic nothing new in the endpoint it asset management space in the manufacturing iot telecom area we have cyber x radiflow in clarity planned for later this year and nothing new in security the roadmap is quite fungible we will work with vendors and customers to be able to prioritize these more dynamically and because they're released in the store we're able to release them outside the family release schedule next we'll cover the minor features and enhancements and the first minor enhancement is to the domain separation support when you're using ire now this includes of course any service graph connectors that we just walked over they use ire as well the key thing here is that traditionally we haven't supported a different domain for each connector or we would be able to only support one domain so when you're running collection from in different sources we can only target one specific domain that was limiting for msps that was limiting also for customers that use domain separation just more support let's say different subsidiaries in their business model now what we do is we can add that domain information when importing data from those various domains and we also adhere to the rules of domain separation so let's say something comes in in the parent domain and it has access to the child or a different domain then we pay attention to those rules when the information is coming in and it's now used within the system so domain separation is a big deal for a lot of our msps and this kind of tightens up our support for domain separation as a whole and really adhering to the domain separation rules when you set up the main separation i just want to note that domain separation is a separately licensed feature within the platform and this you'll need to go to the domain separation business unit in order to learn more to enable this you need to set a property for the ire to true which is platform domain separation enabled now the key thing to remember is if you already have cis created that have not come in under the domain separation rule then the results will be undeterministic as the domain each ci might relive in may not be set up appropriately so we really encourage customers to enable this only on zboot when they're studying a fresh environment and collecting information from scratch from these sources it can be done where you can enable these afterwards but certain precautions need to be taken to make sure that your existing data is in the right domain otherwise the reconciliation rule may not identify with the right domain with the information coming in so please note that this is tricky to enable on existing instances and to take very great care in setting that up the next feature that we have is for ihetl's mapped ci option what this does is allows you to use the existing service graph connectors for example that is using ihetl to disable certain ci's from coming in altogether let's say you have an optimal different sources and you choose to use one source as your master for new cis and the other source maybe hasn't been updated with deleted cis or archive cis so you can choose to have a master source only create those cis and ignore the new cis from a different source now the benefits here is that you can basically use the out of the box servicecraft connectors you could just configure them slightly based on your preferences or needs how they work without having to go through and use all of the different ci types that are available in each connector so you can pick and choose which ones make sense for your given situation another thing worth mentioning is with all of this new functionality we've improved the logging for ihetl we have a lot of customers that use these service craft connectors and they're creating these ihetl import jobs with the additional troubleshooting tools you'll be able to support you better so you can debug what's going on or may not be going on appropriately so i just want to mention that this big feature that we have is the csdm product model association process now what this is that in a typical cmdb we have the ability to connect each ci to its respective product model and the hardware and software space this is kind of done by hardware and asset management and software asset management well but what happens to the logical items well we don't have coverage for that and a lot of organizations hadn't created the applications models or service models to map their cis to as we switch to a product-centric way of thinking and managing nit we want to make sure that we capture the product models first ideally and then the ci's come in as a representation of that particular product model in its life cycle so to prepare for this switch we are investing in this area in terms of the logical ci's that basically aren't hardware and software but more logical constructs that still need to go through a versioning and also a product-centric way of planning them in this release the product models that we're going to be supporting to create the product models where they don't exist for business services technical services service offerings application services and business applications this is a job that needs to be enabled of course the first time that you enable this we will create quite a few product models where they may not exist already and just a word of caution if there are cis that currently have the same name somehow in the logical context there may be some challenges in creating those product models so they may map up to the same one or they may create different ones so you'll have to look at the results of the job and review the results and correct for some of those naming issues that you might have already in the cis the goal is to connect every ci to its respective product models long term and this is just one step along that journey the next big feature that we want to talk about is the new dynamic calculated application service so you might see this as calculated in some areas dynamic in other areas in the user experience you'll see that the dynamic service is now available as one of the population methods for creating application services please no application services is in the user experience under cstm to create new application services you go through a wizard and one of the steps is to choose the population method now keep in mind this dynamic service is going to leverage your existing ci relationships to create the service in our system we have two ways of modeling one is the seem to be dependencies and other relationship types that are between cis and the second method is really a service map the service map is a more high fidelity mapping of a particular service unless a broad set of impacts that are managed within the cmdb as a whole customers who have manually invested in cmdb relationships to articulate their services will now be happy to know that they can see their same ci relationships in a service map particular to a application service so this is going to be a nice powerful feature it was added actually in the rome release but added to the user experience here within the san diego release i want to also take a quick minute to look at how the application service wizard supports these different population methods and when to look at using one note that two of the population methods the top-down discovery and the tags based approach are both require service mapping service mapping is part of our iton visibility or you can buy it independently if you have a older sku when you're looking at different options i think it's worthy to note that the best option is a top-down discovery this really requires an entry point which is typically a url and of course when you do the top-down discovery we will include any of the network devices or servers that are identified as we're traversing the different devices down into the lowest level that we can find the next one is dynamic ci groups it's noteworthy to say that this is basically a query now this might be useful in a situation where you had a naming convention for servers for example that were named for particular applications so you can create a query that has the server name in it and allow that to drive what the application service happens to be this is more or less going to give you just a inventory of stuff and not necessarily understand how they're all connected the next high fidelity is the tags based approach this works for public or private type cloud environments where you've applied tags and in many cases we can use those tags and understand the structures to put together a service map so this is a good option if you have a large cloud environment and you're using tags currently the next option is manual this one really is a manual construction of the ci's that are in the service map so the manual service requires selecting the cis and no automation is really used i would suggest leveraging the dynamic service wherever required as it is a little bit more intelligent with regards to how we process those dependencies and bring those into the service map and that's really the item that i covered previously so it is now on that population method in san diego and go ahead and leverage that where you have robust ci relationships already defined and want to use those a couple of words to note these will in the background stay up to date so as you create or change the cmdbci relationship types the dependencies on the service map will also change and be reflected also interesting to note when you set these up you can specify how deep you want it to go is it five relationships or two relationships so it really depends on how much manual work you've done or information that you brought in from other sources and selecting how deep we want to go and throws dependency relationships in order to build those service maps so keep that in mind and there's just one more noteworthy change i'd like to mention and that is we've improved our iri performance when importing data up to 14 and that's been the average that we've tested out when we're actually working with uh massive amount of data and the the nice thing is that we continue to invest in the performance of the system as customers scale and they get larger they have more data sources we recognize that we want to make things easier and more performant and we have a continuous investment on the back end to make sure that the performance requirements for our customer base are met thank you for listening to this brief update on what's new in the cmd and csdm for san diego