couple guest speakers to come in and talk about this we have been talking about it the last few weeks so i'll kind of bring you up to speed on the other pieces that um that we have discussed in prior meetings if you wanted to go back and check those out now for those of you that uh want to go back to some of the prior meetings there is a youtube channel now called the digital services forum and all of our meetings that were we're actually going through now will be put up on that forum after we're done so right now we have everything that we've done in 2022 or on that on the servicenow community if you want to go out there you'll see we have a playlist and that's where i'm putting all of our recordings instead of the google drive where they were before okay i'll share that too and when we go through the updates okay so so today we want to go through and um before we start we always go through this about the work group and we're probably going to change this to start calling it a forum so there'll be some changes like i said to the structure but we have been meeting bi-weekly since 2018 and i always call it to discuss the service in servicenow and it's really about that part that we we talked about and it's delivering these services and getting better at delivering this services is all part of digital transformation so what we want to do here is really represent that digital transformation thought leadership as much as we can and we do that by enabling all of our members and a lot of it is just coming together and sharing what we've done to do digital transformations in our organizations to deliver specific services the model around delivering the services we do have shared work and the shared work right now is all out on our google drive if you don't have a link to that let me know or drop it in the chat somebody can put it out there and we can get you a link to that google drive as well as a shared instance so we have this shared instance that's it's been around since 2018 and we've been upgrading it but all all of the demos and prior work you can go in there and see some of the things that we set up so there's some standard portfolios in there for state and local government and for higher education so you can see the structures that we've created for some of the demos now if you are going to demo in the work group you don't have to necessarily be on that instance right but when whenever you send me a recommendation for somebody to be added or yourself to be added i'll give you admin on that instance so we're all admins we can all go in and do the same things on that shared instance okay this group is hosted by our architecture team so i'm an enterprise architect with servicenow and our whole team hosts this event so different people will be bringing in different topics at different times and our executive sponsor jeff lubay is the one who supports all the enterprise architects in the americas and he is our sponsor for this group okay so that's basically the group started with three of us back in 2018 and right now we're a little bit over 550 members so if it is your first time today we just have a bunch of people coming on for the first time if you can just drop your name and chat and tell us where you're from and what you do so that we can welcome you that'd be great and uh this is just kind of you know there might be somebody that makes contacts a lot of what happens here too or people are making contacts amongst each other and having side meetings it is more of a networking group as well even though we are meeting online there's a lot that happens in chat during every meeting so if you do want to drop your name in there that'd be great and then other members can see who you are and maybe you have something in common that you can break out and collaborate on i'm going to jump right into our topic for today and mark are you out there i am can you hear me okay i'll just kick it off here a little bit and show you uh where what we've been discussing over the last few meetings and give you some context for what we can talk about today so over the last few meetings we've been talking a lot uh and this picture has come up a lot and a couple of you i think have have taken it and used it for conversations and basically there's three work streams in here right there's the devops work stream which a lot of people are aspiring to there's the work stream where you're supporting services uh which is this one incident problem change and then the innovation work stream where you have hey i need a something new i need a new form and i need to come down and get that form and what's the process for delivering that form from the time it's an idea in someone's mind all the way to the point where it's live on a site somewhere and you can actually interact with that service so it goes through all of the iterations on the idea to the funding request and then it drops into some type of work stream that that's happening uh to actually deliver that service again and again now it could be anything in here right from so we talk about this model for delivering a service there's a lot of things that that affect it right one of the things that we talk about a lot is the size of the service is it a travel request where you have 20 fields and you have a manager that clicks on approve or not something simple like that or is it something really advanced like one of the things we work on at state and local is an unemployment request where it can be weeks of validating the eligibility for that citizen and also making sure there's no fraud along the way it's also the organization people on this call we have people that have organizations that are 500 people and we have organizations that are upwards of 200 000 employees in an organization there's a lot of things that affect this how do we do this right what we're really talking about in the operating model is who do we a big part of it it's not the only part but who do we actually have to develop these things so who who do we need to deliver a service again and again and then how do we standardize this so a lot of times if even if you think of the service of delivering a service right a lot of times we see people doing this over and over and over again every time they have a new service they create a new model for delivering that service there's a lot of people that have been discussing this over the years and one of the groups that we we have internally who is mark is going to talk to us a little bit about today because we had this conversation just to get us started on on a click down on this so mark is the product manager uh senior product manager and he works in our data foundations so he's responsible in enlarged for the common service data model and we want to talk about the common service data model and where is it going and how is it you know i know it's it's not the entire it operating model right but it's it's a large part of that i t operating model so we really want to talk about how that ties in as we model a service on service now how can it support the operating model that we have and then to give some thoughts around the different people that come into play like we've just been waving a hand at it right and and doing these nine roles that we have that probably some people need to fill on that innovation part but what other parts are in there in that model okay and then digital products are new things so the that is a big piece of that we talked about in the operating model as well and then we've been talking a lot about portfolios and i was asking mark on a call the other day hey where did digital we'd have digital service portfolios in our enterprise and dpm kind of where do the products fit in right is that another portfolio is that the same portfolio so those are some of the things we're chatting about i just asked mark to come in and kind of lead a conversation around this and you know we can as usual jump in if you want to but mark i'll hand you the the reigns and you can kind of take it from there and uh give everybody here's some of the wisdom that's been going on in the i think the open group and as well as servicenow right yeah that's right um so anybody that hasn't met me before mark bodman here in austin texas i i uh participate quite a long time for a long time in the open group activities architecture forum rcma it4it and i'm leading some of our cross forum activities at the open group as well something called open digital um frameworks so i could jump right in there's john if you're ready yeah that's perfect mark you take your take share over i will take the share over and i'm going to talk a little bit about sort of the genesis of this digital product idea and where we're going from a common service data model perspective uh in the future where it's kind of kind of arriving at that same sort of juncture so i think i could share i'm trying to share now but i just got to take over from you and i'm going to jump around my deck a little bit but i wanted to start with a few things uh because this is kind of kind of a ground zero for where digital product as an idea came about um so just a little history on my own sort of tenure here i've been here with servicenow for a little over five years i used to manage the app portfolio management product here which is more largely uh at the left of this thing and the i like to think about this is what developers think about creating when you're developing code you're developing an application you're developing something to be deployed and then used by a customer however on the services portfolio side you're dealing with itil and the use of digital technologies in some way you're creating those services and my colleague at the time david thigpen and myself we were in a room and we started to sketch out well what is it we're managing what is what you were starting to bump into each other on this platform because i'm dealing mostly with planning and development activities over here this is majority of the work that i uh i do the features that apm is kind of implementing but over here it's mostly operational in use of technologies or maybe if a problem or incident change is happening how do you coordinate that well as these worlds come together especially if think about devops you you have in the middle something called product and there are certain elements that are in common as we started to add more features to our respective product areas there was more things in common and app service is at the middle which is just you know a conjunction of the two really um think about that about it that way but it's still a foreign concept for a lot of folks because if they're dealing with a smart device in a hospital for example or you're dealing with manufacturing technologies you don't think about those things as app services app services tends to be the some of the hardest things to communicate to my customer base and uh depending on you know what kind of thing you're talking about that name just may not resonate but in the middle so we we kind of envisioned what happens when these two things get together what are they in terms of a planning entity and that's where we came up with this idea of digital product originally and sometimes it's a device sometimes it's a service which is an engagement it's an interaction and that and there there's an outcome that's produced sometimes it's an application that i use on a day-to-day basis so we we tend to muddy the waters between the different worlds and also different contexts and so that's when digital product as a concept was born i'm going to take you into the it4it world here for a moment because over the last four years we've been re uh re-architecting idit freight framework around this concept we've also been looking at it from an i t uh csdm point of view but i want to talk to take you through the it4it stuff real quick because you'll see sort of changes being reflected that we've documented in it4it so the first thing that you'll see here is that we've um uh you've got on the left hand side is really this idea of a digital product instance when you to have an idea for a new digital product you will basically get code assets infrastructure whether it's on-prem or in the cloud completely sas or or combination and you pretty much code those or you deploy those and they become an ins what we call an instance of a digital product you basically have a contract with your consumers of that digital product and different ways to interact with it either there's human interfaces machine interfaces or in the case of a factory it could be a robot the robot moves the piece from you know a to b to c so the the interaction basically is what where you how you consume a digital product and the system basically performs work to pro to see an outcome whether it's a service a smart device or a factory automation step so this digital product is pretty loosely defined here and there's a few other things that are kind of interesting because these digital products rely on one another there's a recursion that occurs the folks that manage the the infrastructure or the cloud resources provide those for you to create applications on them and then you provide interfaces for other applications to maybe interface or services to interface so these are all these are very recursive there's a recursive aspect to this and this is a very i would say different definition than what you see in the in the in the wild but there's a few key things one is system is the word that we're using in the it4it forum we're also seeing contract because that's where the the price the cost and the sla ola the outcome that we promise whoever interacts with my digital product that's where the pro the the the promise is made and this all kind of maps with csdm today this is the 4.0 model on the right this kind of maps when you think about digital products we've introduced this idea of digital product models down here as a catch-all for different types of digital products that we will create whether it's a smart device or you know software that runs somewhere or service that we will perform for somebody or something we also have to incorporate this idea of the technical services and business services these are both kinds of digital products you just have internal consumers over here and here you have external consumers the business folks that are going to be relying on technology to perform an outcome and last but not least is this notion of a business application which is a pseudonym for digital products in many big organizations they basically i think historically i see a lot of companies that take this business application and they copy it into their service table and they call it a day well this isn't really intent and also business application doesn't work with a smart device for example if it's a uh a cart that rolls around in the hospital so we needed to kind of take a look at this it4it definition to say okay how does csdm evolve to account for all these different use cases how do we actually manage uh creating these the la the next thing i want to show you is another thing that comes from the it4it forum that was documented as well and this is a looking at how do we look at the different types of digital products that we have in a large organization so think about any of them can be a smart device a service an application that you're using and we came up with originally three key portfolios the customer whatever products are used by your customers because the interaction with your customers are now digital you're providing customer smart devices like smart cars or smart phones things that are basically in their possession or a combination of devices and services when it comes to let's say your telephone or cable service employee facing this is also covered in the in the case of anything that's internal or external roles that people use hr finance uh applications and to some degree other other tools that could be used to create digital products but we've created a separate thing for that foundational technologies is shared this is like these are things services that we would say are shared i.t services uh these are the things that everything else depends on or is built upon and so think about a bill of materials you want to use networking services backup services uh storage services in order to build something at a higher level that customers will eventually consume or employees do and the last thing that i wanted to kind of talk about here is really the factory automation portion the factory supports all of it whether it's a shared foundational deliverable like cloud requesting and getting a virtual appliance or cloud or in once that's acquired then you're building something for employees or you're building something for customers to use so there's a factory investment that that's required i talked to a customer recently and they said you know what we really didn't optimize this factory automation this factory tool chain area and we have recognized 250 different factories that have been built across our our teams and they're all different everybody chose a different set of automation puppet chef you know different vendors different steps along the way and we not we need to really rationalize and automate the factory in a more sustained way a more standard way because some people skip certain steps in their factory automation when they're creating products for customers or employees they'll skip let's say evaluating the data compliance and if they added credit cards now you're subject to pci and you want to be able to catch that before it gets in the hands of the customers and you violate your policies so these are things that they need to also start to automate down here and rationalize as a portfolio mark so yes got a couple questions in here uh just on the difference that we we get into this a lot with products and portfolios and if i can explain it and tell me if i'm right or wrong but the or products and services rather but the products are kind of what defines what you're building internally right with the team and you're crossing apps and services together and then the services are still what's being delivered to the consumers is that right or do the consumers actually see products sometimes it's a service sometimes it's an actual product in the sense of the laptop that you have in your possession right now that that is a that is a asset that's a product that you basically get service on so it depends on what i would say the primary deliverable is it a action an interaction that's a service or is it a device that would be more more like a product a physical asset but in the in either case that's why we came up with a generic term called digital products because at the end of the day there is um there's a service component to it there's a warranty service on the physical device that you're providing over over the life of that particular physical device and then when it comes to let's say interacting with your finance department to change your credit limit on a credit card for example that is a service engagement you know the product really is is uh the credit card to be honest and it's the extension of the credit you know the credit limit uh so depending on sort of the thing you're talking about we want to be specific right because when we change our terminology along the life cycle that's where it becomes really muddy and that's what we want to stop did that answer the question for whoever put that on a chat no no we can take this offline but do i have a minute to ask a question or we can take it offline sure sure ask my question so my question that i have is you know products you know we have been doing product management for a long time but you have the concept of uh service offering where you have the contract defined as it is now before the product is right then you have the application service that is a composition of the cis right so that's there then you also have uh the capable business capability and business application concepts so what i'm trying to understand is the product is that just an abstract concept or is that going to replace so for example if i have to put my slas am i putting my sla in a product somewhere else or at tso level so is it replacing or you're adding another layer of abstraction on top yeah so let's talk about that here so currently when we're talking about the the elements you're managing you're talking about business applications things like business services or technical services so the today the the worlds between development okay and operations are quite separated now what's bringing it together are agile capabilities agile principles whereas where the team delivers the product and they actually they they adopted the name well before we did right so so they already say we deliver products period right yes and and we'll then we kind of rename it as services over here or we kind of fit it into this business application from a historical perspective the problem is we we may sometimes refer to the same thing the business service is the application all right but sometimes it's not it's a smart device and that's where the current methodology the current terminology because we don't say products anywhere it's all ancillary down here you know the product is really down here we we don't have a product centric operating model within most cases right and the devops teams they're operating in a product centric way but these guys don't yet right are the the design stage they don't call things products over here at all and then over here we don't call things products over here at all but what is the deliverable at the end of the day the the team that is putting something out there is assembling many different products down here to to run as a system so think about this as your system which basically incorporates all of this underlying code and they have rely rely on other systems right might rely on other digital products to run so so in a sense we've looked at this sort of picture and said you know what what's missing what can we really envision to jump to a product-centric model and then bring bring sort of this idea into the main stage right so that's kind of that's kind of the thinking at 4.0 and why did product models have been added but now let's go to the next step okay so uh it's in the answer your question are am i replacing everything not necessarily but in some cases where you already copy your applications into your business table you're doing it already you're already kind of saying this equals this but when you have something very separate that's where it becomes confusing for your consumer knows the applications they're using but when they look at the service they're not sure which service to provide to to choose for example and that that becomes a bit confusing or if it's a device there's there's nothing so here's my comment there you know uh i like the idea product because in the agile world we have been in doing product management for a long time so is that going to be comparable to a business service because it has well this is where we have well this is where we have the opportunity to kind of reinvent ourselves given this product-centric world okay and uh you're leading into the the last portion we want to talk about all right so what i'm gonna yeah no you're you're you're right there so how do we you know envision that next step so what i'm going to share with you next is not published it's not going to be published for a minimum of a year but this is what we're looking at right now this is kind of on our drawing board it's called the now data model and it's in draft and and the idea here is what if we did kind of put digital product in for a business app for business service and down here technical services okay so no matter what i'm sort of reporting and managing as a portfolio what does that look like we i mean even the portfolios we have a separate busine application portfolio separate project portfolio separate service portfolio what if we collapse that into one portfolio concept like like i just showed you the four that that we have um yeah yes and then down here at the right you'll see the the digital product models can be an application uh a service a pure interaction or a smart device software i question a little bit because software as a deliverable is maybe just a down here it's not really a product that runs to deliver an outcome but the offering is still valid you still have to know the sla ola and you still have to know who your consumers are and then we've added this notion of understanding your end customer so what is it they that you sold them what do they have entitlements to did you sell them a device that's in their house or in their position so we needed to be able to understand this context as well as just internal consumers which are usually here so basically what you've done is you've gotten rid of business application business service concept and immersed both of them together and created the digital product which can be supported through the design build uh manage uh life cycle and consume life cycle that's right and it really matters what is it you're consuming right is it a is it a hardware thing a software thing or a combination of the two um and or or i'm just interacting directly with an interface of some sort so the the idea here is that let's let's not muddy the waters any further with the old terminology and what if we just adopted this digital product concept to say what does the world look like and this is sort of our next stab at it you know uh and then you can see that we're also looking at different things like how uh the system is now instead of application service what if we did go with a system concept here the system is decomposed into hardware and software but it's also systems rely on other systems this is a simpler you know systems design is a thing this is something real that we can actually get our heads around see well one thing that i i liked about the legacy the services was that you for the first time had very clear-cut responsible ownership uh now by doing digital product again you're muddying up because who is the owner of the digital product is that well they they sit in the middle they sit in the middle still and that's the idea is that the service owner and app owner are maybe the same person matter of fact i don't know if you guys saw digital portfolio management as a product but digital portfolio management brings together the app portfolio and the service portfolios in one user experience so if you are the owner of both the application and the service you now have one place to go to see everything related to it you don't have to jump around and you know into something ap called apm down here and something called spm down there so so there is we are moving in this direction to bring these two worlds together what we haven't done is made the leap into calling things products yet but that's really the next big phase here is to get into a product centric world we need to call things products okay thank you very much mark um as we as i go through this let me first snag that i got caught into was what about uh businesses that do not have a a sold product that is that is installed or that is mailed out or wherever it's purely a service based that's fine then everything you every everything you provide is a service type digital product then and no big deal but what if it's not a vital product as such for example uh like for example healthcare i see that healthcare is in the background there there's nothing nothing so that you're in you're providing you're providing actual services to the customer on their let's say on their body that's right that's right but but but they interact using digital products that you're managing so somebody created let's say a scheduling app for getting your appointment and they your customer has to interact they have to be entered into the system otherwise you can't schedule an appointment true right so this is louis um i work at baptist health and we in our business applications we currently have about 937 business apps built there who have services underneath but it's mainly the business applications that we use to deliver health health care services to our to our customers yeah and of course those customers may not see all of them they're kind of behind the scenes in some cases right so there's they're behind the scenes systems that sit in front of the system that the customer does use and of course whatever you sell them is is a service you're selling them an appointment you're going to charge them uh so all these back-end systems need to exist in order for that interaction to happen properly and more and more it's all done not on paper it's all done electronically would it really help the model if some of these for example sold product install based maybe we just color code them somewhat slightly different to say these depend on the the environment that you're working in so because they don't they don't apply to you in the case of for example let's say healthcare right they're enabling yeah but things fall the funny thing is on on the healthcare one they're the ones that drove probably this product centric more than others because they have these machines they wheel around the hospital and then depending on where the machine is right somebody in the business will call or report an issue with that machine uh because they're mobile and they have to know where they are at any given time so they pushed it more in the hardware side versus uh service the service stuff is pretty pretty well understood i think it's the stuff like hardware you know that rolls around and it's it has to be accounted for that that becomes a little bit sticky because now you don't really have a business app that matches it you'll have apps installed on it and on the back end of the of the cart that it needs to communicate with in this data center but uh it's it's complicated this is a bit messy it's coming yeah actually that says sell and consume they don't really consume and they don't really you don't sell to them your cart right no you don't you never it's bad that's all right there okay yeah and that's the point right so the the this is lou from senior the mark the for a long time as long back as i can remember years and years the software model the hardware model uh facility models all these models existed and they had a capability to publish a catalog item from the model and it's just to follow the rules and publish all your catalog items from a model and then in quebec i think the service model came out but the service knowledge did not come out with the ability to publish a uh catalog item from the model so when you have any you have out there a product slash service you could just be selling a laptop or perhaps that laptop comes with access so you combine that and you have to make a decision is that going to be a hardware model or is that going to be a service model right yes yes it's a combination most of the cases it's a combination and that's why the system becomes a little easier to understand because this system could be a combination of hardware and software that's now in the possession of a customer or a business person or rolling around a hospital you know that that term still works and the intent of that system is to understand not only what it's decomposed of because that's what we really built these uh to understand is the layers that decompose it into the underlying infrastructure but then they have dependencies on other systems which is also very difficult to manage and articulate in this in the in this world generally so we want to be able to do that better yeah right but the point is that if you stick with the house arsenal designed this many years ago publishing your catalog requests from models models then have the product owners associated with them and that also also ties into apm where you associate your models and your products to get the life cycle so it all rolls up that's right ties in but the key is not creating catalog items without their underlying models whether it's a service model or whether it's a hardware model whether it's a software model i think doing this keeps it very straight that's right that's exactly it and we're taking those and they can be bundles but the bundles have to work together right it's not like a bill on materials where you just order all this stuff it has to be configured it's got to be built by a team that understands the requirements right of that product and the combination of those underlying products and so going here you get more of a product design acumen and a plm sort of acumen versus what it does which is we lose track of that all together other than sam and him which are pretty much understanding the life cycle of stuff that you actually buy from vendors we really don't manage the life cycle of what we how we assemble that and how we consume it internally very well and that's what we want to get back to yeah i just hope you don't change the application service table again when you change the system well yeah what we're i mean the the practicality in how we roll this out is to start leveraging the product model tables more explicitly and referring to things in that basically that we are defining here as products now when it comes to digital products and not just vendor products that's where we're starting to unwind some of this stuff that's happening within sam and ham because their software and hardware asset management have capitalized on the product model concept they're the ones that have used this most because that's where you spend real money with real you know products from your vendors or service you know services uh hardware software doesn't matter but when it comes to the things that you define internally that's where product has escaped us we want to bring it back i'm just saying a lot of work went into migrating from the service classification application service business service technical service to the new tables and now let's change them again well and it's not necessarily changing them it's evolving what we have now with a wrapper to define the product that we're talking about so this is going to be an incremental thing like i said you're this isn't going to see the light of day for at least a year or two but the ideas are starting to uh unveil themselves in products such as digital portfolio management and you're starting to see signs of how we're moving in this direction okay makes sense uh but yeah it'll take a couple generations to actually move it to this simpler model but you know the thinking is there i just wanted to share this because if you could see the thinking behind it you'll some things that you're seeing along the way will make more sense matter of fact we changed the the life cycle definitions recently in order to manage the full life cycle across ever all of these elements more intelligently because previously everybody had a different notion of where the life cycle was whether you're up here talking about a business app or or services services didn't really even have a life cycle or established system or a component of a system down here yet again so um assets were separately managed from cis so we're collapsing sort of the the functionality in the data models kind of helping to drive some of that but the functionality that comes on is going to be more mature to be able to facilitate it the one thing i also wanted to ask and maybe see has anybody started using service builder where you define the service and the offering and then connect it to the app service yes yes yes so so those are that you're good i'm sorry go ahead no i was just gonna say there's some open cases on that because there's some inconsistencies i think between service builder and the native ui on the back end like for example the business field is 4 000 characters and on the native ui it's 40 characters so yeah yeah so more more tuning i guess more tuning but it was i think it just came out in rome so it's pretty new and i think the customer feedback has just started to roll in on that to improve it right so that's it's really a step in the right direction to get the folks that do on the service component to be able to define the offering as part of the the service now imagine if that were digital product and that was sort of also used in the context of an app so it would be easier to define all these things in one spot and then just declare what kind of product is it does it contain hardware software or both you know so so we could streamline the creation and also explicitly define the offering which uh has the sla oil away and starts to enter into the costing aspect right and also even how it's tied to the catalog items how is this consumed yeah mark the service build is good it's consistent with the low code no code user friendly drag and drop you know experience consistent with workspaces and the features functions capabilities because it is sort of that different uh environment it's not as rich as the native ui forms but i'm sure that'll happen over time yeah yeah like i said it's a step in that direction just to streamline the creation of these things um but yeah it's it i would say there's there's a bit of a back and forth between data model thinking and of course how the products are evolving um and like right now customer the customer install based and sold product that's only available in csm and our csm module to make that more common across everything we're looking at bringing that in as well hey mark i have another question the souffle sure so when you had the technical service uh you know on the left-hand side in 4-0 and which was slightly confusing because they were basically a capable or technical function like a team you know windows uh you can say windows or a collaboration or something like that and then you had offering you could say a laptop desktop and you know whatever it may be digital product now that's not going to be parallel to a function anymore or is that supposed to be parallel to a function well it's so it still works in the context of a technical service and now let me go to a 4.0 model to have this conversation a little easier um so so the the folks that manage the infrastructure they provide infrastructure that is sort of acquired through a catalog so if i own if i basically provide uh i know intel or linux images that that works fine uh how that basically yet they have to think about what they provide in the full life cycle because here's what's the cost of that technical services the the uh the support group the offering sla ola and what it pertains to within the cmdb as those things are instantiated that has to be managed well and we're starting to automate some pieces of this so once you define let's say the support group or manage by group here we propagate that information into all ci so let's say there's 30 000 servers in the data center we can associate those 30 000 servers to the support group for each individual one so we're starting to automate and use this model in in more sophisticated ways and they do need to think about their product because eventually these products a lot let's say that the server hardware maybe just physical hardware will stop being supported by your vendor so the cost the the ability to update it the the need to fund those upgrades needs to exist and the problem that i've seen in most large organizations it's not part of the the design it's not part of where the investments happen you know at a corporate level these guys are kicking and screaming for investments that's kind of below the line or not seen in a different portfolio keep the lights on portfolio sure um and that's where that first image kind of comes in where we start managing as part of the whole each digital product plays a part this stuff is really foundational that's which is why we're calling it foundational now in the it4its side because that really dictates where it is in the stack so processing i'm sorry understood understood this is it is a few jumps beyond what we have today but it is helping to bring a product mindset to all the owners of of these services and or applications um yeah they're we had and where does the service owner make sure that there's funding in the next you know year to upgrade all their services or to migrate off of cobalt technologies onto something else right so basically it affects your staffing instead of a business application you have a digital product which can be a collection of other digital products uh created by the technical services or a business services right because basically you've renamed all of them as uh digital products so there is no more that easy segregation between a business service is a consumption driven uh capability uh technical service is a build capability or managed capability and business application is at a you know higher level so now you're almost like you've overloaded the term and depending on the context the digital product can be something that's in the managed technical services or in the consumer yes that's right and and this is where it's quite interesting a lot of companies that i'm talking to they'll take their employee facing stuff and then and then open it up to customers you know or take a foundation aws was a a huge bet that aws made right amazon made and now it's a product they sell to consumers so understanding the outcome when you invest here this means that there's income but down here okay when you invest what you're doing is you're you're investing in your ability to produce new digital products more you know more quickly more reliably uh of course the outcome for employee facing stuff is classic i t making your employee life easier but foundational how much foundational do you want to own do you want to own a data center or outsource it so each each one each one of these portfolios has a different investment planning process and a different outcome depending on how you invest um so that this needs to be understood because the lack of understanding and the changing of of our our terminology across you know the life cycle confuses this picture quite a bit what we really want to know is strategy and outcome customer outcome internal roles or manufacturing right these are that's what's really important to understand and this allows us to get there make sense yes i'm just trying to think how we go how are we going to clarify because the digital product concept is getting overloaded across the design build manage and consume context now and they all well depending on which context you are in uh it will mean something different yes the good thing is that we have teams and and if you're keeping up on things there's something called team topologies that is helping to understand how the the products teams are being staffed and then each team has a position some positions are going to be architects some positions are going to be the product managers some are going to be support but the idea of team topologies and there's another mechanism called helix organizations where you can mix a central team and a federated team to manage these digital products but first but first we need to know what we're working on no once we understand what we're working on and where you are in these four portfolios then the team knows what they are what sport they're in using a sports analogy they know what's game they're playing they know the sport they know the outcome that happens when they win or they lose and so though i see somebody just attached a video to watch because the question i asked is the application service maps will they be system maps now system mapped well that's the idea but we have a long legacy of naming an app service up until now uh i've been lobbying to change that name for two years now but uh you know there's there's a lot of legacy that we've already or mired in it's hard to change something like that you know when you have so many years and a huge investment but what is your vision still to have the mapping at a system level yes okay that's right it it in a matter of fact i want to show something we do change the definitions in csdm slightly over time and i want to just point something out so it's very subtle but it's important this is uh the application service is a logical representation of a deployed system or app stack yes so we're starting to incorporate this language in the definition themselves so we have a better clarity of what we mean by these things success no it's important to just understand your talk you know how you're thinking about it yeah yeah so there's a lot of little things but they all are leading somewhere and even the sdlc component what we're finding is all the infrastructure stuff is all in the cloud right you don't really own any of that but the folks that are building things they're just pushing a config file out there to create a new app service that's deployed in the cloud um so more and more of what we consider configuration management activities and concerns needs to be integrated with that team and in the cicd pipeline yes yes so now it's a slightly unrelated question now uh we are also doing bcm at bjc and so what happens to the business impact analysis and business continuity plan uh those concepts they were hanging off business application now we replace business application with a digital product they don't change immensely but what does happen is a problem that i that you can easily see right now we have a business continuity here bc okay which you you in the design stage you're basically articulating what it is you know the architects are figuring out what's the importance of a capability and then you build something right you basically design this team get certain hardware and software they deploy it they make it all work honky dory well what happens today is you have a separate business service portfolio out here which maybe it is a set of business consumers that aligns to that capability what if a different set of consumers started to consume this yeah how do you account for that easily and and because we have a different thing managed here versus up here uh the k the the business impact could be different based on uh current consumption our use right you didn't design it for a certain thing but now people are using it for something that you did not intend oh so now can you go to the now model please sure the new one yes sir yeah yeah the now model okay but now data model hold on a minute uh yes okay so i don't see it yet now is the bia and bcp connected uh related to uh the consell consume digital product or the design digital product because they can be both because you just said yeah in this model it's synonymous there isn't there isn't a difference because the digital product that you define here for design purposes is still carried through the rest of the area so it's the same one but if two different teams are using the same uh system uh won't they have uh two digital product because their usage may be different their usage may be different but it's still defined in one spot from a criticality perspective the difference is who who are the consumers right who if somebody else starts to consume this under a under one premise versus another premise you have traceability see you just made a comment that maybe two different teams if they use it their rq rpos can be different how would you capture that well the idea here is you'd have to build another offering so whoever is the product manager of the service or a digital product can change the offering it's it's it's not a problem when your system is engineered for you know it's a it's it's the lowest common denominator that goes right the system could be engineered for low availability and all of a sudden somebody in the business expects high availability this offering is your contract with them and if they go through the catalog that will be known but the problem is the guys up here that design it right because of this big separation between the development side of the world and the service of the world that can easily get lost so will they have to support a different business offering will we have a digital new digital product with their new bia well there's two things that can happen uh one is you you now have an over engineered system you can have high availability and your business consumers don't care anymore you know i don't come in on the weekends anymore now you've got you're spending more than necessary here yes uh and b because you have that that visibility you're talking about the same digital product you can say okay folks architects build team let's let's uh de-allocate hardware because we really don't need it 24 7. the opposite is true as well where somebody starts consuming it at a higher criticality than that than is expected so so um but the nice thing is that digital product connection to business capability and here this this becomes simpler because right now this is the consumption this is all about consumption which which now ties to what you'd originally designed for that's like the provider because i'm still trying to think about when we do a business impact analysis here now are we at a digital product in the design level or at a business offering a digital product well well think about yeah because right now you have two different worlds to concern yourself what's the service say yeah what does the app business applications say and they're different stories they're very different and connect connecting the dots today is as elaborate you have to go all the way over here to connect the dots today that is very elaborate and unnecessary in this model sure thank you so i i know i know we kind of went down some rabbit holes on the conversation but i think it will help make some of the points clear on why this will be better long term getting here is going to take a while uh but you know we're thinking about it we're throwing things on the wall and saying will this work and and how does it work and how how can we change what we do today to support this vision right this simpler model that brings these the dev concepts and the in the operations concepts better you know more closely aligned with each other the model really supports the devops um you know the devops direction and then underneath it too with the open group what other parts of the whole it operating model are they talking about so i know there's the organization part like the helix organization you mentioned earlier and then there's you you were describing to me the other day the parts so this is the financial part right the funding part for all yeah so the interesting thing the workshop the work group that i'm leading at the open group right now is looking at a very couple couple of very interesting problems regarding what i just walked through okay um probably the most the most interesting one is how do we apply our enterprise architecture to the products that we sell and so let me go back to this this thing enterprise architects a lot of times are there or basically looking at stuff internally that you have product architects up here but because of the reliance on it okay because software and systems all these things are more integrated and the customer systems are now connected to employee systems and you know you know using shared foundational technologies the the drive is to get enterprise architects into that market facing space to be able to better design products used by customers or partners right that's one thing um also down here the conversations i'm having with enterprise architects are why do we have such a huge redundancy in factory components why does each product team have to actually design their own factory from scratch why don't we have a standard factory so that everybody up above can go faster we can you know onboard a new foundational technology more quickly with a factory spill for that same thing with stuff for customers now that we can deliver things automatically to customers what else can we deliver using the same factory and the factory isn't just the factory to build it but it's the it's the do grc activities right it's the to do the governance aspects of it too and then also profitability you know what how much money are we making what's the liability you know who are those customers so so that kind of drives some of your investment decisions even on the foundational side because like gdpr you can't put you can't cross have data across certain data across certain boundaries in the world so these are all aspects of how your foundational technologies needs to support where your customers are growing so so that's the activity i'm leading at the open group right now is to say how do ya's you know get more involved in these digital products that are used by customers and in the factory uh this is where also you're seeing things where guy t5t is really the um the automation uh it's like it's an abstract model for the factory itself so that's where we're supporting that the repeatable delivery for that yeah how do we automate the delivery of any of those types of digital products and what are they you know it's the same problem because when they're when you're in the factory and you're changing one digital product you need to know the impact to the others right so um as you're changing these and these are changing you know impacting customers and and here's what's really interesting last last thought every digital product that you deliver to a customer has to be supported for as long as it's used and i just the the use case i use is the oven i just bought a digital oven from whirlpool a few years ago when i built my house and i still get factory updates when they update my my software in the digital eleven um i've had it four years i expect to have it 20 plus years right i don't replace my often as fast as i replace my phone you know and uh every everybody that makes digital products now has to support them as long as those products are out there very cool a lot to think about that um definitely gives us some thinking like it we're i think going real general on that delivery model so i definitely want to dig in more on the the open group delivery model also finding a lot of these standards groups in government where all the governments have it uh to the i'm looking at the canadian government right now they have this whole team about how do we deliver services and they're starting to discuss products too so it's it's interesting all the different think tanks that are around the same problem okay well i see it i see it the dod has been asking questions here in the u.s um there's there's just quite a few questions about how do we evolve gartner published a piece on customers agonizing over the definition of product in i.t so i i think part of this this provides an answer is it perfect no but it's a huge step in that direction that seems to work if you get your hand around the abstract very cool mark thanks so much uh lou i know we're going to have you share some of your results today but we'll uh we'll pick that up next meeting okay sounds good thanks all right mark thanks this is really helpful helpful for me anyway my pleasure all right thanks everybody hi everybody thank you bye thank you