 So I'll start with an example. So throughout the next 40 minutes, I will be talking about an example which essentially is employee expense management. Most organization has an employee expense management system delivered by IT in some form or shape. It might be delivered as internally developed or as a service or whatever. It doesn't really matter. For example, we basically say, well, we have a conceptual service called employee expense management, EEM, if you abbreviate it, and essentially it delivers three kind of business functions that you can register expense, you can manage expense reports, and you can improve expense reports. That particular conceptual service is dependent on other conceptual services. It uses, it sends notifications and you actually pay the expense reports, so it interface to financial application and to email service. And also in order to run the service, it relies on a database service and a general application execution environment, aka a server, right? So that's in essence the conceptual service. And the details of it is something you probably have modeled out in an enterprise architecture tool where you took these three functions that the systems is delivering, register, manage and approve expenses, and put it into the general business flow of the businesses that are managing expenses. So coming from the CFO and the finance department working with the business unit of how to do that. So this is a simplified new in practice that would be more dependencies and more details, but there should be good enough for now. Now, what would happen is that demand is raised. And the demand is about people want a mobile experience. And also, actually, we want to reduce the cost of operating the employee expense management. So can we do something in terms of finding a smarter way of running it so it doesn't cost us as much. So that's demand coming in some of it from the business that the mobile experience and the other one is from the CFO or CIO saying, well, we need to figure out how to optimize how we run this. When you capture the demand, you start working the actual way of delivering that demand. So you put it into a proposal that you sign off with an IT project that is going to then actually deliver this. And explaining a little bit about how that goes on. We come back to how it works financially and how you actually allocate money and make a decision. So that will be at the end when we talk IT financial management. The important part here is that people understand, you all understand that there are kind of these two organizations. The one with the business view that works on the conceptual service, work on the enterprise architecture, that communicate with the business through the demand component in terms of portfolio backlog items. And then you hand it over in terms of a project to a development organization. And in the development organization, you refine the backlog items into dedicated requirements that has been developed. And you design what you want to do in terms of the logical service blueprint associated with the logical service that you're going to deliver. And so if you look at a potential service blueprint for this that is associated with that could be one of several group runs you develop, it could look something like this that you have an existing design and you add further instances to it in terms of you want to register the expense. You want to be able to do it by creating from a photo so on your mobile app you can take a picture of your expense and it will be registered. And that would be something delivered by a mobile expense app that needs to run on iOS and Android and also needs to be dependent on a mobile backend. And I won't go into the details of how this is worked out, but this is where you actually start working as a software developer and architecting the implementation of that. It's not the business architecture, it's the software architecture you work on when you work in the logical space. And so let's take a little bit of an intimate so about not how the EM employee expense management system is being done, but how the service backbone then work regardless of what kind of service we are, we're actually working on. So I showed the concept of the requirements and the design with the logical service. But what happens is that you would, you would then start planning out releases of the service you have the project you need to have the next release of the expense management system. And there you would keep track on the bills you're doing so they will be associated with the with the release, the, the requirements you have associated with with the service release. And also the defect that a particular release is or built is happening. And this is where we explain the difference, or one of the things that can explain the difference between the service release and a service release blueprint. That is not typically well understood by most people initially meeting it for it. But what you would have is that first you have a plan release. So the development team say well in April we're going to release version 2.0. But as you approach April, you will actually start building something that could be worked. So it would be build number one, build number two, build number three. And each of them will have a certain set of defects associated as you test it out. So you keep track on what defects are associated with a particular build, not with a particular release, but the build of that release. And eventually you will then take a particular build which you would call a service release associated with a service release blueprint. And that is the one you can release and give over to the fulfillment executions as a blueprint for instantiating and also giving to the service catalog entries so that you can actually know what you can consume. And so a little bit then on the notion of subscription because it becomes very important. When we talk about IT financial management and also how the service model moves from a service blueprint into a desired and actual service model. So first off, in order for a subscription to be created, there needs to be an offer. The offer is what commercially define what you can consume from the service catalog. So it puts a price tag and a service quality and various other things on top of the technical entity which is called the catalog entry or service catalog entry. And when you create a subscription, you also create a chargeback contract. So basically you associate with the subscription a chargeback contract. It comes from the offer saying what this is how you were being offered the subscription. This is how I want to be charged for that particular subscription. And it's actually also where you would create the service level agreement. So the monitoring of how you want from a business perspective to monitor that subscription. But that's outside of the realm of this presentation. And then for each period, each charging period, there will be a chargeback record being generated. So if you run a monthly billing cycle or quarterly billing cycle, that doesn't really matter. But for each of these cycles, you will create one chargeback record associated with that contract. So in April, there will be chargeback. In May, there will be chargeback. In June, there will be chargeback. It will all use the same chargeback contract that describes how to compute the chargeback. And the input to computing that chargeback will be based on all the users' information. And there can be many users' record being collected that are associated with a single chargeback record if it's a complicated service. We'll come back to that in more detail later. There cannot be zero if you just say it's a flat price you're paying every period. You don't really measure usage. You just say it always costs $5 a month to have an employee expense mentioned seat. The way you collect the users' record is actually based on what is in the desired service model. So we'll come back to the desired service model in a slide or two from now. But essentially, as you instantiate an employee expense management system, you also figure out what is the structure of that. And then you know what it is you can go and measure in order to figure out what is the users of employee expense management. And if we go on from there, then essentially what is happening is that it's kind of a two step in R2F is that the service blueprint, the service release blueprint has been registered as a catalog entry and the fulfillment execution knows about it as a template. And then going up through the consumption and down as a subscription, you say, I want an instance of this. So let's think about it when we talk about employee expense management. Really what could happen is that I've developed a new employee expense management and I want to run it in one region of the world. I'm a big international company and I want to run it in, say, Europe. And so as a service owner, I can then say I want to create a subscription to that kind of service and get an instance created in EMEA. And then the fulfillment execution will stand up all the servers, all the databases, all the connectivity that is needed in order to instantiate an employee expense management system in EMEA. And as it does that, it starts by computing a desired service, what should it look like? What do I need? And then it goes on and allocated from asset management. It calls the various fulfillment engines that can configure and stand up the needed services. And as it does that, it populates the actual service model so that you can start monitoring it. And at the same time, you actually also set up all the monitoring and all the collection that you need in order to maintain and manage and track the service when it's running. This is different than a lot of organizations how they do it today because very often it's just a release from development directly into production. So the old paradigm of plan build run with the R2F is replaced by plan build consume run. And that helps a lot in terms of doing IT financial management. So that's another reason why we have that extra step in IT management. So let's go back to the employee expense management scenario. So essentially what we have here is that the logical service model is that we are developing any employee expense management component of some sort with code and tests we can do associated. And then we define a release in April we're going to release it. And the release defines not only the software itself, but also all the things around the software. So what are the requirements to the operating environments, maybe even to the point of people that needs to be allocated in support in order to run the service, etc. And all of that is wrapped up into release package, which is something we have at level two in the IT variety, which consists of the service release blueprint, plus the build package that is part of that particular release, plus the installed recipes, plus a compilation of all known errors, etc. And that package is the package that you will deliver to the fulfillment execution so that it can actually do the instantiation and configuration and deployment of an instance of employee expense management. And the service release blueprint itself is the one that maintains the topology, the service model of the release, which might say for employee expense management version one build 47 that it contains a software built 324 plus the requirements to a hosting platform, plus requirements to some people that needs to maintain it, plus the requirements on a backup service that needs to be running when the software is running. Of course that model can be much more complicated. That's a simplified model we have in this example. And so, once it's been pushed to R2F, you have the, you can create the offer, which would define the policy and contract that can be used to deploy such a system. And let's then imagine that that hands is going to be the owner in EMEA Europe for an instance of employed expense management so he consumes it, and you create a subscription of the functional component will maintain an instance of the subscription that hands is the owner of this service. It's located in EMEA. And maybe the policy has been defined so that you can define what kind of deployment type you want. It could be the production or it could be a test deployment or pre production or various other kinds of deployment types. And it has a reference back to the actual catalog entry. It will have a reference down to the desired service model that the fulfillment engine will create so that we have traceability between subscription and the underpinning desired service model. And the desired service model is where we will translate the general deployment type, the policy, deployment policy at the offer subscription layer called production into, okay, it means that it needs to be 8 times 4 quality. The data security needs to be private because it's real data, it's not test data. And also because the deployment in production, we will allocate the FTEs that is needed, the people that is needed to maintain. And so from there, we go and look into the desired service model and the desired service model reflects the service release model in terms of the software, its hosting, its FTEs, and its backup. But now it's being instantiated with the requirement that for instance the hosting is going to be on the particular IP with stories on a particular loan, maybe that the FTEs are allocated at essentially with contact information so that we know that this is the mail address to get two people to be assigned to actually do support. And there's a particular instance of the backup service. And as after this has been allocated then the fulfillment execution engine will go and actually then configure all of these things. And in addition to configuring them, getting populated the actual service model, which will very much look like the desired service model, except it might have further details on it. Like the serial number of the hardware if there's hardware and we don't really care of as the desired thing but there is an actual thing around it. And then the, you might also, or it will set up monitoring in terms of making sure that, that you collect uses and you collect status information is running or not running. So whether it's working before it finally signs it off as now it's up and running and then it will feed that information back to the subscription module so that you know that now your expense management is running in India. And so if we look at it from a picture perspective, what is really happening here is that essentially this circle I have is, and here I represent it as an actual service. It could also be the desired service they are one to one to each other right that service owner hands has a service contract on the delivery of an other service, which consists of some software and hosting service and a backup service. And if we look at that in more detail, that actually references the hosting and the backup services to see on a hosting service, for instance. So there might be another person in a mere that owns and run a hosting service either internally or externally could be Amazon or it could be internally in our department. Right. And, and that one you get a seat on, which, and the seat is represented as having some degree of network some particular OS instance and some compute that is essentially a virtual machine on a on a hybrid. And so Peter that is the owner here on the on the hosting service has probably automated a way of you to allocate such a speed hosting seed. And as part of allocating you in addition to just getting the virtual machine, you also, for instance in an asset management system allocate and rating system license. And precisely the same is what you will be doing on the backup service, you get a seat on the backup server and with all the right policies which would imply that on a regular basis, your your employee expense management data will get backed up to a backup service somewhere. And once you have that in place, you can start consuming employee expense management. So all the users in a mere can all get a seat on that employee expense management. And you can model that out as well. Now you might not in many IT organization actually model all of these seats because it's, you have 10,000 people in India, and, and you don't want to have a little service model in your team to be for that. But you couldn't practice and, and actually you often do it, but you don't do it in the seem to be you do it in some other systems you, you manage that information to actually know who has subscribed always using the employee expense management. And the owner in media might not be the same one that or all is responsible for your expense management in America's in US, and that could be another person so they each have their own instance of this system. But it's a single software development could also be two different versions of the EM that they're running in America's media. Now we can manage all of that. So let's take a deep breath. Okay, now I went all the way from conceptually outlining that we have an employee expense management system, we have new requirements to it, we develop those, we release them, we put them into request to fulfill. You instantiate a desired service model and the above they also an actual service model. And, and so so that's the entire way left to right. And secondly, what I also showed is that in terms of service model and what it to it for it support is a hierarchy of a key cow service model so that the employee expense management system is dependent on seats on hosting service and seats on a backup service. And you have a service hierarchy among those. These things are very important because that supports that you can actually do cost management, you can, you can divide and conquer responsibility throughout the organization and you can actually also do that across organizational boundaries.