 He's by Senior Director of I.T. Management Software Portfolio Strategy with Hewlett Packard. He's previously held director level positions in HP Software and Strategic Marks in Portfolio Strategy and Architecture. That sounds like an engineer. He created and led the Cross-Portfolio Customer Advisory Board which significantly helps HP Software drive strategy from outside in. He's been most recently driving the creation of a lean but effective integration architecture and business model to help HP and the I.T. customers transform to the new style of I.T. He's put a huge amount of effort into helping this initiative move forward. He's done a lot of work with us, with the group over the years before we met and is now a great contributor. So please give a big warm welcome to Gail Block. Thank you very much, Ellen. Yeah, I'm still an engineer. Now I'm an HP engineer. I still smell bad though, but to some even more. Okay, so why is HP in the game? You've heard from Hans as a major customer. You've heard from Daniel as a service provider and now I'd like to give you the perspective of a vendor which picks up a couple of the topics that these two were talking about but also another perspective that particularly I in my job over the past 10 years have been struggling with tremendously and that's integration. Jeez, integration is a nightmare for everyone and hopefully some of my fellow competitors in the room share some sympathy with me and I also would like to ask for your forgiveness as customers in the room. We don't do it intentionally. It's just a very difficult problem. I.T. is such a fragmented market not only from a modeling perspective, from a data model perspective, from a technology perspective if you look at the various different products. Even if you just look at the HP portfolio and again other competitors can chime in here because a lot of us have been growing by acquisition. So I mean we've had organic investment in our own portfolio but we saw gaps and opportunities to move to a broader spectrum. Actually always with the intention, yeah, if we integrate these things we actually can get to the 1 plus 1 equals 3 type thing which theoretically you can if you get it right. Now the problem is we got those portfolios. Now we've started to integrate those. Now we get into an architectural problem because all those integrations have been built from customer use cases so they are valuable and right in their own right but now you start transporting the customer use case and the corresponding integrated solution from one customer to another and it doesn't work. Why the hell is that? Well the answer is pretty simple because and please ask yourselves every customer that we've worked with has done something like the reference architecture that I've shown earlier because everyone creates out of need their own information model for IT their own definition of what an incident is, what a service is from a data model perspective dependent also a little bit on the tools they use certainly because deep pragmatic but that's a matter of fact and actually in that when we started the consortium we actually collected the information models from all the various different contributors in here and we looked at them and again they all tried to say the same thing but they tell a different story. It's a different language, a different mentality, different semantics what I already explained earlier and that makes integration very very difficult because that has an impact on the technical requirements how you actually do that it's very very difficult to do integration in a change resilient way if you don't have an underlying mechanism so we build a ton of integration I always get into discussions with customers you don't integrate enough and I always respond actually we do too much if you think about the various different products how many integrations do we have officially in the catalogue which you could order as product and download give me a number no raising hands, give me a number 200 200 who gives me more? 700 that's a little too much we've got 450 actually some of those integration packages are a number of integrations in and of itself because it's different use cases in one bundle actually it's enormous if you think about what manpower you have to put in there not only from a building perspective but also from a maintenance perspective all of those products that are involved in those integrations they change all the time and it's getting more difficult if it's not only our own products but also products from our fellow competitors I mean it's very very difficult because you don't have the heads up so now we've looked at those 450 integrations that we have and we compared it against the reference architecture and said okay which of those are actually really critical and necessary now you can give me a percentage number what do you think? you're cheating you have seen the slides come on that's annoying absolutely right 15% of those which means first of all we can make this integration mess a lot easier if we can focus on the right ones which is also a transformation with our customers because we have to make it very aware to our customers there's certain ways you should construct the value chain like a map on which you say okay this is the right way you move from town A to town D well some use cases today go fairly strange ways and that makes it very difficult second of all the way we do the integrations if we do have an underlying data model not boiling the ocean with every data artifact that is out there but the critical data artifacts that actually keep that chain hold so the backbone the spine you can hack off a leg or an arm or the spine is not good the spine is the important thing if we have that we can make the integrations not only more seamless for the customer but also cheaper for me as a provider because I want to compete with the functional excellence of our products not how we plumb it together so that's one of the reasons why HP is in the game because it makes my life a lot easier if we get the right penetration in the market if we get the right level of adoption and that's why we're so grateful to have the open group drive this forward because we expect a major uptake in the market with driving adoption that's one part of the story so the ugly sewage type thing now getting in the more exciting thing why is HP in the game also from a tab down strategy perspective now you may have heard in marketing presentations not from an engineer like me new style of IT so all the trends that Daniel and Hunso eloquently introduced actually the architecture that we've built so far as a stake in the ground for the open group to move to a normative standard we've taken those trends very much into account for example if we look at the way how an agile world today works so the DevOps side of the house that Daniel was alluding to still we met that against the reference architecture to make very sure that we actually can live up to those requirements and we can't so the service integration side of the house so a lot of those services to deliver IT services at the end of the day they are sourced for the most part today with different business models out sourced hosted out of the cloud whatever but at the end of the day it comes down to that service integration issue absolutely and so we've made sure that the real essential data artifacts that you need in order to do that service integration are in the spine so there went a lot of thinking into that but let me get back to one thing that I mentioned earlier wouldn't it be nice to look at IT and ask those critical questions from an executive top-down perspective again you have to have the spine underneath and if you look at how IT evolved over the last couple of years primarily you can clearly see a move from the workflow process aspects and there's a lot of investment has gone into IT rightfully though now to data and analytics because of the need it's no longer about the doing we can get the doing right in some sense but can we optimize the doing that's the big question because Hans is all about taking cost out where to take it out exactly where does it fall down so you have to have the perspective top-down to say where am I at any given point in the value chain like you do in the business in a supply chain I mean you know very well what is your requirement to move from step A to B with the supplier coming in this good coming here manufacturing, good example, you know that very well IT very difficult to be done so that's what we're after that's where we need to go into the data aspect and combine all of the various different angles so we at HP believe in looking at various different aspects of IT from three different perspectives we look at it from a systems of engagement perspective which is pretty much the traditional way the workflow, user interfaces, the doing of it implementing all of the various different steps which leads us to let's say something like a tool chain now the tool chain can be improved but it may more efficient if you have a system of record underneath like this spine that I was talking about that is whole in nature but now putting the two aspects together on top with a system of insight not as a separate thing but as a leveraged activity so the system of record can actually bring quality IT data and that's what we're lacking today in quality of IT data it's not that we don't create good data in the first place but it's getting bad through the doing very very very quickly that's why we have to bring the system of record and the system of engagement together to then build the system of insight in top to drive the right decisions that's what we're really after at HP from a strategic perspective here so as Alan mentioned we've been in this game for a number of years now which hopefully gives us a little bit of a head start so we translated the work that has been done in the consortium and now in the IT for IT forum into an HP reference architecture that really caters for that new style of IT and we've been working with a good number of customers over the past two years to actually test out this architecture and it has proven to be really really good and I really compare it to a map so you can pinpoint very very quickly in the discussion with any customer where the current problem is pinpoint there and then go from there and you can very easily construct a road map from that first problem the most critical one to a value oriented delivery of IT down the road that's how we use it to drive transformation and road mapping with our customers that's the external side of the house there's also an internal side of the house outside in we use the reference architecture actually to drive adoption with our products and drive the underlying systems of record with our products into the right direction so that we are compliant with that spine which again heckles the integration issue that I alluded to earlier furthermore we've taken the reference architecture and actually tried to make it real so we did reference implementations for all of the various different value streams with our products also with other components out there in the market be it open source or things that are prevalent in the market which first of all gives us implementation guidance so we've written up some of those best practices and provided to our customers that's how you should do it that way it actually does work but it also obviously gives us a gap analysis because we're not compliant everywhere so we have to look at and be honest with ourselves I mean where don't we meet the requirements of the reference architecture which in turn creates requirements for our products in the adoption so that's how we go about it at HP and I hope this has given you an insight into why we are here not just for the fun of it even though it is but there's real business reasons for us to be part of the game and we are very excited to work together now with a broader group to make this real in the market and really drive to a better world okay thank you very much what I'd like to do now is to step briefly of sequence to enable Georg to step up and explain the relationship between our use of Michael Porter's value chain concepts and the reference architecture that we have in IT for IT thanks Georg thank you I certainly will so first introduction the reason I'm explaining that is I'm an engineer so by definition of Magnus I'm ugly even though I'm disguised as a salesperson as you can see I will say strange things very definitely I'm incredibly intelligent so you should seek for looking for ideas in this presentation okay now first after Chris introduced the why we did this I want to spend a couple minutes to talk about what it is and again back to Magnus who really inspired me this morning to change my complete script what we didn't do was R&D in this case we actually copied a concept that also Chris already introduced from Porter the business value chain well I actually call it steal it but I don't have to be completely Magnus compliant I think so what we did was in order to tackle the problem that Chris introduced we needed to scope the problem because you immediately can get into boiling the ocean because IT can be vastly expansive and capturing lots of problems that we actually do not want to tackle but we really want to tackle the delivery of IT services to make it better, faster, cheaper, less risk that's essentially what we were doing so we were looking at the scoping of how should that look like what's the taxonomy of IT that actually explains that now as a matter of fact if you ask any customer out there or any vendor out there no matter if everyone has a taxonomy it seemingly tries to say the same thing but it does do it differently there's a different language there's a different mentality there's a different semantics implied so now we should we invent another one or should we just take a proven concept like the business chain and try to scope IT with that that's exactly what we did but the IT value chain per se is a best to end thing so we still have to break it down to make it graspable for people so what we introduced was the concept of value streams for value streams in particular that describe the problem that we're trying to solve a value stream is defined as a set of tasks that are dependent on each other that add value meaning the kind of it is if the tasks are 1, 2, 3, 4, 5 then the result is not 5 but it's greater than 5 because there's a leverage effect to do it exactly in that sequence with that handshake between the various different steps and the context on which they are executed that's what a value chain is the four value streams are strategy to portfolio so you've got a strategic context a financial context you understand what the business demand is you understand how your service delivery is today what your portfolio is today and from that you distill with what you have and what you can do a set of priorities for the next planning period that's strategy to portfolio at the end of the day you have your priorities the next phase is to help new stuff to actually get to the new portfolio at the set of priorities you decided that's all of that requirement to deploy then you have to make it available to your businesses, to your end users which is request to fulfill not only the catalog aspect of it but the whole fulfillment process with all the financial and costing and usage boundary conditions around it and the final thing is when now the stuff has been requested and fulfilled in the production environment we have the detector correct you want to keep it up and running you want to keep it up and running at the agreed upon metrics that all go all the way back to strategy to portfolio so as you can see to make good decisions in the first place in strategy to portfolio you have to have understanding of what's going on downstream in the other processes and vice versa if you do troubleshoot at the end of the value chain what was the driver in the first place how it was built with which types of requirements and how it was ultimately launched into production so that is the value chain and that is what we want to do we believe that actually really every customer and we talked to about 60, 70 customers over the past two years I mean all over the enterprise and we always found that we were solving the same problem over and over and over again every customer tries to solve that problem or a portion of that problem and tries to get stuff as a solution implemented and everyone does it differently so why can't we find a more standard way and save the market a ton of money now that we understood what we want to do we thought about how do we need to do it and that's where Magnus starts to dramatize I mean this vertical change type of thing imagine if you would ask an IT person from 10 different companies for a definition and a model of a simple thing like incidents and you would get one answer it would not be nice today you get at least 10 sometimes you get a novel back with a couple of alternatives wouldn't it be nice if you take tools from different vendors hopefully also from HP put them together in a value chain approach and it actually works dramatizing so at the end of the day going back to Magnus again the real problem that we're trying to solve is to decrease murder even further because a lot of IT executive heads on the chopping plaque and we really want to avoid that that's the real reason why we do now we get into the reference architecture which really does prescribe how this value chain actually should work under the cover focusing on the data side of it and I want to make that point very distinctly because and you will hear a lot more about this in the track sessions this afternoon where we talk about positioning and what is the delineation between what we do and what ITIL is doing we really embrace and not R&D we embrace standards that are out there or de facto standards in regard to all of the different process definitions that have been done in ITIL in ISO and COVID you name it so we embrace that so we look at those landscapes and be sure that our reference architecture actually works with these standards and is in the same notion we even include some standards like for example Posca which primarily works down in the reference to request to fulfill workspace that's an existing thing that we do include in our work so we really leverage and we get boring on that so we really focus on the data side of it and now another dramatization wouldn't it be nice if an IT executive could come to IT and ask critical questions that an IT executive wants to ask wanting to understand where the IT is as a business how profitable quoting quote from an RRI perspective is my portfolio what is my security exposure with the various different services that we have how did the number of tickets degrees or increase over time in a highly multi-supplier environment try to answer those questions today without having a consistent set of data that actually leverages each other and is built as a whole that's exactly what we try to do with the reference architecture and you will hear a lot more about this how and the intricacies when you listen to the track session in this afternoon in which we have is my room still there a Scandinavian chief occupant so we can't really fail can we