 Good morning, good afternoon, good evening everybody. It's my pleasure to introduce our speaker today, Lars Rossum. Lars and I have worked together over a number of years on this initiative. It's my honor to serve as the chair of the forum at the moment, and I will keep my own introduction very briefly, simply to introduce Lars as a distinguished technologist and the chief architect of the IT for IT initiative at Hewlett Packard. He was part of the inception of this initiative, and has constructed the first version of the architect chat, and he leads the initiative that aligns and integrates all of HP's management tools using IT for IT as the reference basis. He's been working on IT and service provider management systems for over 20 years, and has a PhD in computer science and masters in engineering and an MBA in technology management. So without further ado, Dr. Lars Rossum. Thank you Chris. This session will be really why, what and how around IT for IT. So the abstract we sent out for this webinar was really, as has been introduced here, to describe what we've really been working on. Give an overview of IT for IT, what it offers, how you can consume it, and how you can use it in an IT organization, or if you're a consultant, or if you're a tool vendor. It can give a lot of guidance and hopefully lead the industry to a better place than where we are today. The starting point for what we have been doing is really looking at IT as it is today. The observation is that we have a broken chain. There's a lot of things that are quite problematic in IT today. We at the same time are seeing a shift in the industry in how we are consuming solutions, like we are going more and more towards standardized solutions, if possible, the entire concept of multi-supplier, that a single IT organization is not developing everything itself, but is actually consuming services from other suppliers, implies that the area of IT management becomes problematic or becomes more complicated. So buying standardized solutions is great because it puts down cost of IT, but managing it, the cost goes up. We see that there is a number of existing solution framework or general framework for how to manage IT. The most known one is ITA as a framework, but there are other ones out there listed a few on the slide here, but they're more than that. The interesting part is that though they have a lot of details on what you want to do on a process level, it does not really give a prescription on how to manage the service models and the life cycles, and as well as not giving prescription on what kind of systems or components do you need to put in place and how do they interact. Another observation we had was the fact that IT management fundamentally is industry agnostic. So most people want to believe that they are special, and the same goes with IT organization, I talk to many, and in general they go out and state, well, we have a special situation, we have a lot of special problems in our organization, but the more we analyze it, the more it turns out that everybody is really the same. So if you're an oil and gas or if you're a bank or if you're in telecommunications, then it really is the fundamental same problems you're trying to solve. And so it should also be possible to give a reference architecture for how to manage IT in a standardized way. It actually goes hand in hand with concepts of TOGAP, which is also coming and managed to the open group of you should really, for each area that you do IT for, has a reference architecture, a reference to be architecture. And IT itself is such an area. Just like you would have it for a bank, say accounting, you would have a reference architecture for how an account system should look like, you can have that for IT. We did, of course, as part of that analysis, see that the lack of such a standard really is driving off cost significantly. And that has been one of the driving forces. And we have some examples for some of the early members of this work where just the simple thing of interfacing two incident management systems between a vendor and a consumer of a service could take half year, full year to implement could cost upwards of a million dollars to make such an interface before. And fundamentally it's just exchanging incidents. Shouldn't be an issue. It should just be clock and play ideally. And if you go to ITEL, it doesn't really help you in describing how to do that. There is way too much wiggle room in how you actually arrange your incidents within the ITEL framework. So with that said, we started to look at what is actually going on in IT. And we also decided about, it's not enough that we solve just the operational space of IT. It really starts at the planning side. There is some business process modeling of whatever kind of business problem the lines of business have. That leads to some demand being registered with IT. IT try to translate that into requirement. Projects are being created. They've been developed. Defects are being found. It becomes a request for change into operations. You start to monitor there's incidents and events and problems and maybe some kind of subscription being managed. And everything is linked together by processes. Not by data, but by processes. And everybody referred back to some kind of a service model that says, well, this is the account receivable module that has an issue. Then people have to figure out what that is. How does that relate to conceptually what business was requesting originally? And it turns out the traceability in this is close to zero. And that's not just something I claim. If we go out to most of the organizations, they have that issue that you do not have traceability end-to-end in IT. You might have a little bit of traceability within some of the silos, within the operation space, maybe within the development space, but end-to-end doesn't really exist. So what are we going to do? The first thing we looked at was to say, well, essentially running IT itself should be done the same way as you do any other business. And that implies that you should really look at it from what kind of methods would a business apply in order to become a decision? One of the things that many businesses look at is their production of organized business, which IT really is. It takes demand from external sources like the lines of business and then they produce services that have been delivered by IT. And so Porter is a business guru and he came up with the concept of value chain and it was initially mostly used by production companies. And we looked at that and used that framework and said, what would that look like within an IT organization? And the picture you see here, and there's a couple of different ways of doing that layout, but the picture you see here of the value chain really highlights the essential part of it. The value chain has four essential value streams in IT that are called strategy to portfolio, requirement to deploy, request to fulfill and detect to correct. And the rest of the presentation will really be spent on outlining all the details of these four value streams as they've been called. To support that, there's a number of supporting activities, finance, sourcing, vendor management, intelligence and reporting, et cetera. And these are activities or supporting functions and people call it that as well, which I really share across all of the enterprise. So it's not IT specific finance, it's not IT's its own, but IT needs to interact with finance as it's delivering its value streams or implement the value streams. And by having that view into IT actually resonate a lot with business leaders when we talk to them about the IT for IT framework that we put it into a business perspective. Each of these four essential value streams, they deliver values for IT and can be measured and they are interlinked. If we then dive into that in a bit more detail, the next step here is that we have these four value streams that together makes up IT. The first one, strategy to portfolio. It is really where you would drive the portfolio of IT. You figure out what kind of business innovation should IT support and making sure you have all the right strategies in place and prioritization in place to do the right thing in IT. That's also where you at the end of the day have the end-to-end reporting out of the state of the world, the state of IT. Then we have requirements to deploy. That's where we build capabilities for IT. Essentially, when stuff has been agreed upon that this is something to be developed, something to be delivered by IT, you hand it over to a development organization. So the first part we would call plan. The next one you would call build. Once you have a better capability, you put it into production. So traditionally in IT, you would say plan, build, run. But here in IT, for IT, we introduce the step in between which we call request to fulfill. And that's because one of the things that we realize around IT is that in order to become a modern IT organization, it needs to change its form. It needs to be a service provider or IT organization. Today, they are transforming themselves or should transform themselves. Someone not quite there yet into becoming a service provider. They have served their lines of business. And that implies that in essence, all the capabilities that have been developed should be put into a service catalog be available for consumption by IT. We should also say that requirements to deploy when you build something, you could also source something and you decide that it's not something you build yourself because you get it from a self-supplier or you get it from the cloud somewhere and you put it into the catalog. And then when the lines of business really need an instance of that service, they need a time tracking system. They need an oil planning application. They need an account receivable modules to be upgraded or changed or whatever. It is done in request to fulfill. That's a very expanded version of what traditional IT is called change management. When request to fulfill is then pushing something into the data centers to operations, then you will have run detector correct, which is the run part, making sure everything is healthy, that it gets downgraded, upgraded, monitor the performance, etc., etc. And if there are any issues that they are captured and dealt with and problems are raised and fed back upwards back into requirements. So that's the four value screens in IT for IT. So far, there's actually nothing really mind-shattering about what you've been doing to make your change in IT for IT compared to what you've seen or discussed before is while we're using a few new words. But then it's the request to fulfill that consumed part. So plan build run has become plan build consumed run. Another thing that is introduced in IT for IT is to say, okay, we need to be much better at managing the actual service being built to understand what it is. And this is where IT for IT is going a little bit against what we see in ITO. We're not throwing away what is in ITO. If you look at organizations what they've implemented everybody to some degree is trying to do ITO version 3 or the latest iterations of version 3. But in reality, the service model, most organizations is where ITO version 2 was documented. So that is having an EMDB that kept track of what is the realized service. The service running in the data center. Often the EMDB in operation is populated based on discovery mechanism. So there's a long process going on before you get into operations but certainly things pop up in the data center you discover it by some means and then you populate your CMD. Which is a very backwards way of doing it. I do discuss that this is not good enough the concept of a CMS is around really having a full change management system and managing what is going to happen in the data center earlier in its basis. But in ITO version we actually take it one or two or three steps further ahead. So we really say you need to look at services as starting as a conceptual service model. The conceptual service model is essentially just describing what are the concepts you're delivering to the lines of business and attach to those concepts what are the requirements or the demands that the business has on the service. Business don't care about how it's implemented they only care about what is the difference and at that stage you don't care about the details of what does the APIs look like or the user interface looks like or anything like that they care about whether you can do a a mobile time registration or you can do an account receivable or stuff like that. You take that into the development cycle the sorting cycle of the EMDB and what comes out of that or the process of that you are really creating what we term the logical service model. That is a model that describes what how did I actually design this service. So what is the logical service what is the we'll be describing how is the service actually constructed what modules are part of it what are the APIs that are available what are the the way it can be consumed. But you can instantiate such a logical model by actually installing the service and you might install it one place or several places etc and you might have several logical service releases that all come correspond to the same conceptual service. And then finally you get into the point of saying okay I take that logical service and I hand it into R2F R2F will deliver the service into the data center and instantiate the realized service model. That way you start to be able to create traceability all the way from conceptual to logical to realized and backwards again and we'll come more into the details that need as we go along this presentation. So moving on from from that there was another principle we looked at when we started constructing IT for IT and that is really to do a layer analysis starting with a functional model to figure out what are all the functional areas that IT needs that's basically looking at customer use cases etc going on to a lifecycle model where we look at the what is the essential thing that happens in terms of continuous assessment continuous integration continuous delivery around this service model and the lifecycle of those service models. Then we went in and looked at the information model which is figuring out what are the key controlling IT artifacts or data objects that is part of managing the lifecycle of services and then finally looking at what are the key integration points that will then happen within such a landscape that controls these information model objects and what we wanted to do is to create a normative standard which is what we're doing in the open groups very soon to be released as a public standard is to formalize the information model and this integration area because the top layer is what many of the other frameworks are doing a great job of trying to advise IT around what processes you want to use you can use iPhone, you can use COVID there is a safe framework for development for Bluetooth etc but the underpinning system what are the key controlling data models we need to put in place that we use the same information between systems and between suppliers in the IT state so if we look at that we can then look at the how does this IT for IT really relates to some of these other standards of framework we have in the industry that many of you love or use on a daily basis and the first one that most people ask around is ISO and you could say ISO is essentially a best practice framework for IT processes and the taxonomy of IT it's a good framework it is primarily focused on the operational side of IT not as much the planning and strategy part even though it is part of the latest standard practitioners traditionally mostly use it in operations where IT for IT is a reference architecture for the IT software ecosystem right so it describes what is it that you would put in place in IT in order to manage IT itself so it underpins ISO if we take TOGAP well that's an industry standard architecture framework so it describes how would you go about planning out and introducing IT services and in that sense IT for IT is one of the libraries that TOGAP say you should develop for any area you want to to manage and IT itself is an area you want to manage and finally there is a specification language called ARCHIMATE which is also managed by the open group it's a well-formed model language for business services and we have chosen in IT for IT to use ARCHIMATE as the formal language for the normative standard for IT for IT which is also being aligned with TOGAP so it all forms a very nice complementary set of things to look into the ISO part is another standard unlike the other ones and is not part of the open group and I would say they are competing things in the world around ISO but we do recognize that's very important for quite a number of IT organizations so we make sure that we are reasonable aligned with that Going from this we go a little bit into the structure of IT for IT and here we say well in addition to the normative standard as it just describes that we are creating we also create a number of guidance documents which really describe and actually the purpose is to for it describes how typical capabilities and processes will interlink into the IT for IT normative standard so as we will see in the next few slides we have concept of a component like an application component in ARCHIMATE which is called the functional component and the lifecycle artifact or data object that's part of the normative standard but how that links into scenarios that is described in some guidance documents it's not normative but it's a guide to how you can consume the reference architecture and we have that for a number of scenarios like agile development or how to do SLA management and how to do IT financial management another important aspect of IT for IT is that we've decided to develop it as a layered structure so there are five layers in the in the IT for IT structure the reason for that is that we want to make sure that two things basically that is consumable even if you are not a hardcore architect IT architect that you still be possible to consume it but on the other hand it should be precise and specific which requires that we use a lot of the methods from hardcore architecture disciplines it should also be we should be sure that it's end-to-end complete don't have gaps that it really was end-to-end in IT and if we go into all the detail of specification that you can end up constructing in a language like ARCHIMATE it might be difficult to actually be the forest for the tree so to speak so what we've done is that we say at layer one we have a it's an overview layer it's not the normal to standard itself it's an abstraction of the IT for IT that really allows you to talk about it in a single slide you can have all the concepts of IT for IT in a single slide and you don't use any formal notation language you have a simplistic language we use for it only three different symbols in it so anybody can learn it in five minutes I will show it next slide then we have a layer two where we go one layer deeper each of the values being required of whose slide and we start talking about the flow of data information etc and then layer three is where the real hardcore normative standard is specified in ARCHIMATE it's very comprehensive so it's not easy to just grasp at day one but you can drill into that and then you say the last two layers four and five they become vendor specific we realize that detailing something out into the entity degree of accuracy will take forever and would actually hinder the industry in adaptation so we say layer one, two, three will be formalized in the open group layer four and five will be for each vendor but because of layer three they will be able to interoperate so let's look at IT for IT at the layer one and so first a couple of symbols here as I said there are really three symbols the circle black circle that's a data object or key data object we've identified a small set of key objects about I think it's 33 key objects in total that really controls all of IT into it and they are listed in this there are the blue squares these are functional components they are the essential component you need to put in place in order to manage IT each functional component should really control one key artifact so it becomes minimal you can't really decompose that component further without spoiling some of the traceability so typically you would buy or increment at least as a full functional component at a time and then there is the black line which is just stating that there is a relationship between these or a direct relationship between these components so for instance an incident can be related to a problem and vice versa similar an event can be related to an incident and vice versa if you go further down in a specification we have cardinality etc but at level one these are the only three things we have some of the key data objects are the ones that actually keep track on the real service model the model of what IT delivers to the business and they have a slightly different color as you can see at the bottom so the configuration management component will contain data objects that represent the actual services being delivered to the business so configuration items in essence you know in the DSP and so if we drill into the four value streams strategy portfolio has five functional components controlling in total six key artifacts so at the at the bottom you would see the service portfolio component it's a pretty important one it keeps track on all the conceptual services that IT delivers and also what is here in terms of the conceptual service blueprint which is essentially saying well what are the phases that the conceptual service go through so we have a version one of that of let's say a time tracking system and then we have a version two of the time tracking system which has more business features delivered maybe a business wanted it to be mobile accessible and that would come into version two then there is the portfolio demand component which keeps track on all the backlog items that the businesses are requesting so essentially it's equivalent to business demand coming in that is being managed there then there is the proposal component which keeps track on what is named the scope agreements which essentially are the IT projects that are being kicked off so it's the contract that the IT CIO office or the planners allocate a bucket for and says okay we want this to happen and it's handed over to the requirement to deploy it to actually be developed and of course that relates to the backlog items because it's essentially specified as a collection of backlog items that we decided yes we're going to do it and they are again related to what conceptual services to be delivered and then finally there is the policy component which keeps track on all the policies that IT lives under they will be related into which conceptual services to follow those policies and the enterprise architecture component which are your traditional Spark's EA or a similar kind of systems that would keep track on the service architecture of the business services that these IT services will underpin so of course again they relate back into the conceptual service so these are the five things you need to put in place in order to actually be able to manage IT to track on what is IT delivering and the reality is that most IT organizations today do a very poor job of actually doing this but that would be a discussion for another day moving into requirements to deploy there are more things in play here so essentially there is I have to quickly count here nine components eight nine components that are being put into play there is at the bottom again there is a service design which is where you start designing the service and the release decision component is difficult to read the end here which is where you keep track on what are the compositional things you release out and then you have the usual things you have requirements you have defects you have test cases you have source and bills and and and bill packages and I can't have time today to go into the details here I need to have time for Q&A the important part is the IT project or IT initiative story that is being maintained by the project component that's where essentially the budget is handed over to and a project manager will be sure that all of the things that happens in our city is actually being delivered on time whether it's agile or whether it's a waterfall or any other kind of process you're using you can actually do it using these sets of components the next one is requested for a bill and that's the new one the new kid on the block there's a lot of names in here that would not sound familiar to all of you listening into this presentation the essence here is that we are transforming IT into becoming a service provider which implies that you need to have a consumption component where you can go in and shop for what you want from IT and some of the things that are very difficult to get your head around initially is that IT itself is a consumer of IT so if you need another virtual machine for already you should be able to go into a consumption catalog and and with the profile of the developer you can get a virtual machine for that if you are a person responsible for delivering an IT person responsible for delivering major service in a region you should be able to go in and allocate machines for an extra exchange server installation or even allocate the software that you need to put into production in order to do that you need to manage the offers that you can do you need to understand how is the composition of the offers and then the very important component here is the fulfillment execution component which is the one that actually figures out how to deliver it and the implementation of the fulfillment execution component can be an assistant that just keeps track on the manual things you're going to do so kind of in line with a traditional change request process or it could be fully automated sound-oriented way of saying I'll just press the button and we'll do everything completely automated and then also associated with the customer fulfill is keeping track on what is then actually the usage and then doing the showback charge back to whoever is consuming that component there's not more information about this value stream in the detailed documentation and again I can spend a couple of hours explaining the details of what goes on here but it's a very important new thing in IT for IT compared to what you're used to the final one is detected correct here most people will feel at home because essentially these are the components you need to put in place in order to manage the things that are running in IT you have a configuration management system where or component where you keep track on what are actually the services you have running changes there is controlled by change control with RFCs you have service monitoring of it you have an event component that keeps track of everything that happens you can manage incidents, problem known errors you have to be able to manage service level and that is the executable part of service level they actually come to life much earlier in the life cycle it's a full guidance document around how that works in the IT for IT standard and then the the runbook automation component and so if you take all of that and put it together you get this picture and this is and I forgot to mention that in the beginning but essentially all the material I've shown here is the pre-release of the 2.0 reference architecture of IT for IT which is essentially the thing that will be released as a standard in a month from now what you see if you put it all together there's one important thing is that at the bottom you sort of have a line going through with all the purple circles and you start with the conceptual service becomes the logical then it becomes what you actually release then it becomes the desired service that you want to put into production and then finally what you actually have in production that's a line with the various stages of the service definition is what we call the service backbone and that is what gives you traceability so you can go all the way from a conceptual service or a scope agreement or portfolio backlog item and figure out what was actually done where is it in the development what is which data center have installations of this in which versions how many incidents are actually being created on which versions of that conceptual service so suddenly if you have this in place you can actually have true traceability in IT and with that I'm coming to the end we still have another 20 minutes so there's plenty time for Q&A but essentially in summary IT for IT is not trying to replace anything out there it's complementary to existing frameworks but it addresses something that didn't exist before and that is a prescriptive reference architecture for how to run IT itself we believe it's very robust we have tested it out so it's not even though this standardization is just being finalized in its first release now we have a number of IT departments that are following the IT for IT framework and it's used it for incrementing solutions we have tested it against the latest trends in terms of the API DevOps we actually within my organization we have reference implementations of pretty much everything in the reference architecture many thanks Lars I think we've all struggled a bit with the audio so Simon and I will address that later on so many thanks to all for their perseverance with Lars's final slide up I'd like to respond to the question that said that the relationship between IT for IT and IT is important but what about the relationship with RKMate and TOGAF I think the thing to point out about one of Lars's slides is that it doesn't compare apples with apples I mean the point that we're trying to make here is that some of the understandings of IT for IT mask its rather deceptive simplicity there is a complementarity a very strong complementarity to ITIL but what we are not doing is competing with or anything else in relation to TOGAF or RKMate what we've done as good citizens of the open group if you will is built IT for IT using TOGAF and our representation of it uses the RKMate language so the slide that Lars is just running back to now thank you Lars the top level comparison is a true comparison the other two pieces are highly informative but jolly good question so that's the first one let me go up I've got lots of comments about the audio that I need to whiz between another question that was raised was that the word layer is a bit misleading I'm inclined to agree what we have is a sophisticated leveled abstraction so we have five abstraction levels and again the power of this is actually much more sophisticated than it first seems because the abstraction levels moving downwards enable us without being dependent on any process model to enable vendors like CA, ServiceNow, IBM, Microsoft, HP and the others that are already in the forum to conform to the standard and demonstrate the compliance of their products so that is something new and powerful a prescriptive architecture, a prescriptive standard that can be conformed to right down to the product level and then we can also go upwards so the value of abstraction levels moving up is we can articulate this as Lars has demonstrated to CIO and CIO plus one levels in language which is conceptually consistent with the standard but without overwhelming them in the down in the weeds detail that's obviously need to make the CMDB work and make everything integrate to deliver the services in the value streams so again the comment that layer is a bit misleading I would take that one on the chin these are abstraction levels pardon the clicks I'm trying to scan out between the questions a question was asked IT software ecosystem is there a clickability to telecommunications and IT infrastructure data centers extract etc the answer to that is a qualified no we are dealing with the business of IT this is various labels in different parts of the world and the business but what we're looking at is the business of IT in other words that specific area and I would like to add to that go ahead Lars in the sense I in my past life I've worked a lot with the telecoms industry you could say a lot of telecoms is today in a transformation to become managed service providers so they become more and more IT organizations and in that sense a lot of telecoms can actually use this as well there's also another thing I've looked at ETOM which is the framework for telecoms so to speak it's managed by the telemanagement forum and there are ideas from that that has migrated into to this framework so the concept of consumption the request to fulfill and the concept of having a layered way of presenting it can be traced back to ETOM so we do have some degree of understanding of what goes on there absolutely so I would underscore Lars's elaboration there by characterizing if you will the IT for IT initiative as a long overdue perception of IT service management as its own industry vertical and what we've been able to do with the leveled abstractions is to accommodate the learnings from other standards in other industry verticals to truly appreciate the space that this can occupy in the frameworks and standards landscape out there so we were also asked a question about performance metrics in enterprise architecture and work products such as the ones that are articulated in TODA our response to this is in the substantial guidance material that comes with the reference architecture so just to give you some background we have almost 50 organizations actively contributing to the collateral that you've seen Lars introduce today one of them is Westbury Software who are in the business of performance measurement and management and we have an active work group which is developing KPIs which provide the full insight from the models that Lars has introduced so again there's a huge benefit in our involvement with the open group in that we can draw that if you will structural need from TOGAF and deliver it through one of our own work groups within the forum but a great question there again bear with me while I scroll up so while you scroll up I picked out a question here or two questions but the first one is can you implement IT for IT incrementally very much so that what we recommend all our customers and typically how you would run projects we typically see that people start looking as they detect the correct area and implement some of the functional components around incident event monitoring etc and then move out from there to other parts so you can definitely do it incrementally and it's not a ribbon replace very often existing systems you have in place can be made part of it so typically the first thing you would do is to map your existing landscape into IT for IT and then you discover you can use it as a way of discovering how you would to be architecture could be based on your current as is architecture that is what systems you already have in place a lot of overlap typically takes place in most organizations so it becomes a good backdrop for that associated with that question there was is this primarily an organizational change thing or my comment here would be no it's actually the opposite the IT for IT really supports on terms of is there any kind of way you want to organize yourself and any kind of processes you want to do it's not true that it can be any but the the idea is that it is a staple with respect to the organization the thing is that when you implement software systems in enterprises they typically live for a long time you want them to be safer for a long time and and by making sure that you have a consistent architecture the component you implement any component that living component you want to make sure that that is something you can use for a long time and you might change your organization many times you might change your your processes of how you work but without changing the components we have proven out in the framework that it works with a lot of different processes and organizations that means that we do believe that often you can also get a lot of benefits out of combining the two so I'm not saying you shouldn't do organizational change or process changes why do you do it yeah thanks thanks very much Lars just to elaborate a little further on that I mean the the the real power of this leveled abstraction that you see on the slide in front of you to extend Lars's comments a bit this work is completely process model agnostic so we were asked whether or not this would accommodate Deming's work of PDCA and so on and so forth the answer is absolutely yes this is sufficiently agnostic at the process model level to accommodate anything from waterfall to DevOps and so on and that is the swappability if you will this approach to building the collateral and these upwards and downwards abstractions that you see indicated by Lars's arrow on the right hand side of the slide makes this truly unique and definitely a space filler in the landscape at the moment there's one question here Lars I'm going to direct to you because you're in a much better place to answer it we were asked what do you mean by a realized in quotation marks service model right some people also call it a physical service model so really what we are talking about is the model of what you are actually running in your data center something you have turned on or at least put available in the data center so it can serve customers so it's traditionally what you go out and have in your CMDB or CMS systems and populated typically by a discovery and so physical doesn't refer to the fact that it should be the machines as opposed to the application just means that it is something that now has been realized it no longer has been planning or setting state the it relates to slightly relates to another question because I see there was a little bit of discussion about does it also include machines and ships and what have I and yes it does the service model will when you model what you you are actually putting in the data center you need to go all the way down to the actual hardware so the idea is that IT for IT was managed from the business service level all the way down to the physical machinery that it's all running on top of of course if you have an IT organization that relies on cloud services to deliver a lot of it some of that will be abstracted away from you but we are not protruding ourselves from also managing the physical world Wonderful okay we have a related question which I'll initially respond to but then bring you back in again Lars is the question was can you define what you mean by life cycle level and then the supplement was life cycle of what my response would be it's an end-to-end overview soup to nuts as we would say in the USA but in terms of the specific perspective the life cycle perspective of IT for IT begins from the value chain in the four value streams and the reference architecture is sufficiently rich that the functional components and everything else prescriptive required to design and choreograph all of that activity is rich to support that whole of life cycle and do you think that's a reasonable response Lars or would you care to add anything No I think that's a reasonable response there is always things that can be evolving more and when it comes to the service model and the life cycles of services there's still further work that we're currently doing looking into what other standards are doing here there are interesting standards like heat in the open stack and in Tosca in places for instance and we don't want to replace them with something else we want to make sure we have pointers to them and align to those things there was a question around how we relate to some of the work that is going on by on the UPDM group in OMG I unfortunately I don't know all the details of all the relationships we're doing is the work that we have in IT for IT is growing dramatically over the past year but we do have relationships into the OMG and we're looking into how we can standardize the representation of ARCHIMATE and related things we use an extended version of with some UML part as well in the detail spec and making sure there are exchange formats for that from OMG I don't know the UPDM programming in particular so I hope I sort of answered that one yes indeed there is some more specific ones I'll just take one more I can there was another one is are there already models available in some of the commercial modeling tools FlyMaker, Truce, etc and yes there are some of the people working in the IT for IT group that have implemented versions of it right now within the IT for IT group in OMG we have used the start EA Enterprise Architecture tool for representing ARCHIMATE but we are trying to find an open source tool that is strong enough to be able to capture all this and to not put any favor of any particular vendor but I expect that pretty much every of the major modeling tools will have a version included very soon Wonderful many many thanks Lies for a splendid presentation and thanks to you and those in the webinar for persevering with less than optimal audio I'd like to bring the session to a close now many thanks for your participation