[Music] all right so we've got the design part which is where your business application is and we have a business criticality uh field on here right so that's that's that's known we we also have it here and we also have it on the on the service offering okay so there's kind of three places where it occurs this is a design business criticality which is like a business requirement think about this as when you're paying for creating a new application you are design it to be you know highly available or available whenever you know at your leisure so anywhere on that spectrum you know from from critical to non-critical so so that that's gonna really dictate how much money you're gonna spend and really sort of uh what what you're gonna have the team do especially if you have a devops team you know who's going to carry the beeper so that's going to be that's going to be sort of an indicator of of downstream impacts i'll ask you a quick question do you do you feel that business application and application service uh i know they don't have to be one-to-one but at least as a starting point in general we feel like there's a footprint of one in the other and that they they are closely aligned yeah they're closely aligned and they're it's one to many because here is the first place where we store environment so you've got your non-prod your prod environment so prod you know testing dev so all of those environments are indicated and also if you deploy the same business application in multiple let's say data centers or regions or buildings you'll have a different application service in each one okay and that really pertains to its footprint so this is decomposition okay right but but it's based upon environment more and and or geographic location more than it is a concept of we need multiple services it could be that we need multiple services to deliver that business application but in general you're saying the decomposition happens as a result of the things you just mentioned that's right that's right yeah you you will have dependencies between them so if you do for example have uh this application service that you you define you deploy on its specific hardware consisting of its specific software um this is decomposition but you can't have dependencies between them okay so if if they are dependent on one another and they're not you know of course they're not going to be dependent on themselves that would be ridiculous but if they're like there's an ldap application service or a i don't know a sales tax calculation application out there that you call out to there's a depends on relationship that could exist between them would you do that would you make that relationship at the application service level rather than the business application level or yeah because this is this is purely design it can be here as well right application business apps can refer to themselves but this is pre-build and pre-deployment remember so this is purely a design view when you're looking at architects saying you know what other types of apps out there do we actually depend on that differs from the deployment picture okay so we want to separate the concerns the line you know vertical and bottom this is the dev component devon planning this is the ops component so you got you got to separate those two worlds we do have our separate models and we need to to segregate though but relate them you know what well so what what happens when you're where we are which is six months in and ea is expecting the design domain and all the applications that we manage they're already deployed to be part of their domain and part of the business application inventory i'll call it is it is that backwards are they are they is this really supposed to be net new going forward in terms of the design domain net new and existing right um obviously okay so yeah yeah yeah yeah so if you went back and you at least had the business apps for everything you have deployed historically and those in those relationships you have a good design view of everything right that is conceptual in nature here it's not it doesn't really articulate its underlying structure until you say okay where is that thing deployed right uh if it's not deployed yet it's still being constructed you won't even have that okay you won't have an app service that exists yet so you're just okay so we do have this we do have this yeah and and i was going to ask because i noticed the new model does not have a direct relationship between business applications it is it is still direct it's a uh i get into a lot it's a purely an optional stop okay that's dlc think about the development going back to this picture so this is the development teams basically breaking down the componentry of the business app for for team assignments of what they're going to work on if there's a bunch of microservices or in the first app we're going to release there's going to be something called a config file that's represented here and we're going to validate it before the config file gets deployed as part of an app service is that the same as the track configuration file that we have today it's we bought a company last year called sweegle and we've re-platformed them and this sdlc component represents what we're managing there from okay and so but it's it's specific to config file like what it does is we we take a config file from a uh source repository for example as part of a ci cd pipeline and we we bring it into the system we decompose it into our system okay and then and we break it apart we evaluate the parts of the config file to say oh you know what no their text passwords no connection strings without https so we we have a a thousand validation steps on the config file before we allow folks to deploy it okay so would the sdlc component also include things like kubernetes objects um to some degree those are again at that dev design level maybe they could represent that but we introduced it because we have about five product areas that are going to be fleshing this out and they needed a place to to be part of this scenario you know what i mean okay so lots of devops use cases that are coming that's right that's right so that's gonna placeholder for now and it will expand and get more elaborate as we go but um cool right yeah right right but first for our purposes we've got we get we have this and that works just fine for decomposition and then you have depends on between them so where does it tell help me contextualize where business criticality is important where it matters because he kind of mentioned it against business application but you said that was really in terms of prioritization and that is what i think of when i think of business criticality yeah how does how does business criticality come to be maintained in a way that will make sense in either the manage or the self-consumed space i'm thinking applications against application service or business service offering or even business service and then how does that play in the sla if it plays in the soa yeah so the criticality is on the application service as well when you're when you stand this up you also indicate the criticality of these which is like the non-prod stuff i mean of a critical would be lower yeah would be lower right absolutely yeah of course of course yep yeah and it would have a different footprint because you they're not going to do like file replication across data centers and all that you're not going to do that in yeah obviously yeah that's too expensive so criticality of dev is not is lower obviously yeah and honestly we're really super focused on product operational production insurances so yeah so while we realized there's decomposition and there's a one-to-many business application application service because the stacks across the environments and and how business criticality would fit in there we really are thinking of it in terms of just that operational production yeah stack that is not always but almost one to one with business applications yeah so so prod business cutter quality should pretty much match this okay because that is your design that's sort of your representation of the deployment of a uh of an investment for a high business criticality app right yeah yeah is there a doubt would there be a downside to changing the out of the box list of values from low medium high critical to match what is there against application services i mean there's there's no i won't i wouldn't say there's any major major impact on doing that this is where i would defer you to kind of talk to the bcdr team on on the grc team because they can probably provide a little bit more you know granularity on how they use all this because they're they're more focused on the the operational aspect of this not necessarily design and planning but you know yep yeah but but yeah i would i would i mean i don't think there's going to be a major harm in doing that so yeah at this point yeah and there's a debate over which one should take precedence but i think that's a great uh response is just to like let's know more about the bcp dr space yeah so the the last part is the business criticality of the offering itself and this is this is the expectations you set with your consumers from a catalog point of view and it also should match your criticality of the application service which it actually is using now you know the criticality of services could be lower than how it's designed and implemented so you can have a group of users that only come in you know five days a week even though the system is designed to be 24 7. you know so so these the and you can separate out or tear out the different offerings for the different audiences so if this group of folks has an outage if there's an outage these guys aren't going to be you know too worried about it on the weekend but these other folks which have a higher criticality right these might have a higher criticality on the same application service may may be calling in now sorry go ahead that's a little bit of a detail that you don't need to get into what you're really trying to do is match criticalities but it doesn't always stay the same because it changes over time and you want to make sure that you're exceeding at least the design and implementation for what your customers expect how does business criticality play between business service and business service offering so it's a kind of a roll up so we store that information about uh s delays and commitments criticality here and then it rolls up the service may have two different offerings one that's low criticality when it's high that's fine that allows you to tear your service into different criticalities and those lower ones might actually go to another uh maybe it's dev maybe they can you're offering up a dev environment for consumers and you still allow people to do tickets against it you know and uh you just don't get out of bed when death goes down so then how is business criticality used to set sla or is it just it's a reference attribute and you can look at it and say well does this sla make sense given this business criticality against the service offering or is there actually a calculation that would happen there theoretically behind the scenes yeah so the the sla is is sort of joined in um but yeah has more specific commitments to it and usually you tiered that out as well in some way and the sla will be specific to the offering and the consumers of that offering so yeah there could be contracts involved and i was going to switch gears here in a minute but when you're when you're designing and implementing your offering you have a lot of stuff to to kind of put in there have you used service builder before have you looked at that is i don't think so is that when you if you're creating a a service through sort of the the interface like from an spm perspective yeah and i was going to ask because we noticed that when we were starting to talk about tying together the logical ci layers that we we ran into a dead end basically that business service so we have connections between application service service offering and and business application but then there's nothing that is connecting back up to the business service the product and and i expected a relationship to be there when we populated the product against business application in the application service uh but there's nothing there at the moment so i was wondering if if we didn't we went bottom up instead of top down if we'd gone top down it would have connected the things with the relationships that you would expect we're getting there if you look at digital portfolio management they are bringing we're bringing the business app and the business service uh together in one user experience but service builder gets a little bit more detailed in actually defining all this stuff um and so here's your your business service that you're defining uh part of the portfolio and you know there's a status for it generally and we have business cases for it but we don't have criticality at the business service level note that right right there what there's no concept of criticality or sla at the business services lab no it's for rolling up the uh what's going on with those services at the offering level and that's where we get into that level of detail so you have multiple offerings per service uh obviously you'd at least need one um when you go into that new offering and these can be tiered you've got the type of consumer you can specify and this is where criticality comes in also we're getting into life cycle planning here so when when you want to do with that description of the offering but then you get into others certain things like the team that's working on it operations this is kind of where you get into the commitments now the commitments can uh can be uh really granular there and you can have a a pretty elaborate you know stated commitment there so is this like agreements today it's sort of like agreements um it's the commitment to fulfill the agreement when you have if you have a contract or if you have a person in the catalog ordering this um this would this is something they should be able to see and understand this is when it's going to be available these are the commitments that we have maybe from this centric language right yes exactly exactly and then you connect it to the catalog items this is where you know it services in the in the self-service area and uh and then and we also talked about dependencies there may be yes yes this is major this is really important us and we don't we're not seeing this i don't think today in rome is this part of san diego this was actually its realm you should be able to see the service builder in rome okay i'll look that up because i knew that this existed against service offering and this goes back to what bcp was saying about we need to understand the dependencies across logical cis rather than just top down from application service down to hardware infrastructure yeah yeah and we're trying to make this more easily set up for a layman you don't have to know the model um and this is you know we've got little guidance tips over here on what to do um you know how to use or subscribe to this service uh financials you know like what's my cost what's my price so what should i you know and this could may not may or may not be exposed to the user but it should be um they should know how much they're gonna you know cost the company and then there's a estimated spend aspect too um and then this is a bit of a pie in the sky this isn't like a general ledger level detail right accounting level detail but this is for for folks to thumb in the air express this and track it and then last is performance now this is an area that's going to change a little bit i'm going to go back to the diagram for a second uh performance based is based on rolling up anything that's related to this particular offering based on its underlying you know application service in this case okay so that's though that's kind of what will will tell you whether you met the certain kpi of the uh of the commitment or the performance right from an availability perspective uh also gets into some of the uh business continuity planning and you know if it did go down did we did we get it back up in time what was the outage yeah so that's my my that's my other question is how at what level of logical ci do we stop seeing relevance to business continuity planning yeah and my thought is everything you just described and what where i kind of was seeing this going was that business service offering could be a really great hook if you're trying to prioritize things and understand relationships between things from a bcp standpoint and i just don't know the business service or service portfolio or business capability maybe business capability to degree but i just don't know that anything above the level of service offering has enough is substantive enough to matter in terms of if you're looking for attributes to say this comes before this and we have to do these things in this order with this priority right yeah well and it it gets a little tricky because of those offerings can depend on other offerings you know what i mean yeah um and then there's a decomposition aspect where where the application service may consist of many in underlying piece parts um servers and software yeah and and this this might it might be a fault tolerant design where something can fail in one data center and it's still up and running the users are none the wiser you know what i mean so so you're still meeting the commitments of the customer uh so how we're doing you know dealing with outages how we're dealing with availability metrics we're going to be applying it across the board so that we can aggregate this so the idea here is this ultimately down here these are the physical this is the physical tier is going to drive all of the all of the reporting above it okay so so that's going to be why that's going to be why the business continuity is is important here but it's not too critical here because you don't really you have a different one here which is really at the consumer level uh it's important to you know match this obviously but then also underlying all that infrastructure the criticality here also comes into play right if i if i'm designing an application and i order you know i'm on the team and i'm going ahead and i'm designing my production environment and i order something from the infrastructure team that is doesn't quite meet the sla you know i i've got i've got a lower tier offering here that i consumed right this is also part of the catalog of the piece part the server that i implemented in a higher tier business continuity requirement so we don't store continuity down here necessarily we store it at the offering level which is why the the dynamic service is really important so here's what we can do with all this right so let's let me just draw out where all the business continuity parts are and what what we can do now so we have business continuity here when you're designing this at the component tree level right at the individual so we definitely have a gap here by the way which is we really do not have technical service offering defined at all okay so so this sets expectations for the guys that are assembling new things or you know so this would be like i need a linux server or i need an oracle database instance but but again so if i need a linux server is that a linux server for the dev environment or is it one for a production environment and and this is how they're going to get out of bed or not when the when the incident comes in against their particular server yeah okay now now that trickles up to the folks that are expecting service here so so think about it this way if you have bc business continuity here if you have it down here for every piece part we can see where there's a mismatch between what the customers are expecting and what the criticality is of the underlying componentry so we could do some pretty advanced stuff at that level okay but it takes you you know you do have to implement the technical services you do have to implement the business services um and this still just pertains to design and implementation but uh where it really matters is here and actually the the design of the overall system like the dependencies that you uh develop between these component trees these guys don't know obviously they're just giving you hardware they don't know how you're designing it and putting it into operations so um you know only somebody up here can really know that to drive the design so so say sorry say a little bit more because you said two things one was you said this is where business continuity really matters and you were indicating that was against the application service yes okay and then also you talked about the mismatch and you're saying basically that a a technical service offering might have a mismatch in terms of of the the criticality or even sla of what's being deployed that is a dependency for the business service offering that's right you can have 10 different services you're consuming you know think about networking and servers and databases and all kinds of stuff down here provided by different teams there's a consumption provider sort of aspect here but these teams are providing a service that you're using now as a as a component within a larger deploy deployed application server so what what are the implications of that mismatch because i think speaks a little more yeah go ahead sorry yeah risk and not meeting the sla if there's a failure okay and you're just saying it's it's normal that like you it was your statement about these guys over here don't necessarily know what they're building the server for so so their sla may be based upon what their turnaround time is or what their expectation is of delivery of something that's independent of what business service it underpins and so maybe maybe you have a a most critical business service but a a tier of linux server deployment that is not most critical correct and and there there lies your your risk profile when you're looking at continuity and business continuity does that dr planning that's where that comes into play now now this is an advanced use case this means you're going to have to have those technical services well-defined dynamic ci groups that you know pertain to the infrastructure and you can trace these things back to the criticality here and then of course over to the customer but uh that's kind of where we're going and the reason i say that is we're changing how we're going to be tracking availability at this tier so avail actual availability is is going to be measurable at the individual componentry level and but then again it kind of trickles up here and it can be done here for metrics right did i that is am i meeting my sla even though it's not you know available i'm still okay because i'm still mating my sla or did i breach it you know because i'm i've exceeded i've i've gone down and i haven't met the expectations of my customers i'll ask a very high level question knowing that we really should have a discussion with the the bcdr folks about their product um can you do effective business continuity planning without having your technical service offerings built out you can i mean obviously you're going to do it here and the architects are going to say you know yeah we design the production environment with log shipping and multiple power supplies across data centers or whatever right that can certainly happen um but you're really relying on the architects to know the design and what componentry they're using right they have to know everything they ordered you know in a catalog at one point and and how it's constructed otherwise you know but the more the more isolated you are let's say this is cloud maybe your infrastructure is in the cloud you still have to understand the sla of your cloud provider as you know even if you're not owning the server it's a virtual server you still have to know what your cloud provider is providing you know so it's a very similar situation you know with technical service offerings it's just you're you're buying it versus having an internal uh people provide it if you took both sorry i know i'm throwing ridiculous hypotheticals at you uh if you took both technical service offering and business service offering out of the picture and you just were dealing with business application application service is that enough to understand from a business continuity standpoint or dr standpoint what you would need to stand up in what order uh to a certain degree again it really relies on the architects understanding you know the design of the underlying components but um if if this sla is is not there because what we've seen is is this and that's really what i'm asking if sla is not there because that would have to be against service offering right you wouldn't have it against application service or business application right right because these guys um you know you might have a network team basically they said okay we're low staff are we're going to lower the sla of all our network here how do you know how does the how do these folks up here know that that happened you know because you're going to evaluate this periodically this isn't an operational area here you can still do operational you know metrics here right you're doing that from availability on the app service but that depends on all that underlying componentry and there may be a lot of things so it really one team can be your weakest link in the chain but what we're trying to get to is a a level of of granularity and measurement so that we can find those weak links right if they change their sla they lower it right for the things i'm using wait a minute right no that doesn't work that doesn't work because that's not what they expect right yeah and that and that makes sense what can you use to prioritize and what can you use to determine dependencies and that's why i wanted to take you through this because this is how we're gonna aggregate metrics um we're looking at changes to how we're tracking outages and everything is going to be following this paradigm that i just walked you through okay so so it sounds to me like because we're still we're we're still in the situation where we have all our services aggregated in the ci service table and have not split them out into the technical service table and the business service table i am going to suggest that rather than doing a scenes migration a lift and shift that we maybe need to go through this interface when we create or move or migrate those services out of ci service and split them out this absolutely would that yeah okay yeah that's why you want to search relationships well and i wanted to draw your attention to this because this is where you get into the what's really critical to be able to define on these things when you're defining them the team that supports them you know these are the support groups that are going to be you know dealing with it here's the folks that are going to be subscribing to the service now what does subscription mean in that context when people subscribe to a service okay so a service can be just subscribed to and by an individual so this would be like a user table and an app okay for example but if this business application uh for example uh supports all of the buildings or in a specific state or in a specific you know for a building like the badge reader you can provide that here okay from a location point of view or company or department so you can do departments as well hr all of our hr depends on this thing so however is this really just tagging is this really just no this is establishing a reference to the particular offering why this is important is think about let me go back to the diagram in a minute if if you have a change or an outage of a server just one server but now you know which app service is part of you know the offering that that depends on it it's part of and now you know the subscribed users you don't have to spam the whole company you could just say let everybody in this location know that this is going down for an hour right now we don't track it at a granular level at that subscriber level for the most part right we span the whole company no matter what happened but this gives you sort of that level of granularity that you need to properly manage outages changes even changing the sla i can say you know what we're gonna take and change our sla for this location because you know we're not gonna stop it anymore you know 20 percent right so think about you the service owner is the proprietor of their service they they are the the the the manager the product manager of their service and they i was going to say what role do you do you typically associate that with yes portfolio manager service yeah but i mean is that like a product owner is that the pdm is that the where we're going where are we going is we're joining up the business application with the business service and the offering uh because this is turning into a product owner when your product owner you sort of own the entire life cycle from design and implementation okay all the way through the consumption of these things and then you should know who is consuming your stuff okay yep so this gives you the facilities there's it's still divided a little bit between the business app to your area and the business services or the technical services if you want to get that to that level of granularity but yeah it that's what is where we're going we're bringing it together i'm going to ask another outer left field question one of the things that we ran into when we were refreshing or the the baseline of product and portfolio was that teams came to us and said we have one product but we have three pdms or we have more than one product owner we have more than one uh even portfolio manager in some instances what what do they own though i mean if they have more than one what does that really mean i don't i that's that's very much the question right yeah and what they've said is our product is too big for one person to manage it and what i have suggested is that maybe the service offering level we could get to that one-to-one relationship or some something below the service level because they're they're trying to say i have a team of x number of pdms or product owners for single business service yeah so we see that in like a a monolith that's broken down by separate microservices uh that's another use case for the sdlc component that we're going to be implementing so you might have a different owner for each app service here at this tier and this portion of the application design because these are all going to be highly integrated in a microservices design you're talking about multiple app services that are all uh loosely coupled highly integrated and they could even be deployed on different hardware but this is where you can get into multiple owners of each of the components out there and honestly i think the ownership gets to be one-to-one when you start talking about just application service level yeah it doesn't even have to go because there would certainly be a collection of micro services underneath that but i i think it's just at the business service level it's a many um resources to single role relationship yeah we're trying to get them to understand that there's a bunch of reasons why that isn't really a the way that we want to manage that that ultimately you need to have a one-to-one relationship to have effective workflow and yes you know ownership and all the rest right yeah yeah and and here you would if it is a microservices you might still have one business application tier and you have multiple microservices multiple owners of each of the componentries and potentially different offerings but even the customer they may not really care or even know who the multiple owners are right when they come in they're going to say i have a problem with this thing no matter what it is and then somebody's going to have to troubleshoot it oh the server used in this particular microservice is down you know so that's the person we have to get on the phone how granular do people get sorry i'll ask one last thing because they've given a ton of great answers it's all really great information i'll ask one more thing which is how granular or not granular do organizations tend to get with business service offering so like i certainly have seen all the lists of examples of like you know gold silver bronze or um you know building a workstation or a laptop for an executive versus a help desk employee or uh by region or things like that but i'm just wondering how much more what are what is there a reason to discourage um granularity of business service offering maybe in some of the ways that we've done it which is to say business service offering is less one-to-one with business service and more one-to-one with business application and application service so now we have this triumvirate of business application application service and service offering and they're virtually one-to-one and they're tightly coupled and they're talking about making it so when you create one it auto-generates the others so that is kind of where we're going from a product centricity point of view you know that devops ci cd pipeline uh approach um where they you know a team owns the whole thing and usually have a product manager here product manager or owner um that is where we're going um the the problem is historically we've had a huge separation between the dev world and the the you know operations world and support world so we're trying to join those together but we're having to kind of drag some of the old stuff with us with regards to how we think about things but the user experience should be more seamless right um there's a portfolio management if you haven't seen that that's where it really comes together because i could i could say i own both the business app and this in the business service and everything related to it right so you're you're now triangulating on that app service again and uh if you get the two these two parts right the business app and the business service everything else comes with okay okay well yeah and there's a white paper i wrote on digital product management digital shift to digital product that kind of articulates that that's kind of where where we're going okay yeah if you could uh email me that link i would appreciate it okay yeah any i know you have a lot of material material out there um and whenever we have a conversation like this you recommend something i definitely like to go look at it because it's very informative so yeah and it's it is um you know we we're evolving slowly incrementally um what really needed to do is say well what does the end state look like right when you're thinking about this product-centric way of thinking and um you know in the in the cur in this model and uh that's kind of what the paper represents so but i i know we're way over actually so yeah sorry sorry for taking so much time but i i really do appreciate it