 Dana is principal analyst at Interarba Solutions, an enterprise IT analyst, analyst market research and consulting firm. Dana's honed his skills and refined his insights as an industry analyst, pundit and news editor covering the emerging software development and enterprise infrastructure arenas for the last 18 years. He's a former senior analyst at Yankee Group and Aberdeen Group and a former editor at LARGE and founding online news editor at InfaWorld. Former news editor at IDG News Service, digital news and review and design news. Dana's done a number of these for us in the past, leads a great session and I think this one will be, we did have questions as we said before, we did have some questions for the Microsoft speakers earlier, which I think Dana's going to try and weave into those. But I'll let him introduce the panelists, but for now introduce Dana Gardner. Thank you, Steve, and thank you to the open group for hosting this panel. And let me introduce our participants. You know, we've heard a lot about IT for IT and we've looked at it from a variety of different angles. We'd like to elevate the discussion a bit up to the level of business value. And so to learn more about that, we're joined by Chris Davis. He's the Professor of Information Systems at the University of South Florida and also Chairman of the Open Group IT for IT Forum. Come on in. Lars Rosen is a Distinguished Technologist at Hewlett Packard Enterprise and a Chief Architect for the IT for IT program. Thank you, Lars. We've heard earlier and we're joined again by Ryan Shearmerer. He's the Business and Enterprise Architect at Microsoft IT. Hope I got your name right. And David Wright is here. He's the Chief Strategy Officer at ServiceNow. So have a seat. Get ready. We want to make this interactive. Please tell us not only how you feel, but react to what other panelists are saying. And let me start with some observation that I've had this morning listening to this discussion about IT for IT. I hear it's a standard. It's a framework. It's a methodology. It's a business enabler. Chris, is it all of those? Is this a whole greater than the sum of the parts? Help us understand better what IT for IT's potential is. In terms of potential, I think it can be seen as all of those. So I've been academically in that space for 20, 25 years. The thing that really is different, the thing that adds potential to this is the value chain orientation. So as well as being a really potent technical standard, we've abstracted this to levels that can be immediately appreciated in the C-suite. So people like Kathleen come along and they see it and get it. That provides some traction, which I think is a very positive thing and will enable us to pick up speed as people like Tuan invite real penetration down to the CMDB level and so on and so forth. So we've got this multi-layer view. Lars and I articulated it as levels of abstraction. But I think the integration of Mike Porter's stuff really adds some perspective to this technical standard that maybe isn't present or hasn't been present in other frameworks and tools. And as we try to sell this up the value chain into the organization, perhaps frameworks is lost on some people after a certain height. But IT for IT is a nice brand. It's got a nice ring to it. It makes sense. Do you expect that IT for IT is something you would take to a board setting environment and have them understand this concept of a value stream and consolidating around that? Yeah, I do. I think some of the observations that were made yesterday about the persistence of models like value chain, value stream and so on, they still make enormous sense to people at the CIO level. And that then enables the conversation to begin and also provides the ability to see whereabouts, how much of the standard, which particular value streams, where in the organization it fits. So as well as being very potent and very prescriptive, we've got that conceptual agility that the standard provides. I find it really exciting and really quite refreshing. Now, Lars, one thing that's also interesting to me about this is this was an organic development within IT organizations of, for and by them. Tell us a little bit about how at Hewlett-Packard and Hewlett-Packard Enterprise you developed this and why it was a good fit for the open grove as a standardization process. Well, there was a couple of things that made us kick this off and together with Shell initially and then a lot of members came over the years. It was, for us in Hewlett-Packard Enterprise, it was really around consumption of our tool sets. That's where I came from. I'm sitting across portfolio group and say, well, we all draw on all of these diagrams about how it could fit together and we had these endless discussions with customers about whether this was right or this was wrong, et cetera, and was completely disagreeing with all our friendly partners as well as not-so-friendly competitors about what was the right diagram. So by putting this into the open and we choose open group for that particular reason that's shown in the past that it can create these kind of things, allowed us to have that common framework for defining the 2B architecture for our customers and that simply made it much easier for us to sell our product suite. So it made a lot of business value for us and it also made it much easier for our consultancy service. Didn't have to argue about the 2B architecture it was given then we can talk about how to actually implement it, much more interesting. And while we're speaking about Hewlett Packard Enterprise and your experience there, do you have any tangible metrics of success as to how this improved? You went through a large business separation of IT departments. That must have been a difficult process. Was there anything that the IT for IT approach brought to that particular activity that you can point to as a business driver, business benefit? I can because it's, again, a very large organization is compartmentalized in many different ways and you could say, well, how does all of these units interchange and work with each other because it goes both ways. It's not only the split but it's also all the acquisitions we're doing over the years, right? And then we have a framework that we can use and plug things into. We have a standardized tool set we can use and reuse over and over again. We counted at some point before we had IT for IT how many integrations do we have between our various IT management products and it ran into about 500. And what we could do with IT for IT really drill down and say well, there's only about 50 that are really interesting, right? And we can double down on those and we can now measure how much these are the ones that are being consumed moving forward internally within our service practice and as well as with our customer base. And a reminder to our audience if you do have questions for any of our panelists, jot them down, get them over to Dave and we'll address those towards the end. Ryan, at Microsoft, I'm wondering about bimodal IT and shadow IT. Because you perhaps have a more concentrated view on IT and you can control perhaps your organization, you don't have that problem. But maybe you do. If there is any degree of bimodal IT at Microsoft or shadow IT within your IT organization, have you addressed that and has IT for IT been a use in that direction? Yeah, those are great questions. First, starting with the idea of bimodal IT. When we go back to some of the research and the thoughts coming from Gartner over the last couple of years about different parts of IT needing to work at different paces, some needing to be more agile and working faster, others needing to be sort of the foundational stalwarts of the organization providing that consistency and that repeatability that we need. And Microsoft, we tend to look at it a little bit different. When you think about agile versus waterfall, it's not a matter of one versus the other. Should we do one or the other? There's a place for both of these as tools within our toolbox within IT. There are places where we want to move in a more agile way, where we want to move faster. There are also certain activities where waterfall is still an excellent methodology to drive the consistency and predictability that we need. A good example of that is large releases. We may develop changes, develop features in a very agile way, but as we move towards making large changes to the business that impact large business functions, we need to roll those changes out in a very controlled, very scripted way. So we kind of take a little bit different look at bimodal than some companies do. Your other question was on shadow IT. One of the things that we've challenged a lot over the last year or so is this concept of what is the role of the IT organization relative to the rest of the enterprise? And as we think about that, we're not thinking about IT as a service provider to the enterprise, but as a supporting function to the enterprise. And what does that mean? It means shadow IT doesn't exist. It just happens to be someone else within the organization providing that function. And so it becomes less of a question of controlling and preventing shadow IT and more of embracing that outside-in approach and being able to assimilate those changes and coordinate them in a more structured way to manage things like risk and security. Well, we heard from RoboBank that there was a bridging of silos benefit to IT for IT. In either bimodal or shadow or perhaps another area, can you perhaps relay a way in which IT for IT helped you bridge silos and consolidate culturally and otherwise your IT efforts? Yeah, absolutely. And very similar to some of the experiences that Lars explained at Hewlett Packard. At Microsoft, we've had a number of different product groups focusing on different product and solution and service suites over the last few years. As we've moved more recently over the last couple of years to more of a one Microsoft approach, we're looking at how do we bring the organization and the enterprise together in a cohesive way. IT plays a role in enabling that as a supportive function to the company. The IT for IT standard has been a great tool for us to have some sort of a common talking point, a common framework to bridge those discussions about not only what we do internally, but how the things that we do internally relate to the products and services that we sell out into the marketplace as well. So having that common framework, that common taxonomy, it's not just about talking with customers, it's about talking internally and getting the entire enterprise aligned as well. Dave, as organizations are working at different paces towards being digital businesses, they might look to their IT organizations for leadership. We might as a business want to behave more like our IT organization. At ServiceNow, I've heard you describe that ITSM is one step towards business service management rather than just IT service management. How do you see the evolution from ITSM to business service management towards a digital business, and how do you foresee IT for IT perhaps aiding and accelerating that? So I think the interesting thing about IT for IT is the fact that it conceptualizes the whole four stages that people go through on the journey. Now, the great thing that... I suppose you could say the gift that IT will give IT was to give it an operational framework to work to it. Now, most other parts of the business haven't got an operational framework. If you want to request something off most parts of the business, you'll send them an email. You want something off legally, you want something off marketing, send them an email. They haven't got a system where they can request something. So I think if we can take some of the processes described in IT for IT and be able to then publish that in a business service catalog, then you effectively allow everyone to have a single system of engagements. They might have their own back-end systems, they might have their own human capital management system, their own ERP system, but how do you engage and link all those companies together? I think the other thing that IT's learns over a number of different implementations is how important the experience becomes because if you can generate an experience where people want to use it, that's what's going to drive adoption of that as a function. You imagine, you imagine, let's take this room as a whole, if we all sat together and we built Uber, it'd be crap. It'd be really good for the taxi drivers, but it'd be terrible for the people who actually wanted to request the service. And that's because we tend to build everything from the inside out. The fact we've now got a way to elevate that position and look at it from above and understand all those components and be able to track all those components from start to beginning and give people visibility in where you are in that process, that's not just a benefit to IT, that's a benefit to anyone who provides a service. All right, as we also explore ways that we can evangelize and advocate for this in our organizations, it's helpful to have places where it works first, the crawl, walk, run approach, if you will. Chris, can you help us understand perhaps areas where applying IT for IT early and often, as a beachhead, to then expand and also to relay value up to the business so that they would get behind that effort? Where are some good starting points in an organization rather than boil this in at the ocean level? I think where you have the need and the competence. So back to my earlier point about how the standard can be envisioned and the point that David just made, I think that what we offer in IT for IT is something that's not only prescriptive and ready to hand, but it's also ready to mind so people get it very quickly. So I think the quick wins are the important ones, not necessarily the low hanging fruit, but the parts of the business where opportunities like the ones that David's just suggested, if we were to try to do something like Uber, that would be too much. If there's somewhere in an organization like Microsoft where Kathleen's in charge and there's a group that can really gain rapid traction, that would be most effective. And then the telling of the stories, the work with Twan to explain how from the early stages of development of the architecture it was useful at Rabobank, that adds momentum. Lars, same question. Where did you see this as getting traction best? Maybe it was new efforts, green field application development, mobile first type development, maybe it was some other area. Where might you point to as a great starting point to build this into an organization? Well, it's pretty simple actually. We've done more than 50, maybe 100 engagement now using the IT for IT model with our customer base. And it's typically, so it's very often the central IT, it comes out as saying, well, we're doing innovation. It's the automation story that comes first. And then typically you end up in a discussion around detector correct. It's a familiar area. People kind of understand the various components that are involved in that. But again, back to what you also mentioned before is the layered approach allows us to go in with a single slide. We can put it up in large format on the wall. You can start to put posted notes on it. You don't need to understand architecture. That implies that we can have decision makers coming in. And we break down a lot of silos in the operations area just with detector correct. That's where 99% of our engagement has been starting. Then the request to fulfill with the experience, that's where people want to go. That's the holy grail, one of the holy grails. There are actually two holy grails. That's one of them. One is to be able to do strategy to portfolio. And no longer just saying, I have this application, I need to move it to the next version. But I actually really understanding what are the services, not the applications, but the services I'm delivering to the business. But you can't really do that until you have the downstream. It's more in order. You can start building up that service backbone that is so crucial to IT for IT. Is there an element of educating the consumer of IT in an enterprise to perhaps anticipate services differently? When you mentioned, Ryan, earlier, the request to fulfill value stream, I can understand how that makes a great deal of sense from IT out to the organization. But do people, do they have to make an adjustment in order to receive things as a value stream, to consume them, to think of asking things through the lens of you being a broker organization? What must we do to educate and help the consumer of IT understand that it might be a different ball game? I think we need to take it from the lens of reducing friction within the organization. The consumers of IT are operating in a changing landscape. I talked about that a little earlier about sort of the network effect and how it's constantly evolving, constantly changing. And the needs and desires of the folks consuming technology and information will continue to change. Yes, request to fulfill really helps provide the mechanics for a corporate IT organization to become that broker of services. But when we look at that from a consumption perspective from the users of services, it's all about enabling them to change their mind, change their needs, change their business processes faster, and removing the friction that exists within the process of provisioning today. Something that's a new technology that they want to bring into their organization because they see a potential to it. How do we get that in there faster? The whole request to fulfill value stream is about accelerating the time to value for new technology coming into the organization and reducing the friction in terms of the request process. Dave, anything to offer on that same side, the consumption side rather than the delivery perspective? Yeah, I think when you look at how people actually consume things now, there's definitely a trend going on where people are becoming more service aware. So we're getting this breakdown now where people are saying it's not about the CIs, it's about the service that those CIs support and how you can take something and you can have not a CI centric CMDB but a service centric CMDB, how people can map those relationships. So I think the whole consumption side of it's flipping now as people's expectations come in line. And the other thing I found specifically with the IT for IT concept is people start to put together the kind of business logic very quick around things. So they'll look at the whole process and I had someone said to me, we were having a discussion a few weeks ago, they said, so if I understand the cost elements of each of those, I truly know what that service costs. Could I move and actually be able to manage my systems based on what it's costing the business, not the fact it's a 7.1 problem or it's a red light, it's costing me X amount of dollars a minute for this to be down and I've spent this much money actually building it and getting it out. But you've got to have all those elements tied in all the way from the portfolio element right the way through to the run element. So it really seems as if it also offers the value of rationalization, prioritization, but in business terms rather than IT terms, is that fair? Correct, yeah, that's fair to say, yeah. As I try to factor where this will work best early and often, not only would we look at specific parts of IT within an organization, but we might look at specific companies as a culture, as a type of company, but also vertical industries. So I'll go back to you, Dave, because ServiceNow has a fairly horizontal view of many different companies, other particular companies that you think it would be as a culture or a type of company better suited for adoption of IT for IT or other vertical industries where this makes sense first. So the people that I've seen who've been most disciplined about wanting to be able to look at things holistically right across the whole gammas has been the pharmaceutical companies. So pharmaceutical companies have come along and they're obviously very regimented the same way finance are. They're the people who seem to be the kind of early adopters of looking at this whole holistic process. I'd say if I look at customers, the people who are adopting it first at a low level tend to be the financial institutes, but after that the conversation tends to go through sort of pharmaceuticals. I don't think any one business has really nailed it, but this is the challenge of every company. Every company has an IT division and they run IT, but their business isn't to run IT. Their business is inherently to provide financial services or develop drugs. So actually looking at what processes people do to drive their core business, the people who are very regimented and disciplined tend to be the people that are saying there's got to be a way we can gain more visibility into what we're doing from an IT perspective. Ryan, thoughts on the similar question about where this is applicable either as a type of company or a vertical industry? I would look at who's most threatened by the changes going on in the world today. Where are cost pressures to drive efficiencies, most prevalence? Because they're going to have the most motivation to change quickly. I would also look at companies that were perhaps early adopters of IT who through their early adoption have ended up with a lot of legacy debt that they're trying to manage, and they're now needing to rationalize that in order to get their total IT cost profile down. In terms of specific verticals, I think there's pockets within each vertical or each industry that there are opportunities here. I would look at it maybe from a scale perspective. If you go back to the sort of scale model that I shared this morning about the different sizes of organizations, a lot of small organizations don't need this. A lot of startups can build it into their DNA. Some of the companies that are more of your legacy, more mature enterprises, have more of a fundamental need for this type of structure and are going to be able to reap some benefits more quickly with only a few pieces of it. So I think it's a scale question. I think it's a risk question. I think it's a who's under the most pressure to improve their cost performance? Well, as all of us are under pressure to transform and adapt, we're all doing many things at once, and it's difficult to know what you're doing and its impact on the improving, hopefully improving environment. Is there a way for us to perhaps think about when we adopt IT for IT, what we should expect to see if we're doing it right? So if I do IT for IT correctly, how might I know a few months, six months, a quarter or two down the road that I can attribute improvement to that particular activity? Let's start with you, Lars. There's a couple of different things that I believe can be measures on it at an abstract level. We're actually within IT for IT trying to make more concrete KPI assessments of what would make sense in terms of measuring it. But more abstractly, it's around, are you really embracing the multi-supplier options that reside in IT for IT? That's one of the reasons why we kicked it off. Shell has some good examples of what it costs to integrate a supplier, and that's tremendous high cost, typically, because you have to design how do you exchange an incident every time over and over again, right? And that becomes much more reusable. So that's a place where you see that the cost of working with your partner should go down. You can become a service broker. So that's a particular area where we would see benefits very quickly. But it's also coming back to the original question or the questions before. And that's also where I see the typical companies that want to pick it up are the companies that really are having that pain of it's not a centralized IT any longer, it's lines of business IT, it's central, it's suppliers, and you're self-supplying to others. If you have that problem, then IT for IT is really good for you, and you can quickly see benefits. Chris, thoughts on this notion of how do I attribute benefits in my IT organization at the business level to IT for IT? So, this has been another holy grail for academics. I mean, we go all the way back to the 1970s constructive cost model and things like that. I think Lars has hit the nail on the head. The other thing is what Kathleen said this morning, I think it would be less easily measured, more easily sensed. There will be changes in mindsets and so on. So it's very difficult to articulate a measure. But we are working on ways to make it much more tractable. I think if I can just add one of the... Dave, sure. One of the interesting things, I mean, I've been implementing ITSM systems since the mid-90s, but we still do one thing in the same way that's really weird, and you kind of hitting it with this question, it's can we define the outcomes? I think whenever anyone undertakes a project like this, where they decide, hey, we're going to completely redefine the way that IT manages itself as a business, you probably should design the outcomes and the metrics that you want before you put the system in. Almost everyone, I can ever remember, implements the system and goes, cool, let's write some reports. And then you take the reports you can get, and you'll say, oh, we'd like a report that shows this, and the consultant who's put it in goes, oh, yeah, you can't get that. If only you step back and said, well, let's think what we want and build a system that delivers that data, it'll provide a lot more values to the business. Well, I've had a chance to ask lots of questions. Let's go now to our architects, the people in the trenches. Dave, help us out with some practical approaches to implementing IT for IT. Great, thank you, Dana. First, I want to mention that since Chris and I were both one of the sepia-toned people you saw in the picture he showed, it's really gratifying to see the new participants, like Ryan and David, come in and adopt this technology and give us their insights. So thank you very much for participating, as well as our legacy folks. IT always has a legacy, right? It's the first time I've been called a legacy person. Finally, do your face. So anyway, get serious here. Each speaker mentioned the need for better data management as part of this process. And so this is a governance issue. And who in these evolving organizations should be responsible for data governance? Is it the business? Is it IT? Is it a third entity that should be doing that? Any thoughts on that? Let me take that one. I think we need to start by rethinking the idea of data governance. We're trying to govern the data because we're trying to create too much data. We're spending far too much time adding overhead tasks to people who need to do their day jobs, people who are trying to execute on the value stream in order to generate data needed to make decision making. And when we don't get the data that we're looking for to drive decisions, we apply governance and we apply more overhead on top of it. As we think about IT for IT and the fact that we have a value stream and a separate set of supporting functions, it gives us an opportunity to say, how do we reduce the amount of data required to be generated in the value stream itself? You know, the extra data points that someone collects as a part of a request or the status updates that are created as a part of a project or an agile release. And how do we get to the point that we can derive that from the operational systems themselves and let people just do their jobs? Yeah. If we're not asking people to manually create data there's no need to create governance processes for it. That's where IT for IT I think has a lot of value here. You know, we're going to get greater data by making people's jobs easier. I would like to add to that and very much in line with what you're saying is that that's one of the purpose of the service backbone is that everything relates back to that one. And so if you really follow it everything would be available. You don't need to do anything further almost in terms of data stewardship or any log message, any incident, any report or set of data from the development can all be related back to the conceptual service and then you can have fun with creating the reports you want to do but you don't add any overhead to the individuals in the value chain. Next question? Sure. This was originally for coming out in the Microsoft presentation but I think it's more general is that can you elaborate on how best to address the people and mindset shifts you need to make as you transition to this kind of a model? So from a Microsoft perspective, you know, I think it starts with valuing the individuals, the contributions they've made to the organization and the opportunity for them to be a part of the future in where the company is going. Making sure that we tell individuals and we reinforce that they are valuable, they are appreciated. Change is always difficult. When you talk about changing skill sets, asking people to learn new skills, adopt new ways of working, it's uncomfortable. You know, we're moving people out of that comfort zone and asking them to do something new. But I don't think this one's difficult at all. It's basic, appreciate your people and tell them thank you. So given a complex service request demand by a business user, how will ITA for IT assist me in designing a service with, say, you know, five different vendors? Well, the first thing is that within S2P, which is really where such a thing comes in, it's a new service that needs to be introduced, we now actually have the framework for working on the conceptual service that will make up whatever is requested. But everybody in the room here should probably appreciate the fact that you're saying, well, we're not throwing away all the good stuff that goes around Tokav and architecture in general for the business. If it is a very complex thing, you need to have an enterprise architecture worked out for that. But it feeds into the pipeline of then actually executing it. You can split it up into project. You can still track them as being part of the bigger things. But it do lead to that very important thing in IT for IT. And in the industry in general is that you have to design small things that are making dependencies to each other. So one service depends on another service and so on and so forth. It's not just app on top of infrastructure or platform infrastructure. It becomes much more complex with respect to that. But it's the way the industry goes. Any more? Oh, we got lots. Tell me when we're at time too. So what are the most important steps a small to medium size enterprise could take to move to this service broker model that's been advocated in IT for IT? So I think if it's a small to medium enterprise typically they're going to be using multiple systems kind of cobbled together. There won't be any real formality around it. The first thing for them is to get a common place where they can go and request these services. So that catalogue's got to be structured in a way that's easy to use. So I had a funny story. We were looking at how we designed UI and UX for how customers interact with software. And we hired a whole group of people who were 23 or 24 years old to actually build UI. And we were showing one of them a standard service management type of process you'd go through. And he said, it's very complex. And I said, yeah, it is. So how do people learn how to use it? And I said, well, what typically happens is you roll the system out and then you send all your users on a training course. And he said, so he was horrified. He said, so you're allowed to write software that's so bad you have to train people how to use it. I said, yes, I've made a good living for 25 years, didn't I? But to be able to get a catalogue, especially in a smaller business where you've perhaps got a younger workforce, you've perhaps got a more rapid turnover or a potential to expand, it's developing systems where you don't have to train people how to use them, where it's very intuitive, hey, I go onto this, I request something, and then suddenly something pops up, hey, I've got a task I need to do. It's not like they're going in going, well, what does this mean with 300 fields on the form and a couple of tabs to go through? It's making work as simple as possible. That's what's going to drive the adoption of this. But then at a higher level what really drives the adoption is the visibility of the end result that you get from this, having that clarity of information. If you imagine everyone in this room is used to seeing incidents by category. So you can see a percentage of whereabouts you're spending your time or you're on hardware issues doing software upgrades. No other part of the business, especially in this consolidated business model can see that. If you go up to human resources and go give me a breakdown of percentages, how much do you spend on each different type of task? You'll get some tribal knowledge bullpark figures, same for legal, same for finance. Everyone who's been there for a while knows it, but there's no metrics. If you can provide those metrics at a top level that just drives it further and further into the organization. Do you have time for one more, Dave? One more, okay. Which one to choose? Of course people will be able to interact with these folks at the breaks and at our evening reception if I don't get to your question. How does IT for IT help in the situation where a company is trying to eliminate a data center and move to the public cloud? As a broker of services who owns the system integration across those services? In the IT for IT model? I'll take the first crack. Again, it's a classical scenario around saying where can you rationalize your portfolio really, right? So it's do I outsource it? Do I move the infrastructure to the cloud? Do I still maintain the actual application, etc.? You can't make these decisions without having a systems of insight around what you're actually running, how it's been consumed, what business value does it bring? Which goes back to strategy to the portfolio. What conceptual services do you have? How are they currently implemented? How are they running? What is the quality? How many consumers are there on it? If you have that data, it's actually fairly easy to make these decisions. But typically most organizations the exercise is 60 spreadsheets and half a man year, no not a man year, half a calendar year 60 people trying to figure that out really correct, right? And that's again because you don't have a service backbone you don't really have connected information so implementing IT for IT will allow you to make these decisions much easier. Let me add on to that one just a little bit. As we talk about you want to move something to the cloud how can I use IT for IT to help me? We have to remember that this is an area that the industry is evolving we haven't got it all figured out yet. IT for IT is a great starting point for having the conversation with those folks helping you with system integration, your cloud service provider to go through and step through the questions about how does it need to change? What needs to be done differently? What are the things that the consuming IT organization no longer needs to do because the cloud service provider is doing for them? For now we can start by using IT for IT as a checklist. Use it as a starting point for brokering the conversation to say hey have we thought about everything? Over time this will get repeatable it will become a common pattern and we'll just know and we won't need to have that conversation but for now IT for IT is a great reference model to help us have that conversation. Would it not make sense for you as a consumer of cloud services that a consumer is using IT for IT and wouldn't that give you a common denominator by which to pursue some of these benefits? There would certainly be in the future I would hope when we come to tool certification within the open group a cloud provider would also need to be certified to say well if you buy my service I can actually provide you with an incident interface according to the standard so it's easy for you to hand over and forth if there are issues just to take one example right? It always comes down to people, processes and tools and certifying against those. Any more to offer from anyone? Yeah the one thing I can offer is since this standard launched in Edinburgh three months ago I can't tell you how many emails I keep getting from our account teams from customers who are asking us that exact question. Customers are asking the question about IT for IT how does it play with the service provider landscape and how can they use it to drive a conversation with us so the word is getting out and the best thing you can do as a consumer of this stuff as you go work with different service providers ask the question, ask their opinion ask for their thoughts on it. Look great I'm afraid we'll have to leave it there I'd like to thank our panelists we've been joined by Chris Davis Professor of Information Systems Chairman of the Open Group IT for IT Forum Thank you Lars Rosen is a distinguished technologist at Hewlett Packard Enterprise and the Chief Architect of the IT for IT program Ryan Schimmerer is the business and enterprise architect at Microsoft IT and lastly Dave Wright is Chief Strategy Officer at ServiceNow Thank you very much