 So what is new, it's actually not a lot of things, but there's a lot of thinking behind those few things. So we changed the service backbone of it variety a little bit. We simplified conceptual service, we changed a bit in logical service. We included the service catalog entry and the deck to correct now called actual service instead of actual service CI. That all seems very simple, but the important thing is the white paper behind it that has been written. And that is actually based on work that was done in Price One House Cooper where they implemented the service backbone using various tools. And so we got to truly test out does it work or does it not work. And that's the reason for us to trim a little bit in the standard. Then as a consequence of the work we did with financial management, we focused a lot about how can you do cost tracking across the value chain. And it turned out that using the service backbone and using the concepts of all the connectedness that exists in IT for IT, can actually do a pretty smart way of doing cost tracking. And there's a white paper on that and the white paper has fit a lot of updates to the standard in terms of data flow that needs to happen, as well as some attribute definition that I'm coming into the functional component to support what data you want to collect in various places for IT for IT in order to support financial management. And then finally there is a few minor changes here and there that is basically just the people discovered box if you will in 2.0 and that's just being introduced. In some of it is also around some of the definition that was written in the core section of the standard to clarify and make it a bit more precise what is being done. And actually if you look into the details in general the structure has been more aligned across the value chains, the four value chains documented, and in 2.0 they were written by four different people. And even though we tried to coordinate it a lot, it wasn't completely aligned and it's much better aligned now in 2.1. I won't go over these edits that start you can see it from yourself when you read it. So the first change is a pretty simple change but I think it's pretty important. If you look at the value chain picture in the middle, it used to say reference architecture. That's really not kind of the middle of it. It's all part of the reference architecture. So the important thing that ties all the value chains together and ties the value chains into the supporting activities is really the service backbone. So we promoted the concept of the service backbone into the value chain concept. So that's actually pretty important when we start introducing this topic and that you will also see that as we go through the presentation today that the concept of what you can really get out of having this service backbone is pretty amazing. The next thing is the level one diagram itself. And what you see here is 2.0. So you should all know that and love it. And now I'll press the button and we'll shift into 2.1 and you have to think about so what really changed. There we go. Did you see it? Can you see what changed? Probably not, which is a good thing. The changes are very small and it should be so because a lot of people take this level one diagram as a starting point for a lot of these questions. You all learned it. So we haven't dramatically changed what you start out with. But there are a few changes in this diagram. So the changes are, well, we changed some of the names of some of the data objects. So it's now called enterprise architecture in the architecture component. We changed the logical service to, well, used to be called logical service blueprint, but now we call it logical service blueprint concept confused a lot of people. But we come back to that the blueprint still exists actually. At level two. The service model consistency around the site service and actual service it was called actual service CI and that concept of CI was really about shouldn't be there. So we have consistency now. The service catalog entry has become part of the service backbone that's a pretty controversial topic actually has been going back and forth a number of times but essentially it is part of defining the services so it's part of the backbone. The bigger change is that the conceptual service blueprint disappeared. So service portfolio at level one only really have a single thing that it maintains which is the conceptual service. And again that comes back to the simplification that was the realization when price of waterhouse Cuba was was actually implementing service backbone that you really did not help to have to it actually confused more than it helped. The other change that happened and that the consequence of it financial management is that in the chart back showback component in R2F. We now have a charge bank record in addition to the chart back contract. And that's pretty again pretty important to have and track. So that has got introduced. That's all pretty simple. So we can end here and say this is what happened in it for it in version 2.1. Of course, the details of what matters. So if we go through each of the four values screens at level two. We'll see that there is a bit more changes going on. The first one is in S2P that the conceptual service blueprint actually still exists as an auxiliary data object. So it's not core in tracking into it, but it's still something you want to keep track on the various versions of a particular conceptual service. The rest of the changes are really around the data flows that is happening. Both in terms of systems of record data flows and in terms of engagement data flows that has been added because of working it financial management and there's quite a lot of them. In S2P, which is not surprising because that's where it starts and ends in terms of it financial management. Here I won't go the details of how the various budget information or scoping information etc is being said the back and forth between the components that's all documented in the standard but it's important to know that there is now a lot of these flows being documented. They support the financial management and that's a very important enrichment of the standard. It is not changing the standard it's enriching the standard, which of course again is a very good thing so you don't have to throw any information away as such. Moving on to the R2D requirements to deploy. Again there is a number of data flows that has been introduced because of IT financial management. And you would also see here that the logical service blueprints still exist. So basically what we did was to say okay the logical service is something that captures that you have made designs for a particular service and how you want to deliver that service. So it's a systems of records that captures that you have service designs. The blueprints are really the architectural drawings of how you develop your piece of software and yours you will have many artifacts of and you would associate them with the logical service that is being developed. So the logical service is more a container for all the things you do around service design. So that change helps in communication because you don't have at level one to talk about this blueprint thing. You just basically say you have a logical service which is part of the service design and that's where you keep track on what you have designed. Moving on to request to fulfill. There is again as with the STP quite a lot of things happening as a consequence of IT financial management. That is not surprising because that's where you consume the services and that's where you have these components like usage and charge back show bank which obviously is very relevant to IT financial management. So the data flow here has been significantly enriched and added so that it really reflect what you need to do. We'll come back to some of that much more in as we move to this presentation today. There was also the service model naming consistency with design service and an actual service that is of course is reflected at level two as well. And the fact that the service catalog entry has become part of the service backbone but that's the same as what you saw it at level one. Finally, we get to the detective correct at level two. Detective correct is the least impacted in 2.1. Again, it's really just this service model consistency that that has changed. There isn't really anything coming in from the IT financial management side on detective correct. The fact that it's running. It's running. That's nothing to do with the financial management that's all happening at request to fulfill. Anybody working a lot in the D2C area won't really see any significant changes except for the actual service is now called actual service and not actual service CI. The way you model an actual service is probably as a network of configuration items as we love from existing seem to be technologies. But it's abstracted as an actual service.