 Introduce you to the first of two tracks this afternoon led by the members of the IT for IT Forum team. My name is Chris Davis. We met this morning when the forum was launched. This afternoon we have Lars Rossen, who is the lead architect for IT for IT at Hewlett Packard, another Scandinavian from Denmark and Charles Betts, the author of the book I mentioned this morning and they're going to talk to you about positioning IT for IT in the broader standards context. So without further ado, I'll leave the floor to them. Thank you and I'll kick it off here. Yes, I'm from Scandinavia and I think everybody's going to make reference back to the keynote speaker this morning. I do listen to heavy metal music but not quite as heavy as the one we heard earlier today. I am an engineer by heart but I have a wife that understands how to dress me up how I smell I can talk about. So this session will go a bit more into details about the the positioning of the IT for IT work with respect to other standards out here both within the open group and outside of open group. There's been a number of questions earlier today on the topic but we can go much more into details. The agenda that we prepared here is really first then an introduction why I'll be doing IT for IT to some degree has been answered earlier in the day but slightly different spin on it then we'll go into a little bit more about what is IT for IT. So what is this strange diagram really trying to tell you that you see occasionally with a lot of blue boxes and black circles etc. Then relationship to ITOL, TOGAP and ARCHIMATE because they sort of are closest to what we're doing in various ways and then standards in more general terms. And I will start with the general stuff and then I'll hand it over to Charlie for the more specific on standards. So the first part is this disruption that we talked about earlier today a new style of IT. This is one of the reasons why we looked at saying well what we're doing right now is not good enough. There are two sides to it as Georg explained there is a side to the saying well integrations and what have I doesn't really work. We all have a multitude of systems and we are trying to integrate them we can do that better. And the other part is that the new style of IT has more agility all of these buzzwords etc that we all supposed to talk about but actually what is interesting on this slide is more this black line on top of it which is the systems of record systems of engagement systems of insight which is something we innovated within the group of companies that came together before it became open group where we really look at these systems of record and systems of engagement as something that are going back in the industry Jeffrey Moore talked about the systems of engagement is the new way of doing it while he talked about that 10 years ago is a new way of doing it and systems of record was the old legacy mainframe world of doing it and really as Georg explained earlier today in HP we look at it slightly differently and say well actually systems of record is still very valid having a basic understanding of the connectivity of data is important right I can't just throw that away but it needs to support a systems of engagement and so what we see with a lot of the other standards we're going to talk about today is about different way of engaging with that underpinning data fabric that the IT for IT is doing and then if we do that in a smart manner then suddenly we can also use it to create a systems of insight we can actually understand what is going on end to end in IT not just in the operational space or in the development space but end to end in IT and that is especially important in this new world where you have a multitude of suppliers as well you're no longer living in isolation as an IT department everybody is sourcing outsourcing insourcing around sourcing or whatever we call it and as such we need a smarter way of actually tracking what is going on so that we can still have good insight we can look at it in other ways around what is currently happening in IT is all about broken chains right individually within silos that might be working okay okay but as soon as you become more end to end it doesn't work I don't know whether I'm allowed to to quote some of the statements I have from some of the the big companies so I will let them be unnamed but the concept of actually spending three months 200 spreadsheets in order to figure out what is going on in IT is not uncommon it's actually more the rule than the while there's also companies that simply just giving up on doing it I guess but there is no single place you can go to doing that and then you could go in and say okay isn't these other standards that exist like ITIL, COVID, ETOM, ETOM is from the telecoms world going to solve that if you just follow those standard or best practices won't it actually solve it and the short answer is no it isn't and it's not because these standards are worthless or not the right kind of stuff but they haven't had that focus right. COVID talks a lot about the measurements the KPIs how do you measure your business but it doesn't really prescribe how you then do it it's that this is what you should measure fine okay let me try and measure it but I can't actually connect the dots right so I don't know how to do it so that needs a prescription in order to do it and so that's really what we be looking at prescription is a keyword in what we're doing here so you saw the the value chain before I wasn't really sure about how exactly the conference was working so maybe I would have spent a lot of time explaining this but Geek already did and I assume everybody was in the beginning and wasn't falling asleep because the engineer that talked about that was so inspiring so obviously you really have that pride in your brain here but I'll go to the next one here which is technically in a in a different manner which is basically to say well we did another thing when we did this work is that we we started with what you could so say the user is a North Star out the customer is it from an HP perspective being a vendor all the IT departments are our customers and we really wanted to look into what are the real use cases they're using an example which you will hear more about in the next presentation from case is around so I'm giving you a little commercial here is around how do we exchange incidents among suppliers and it turns out everybody's reinventing that wheel but case will come back to that but that's some of the kind of input we are taking in as the input to developing the reference architecture and then building up a functional model of what are the functionality you need we actually relate that to capabilities that some of these other standards are describing like I so then a key thing is the the lifecycle model as we call it that's really looking at the at the key data artifacts that controls it end to end and we identified that the fundamentally are approximately 25 key artifacts that if you control those and really understand them and really understand the lifecycle of say an incident or request for for change or a release object or a requirement etc then you can actually control IT we went in again with some of the the the big IT organization we worked with and looked at say do you have a reference architecture already do you have any information model and some had some had actually very amazing reference architectures they were huge you can print them in in A1 in Europe yeah so we can we can use that terminology for paper two standards competing there but on A1 paper with with with all the artifacts or data objects that connect and they would have hundreds or at least more than 100 and the problem with that kind of an information model is that it might be correct or you can spend a week discussing whether one of them is correct or not correct but it's not possible to implement because nobody really believes in it at the day you're finished it's also irrelevant it's also so that even though everybody here are in some form or shape architects I believe it's it's a very architectural heavy organization the Oven Group it turns out that a lot of the people we work with are not architects which is really frustrating I had a colleague of mine say can't we just make sure we send everybody on talk at courses and he meant everyone right because of course everybody should really just understand these kind of concept because they make sense and and that would be a nice solution to the problem but it's unrealistic right so we're very much looking at how can we how can we distill it down into something that at a high level is actually something you can communicate and you can all agree on and we came back down to these 25 essential ones and then understanding how they interact that's really the essence of what we're trying to do with this so that leads to the information model the underlying foundation integration layer we actually don't try to do within the standard we're leaving that to vendors like ourselves in HP or or some of our competitors or partners right because we we want to concentrate on that middle layer and getting that in place this diagram shows how we organize the the standard and again just for you information here we've we worked as was presented earlier again today since 2010 ish I actually personally worked on a preversion of that back in 2006 so persistence is actually part of what we're trying to do here I would say this is the third time around and I think this is the time it will actually really succeed in the industry we we just packaged up version 1.3 of that work and it will be released as a snapshot this week within the open group it's only a snapshot because we're only just starting this forum and so after this week has gone we will start working on 1.4 and 1.4 we'll try to then turn into a more approved standard within the open group with all the processes involved in everybody working on it etc but there is a 1.3 coming out and the way we structured it's a normative part with a set of framing and and value streams document if you could put it that way which is basically describing each of these value streams it's actually combined into a single document at the moment and then an underlying repository we're using sparks for that using the archimade language to express that where we have a number of of concept embedded and there's a long discussion about why are we not just using archimade concepts but I'm not coming into that discussion today but there's something called functional components which is the essential system if you will or component that deliver an aspect of a value stream so functional components relates to value streams and there are these artifacts so each functional component typically control one artifact so there is for instance an incident component which is controlling the incident artifact no surprise there that's actually the area most people can agree on as you move on to other parts of the reference architecture there's much more to be discussed because it's a less mature area of the it value chain the artifacts will have attributes they have relationships some of the artifacts are special because they form what we call the service backbone which I will talk together with Richard on after the break four o'clock ish so come back for that one and there are some essential services being delivered by the functional component that is create incident delete incident etc for instance these relate to the capabilities an IT organization needs to deliver and the scenarios that exist there but notice that goes into the guidance part so we split the standard up into the normative part and the guidance the guidance is a lot about taking what is already described in other standards we don't want to reinvent that but we want to reference that so the capability disciplines a lot of them that we mapped out come from ita we're not saying it should be different but there are also things that doesn't exist in ita then we described it in more detail so that's the basic structure of this the other thing we did was that we we copied as we should always do and and the layering concept is something I copied from etom a quick question how many people here are familiar with etom that's a bit less than 50 percent or maybe it's 50 plus some people sleeping but so basically etom have depending on how you count whether you count zero or not six or seven layers and we say well that's actually a bit overkill we'll only have five that's enough for us another thing we did was to say well the first layer is is really just the end-to-end overview and I'll show that in the next slide the second one gives more detailed description at the at each of the value stream and talks about the actual flow of data going on the third layer is the architectural reference here we shift to notation style which is a formal archer archymate notation where the top one here we use an extremely simplified notation so the people that are not trained architect will not say I don't understand it simply because the simple state haven't seen there are only a circle a box and a line right everybody can understand that pretty quickly then layer four it becomes vendor specific and we basically says what in the open group we're interested in standardizing two layer three but we still structure how companies should go out and do the their specific specialization of the standard because there will be specialization HP will do stuff that isn't in the standard that is expanding on the standard and everybody would do that our competitors will do that but at least it will be in the same frame and then finally layer five is the actual implementation of a solution right so one of the issues that existed in etom though I think it was a great piece of work is that at the top layer fairly quickly the telecoms industry got to an agreement on that and it's still today 20 years after inception it's still being used as a taxonomy for talking about what you need to do if you are telco they never really finalized the bottom layer or pretty much nobody really implemented the bottom layers in a standardized way and we say well we're not going to play the same game because then we're just going to fail the same way and that's not interesting right saying oh okay let's make sure we actually get one level further down that than etom did that's around layer three and that's concentrate all the effort on that then vendors can do the rest and so this is what came out of it that is version 1.3 maybe some of the other presentation will still use 1.2 because it's only pretty much today it's being released it has the artifacts that's the the key artifacts the one that are essential for IT that's the round black circles has the functional component which are the essential system you need to implement in order to implement something end-to-end that's the blue boxes and so you see the the incident component up in the upper right hand corner it relates to to the events it relates to service monitoring relates to configuration management component which is sort of equivalent to what you use to see an ISO as the cmdb and then you can that's the operational space that's actually what is most well understood in the industry and you can go all the way back to the the planning side the strategy to portfolio where you have components here enterprise architecture policy component a proposal component where you figure out what are you actually spending your IT budget on the the demand component where you track what is the strategic demand that comes in it becomes the portfolio backlog and then the service portfolio component that actually tries to keep track on the business aspect of the service you have and that goes back into saying there is a a service backbone that actually ties it all together at the bottom and again i'll speak a little bit more about or somewhat more about that backbone in in a presentation later today so i'll not not do more in in this one so coming back to the to the standardization stuff the the first observation would be if we look at ARCHIMADE TOGAF ISO and IT for IT what is really going on here well IT for IT is a reference architecture for the IT software ecosystem so really describe what software should you put in place what data objects should the software control and and how should they interact with each other and it tries to do that in a very prescriptive manner but also vendor independent right ARCHIMADE that's a well formed modeling language there are a lot of those out there in the world but ARCHIMADE seems to be actually very well suited in two ways with respect to IT for IT one is that actually expressing level three is possible more or less directly in ARCHIMADE we have certain issues there and and so we're starting to work with the ARCHIMADE group within the open group to to get better alignment on that and then you could also say that within this backdrop and that's actually version one to two sorry i hadn't got that one updated slight changes only but within the service backbone you need to model the service you're delivering to the business and there ARCHIMADE is also a good candidate at least at the at the conceptual side of the of the house we have TOGAF and again i will not try to be the expert on what TOGAF's purpose is it's very well established in the open group and also we see extreme uptake in the IT industry around TOGAF it's becoming more and more popular in terms of planning there is an aspect of of enterprise architecture in the in the IT for IT work and it would be natural that it really is based in TOGAF there it's not a prescription in IT for IT that it needs to be TOGAF but it is a nice alignment the other thing you could say is that TOGAF works with the concept of a 2B architecture and so if you want to actually implement IT for IT you need to design a 2B architecture then you compare it to the as is architecture and then you figure out what to do that's a TOGAF in 30 seconds right and this is the 2B architecture or should be the 2B architecture for all IT organizations when they plan out how to run their own business the IT for IT right so it gives an ability to to simply if you work in TOGAF you take that out and plug it in and we've discussed with the TOGAF forum can we make because they work on what are the actual library of 2B architectures and this would potentially become one of these libraries ITAL is a best practice framework focus a lot around processes and and depending on what kind of training you have you you can discuss whether it's processes or capabilities or disciplines or what it is and I'm sure Charlie will elaborate a bit more on that because he's the expert on that we have a paper on how it aligns but at the end of the day it's a best practice framework for processes that's a simple way of saying it and these processes we've tested on top of the IT for IT reference architecture and it's possible to do that it's not necessarily the right thing to do you might not believe in ITAL in certain aspects of what ITAL described but you can do it on top of of this data model because ITAL doesn't describe the actual data model that needs to be beneath it so that is how these things work together can picture it out in the in the value stream the the the IT chain where TOCAF relates to sort of the front end and and ITAL to the back end depending on what is front and back and but you could say the the planning side versus the operational side yes ITAL people will say ITAL also go all the way to to to planning but it's not really what's used most and similarly you can say TOCAF also go all the way to operations but again that's not really where it's it's most used and then in between there are various other things save prints to etc that is relevant and mapping some of this stuff Charlie will come into it and archimage sort of as one thing can underpin a lot of that work that's the first part of it with that I'll hand it over to Charlie for the more detailed part thank you Lars and thank all of you this has been a very exciting day so we're not doing a clicker just doing on the off okay where'd I hit that's interesting the space bar that's it's windows 8 that's always oh no yeah right right in some detect some detect to correct here sorry okay um so uh I um once upon a time was ITAL certified although probably not current anymore and I've also been a reviewer was reviewer on service strategy in the big version 3 rewrite certainly have been engaged in various forms a little bit about myself probably the most relevant work I had here have in my career to the IT for IT work was when I was at Wells Fargo where I had a role very similar to Carol's as the chief architect for the business of IT there so in that role for six years I found myself as the consulting architect to the CIO's directs and their directors you know who were trying to understand we have a five billion dollar IT value chain here and we have the equivalent of what was been commented on previously spreadsheets and emails you know we have nothing resembling an integrated architecture so we went and we built the big architecture as so many other HP clients have done over the years and of course one of the first things I did was I said well buy me ITAL how many people have actually seen ITAL I mean we hear about ITAL but I actually seen the content so yeah I mean okay so you've seen all five books you know they're they weigh about you know three or four kilo two thousand pages uh six hundred dollars to purchase it's actually you know not that easy of a standard to get your hand on just because of the sheer cost and um I have you know have in my possession most of the um well I have all of version two and three in 2011 and a lot of version one and there's a lot of things that ITAL does very well in terms of describing how the IT industry has gotten to where it is and how it talks about what it does um you know but in at the end of the day ITAL is primarily a narrative uh a lot of check checkboxes a lot of checklists a lot of verbiage about this is best practice this is what we've seen this is what we've seen works of course there's always been this tension with best practice and yet let's propose some new things like CMDB which I don't think anybody can say was a best practice when it was proposed because nobody had ever really seen one and in fact the vendors came after the fact and started building CMDBs but because of course ITAL says this is a best practice system to have in your environment therefore you should buy one therefore we should make one so that people can buy it but where did the idea really come from um I happen to think it came from the early metadata repositories in the uh in the uh data management space but that's another story and at any rate we can see the key distinctions between IT for IT and ITAL are here a little hard to read but IT for IT's intent is to be prescriptive uh it is to be structured it is to use a formal metamodel uh it has an architectural origin and focus I do not think it will ever be 2000 pages uh you know who knows but it seems like that might be you know not exactly what we want to take it it has more of a solution orientation as to educating practitioners ITAL is very good at educating a practitioner and saying this is what you need to know in a large IT management context so here's you know here's the training that is based on this this uh body of work whereas IT for IT is more about how do you solve it I think the great the great metaphor I've heard this week is is that uh to so many customers of companies like HP and IBM you know when you buy the management tools the portfolio the service desk all that it's like buying a large piece of IKEA furniture without the instructions so if you can imagine you know what it would it's like to assemble IKEA even with the instructions now okay you have no no guidance you know that there's a nice piece of furniture in there but how do I get from event management from to portfolio management what's the relationship between my enterprise architecture tool and my CMDB you know these are all you know very much open questions and they've been open open and problematic questions for so many architects who get at some point pulled into this question of okay you've been a supply chain architect the HR architect you know the marketing architect the demand deposit banking architect we need you to come over to the IT group for a little while because they have some architecture problems too and you wind up over there and it's like what do I do I have this this mess of silos but I have no end to end value chain orientation ITIL started to talk about that with the service life cycle IT for IT is definitely taking it a large step forward we have a focus not only on a very large IT value chain abstraction but we've taken it down to a manageable next level it's one thing to draw an IT value chain and many people have I put one in my book in 2006 but how do you actually get from you know saying well at this end we've got some demand and at this end we've got some IT services being delivered what do you how do you then what's the next logical step downward and when I saw the IT for IT architecture of strategy to portfolio requirement to deploy request to fulfill and detect to correct what the light bulb really came on there I said okay this is actually much more actionable these are all more countable they are all more real we can actually turn this into an architecture and so that's where you know IT say IT for IT has this sense of large grained end to end value flows now the semantics as we've seen the semantics for a long time hire to retire procure to pay idea to cash quote to idea to product quote to cash I mean these are all well understood ERP abstractions and so all IT for IT has taken this very well understood and a set of abstractions that actually I first learned when I was when I myself was at Accenture you know that that was all the conversation back in the day was you know procure to pay you know and of course that derives from you know the standards and the business process work of people like Rumler and Brayesh IT for IT is intended to be mutually exclusive and comprehensive we care if stuff overlaps I till very specifically says it's more like a set of tectonic plates that kind of bump up and overlap and we're we realize that we did not do a completely rigorous job of rationalizing I do in all fairness believe that that's a quote from I till version two but I think it still applies in large sense to I till version three as architects we have to have mutual mutually exclusive and comprehensive architecture and IT for IT that is one of the quality criteria that informs our work we have the precise representation of data and integration patterns as Lars has mentioned and is as Garrick has emphasized as well where I till does not talk about that at all and I'll speak a little bit to COVID as well IT for IT I am the leader of the agile work stream now again in all fairness you know we want to be be fair and accurate when characterizing other standards I till itself now has you know white papers and some collateral on bringing in DevOps and so on and so forth but I think that you know we continue to maintain a commitment in IT for IT we realize that agile and DevOps are essential to how IT is delivered in the in going forward and and I think that's that's going to also differentiate us and of course I till is a proprietary only owned by Axelos which is a joint venture of capital in the UK government and there is not an open governance model period and there's been a lot of conversation about this in the IT service management forum I've been you know peripheral and observing to observing those conversations for many many years and there is as far as I know not going to be a change in that and I think you know all industries go through this maturation process I mean we see pure standards that we can compare ourselves to like arts like etom like buy-in where you start to see that actually no there is a community here in this community needs a voice and now has a voice and has a platform where the IT industry itself can say yes we are going to move forward with this now industry consortiums you know have their pros and cons you know you have to be a vendor you know you have to be a vendor you have to be incorporated to some extent to get involved there tends to be a lot of vendor involvement we're always looking for more practitioners to get involved but these are these forms are known to work you know these industry consortia you know the thing is you always have to ask yourself well what do we know can work well we know an industry consortia can work and we know that there that there is a track record over time of them producing valuable and helpful intellectual property that is is is a kind that has some sense of accountability to a greater good so I'm very pleased that we've come this far with the open group this is my overall this is the overall conceptual model that was used essentially to sell IT for IT in part to the open group leadership as why we were doing what we were doing and why we thought there was was a gap in the industry now this is not necessarily an obvious diagram and I realize that again some of the text may be a little bit hard to read but let me step you through it please because certainly we want you know we want to continue to have feedback on is there an opening here so let me make the case and I'd like you all to look at this skeptically and critically and tell me if I'm off base on the left you have degree of prescriptiveness so at the very top you have high order standards that are narrative conceptual and then below the line perhaps you'd have all your definitely computable things like the IEEE and W3C specialized in but there is a middle ground as you see standards that become more and more prescriptive you compare EDI to V-core you compare HRXML or XBRL to GAP you compare you look at ETOM we're at the highest level as Lars indicated there is you know this this very high level abstraction but ETOM goes all the way down to a fully attributed data model now in IT management and this is where people who you're less women is like Charlie yet another IT standard I mean what on earth are you thinking aren't there enough but we have COVID, ITIL, CMMI and Togaf all clustered at this very high level abstract computation independent I've borrowed from the OMG stack here computation independent platform independent this is not quite platform specific but it's at least plot at least syntactically precise and that's the direction we're headed now IT for IT is not there yet but it is positioning itself to move down into greater levels of syntactical precision and at some point we will have to make the business decision as a standards body how far to take it as Lars alluded to with ultimately the limitations that ETOM found but that is the space and this is how we characterize it to our pure standards bodies you know and standards organizations and companies such as you know ISACA with COVID and ITIL and the rest and and SAFE so any comments on this certainly cards are certainly in order I don't know if we are doing the cards here today but as I compare you know I see I see you know the standards that I tend to look at are the national retail federations association of retail technology standards anybody familiar with that work again nice precise fully attributed data model it's used very extensively throughout retail again it's a consortium effort been successful you go to the national retail federation my gosh the arts pavilion is huge with satellite booths from EMC and Oracle I mean it is a very very successful standard buy-on and banking acorn insurance ETOM these are all the things that we're kind of benchmarking against so to speak and again this is an open conversation it's a you know I'm dying to hear further feedback about how we've characterized this I oh I continue to put that this is a draft and needs for their vetting so even though we've had this conversation now a number of times and so far nobody has said well this is just completely off base or mischaracterized okay how we doing on time okay terrific um agile I'm gonna talk a little bit of let me talk briefly about cobit because that was mentioned so I myself have been an author of two cobit standards there is a configuration management with cobit 5 I'm an author on that and I'm an author on a cobit standard called enabling information has anybody seen either of those they're small ancillary cobit volumes I got involved in the cobit enabling information without telling tales too far out of school here I hope I got involved in that because I thought it was going to be a data model for the business of it that I saw it was going to move in and actually have cobit undertake a structured data representation and actually we did that whole work and produced the guidance and the decision had initially been going in that direction but ultimately that is not what co what isaka chose to do with that so uh you know I feel quite confident in expressing to all of you that no there you know there's not overlap with what cobit is doing with isaac with uh isaka is doing with cobit um I can talk more offline if anybody wants to hear more more about that story um well let me step to agile um now agile of course is not a standard and there is this ongoing kind of anarchistic emphasis in the you know orientation in the agile community where a lot of folks are like standard stay away for me with that standard stuff you know I just I don't want to hear about it uh that's not necessarily you know I think possible in organizations where you know the it budget is five billion dollars a year but we are certainly watching agile with great interest and I think that it is very much a mistake to think that agile is just a social movement who here has read this book the principles of product development flow by Donald Reinhartson I think this is the most important book in the IT industry currently it is being cited it is cited by virtually all of the agile thought leaders it's cited heavily by uh Dean Luffingwell in his work on SAFE the con the book Kanban by David Anderson was inspired in part by his conversations with Don Reinhartson Don Reinhartson is like he's the man behind the curtain of agile in a lot of ways and he's done it because this is an actual theory for why agile works agile doesn't work just because there's a lot of millennials in the workforce who don't like governance that's a caricature and it's incorrect agile works because it understands certain realities about queuing theory variability fast feedback batch size a lot of which has been drawn from the lean literature and Reinhartson brings it all together here and one of the things that he is most concerned about is visibility into cues and this is one of the thing this is one of the current this is the current you know brings you all up current with what what the conversations you know Lars and I and others are having about how where do we take IT for IT because the problem with IT management right now I believe is that the operating model is still immature almost to the point of being broken there is not a sense of execution management which is why I'm so interested in the ANSI ISA 95 standard which actually specifies what we mean by execution management IT is still trying to wrap its head around what it means by execution management and in a lot of ways the ITIL standards have you know standards like it have kind of confused things and I'm getting a little bit deeper I love to talk about this stuff offline but at the end of the day what we see coming in IT management with agile is simpler lighter weight process and execution models challenges that come from the agile community saying why do we need an incident process and a defect management process if the end result of the defect of the incident is to route a defect back in as a user story why do I need an incident a problem a defect to change a user story and an issue you know and the trouble is is what we're seeing is we're running into this queuing gridlock and so this is one of the current thought experiments that we're engaged with with IT for IT is where are all the cues coming in in IT for IT because if we're listening to people like Reinhardtson and the insights they're bringing in from lean and operations is this whole question of how do we start to optimize the execution in IT management better now then the other question is is how do we engage in this discussion as an industry standard where we want to truly be based on best practice and yet the industry practice is changing very quickly this is where it's exciting and interesting and we don't necessarily know the answers yet I see Chris is standing here this is the last of my slides so I'll back to back to Lars thank you so summary I'll do that very quick that's a summary no so it was quite a journey that we tried to do here in in in 40 minutes focusing really more around what is around IT for IT than what is IT for IT itself though I also went a bit into that of course there will be more sessions around what is IT for IT later in the day I still want to come back to to the fact that prescription is in a very important aspect of what differentiated IT for IT from a lot of the other standard works and the associated with prescription the core data model that allows us to connect everything right and I like the fact that we managed to come down to something that you can present on a single page which basically if you print it out in A4 you can still read it right yes okay on that distance it might be difficult to read up here but you can actually read it in A4 and then what we do is that we we go out we blow it up maybe to an ace one again put it on the wall and then we use it to actually go to what is currently happening in a given IT organization what is the as is and to be state and we can use that taxonomy and within an hour I can get everybody to actually understand it I've talked with my wife about this believe it or not and she's a oh yeah that makes sense she's an accountant not in IT I should say so so it's it's it's actually something that that is useful to to get a taxonomy about what is going on and then she also said oh so you spend three years drawing that picture really but okay that's that's a different story