should be there yeah okay figure that out all right cool good thanks hello everyone good morning good evening um today's session office hour number 52 is all about cstm 4.0 and we have with us mark bodman who is the subject matter expert in this area he is the senior product manager of cstm cmdb and he used to be the apm pm and he also participates in the it4it forum so i i also see we have a good crowd here today so mark without further ado the floor is yours great thank you very much sure um yeah and we also have darone here who is the apm product manager now so uh uh so this is uh great he can answer additional questions that come up around 8pm yeah and all the participants as you uh as mark is going through the slides if you have any question please feel free to put it in the chat window uh either doron or i will try to answer them thank you mark please start great uh okay so um just to give you a little background the csdm is a is a model that we use to manage the information in our platform and it kind of extends on the cmdb uh and whether you know it or not you're using it when you're using our products these days um a little bit of a safe harbor statement let me also mention a number of product areas that we're investing in in the future so don't make your buying decisions based on any futures um this is a very large presentation that we're only going to get into a portion of all of the the content here i'm going to provide links to the content that's already recorded out there that you know we don't have time to cover today and i want this to be more interactive as well as we get into it but i wanted to start with this perspective because what we have is the the the common service data model is all about providing a common model for all the products and all the views that we have on the on the platform so it's not there for its own good it's there to help each product realize value more effectively more efficiently and this is just a nice overview that i like to use to kind of single out what that value is in each of the areas of the platform um so this it does say cmdb but the actual seem to be here is a little bit more than just infrastructure which is the legacy cmdb it is it's more it's more into the what we call service graph and that's a good way to think about the common data model is really it's a broader model than just infrastructure and we'll kind of highlight that in a minute and uh this is just another overview of that dependency on that seemed to be in service graph perspective uh things like asset management is very hardware and software focused but apm is a bit higher level in the in the conceptual area of planning so before things are actually built or to be able to aggregate information when you're doing planning there's a key you can't really look at the server level detail in apm you're looking at a portfolio of apps that you think you have and that you want to invest in or need to have in the future but you can see there's a lot of other areas that we've invested in here too and that use this model or contribute to it in various ways uh the big one that we're seeing a lot of interest in and a lot of new functionalities in ci cd pipelines and teams to this so after you plan on investing in an application for example the teams kick off and they build something and that we want to maintain that traceability through this model and then of course once it's actually built it but it's deployed made or it's being used you know advantage operationally uh in providing services to your interior consumers it all kind of connects which is how i look at the whole model so the csdn model is really a life cycle management of digital products and services uh it doesn't say business applications here because business applications is really just another type of digital product that you take software and hardware you run it in your data center cloud data center and you provide services so we want to be able to understand sort of the traceability between what's being planned on how it's being developed how your pro how it's being managed operationally and how it's providing that service and it's all interconnected and supported by what we call the service graph and csdm is really that guidance it's the model that prescribes how do we connect all these dots how do business applications that are more conceptual in nature for planning purposes how do they connect to what's being built deployed and then what what kind of service are they providing so this is a key element of our platform and how we maximize the value of a shared model in this case um the one thing that i also want to to harp on is that in the csdm we focus on the common bits of the data model we don't try to encompass everything in the platform we have hundreds thousands really of tables and so we are focused on what's actually being managed across the board uh and shared what's common across many products so over time we evolved cstm in order to add those new common elements and so you'll see it grow and change over time and we also have products that don't use common elements today that are transforming their free factoring to leverage the cstm so that's something to keep in mind the good thing is that um just going back a little bit historically uh when i was representing apm i built it to leverage a lot of the common model and and this was one of my core principles when i was thinking about the design of apm originally and we continued to do this we kind of adopted that same philosophy across the board here and that's thus the csdn was really born out of that that ideal of leveraging that common data and getting everybody to to subscribe to that internally all the different product managers that was the intent of this particular investment in creating csdm in the very beginning and to explain what csdm is uh and the different domains when we talk about csdm domains we have the design domain the build domain managed and consumed domain and this is where we separate the concerns from planning activities versus build activities and and the of course the separation of concerns is different elements of the model different levels of detail uh operations concerns are here this is where i tell them itm kind of sit and then down here service management concerns i would say historically when the user rolls separate products you may have copied data from one to the other a common thing that i've seen in the past is copying information from app portfolios into the service portfolio because we're on the same platform that doesn't make sense anymore so a big part of this model is to support the activities but do it together so that we do understand how these things are related and on top of everything is the foundation's domain and the foundation's domain for us is going to be shared elements of the model such as location hierarchy where are the people that are doing the development where are your customer consumers that are doing uh providing service for where is the hardware and software deployed in the data center so location is common across of many use cases many of the areas of the model within our platform so that is foundational when you see that area as we get into the the definition the one thing that i wanted to kind of keep in mind too is that we have a number of principles that we established when forming csdm the first thing is we wanted to simplify the concepts in the model because a lot of folks didn't understand what they were we didn't have definitions we actually agreed on the definitions that we provide and we use internally across the product teams we also uh all of those tables that are coming in are now out of the box so if if they are common you don't have to install a product that you may not own we want you to use the right tables even if you don't use the products for those tables immediately um we also have focused a lot lately on data governance processes and apm does take part in some of those just from a conceptual point of view by introducing a process to create new applications you don't want people to willy-nilly uh add them to the portfolio without going through some level of governance to just make sure the names conventions are stuck or in the in the description are being adhered to based on your standards uh and other things here of course are also matter but yeah these are the important ones to me uh and and really the ones that kind of help get this moving in the right direction um we've been at it for quite some time as well so i just wanted to kind of go away all the way back to kingston is when we started to making making decisions about putting some of our uh our key elements out of the box making sure that we are providing those and we continue to make changes all the way up to here and csdm has evolved along the way we're up to csdn version 4 which came out just after after our rome release i'll explain kind of why there's there's a bit of a disconnect between the releases and the versions of cstm because it is guidance and we we don't necessarily tie to a specific release but a lot of times the products need to be able to use that guidance or to be able to introduce a new element of the model those products need to support it so there is some there's some consideration for the release cadence as well and i'm assuming some people here may already know a little bit about csdm so for the for the folks that are already educated and sort of know what cstm is all about up to version three uh this is just a quick understanding of different things that we've added along the way and how we've changed our product to be able to support or extend cstm um as we go back in time we we basically have a number of things that we've done over the different releases the the version four changes that we made in rome and all the way through san diego are really adding this new build domain in between business applications and application services now this build domain and the sdlc components within it are purely optional and i'm really um i'm very happy that the apm team actually has added this as a capability to support some of the apm use cases especially in tpm technology portfolio management so you can use the the business application analysis down into the underlying technology by looking at um the sdlc component or bypassing it which most customers are doing today but the sdlc component was added because we have teams that are building new capabilities uh microservices or delivering config files that will eventually configure what's actually deployed either in hardware and software and so we are extending some of our policy checks into this development domain where things are being managed either in artifact repositories or social code repositories and structure that's used and managed here like microservices structures will basically inform or be mirrored on what's deployed in each app service so the build domain is uh currently not used by a lot of different products but a number of product areas like light step integrations uh devops agile products are all going to start using the sdlc component much more readily much more heavily and the devops config is the first one to represent what we call a config file here so that we understand that we are meeting those policies when we deploy these config files um so so that's there it's purely optional i do have a lot of customers that tend to want to use this for a number of different use cases the one that i i found from an apm perspective that many organizations want to use is for apis to be able to describe apis that are being provided by those build teams or a third party application you're deploying and be able to manage those uh those integrations so i think you might see some functionality in the future to address that from an apm perspective the other thing that we added recently is the business process in csdn version 4. the business process has been there for a long time but we never really had it as a common element of the model which is to say what products use it and how do they use it so it was added in order to support business account to uh continuity management dcm dr testing and management risk grc and also rpa robotic process automation so processes are now a key part across multiple products we sell and so you'll see a much more i would say aggressive use of this object and more prescriptive use of it with those product areas though other thing that we added is a common life cycle definition and those life cycles were actually added back in the paris release but we never really made a big deal about it we didn't highlight those uh until csdn version 4. the reason for that is because over time all our products that we sell are going to start using the new lifecycle definitions which are a base element of the model previously different organ different areas of the model had different ways of articulating life cycle so what you had here in the design stage life cycles were very different than what we tracked down here with server hardware and software and there's no easy way to report or synchronize that information so if you made a decision an apm for example to retire something that's already there how do you synchronize that decision with the life cycles that are uh uh in the deployments of that application business application so we're trying to get everybody on the same page with regards to life cycle and there are some functionalities that we implemented to migrate old to new life cycles and synchronize those while folks re re-architect or retool the products that we sell or leverage those life cycles another thing we added was location types this location hierarchy is important for a lot of different use cases and whether it's where the data you know what data center what rack and elevation the hardware is in or what continent maybe a business consumer is in when they're coming in for services so now we've added a location type so that we can appropriately leverage the locations and filter them just for the use cases that are specific to the use to the areas of the model that you're looking at and also populating and the last big part was technical services is now part of the service portfolio previously the technical services that we had in the in the platform were pretty much isolated to event management use cases and we weren't using those technical services in the portfolio management of the the services alongside business services so this brings the two worlds of managing basically the infrastructure and back-end what i would call shared i.t services in line with business services where you have and consumers to deal with this is a big step along the way to what i call product centricity product models is another thing that we've had in the platform now for a while but we're starting to leverage these in a much more holistic way some organizations are shifting to what we call product-centric ways of managing i.t so product models are are going to help and facilitate that and also bringing the technical service in line with the business service helps to collapse the portfolio management of digital products and services into one portfolio another product that we released that does that goes a step further in this whole exercise is it brings the business applications together with the business services and technical services as well the the reason for this is because we're seeing teams manage uh everything they manage both the business applications and the business and or technical services related to it so to be able to facilitate that full life cycle the fact that the team has control over their their design and planning and development activities but also operations activities down below so that can now be facilitated by digital portfolio management uh so the other thing i also wanted to mention many organizations have taken a step to rename their business applications to products or digital products so they already treat their applications like products in that in that notion of a full life cycle and they do synchronize those with the services that they're providing as a result of investing in those digital products so there's another thing that i typically see with a lot of with some of the ipm customers that a little bit further ahead on that product thinking the way of thinking about digital products so i've been talking a lot and i haven't really looked at any questions um i'm looking at the chat i don't see anything yet here but i wanted to take a quick pause and see if anybody did have a question that we can answer before we move on all right no questions great so i'll continue um in csdm so this is a a a larger view of that particular of the framework so you can get an idea of all the different things to see when we're talking about csdm there's a number of components that we see on this map the the key thing here to think about is that the four domains are really there to to manage the data from these activities uh and so each one the data elements that are there are specific to the products and the activities that are called out along the sides you'll see personas these aren't actual roles in every case so application owner you can say there's application owners for apm but there's actually two there's a business and an it and many organizations may extend that into additional owner types teams the same thing teams is a bit different we are migrating to more of a team-centric way of managing things and the app owner would be one of the people on the team or product owner or service owner so these are all different positions to play on teams more like a team sport so we are migrating to this team's concept in order to be able to say i'm on the team that manages the full life cycle of xyz digital product or business app or business service so we want to be able to collapse some of the the model to be able to understand this but also how we're managing and describing the teams that are involved so hi is there a question okay there was no question um so that's something to keep in mind when you see this team's concept you'll start seeing a consolidation of teams that are across the board and we did release some capability in our in our rome release to be able to describe these teams which are basically uh a list a related list of different groups basically it's how you want to think about it today so but that of course is one related list that can be associated with a specific entity like a business app or a business service the other key personas you'll see is technology owners over here technology service owners app service owners that are basically the uh of platforms or behind the scenes and down here you'll on the right hand side you'll see personas like this the service owner now the service owner is sort of the center here because the service owner provides whatever the investment was to end consumers and this is an area that we're looking at migrating eventually to what we call a product owner and a pr a product could be a an application and or a service a device so as we evolve the model in the future beyond 4.0 uh we're moving towards this product-centric way of thinking and then making what we're managing a little bit more generic and suitable for what it is that you're actually creating and managing so uh you'll see some of that in in some of the later slides so product centricity is a big deal going forward and i just want to kind of pause here are the folks on the phone is anybody going through that journey or looking at product centricity as one of the key transformation initiatives that you're going through just curious uh yes at trinity health we are going through that right now too we've gone to a product-centric model okay anybody else going through that looking at that no well if you're afraid to speak up i mean we can kind of talk offline at some point about the view but this is this is one of the things that uh we're seeing it kind of started from the devops perspective where we have uh the the team the devops team that does own the full life cycle and there there are some conflicts or maybe some challenges in integrating that model with uh what happens really at that portfolio level or in classic it service management so in a way we're going to be merging these worlds together on the platform and a big part of that is going to be that business applications and services kind of coming together so i would definitely look at dpm as a as one of the first big steps that we're taking in that in that context and uh some of these other changes will start falling into place as you uh migrate and as we migrate to that to that way of thinking as well okay so the other things that i wanted to kind of cover here from a csdm perspective are some of the uh examples so when we're looking at the csdm model we have different patterns i call them patterns in which to document business applications and all their things within the platform to address all the different concerns in each of those different areas and so platforms is kind of an easy one to kind of start with because we do have service now as as the key one uh and i'm gonna pick on apm a little bit just because there's a very specific way of managing platform hosts that are applica type business applications versus platform apps and what you have is uh like the mid server is neither but i just put it in here uh just just for for including it um but the servicenow platform is an application business application that supports other applications that are built upon it uh and it's different than let's say a a platform like uh salesforce or sharepoint can be thought of as a platform so these different platforms are supporting and constructing different applications for different purposes on those particular platforms this is kind of important to leverage this architecture type in order to distinguish one from the other and there's some nice functionality within the apm product to be able to support that now once those platforms from a planning perspective uh an ownership perspective are identified so think about these are you know the different owner of the platform versus the modules on the platform they serve different purposes and when we deploy these and recognize how they're deployed we have a platform instance that recognized here for each of the prod and non-prod environments so here's a application service in order to represent each of the deployments in a not in those environments and then we also have an application service dependency on that particular platform that represent each of the business apps that are deployed on the platform in those environments why this is important is to support operational use cases so for example if the platform happens to have a problem everything on the platform if you have multiple products that are actually on that platforms providing different functionality each one of those products basically you can understand that there's a there's an impact likewise if only people are calling in on one product on the platform but everything else that you actually post on that platform seems to be okay then you can direct the ticket to the right team and isolate the problem to this product that's on the platform not the platform itself so operationally this is important to be able to distinguish and also assign resources from a help desk perspective or even a third-party vendor like ourselves if the pro platform has an issue or do you need to talk to a a team that specializes on the products on the platform so these are the operational context down here this is really where we're managing the the technology after it's been deployed and as it's used some components like i said are deployed in the data center and uh this is not a platform app it's deployed in the data center and it's a typical app where you have uh an underlying piece of infrastructure and applications running on that infrastructure which then are part of the app service so this is the the what i call the typical on-prem model for this and uh this these would be sas this is a sas model and i have a lot of questions from customers that say do we need to create application services for sas sure because you have different support groups for that you do have different metrics and reporting that you perform and a different cost and a different way of making that available to your consumers so even when it's a sas application such as servicenow which is all in the cloud you still have the application services to be able to distinguish each of the environments the spend and also be able to monitor and manage expectations from a support perspective each of these can also be related to product models software product models uh obviously in this case or hardware product models in case of infrastructure so product models is not a what i would say a a large part of what's used across the platform we use this information in an apm context because we're able to aggregate all of the different software product models and hardware product models used underneath a particular business app and then of course relay that information back to the app owner in order to evaluate risks of any of those these specific hardware software being used that particular use case is pretty powerful and we we need to understand the product models in each case and the end-of-life end of support dates for for them to be able to evaluate that risk in a way apm was leading the way in terms of leveraging what i would call a large swath of the cst model in order to perform more sophisticated analysis like tpm risk calculations can i ask a question sure sure thing yeah so i understand having application services to help identify different support groups for the technical components but if there's one team that managed the whole service now platform um would you still recommend breaking it out by platform application and separate application services for each module um i would for a couple of different reasons one is because we license and we charge you for for these modules okay so so what you're what you're being charged for what you're paying us to provide you is going to have a different cost model and you know you if you char if you turn on more stuff there'll be more things on servicenow which you're using what i find is a lot of organizations from an apm perspective are moving towards a platform architecturally which means to say they don't want stand-alone apps right they don't want to they don't want to manage many standalone apps they want to have one platform with a bunch of apps on them so that they limit the the risk they maximize their investment in the platform uh so this gives you some granularity in order to take that measurement the other things that i also wanted to kind of point out is the the business apps on the platform provide very different capabilities so when you're looking at investing or optimizing what you do in each capability from a strategic pla planning perspective you have this level of detail if you didn't ever it would look like everything is on service now but how do you break this out from a cost perspective right or a road map perspective like change management here at servicenow doesn't change very often but hr is fairly new so there's maybe some risk in using some of the newer products uh before they're mature versus something that's a little bit more mature so those conversations are basically for different areas of your business and they're also have different consequences for use or non-use that make sense yeah thank you um so i built out the model a little bit further also illustrate the uh business service aspects okay so the the services that are provided are based on the application services that they're using not the platform same problem here is do i call the platform owner who may not know much about how hr pro the hr product works but typically we want to have some expert that's responsible for the hr product area who's providing that product right and then of course all the consumers come in they can be directed to the right support group that knows hr not just the platform as a whole so so yeah the support groups and the supportability of the platform versus the apps on the platform especially in larger organizations where they have uh a a much larger team a lot much i would say a lot more products that are on the platform that are being used this model works best and we also see some customers that develop their own products on the platform so they are developers and they have a lot of custom things that they actually develop as well so onboarding new products that are on this on the platform you need to take care in this as well and also understand sort of the purpose of those from a consumption point of view from a service point of view okay so um i hope this helps i mean this is just one example of a number of them that we have i do have uh like i said a lot of this stuff is recorded in material that i can send links on later but once you see her the apm context fits in with the rest you can see now where there's some synergies uh the other thing that i wanted to also mention and this is not maybe obvious for for folks that are more focused on the apm side of the house is there's linkage between the business capability and the offering why that's kind of important is because when you invest in an application um it is there this is more or less the investment path which means the business application the team that basically supports this are the ones that are going to be providing services to the rest of the org so the investment path is really coming down from that capability perspective the actual use of those applications however come up through this this side and now that we have the business service uh and the offerings that are connected back to the the capability we have a feedback loop if you have a lot of tickets for example people are reporting lots of tickets with onboarding onboarding uses the app service down here the production environment which kind of come back to here so that feedback loop from a business application point of view is pretty straightforward and also the understanding the purpose for that particular business app and the consumers of it we have that that full traceability back to the capabilities so something to keep in mind what i what i have found is for example this is pretty straightforward and this is usually done from a application portfolio management perspective alignment workspace uses this but when it comes to the service feedback it's a bit disconnected today without this particular perspective we also have different portfolios of business applications versus portfolios of services in dpm we're starting to collapse that we have enterprise portfolios which is now a superset of the two so something to keep in mind as we bring these two worlds together uh the application and the services together this is just a little bit of piece of uh of how we're bringing it together at least in cstm now so any questions about this i appreciate the questions because it this is way beyond of course the apm use cases but it has it gives you insight on where we're going and why especially when we go back to the earlier portions of the of the presentation where we're talking about the full life cycle okay okay so um a couple other patterns i just want to do one more real quick that's really common and i'll talk about what's going to come next one is a microservices pattern some business applications are quite large and there are different modules or microservices that are implemented underneath the hood um i'm using an online sales management as a particular example in this case where we have a large website that may be broken into different modules that perform different activities underneath the covers now each of those modules that are stood up more microservices have different code associated to them so this one calculates taxes for the sale where this one deals with currency conversion so all of them are are basically used in the context of the overall online sales management application but you may have different teams you have different software different kind of costs for each of those microservices and you can upgrade one without having to upgrade the other so you can upgrade your tax tax calculation with the newer tax rules you know because those those change from time to time and not have to change anything else so you're isolating sort of the impact to the other functionalities and you're able to have teams upgrade pieces of the app without the whole thing having to be impacted so microservices patterns are becoming much more prevalent and we don't really i have some customers that do want to articulate those in the business applications here but it's not really appropriate because they are managed as a whole even though they're different modules underneath the hood the users aren't exposed to those different modules they don't know any better and you invest in it as a whole right so the whole sales application has to work even if there's a problem with one module or another that's more for troubleshooting and isolating problems but the customers don't care they don't care if you have multiple modules underneath it or not they just want their order to be placed so just keep in mind that that that you can decompose your business applications into these application services that are here in the future we'll be also looking at cert the sdlc component to assign teams that are building these particular microservices so moving into that whole devops or agile methodology in that red area that build area that we we walked through in the beginning um and then when you're dealing with of course uh activities like business services and uh online ordering uh this is the overall service regardless of the number of microservices below it uh of course if if one of the modules is down the service might be degraded or you might have to delay the order intake process until the module is up so there may be some queuing or some some uh compensation processes so you so that of course can be uh taken care of in the architecture of the system and you can also start messaging degradation based on one of the modules being down and you know we can't place all the orders because the tax calc is down or maybe the currency conversion for one of the countries or support is down so uh so this is just another uh example that i wanted to take you through any any questions or on on this one quick question sure um how do you how do you configure it within the cmdb the references that you have indicated here so i know how to do the relationships but is how do you build that out so these references are built out in a number of ways um and it's there are functions features and functionalities that we've introduced that you may or may not be aware of at this point um one of them is there's a product called sro site reliability operations and that that establishes this reference here that i'm talking about so as you introduce another microservice and and it's set up for those devops teams that basically are controlling their destiny to set these up um they can actually create them or destroy them based on their release process okay so that's that's one method that we see the other method is that we do have a application service wizard that's part of the cstm navigation when you go to csdm and you look at the app service inventory you can say i'm adding a new app service define its parent so we we we have a similar mechanism when you define the parent and defining the the relationship from that point of view oh great okay yeah and and the last one which is a little bit more of an advanced use case is through apis and automation what we're finding is um ci cd pipelines that are used to deploy these applications in an automated fashion so as the organization that manages this app as the dev team manages that app create a new module that needs to be deployed their cicd pipeline will can automatically create the the the additional module the additional app service uh through apis and command lines we added that uh fairly recently in rome as well so we can use puppet chef or even command line scripts to be able to uh to do this work as well thank you any other questions i appreciate the interaction by the way all right so i'm going to take you to what i call what we're calling the now data model and this is going to be a little bit in the future i i wanted to give you an idea on what's next and how what we're thinking of next as we bring this all to light what we have um what we talked about so far is really this idea of digital products uh being used here uh there's a there's a synergy with the business service but they're typically you know before servicenow you might have bought different products to manage the app portfolio versus defining the service portfolio within our platform we're all together and what i find is that for for business apps anyway the business service definitions are almost the same and this is confusing and it provides folks are going to have to do more work to be able to define both of them because now they're both on the same platform why am i having to articulate the same kind of information here in the service portfolio that i'm actually articulating here in the app portfolio so as we bring those worlds together we're we're looking at something called the now data model in the evolving csdm in order to address this more holistically so this is again this is something that's a few probably two years out but i wanted to give you some insight on where we're going with all this and um it might be a little bit of a shock for folks that you know you know do apm today but you'll see how it works in the future as we go um the first thing i want to kind of take draw your attention to is digital when you're seeing digital products okay we're talking about a an application a hardware device a service or software okay and so digital product models that we're going to be supporting are going to kind of be variable based on what it is you're you're managing and i i've taken some liberty to change out everywhere you see a business service technical service or a business application to a digital product why this is important is that from a design and investment point of view what we're finding is companies that are creating products that ship to customers you know it is involved or these digital products are used in the factory or yeah they're not just back office anymore it's involved in a lot of things and what we mean by an application doesn't fit the mold you know using the same business application doesn't fit the mold for example if you're a hospital for the carts that you roll around in the hospital to perform work you know from a capability perspective so so the the business application has kind of run its course in terms of uh being a a way of defining any kinds of digital products that you're creating and meeting sort of all of these different scenarios uh so that's the big change that we've kind of introduced here so that we're more generic the the main thing that we do want to continue to support is some of these digital products that you have are technologies that are pure hardware being managed or back-end systems like ldap or batch services that are being managed that are focused on technology consumers inside teams that are building things using these technologies okay likewise over here we'd still have services being offered and uh but there's a synergy now we can kind of take that application name and and preserve it all the way to here though this is the app i'm using this is the service that i'm i'm expecting from it and i can actually have synergy there we're also introduced this idea of customers products sold in whatever is installed to support them um those have an impact to what you're managing in it directly through the infrastructure that that you're that you're managing in the data center or application services that are hosted and you'll notice that we also change the name of app service to system i find a lot of customers just can't understand the name application service when you say application service we kind of lose them um we always sometimes explain this as an instance of an application because you remember up here we had a business app these are each of the prod and non-prod you know instances but more generically what we're talking about is a system that is a decomposed of software and hardware you know going through the network devices and this these are all configured to work together and systems depend on one another so um and and you have other systems that might depend on you so thinking about this as a system or in a system design is a little bit more conducive to the future when we're dealing with a a broader set of things that are consumed by by customers or these dependencies internally that we have that aren't easy to understand so by simplifying this model by simplifying a language to system it becomes easier to understand what we're talking about um so those are the big changes that we have in mind we're also looking at how do we on other areas of the the model like stories are specific to a component that's being uh delivered that a team might articulate we have epics and features for products that are going to be built and funded and by those teams so once the funding happens uh from based on a demand or an idea that comes in so the ideation is an area that we want to also support because ideas can come from customers internal business partners or even you know the product managers themselves as they look at the market so this is a kind of a next step iteration thought process on where we're going uh in the middle you'll see that we also are looking at product owners system owner product will include of course the application and service today but what about the folks that own the hardware devices and just software developed so this will address more a broader set of ownership uh and also that whole full life cycle management to you know preserve what we're talking about throughout that lifecycle a little bit future oriented i know but it is still something that you want to keep in mind as we continue to evolve or use apm it you can start looking at how do i take these business apps and uh and still still plan still look at that but how do i incorporate things that are hardware that don't really fit the mold uh or maybe um deliver things to customers that don't really fit the mold for for a business applications so just wanted to pause there any any questions at this point might be maybe a little bit much to to uh internalize but just giving you some insight on where we're going next all right well and i um from a tiny perspective what do we have left just want to do a quick time we have eight minutes left mark yeah so um yeah i just wanted to leave you with this just to give you an idea where we're going and uh just keep in mind this is gonna be probably about two years out before you see this become reality there's a lot of products that we sell that are that are part of the story that need to be brought forward um new products like dpm are sort of a tip of the iceberg and but it gives you an idea where we're going so i want to open up for any other questions if you came in here and you didn't see a question uh get answered that you wanted to know about understanding about csdm and how that works is there anything else that you guys have or maybe some feedback or something that you would like to see in future and you would like to share this is your chance okay can i um can i ask you about the the customer part of this and your service portfolio um area that can be used today right with uh to determine we've got some crazy work around that we you know say this this uh business unit if you will is is using this product and we and it gets really crazy for us as we get into uh mergers and acquisitions and how to you know get rid of that and i'd like to see how to leverage that perhaps a little better to uh maybe using the service portfolio to say here are current customers here's here's what this you know somebody said this site you know this site needs to be divested what are they using um is that um because we've just completely avoided that green square to be honest um yeah is that the proper way to do that uh yeah there's multiple ways right now in the in the uh let me go back to a current picture of ap uh of uh csdm to have that conversation this is a little bit too much um yeah so what you what you'll find right now is you have a portfolio of business applications so you have a portfolio construct here you have a portfolio construct here which is different and you also have portfolios um for projects you know so so we have different portfolios that are created which are basically hierarchies to understand you know how to organize the things that we're talking about that that's been some of the challenge because a lot of the m a work that i've i've really worked on is around the business capability or the portfolio rationalization here independent of the service portfolio here uh okay but you what what this gives you is understanding your consumer and to be frank not a lot of customers have broken that out there's a functionality called subscribers that are part of this service offering and the subscribers can be a location that subscribes to a business service offering a group of people a specific set of users or even a department or company so the different subscribers that are here gives you who's actually using something you know as you as you analyze that it's not connected to the business application directly or this hierarchy up there it's connected to this hierarchy of business service portfolio and that's been some of the challenge um as you rationalize you're having to set up different portfolios to rationalize different pieces of the of the picture you know um it's not very efficient not easy to manage where we want to go is is if you look at dpm i suggest looking at dpm as a picture of the future dpm has uh two portfolio constructs one it's called enterprise portfolios this is sort of that future where we start bringing these together and one is called personal portfolios and the personal portfolios might say i'm a service owner or i'm a app owner of something i just want these apps and there or these services together this personal portfolios is um is not the one but these enterprise portfolios i would say might be a good step in that direction to kind of bring those worlds together because that's where you bring the app and the business service together in one portfolio construct this is interesting i think we're using some uh crazy workarounds to to do that very same thing we've got you know either what call it business unit uh what business unit is this being uh used in and if there's one i'm calling local if there's you know more than one i'm calling a regional but if we just leave it blank it's it's enterprise and so it's uh yeah it's not quite clean right now well that's exactly it that's exactly it so a lot of folks try to match up the business application to the the department for rationalization of this meanwhile these services are being defined with subscribers that also point to this and they may not match right um they're they're not equal and that's been the problem when you go rationalization here it may not reflect reality down here you know what i mean that's right absolutely yeah you're on this you i think you're thinking about the problem in the right way you're seeing it you're experiencing it we have a vision on how we collapse this so that it is more effective and efficient but we are we're you're just starting to see the product change to support this right um but you're if you're using apm today you can start looking at some new things like dpm in order to start bringing those worlds together i'd like to know i'd like to add a conversation about how do i align myself to to leverage what you're doing two years from now because clearly that's where we need to be yeah yeah and and we've been working at it for a while and we still have a lot of work to go to kind of sort out specifics in each product area but you know the the objective is clear it's just how do we get there and what does it look like until we get there that's going to be money okay thank you okay all right i think we're at time uh i hope this was valuable for the folks that are here and uh you know glad to do this again sure and this recording will be posted on the community channel so if you want to see it again please please you can access that from the community channel thank you mark thank you doran and everybody who joined our call today thanks a lot for joining and asking good questions see you again in the next office hour till then bye thank you thanks so much you