 So, as if you didn't recognise him, Hans van Kesteren, VP and CIO Global Functions for Shell, Daniel Benton, Global Managing Director of IT at Accenture, Georg, Senior Director of Portfolio Strategy at HP Software, and first and foremost, Chris Davis, the chair of the forum. So, Chris is going to start. So, I'm going to introduce Chris very briefly. As I said, Chris is the current chair of the Open Group IT for IT Forum. He's a member of the faculty, tenured at the University of South Florida. Well, thank you very much. It's a great honour and pleasure to be here. The linkage from the futurology is about creativity, and my role simply today is to explain who we are, what the problem we've been addressing, and the great work that we have been able to put together with the folks in the room over the last two years. So, the problem which I've looked at for a time, a lack of cooperation across all of IT leads to what systems thinkers call sub-optimality. Much research on software failure talks about not so much catastrophic failure, but how software systems disappoint. I think the sense of disappointment many of you have understood. Secondly, insufficiently integrated IT management lacks prescriptive guidance. So, the group came together when they realised that they were all trying to solve what seemed to be a very, very similar problem. They were each trying to be creative in a side-o. They quickly realised that there was an opportunity here to demonstrate some creativity. The other aspect of this, critical to the success of business, was the inability to gain true insight in order to make good decisions. So, some empirical research, you know, the scientist in me as a university person these days, that rang true too. And then finally, immaturity in this ever turbulent and ever innovating world makes it virtually impossible to tack complexities like cloud, agility, mobility, bring your own device and all of the other, what are now called disruptive innovations. So, Clayton Christensen, another man with a Scandinavian-sounding name who is in fact another Harvard guy like Michael Porter, came out with this idea. We are confronting it in the IT for IT forum. So, this is the dynamic problem that we've tried to address. IT for IT is an evolving open group standard. Today is the launch. IT for IT provides a reference architecture for managing the business of IT, IT management in the broadest sense, enabling insight and also with an emphasis on evolution and continuous improvement. It's our hope and indeed aim that in this way, the new standard will enable IT execution across the entire value chain in a better, faster, cheaper way and with less risk. The open groups IT for IT forum is fundamentally vendor-neutral, technology agnostic so that we can be responsive and agile and industry agnostic. So, we can be vertically and horizontally innovative. That is the broad goal. At the moment, we are made up of two groups, if you will. The original founding members of the IT for IT consortium, representatives of whom are in this room with us. So, as the morning progresses, it will be my pleasure with Alan Brown to introduce you to some of the founding fathers, if you will, from the original consortium. Colleagues at Shell, Hewlett Packard, the Dutch insurance business acmea, Munich Ray, who I don't think we have a representative from here today, Accenture, PricewaterhouseCoopers and AT&T, all contributed, if you will, the initial stimulus for this. And today, we are growing rapidly. I'm thrilled to announce that we now have members in the open group IT for IT forum that include Capgemini, BP, logic Carlos, Umbrio. I think we have two representatives from Umbrio who welcome. It's nice to see you face to face, who unfortunately aren't able to stay for the whole week. ATOS, IBM, architecting the enterprise and Microsoft. The work of the original consortium began back in 1911. It was stimulated by a conversation among major customers of one of the vendors. And through the first year, we rapidly moved to, or they I should say, rapidly moved to the development of a reference architecture-based addressing of this problem. So in August 2012, the early phases of the reference architecture, the very early versions were created. Through 2012 and 2013, we moved to the first substantial release. And as you can see, also we moved through a number of levels. So the architectural emphasis of this, so I'm struggling here to make a pun on the challenge of architecting and gardening the enterprise, but I'll let that go. We have a strong architectural emphasis. This makes sense to an awful lot of existing forums in the open group, not least because we've been careful to pay attention to what Togeth and the Archimake forums already do. So we have a multi-level structure to the enterprise architecture. And you can see on the timeline at the bottom that that's evolved to the point that we're at today. October 2014, when we fully publicly launched this forum, we have a substantial but still rapidly evolving enterprise architecture for the business of IT. What I'd like to do now is to step briefly out 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, a very quick 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 wanna 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 like. 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 or any service provider out there for that matter, 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 vast end-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. Four 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 bottom line of it is if the tasks are one, two, three, four, five, then the result is not five, but it's greater than five 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, you've got 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 the set of priorities for the next planning period, that strategy to portfolio. At the end of the day, you have your priorities. The next phase is you either need to change stuff or you have to build 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 requests 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 has been fulfilled in the production environment, we have the detector correct. You wanna keep it up and running. You wanna 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, it awfully helps if you understand 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're 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 wanna do, we thought about how do we need to do it? And that's where Magnus starts to dramatize, right? 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 block and we really wanna avoid that. That's the real reason why we do it. 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 wanna 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 that are out there with regard to all of the different process definitions that have been done in ITIL and 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, TASCA 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 to worry about it. 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 name still there? A Scandinavian chief architect. So we can't really try it, can we? Wonderful. Okay, don't. In this, I would like to hand it over to Ellen to introduce Hans. Thank you. Well done. Thank you. So yeah, I'd like to introduce Hans and interesting story. I worked for another Anglo-Dutch company, Unilever for many years, and a great company. Last weekend, I had the pleasure of a London Business School alumni reunion and one of the husbands of one of my co-student alumnus won the 800 meters in Mexico gold medal in 1968, 88, something like that. And he was employed by Shell at the time and they gave him the time and gave him a lot of support at the time. Great company to work for. Anyway, Hans is the VP and CIO of the Global Functions of Shell International. He joined Shell in 1979 into the IT function and found that not exciting enough so moved into accounting and finance. But now it's exciting again, so he's back. And he came back into the IT function to head up the Global Functions at the time that the IT for IT idea was born. So before Shell, he worked for the, spent time with UN in Swaziland and Italy. With Shell, he's been in the exploration, production and chemical areas in places like Brunei, obviously, Rotterdam, which is the head office, yeah. Aberdeen, we will know about North Sea Oil. And Gabon, yeah. So very widely traveled, very experienced executive, many years in Shell. Please give a big warm open group welcome, Hans van Kesteren. So hopefully you've got the little green signs in your head. One thing I like to reflect on is something not working. You dropped it. Oh, I dropped it. Fortunately, I've got a loud voice. Yes, you're doing well. There you go, sir. I was recently in San Francisco for a week where we visited a number of our suppliers. And in the weekend, I was driven by a chauffeur to Napa Valley, which I can really recommend. Very good wine. And the chauffeur driver was actually during the trip, resetting his navigator. And I had some very sort of scary moments. So a plea to you is if you have a navigator in the car, do not fiddle with it when you're driving. It seems trivial, but you could get yourself in the bear a bad car crash. The second thought I want to share with you before I get into the sort of meat of my presentation, I was linking in with, I guess, what we heard from Magnus and thought, well, I'm going to tell him, let's talk about not really about competition, and I'll say a few words about that. It's also not really about creative, although you could argue we did quite a bit of work in preparing for this launch to date. But it sits sort of in the middle because if you can't get your fundamentals working well, you can't liberate resources to do the real stuff which will give you a competitive ad or move up vertically. The other thing I was really delighted to hear, I was thinking about myself, well, I'm very close to retirement. It's very, very easy to step out of the company, actually do some interesting stuff. So perhaps a few light bulbs and for me to start my own business. I've also had the privilege of being in this business for about 40 years. I still remember the first computer I worked on was in 75. It was a cyber from the CDC company. It was half a megabyte memory. So it looked a bit like the five megabyte drive you saw early on the picture. We had an immense big hole air conditioned and that's where this big machine sat. So needless to say that I have seen an enormous change and I've talked to younger people today. I say change is not something of the last five years. It's been with us for the last 40 years and that makes it a very exciting to work in. In my capacity as Global Functions CIO, I look after 20 functions in Shell. They're all globally organized and IT actually is one of them and it's the largest. And so when I joined or went into my role, I quite quickly bumped into Carl von Zeeland, our lead architect and he had this vision and said to me basically Hans, can you support it? Because I think we've got a great gap to fill here and he had a very convincing story and so since 2011, I've had the privilege to support him and the early work on this. And I'm personally very excited about that. We are now at the stage that we can launch a forum because my belief is that we need more parties to contribute to what I think going to be essentially a very important bit of standardization work we need to have and I'll come back to that earlier on. Or later on, sorry. We didn't quite start in 1911, by the way, it was 2011, Chris. Oh, I understand. Sorry, but it did take some incubation time to get where we are. A full century, nothing. Good. I will give a bit of context, I'll tell you a bit about Shell and IT in Shell to I guess make the business case for us a bit alive. So bear with me, I'll take a few minutes to talk about Shell. And in case you would decide to are to sell or buy Shell stock after my story, you're on your own. That's what it basically says. It's a wafer. I will not give you the time to read it, but believe me, we need to put this in. So what is Shell? I hope the technology will work. It does. Shell is effectively it's got two parts, an upstream and a downstream part. For those who are not familiar to the old company, it starts with looking for oil and gas, developing it, exploiting it, and then it goes into the downstream world where we're talking about transition, transport, and bringing it to the market. Simple picture, quite complex business, if you think about the fact that we drill wells in two to three thousand depth of sea. We put big installations in place in Sakhalin, in Siberia, and I'll talk about some of our innovations later on. So that's Shell and not Shell. It is truly a global organization, as you all will know. We employ about 87,000 people. Actually, all our payrolls, if we would actually count all the people who actually work for us, we're probably more than a million. And we have a tradition of working through many suppliers and we'll continue to do so. That's also the case in IT, by the way. Two-thirds of our labor force are from suppliers, probably even a bit larger. I would like to focus on the 1.3 billion we spent on R&D. We believe we only have a competitive place if we can actually keep innovating in the area where we're already working. And we have got a pretty decent track record. If you think about, we were the first to do LNG, any big way. LNG is about liquefaction of gas, then transporting it to the market. We were the first to do deep water drilling, and so we went into the Mexican Gulf as one of the first players. And recently, we've gone live with a big GTL plant, which is converting gas into liquids. Again, at first, that's only possible if we actually invest significant dollars. IT plays a quite a specific role in there, and we have actually got a separate department doing innovation work. So they're not hindered by the rest of the organization as it were. That's a bit, by the way, which is intellectual property. We will not put in any kind of standard. That's where we want to compete. But the lion's share of our IT business is non-competitive and just good table stakes. The last thing I want to say about these statistics is 3.3 million bells of equivalent per day. Half of that actually is gas these days. It's probably around 3% or 4% of oil production, so it's not that big, but still significant in size. Some people think of us as the sunset industry, and here's a clear link with, I think, Magnus, is if you just look at some of the statistics presented here, in 2050, we'll have 2 billion extra people on the globe. We will have probably twice the number of vehicles. A lot of people are not using energy these days or not substantially. We'll move into the next stage as well. So that will mean that we will double energy consumption in this span of period. We will have to, in the meantime, half our COT emissions to keep the environment sober or clean, and we will have to become twice as efficient. Of course, renewables will play a place, and God knows what else. Think about a little bacteria, but hydrocarbons will take a significant share of that if you just look at the extrapolating our demand. So we're very much, I think, a crucial player in a sector which is going to be very important for the future of the world economy. There's no doubt about it, and quite a big challenge which will require a lot of out-of-the-box thinking. So how does IT for us sit in Shell? Probably, again, a few statistics. Needless to say that IT for IT in Shell is business in its own right. We spend about $4.7 billion a year on IT. And you can see from these statistics how sizeable the landscape and applications we look after. And the story behind all of these data, I just want to give you a sense of how important IT for IT is for Shell because it's significant amount of money. And of course, we have a reliant as well. Just to pick up one figure, we have 8,000 applications. 500 of them are business critical, which means that they're out of business for more than four hours. Something stops. And so there's obviously a lot of attention to make sure that we start up within a few hours when we actually have a problem. I think the 20,000 virus attacks per day is also interesting, statistic, just to highlight the challenge we have in that space. And it's not only virus attacks per subject to. So, again, I think an interesting statistic. So what does this response... What are the key challenges in this world? And just pay your attention to the picture in the background, which is the sprawling city of Mexico and probably an example of what happens if you lose control of your asset base. And that's why I've chosen that background. Look at the key challenges, increasing demand and growing asset base. We run about 1,000 projects per year. You imagine every project potentially adds infrastructure, adds middleware, adds licenses. So that by itself is a big challenge. Rapidly advancing technology. You've heard a lot of this disruptive technology, which is a word I'm not allowed to use anymore since I've listened to Marcus this morning. Anyway, you're a cloud, services, mobility, consumerization, things of internet. Think about the in-memory computing. There's so much happening at the moment. So the landscape is changing dramatically. Increasing number of players. If you look at the number of suppliers we were working with 10 years ago, we actually, our core system has got 12 suppliers. We see that rapidly expanding to all sorts of people have also got a value proposition for the company. And the business has become increasingly dependent on our services. So I already mentioned the example of the 500 business critical systems. I don't have to say much about increasing risk, including cyber crime. You can read about that every day in the week. Business requires rapid deployment. It's interesting that we have increasingly IT-aware community in the company, who basically demand that we respond to the IT function quickly. Otherwise, they'll go out and buy their own solution. And that's the beginning of a disaster thinking about the sprawling city. Actually, we have quite a number of business-managed applications. And obviously, we're paying a lot of attention to that. And then probably last but certainly least, the increasing cost pressure. Under this growth, we see a huge growth or significant growth of our base cost. We've taken a lot of costs out over the last 10 years, but in spite there of the base cost rise, actually overwhelms that. And as the company is not prepared to spend more than a particular limit, it starts crowding out our investments. So we need to think about the clever way of bending the base cost curve and making sure that we continue to invest as well. This points at a huge integration problem. That's the way I would say it. And I think GeoGurria has given a very elegant example of the connects you have to make in this world. It's interesting that ironically, I would almost say that we've invested in big ERP platforms for our business with a full integration proposition. However, for IT, we have not put any solution in place. So we're still working with spreadsheets and all sorts of loosely connected applications, struggling to make sense of the end-to-end lifecycle of our IT products and services. Shell's IT strategy, very simple terms, has three bands. One is about delivering business outcomes. The three pillars in that, the technology bit, which is very much the property stuff where we really want to make a difference and think about processing of seismic data, et cetera. Of course, we want to deliver our projects successfully and we want to drive value with our existing platforms. And of course, it's a lot about data and processing and analytics and so on. At the end of the road, the fundamentals are all around making sure we have reliable and secure systems and you should actually probably add affordable to that as well. And then we cannot do that without people, partners, and the community. We have, as I said, already 12 ecosystem partners and I see this as a community as well, which will be complementary to what it is we're trying to do. All in all, I would say that we're taking much more of a portfolio approach than we have had in the past. We used to look at investments and then looking after them when they sort of matured. We're now looking at our portfolios per function and per business to make sure that we see the cost of value and the risks looked after properly, which means that we make a new investment. We also need to take stuff out, otherwise we can't manage our base cost. So that brings me to my last and probably most important slide is what's the case for action in terms of launching this IT for IT forum. And I always think that pictures tell a lot about where it is we want to go. If you think about the sprawling city, that's not where we want to be because that's uncontrollable. We want to get to a neatly organized town in which we have full control. Think about overall cost, value, proposition, also security. So we fundamentally believe that most of the work we're doing in IT doesn't give us a comparative edge and so it makes a sense to share what we are doing in this space with other companies. And so we have started on that journey in 2011. We believe that if you look at a little red diagram, it actually describes in simpler terms what a management system would look like through the full life cycle. It's going to be adamant that we have the full visibility of cost and for those who've been involved in creating that in our business, you know how difficult it is. Probably even importantly, maybe even more importantly, we need to know what value effective your applications deliver and then we've got also this performance, reliability and security challenge. So creating a management system around this, we believe, will be a great value proposition, not only for us, but for many in the room and we're very pleased to see a number of parties already voting with their feet. So in summary, standards will help us mature our industry and deal with the new challenges which I've described to you. It will create a common language so we can share best practices. It will further advance our professionalism and of course ultimately, and somebody was asking me to how long will that take, we will have a common platform. So if we have the service provided or we buy a bit of software, it all fits in what we already have. So we don't have to worry about integrating it all. Now that's probably a vision which will be five or 10 years ahead. But I think the benefits of getting into this open dialogue, I see it will be quite immediate. And so I'm really looking forward entering the dialogue with yourselves and really invite you to participate in this forum because I cannot see how you can do with that, and frankly, or you could keep trying to find your own solutions, but I suggest that getting into this arena together with other companies that would be of great benefit to your companies as well. So thank you for that. Well done, thank you. So yeah, Shell has a long history with the open group of being a leader from the customer side, right through from the early XBG days, the Unix days through enterprise architecture, Tegaf and so on. So very, very strong supporter and an organization that leads from the front. And I'm very pleased to have you driving some of this as well. So we're now going to move to Accenture. And I'm going to introduce Daniel Benton who's Global Managing Director of IT Strategy with Accenture, which covers the IT strategy and the IT transformation areas for organizations, helping them to improve their performance. He's also a leading thinker around the CIO agenda and sponsors the Accenture High Performance IT Research Program, and driving much of their thinking around digital business. He's architected and driven transformation programs in the IT function of several major organizations in Europe and the US, and actually advised it to many clients around IT strategy and governance. So please give a big warm-up and group welcome to Daniel Benton. There we go, that's me, they've got the right person. So I'm responsible for three things in Accenture. There's IT strategy, which all around business and IT alignment, enterprise architecture and the practice we have there, and what we call IT transformations, and as just mentioned, we manage those three things together, because clearly one's about setting the direction for technology within a business, the next one's about actually what underlying blueprint you need, and the third one is about how do you get the IT organization then actually fit to execute that? What set of capabilities do you need? All three of those are actually causing complexity at the moment. There are trends going on within each of them that are making life just more complicated. So if you're a CIO at the moment or if you're running a technology company, no big news, things are getting more complicated. And we're seeing, as Gail has said, a consistent set of issues and questions coming out of most of the clients that we talk to at the moment about how do they cope with this world, and that's why we're delighted to be part of this consortium and why we think it's really important. So let me drill into those three areas a little. Obviously we don't believe in digital, having heard Magnus. Unfortunately, most of our clients and most of the business that we talk to do. And you can talk about smack convergence, how to apply social mobile analysts and clouds to business processes, how to create new business. But for me actually, that's not the important convergence in digital. For me, the really important convergence is this complete convergence between the business and the technology agendas. So life used to be easy. There were some business people, some of them worked out what they wanted to do. And if you were a CIO, you then worked out, well, how much money did you have to spend? What did you need to spend it on? And you develop an IT strategy. And IT was very much an enabler to a business strategy. What we see now is that technology is increasingly actually becoming the business strategy. And in a digital world, it's less about, this is what I want to do, what technology do I need? It's about if I had this technology, how could I create value out of it? And that's driving a very different relationship. And in this intersect between business and technology strategy, we see the emergence of all sorts of new beasts, called the chief digital officers or whatever. Actually, that should be the job of corporate IT. That should be the job of the CIO. Because if you're not driving that agenda, someone else is, you're just being the service delivery organization. So there's an open door there. And businesses are looking for technology to come and create value, to come up with new innovation to work very closely with them. And from our own point of view, beginning of this calendar year, we actually joined our business and technology strategy organizations together. Because increasingly we realized we were having exactly the same discussions with exactly the same people and exactly the same clients. It's become the same agenda. I'll mention that I run something which we rather grandly call our high performance IT research. We run this every couple of years or so and we talk to a couple of hundred CIOs around the world and find out what's on their mind. And we measure the performance, actually a self-assessment thing against 150 different measures of the way you could measure an IT organization and its performance. And what we discovered when we did this last time is that there are three things that the people who get it right seem to be getting right consistently. You see here the perils slightly of moving a four by three slides to a 16 by nine screen, but there you go. Three things they get right together. Innovation, agility and execution. Now, IT execution is just can I deliver reliable IT on time, on budget in a way that works to support the business. That's if you like the table stakes. But as I'll show you that's actually getting considerably more complicated at the moment. Innovation is really about that, owning the debate with the business, helping the business to co-create strategy, new ideas for creating value with the business. And some people are very good at that. Other people are less good, but in many cases, not because they don't want to, it's because they can't. And that's where agility comes in as well. Agility is really to say, the pace is moving faster than ever before. And in too many cases, IT gets in the way. So how can you respond to a very rapidly changing business environment? How can you run IT differently so that you can be really agile? And the problem that nearly every corporate IT organization has is it's a bit like the Irishman, who when he was asked for directions to the next town, replied, well, I wouldn't start from here. And that's the problem that everyone's got. It's legacy. And it's not legacy just in terms of the architecture, it's legacy in terms of the processes, in terms of the organization, in terms of the people, the skills that you have, the relationship with the business, et cetera. And the people who are actually performing better and able to drive the debate with the business seem to have solved agility, particularly to start with. And particularly, they are earlier adopters of new technology. They managed to keep on investing when other people weren't. And where they are is they're further on this journey. Everyone now is trying to deal with a hybrid, a hybrid of on-premise legacy, private cloud, public cloud. Let me draw that more simply. On the left-hand side here, you can see this thing which looks a little bit like an alien with two ears. IT in the middle, largely still within the firewall. People are trying with some external stuff in the cloud there, either from an infrastructure point of view or they're trying to use Salesforce or some early SaaS. Everyone is an inexorable journey from the left to the right, moving at different paces, depending on which industry they're in, depending on where they started from and where their legacy is, depends on their appetite for risk. But we're moving from somewhere where I used to control my IT, it was within my firewall and I knew where it was. To somewhere where I will still have some stuff within my firewall, I will still always own things, but increasingly, I'm going to be sourcing services from outside. Even worse, the services that I'm sourcing from outside source their own services from somewhere else as well. So we have the emergence of service aggregators, cloud service brokers, et cetera. That can be fantastic in terms of solving your agility problem if you can get it right. But it adds huge complexity. Somehow you've got to manage all of that. Somehow you've got to join it all up. So if you're going to get the agility that the business needs, problem, you've actually got a much more complicated architecture than you have before and you've got to find a way to manage that. Similarly, from an organizational point of view, if I stick my IT transformation hat on, this picture will be extremely familiar to you by the end of the day. It's the value chain that you all put up. The way that people run IT is changing significantly. If we look at the planning end of things, so we said the whole strategy process is changing. It's not about just receiving a set of requirements and working at how to spend the money. It's actually co-creating strategy with the business now. Then all of that as well. Actually, there are a huge number of ideas out there. If everyone is now multi-sourced, if there are lots of new startups out there all with good ideas, how do I plug into those as part of the, as part of the strategy process? How do I know what good looks like? How do I then take that into the business value creation discussion? So the planning process, the strategy process is changing, but not as much as the delivery process. Now, we all come from a world where pretty much every IT organization that I have ever come across has people who build things and people who run things and they're very different beasts and they don't talk to each other enough and so on. Actually, increasingly, the distinction between those two is blurring considerably. And if you look at things like DevOps and so on, or if you look at what we're calling two-speed IT, there are very different ways now of delivering things. So what I mean by two-speed IT is the fact, you know, it's traditional waterfall, but there's also now as well. When we talk about agile, I don't just mean agile, the methodology. I mean the sort of set of digital people that come along with their skinny jeans and strange haircuts who sort of do a different sort of IT at a very different sort of pace. And every CIO has to work at how to manage the two of these together because different models for different sorts of projects are actually required. I've talked about incubation and prototyping. The idea that you could come up with a set of requirements and then work out how to spend a large amount of money on it has changed. You need to actually pilot things. You need to start to innovate. You need to incubate stuff, prototype, work out whether it works, iterate as necessary before you work out when to suspend the big money. And actually knowing within all of that, when you've got something that's going to work and when you can start to commit big spend, becomes a really different way of thinking about your whole investment portfolio. On the delivery side, as we've seen from that model on the previous page, it's not so much about, I've got my own stuff and I need to run it. It's now all about service integration. It's how do I run other people's stuff? How do I join it all together? The whole area of resourcing is very different. So the whole operating model has changed, if you like, from one where years ago, I actually had a set of people who built and operated my own IP and I own the people to one where I started to be multi-tourced, to one where I then started to use other people's software and other people's IP. So all of a sudden I had an IT organization which was really trying to use other people's stuff with other people's people. I then virtualized the whole thing through cloud and I've now got this very complex architecture that I see on the other side. So actually working out how to source that, how to integrate it all and how to manage it all together is a real problem for people. How do I get transparency of that for the business as well? Hans mentioned now the business is more enabled than ever before to go and get its own services. Actually, I need to behave as though I'm Amazon or Salesforce. I need to be able to get great transparency to pricing, understand how to manage all of that and understand what I'm paying for from my suppliers as well and work out how I can provide those services to the business and the transparency of the costing underpinning that. Another area here, we've talked about security. It's not just about cyber. It's the fact that again, if I don't own my architecture and I don't own my people anymore and I probably don't own my customers because they're talking to each other, okay? Not just to me anymore, thanks to social. Understanding the whole security profile of what I've got in that very complicated architecture in that complex operating model as well becomes really critical. It's the thing I lose my job for if I'm a CIO. But increasingly, it's not about having the perfect firewall around something with 17 lots on the front door. It's about understanding what business risk I'm taking, understanding what I do when risk happens because it's bound to at some point and particularly understanding across that extremely complicated ecosystem I've now got where are all the risks? So it's no surprise in a world that is complicated from an architecture point of view where you're changing the whole relationship between business and technology and where you're changing the entire operating model of IT that we see lots of tools popping up all over the place to help people manage this complexity. But the problem we find therefore is that you've actually somehow got to get control of all of this whilst actually still giving the agility of the business once it's not acceptable to go and say, sorry, you can't do that. And the business is saying, I can just go and source this. I can buy this with my credit card. You've got to find a way to be responsive, to manage that ability, to take advantage of those architecture and operating model trends whilst retaining control. And that's where IT for IT starts to come in. You need to be predictable and measured. You need to be controlled. You've got to be able to enable these various different styles of IT as well. I was talking to one of the very large banks recently and they've been trying to move their entire model, their multi-billion dollar change budget to the new style of IT. That's not the right thing for them to do. That's the right thing probably for about half of their portfolio, probably less than that. They've got to carry on delivering the legacy it's got to work. So managing several styles of IT together, it's not two-speed IT, it's multi-speed IT. Different ways of working, but still join them up into recognizable, into an IT function that works where you understand the risk. And what we find is although there are tools all over the place, historically those have tended to happen in silos. The silos themselves are changing. Those tools don't join up well enough together. But you've got a remarkably complex management problem here. So we're hugely supportive of what's going on in the forum here because actually we just see that this is only going to get more and more complicated. And if we can join this together, that's useful for everyone. It's useful for people like Hans. It's useful for all the clients that we work for. So with that in terms of how it's going to work, I'll hand that to Gail. APPLAUSE Great, thank you. So yeah, now we're going to look at the HP, why is HP in the game? And you've seen Gail very briefly. I'll just run through his bio. Senior Director of IT Management Software Portfolio Strategy with Healy Packard. He's previously held director-level positions in HP software and strategic marketing 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 IT customers transform to the new style of IT. He's put a huge amount of effort into helping this initiative move forward. Done a lot of work with us, with the group, over the years before we met. And he's now a great contributor. So please give a big warm-up group 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, to some even more. OK, 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 Avenda, 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. 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. IT 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 in 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 a 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 it'd be 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 and to change resilience. Why? If you don't have an underlying mechanism. So we build a ton of integration. I always get into discussions with customers that 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 catalog which you could order as products and download? Give me a number. No raising hands. Give me a number. Huh? 200. Who gives me more? 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, but let's face it, 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, right? 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 that there's certain ways you should construct the value chain, right? Like a map on which you say, okay, this is the right way you move from town A to town B. 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 boarding 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. So 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 tabdown 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 Hun so 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, outsourced, hosted, out of the cloud, whatever. I mean, 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, probably manufacturing. Good example. You know that very well. And IT very difficult to be done. So that's what we were 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. So the workflow, user interfaces, doing of it, implementing all of the various different steps, which leads us to, let's say something like a tool chain, right? Now the tool chain can be improved, made more efficient if you have a system of record underneath, like the 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, integrity and 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, I mean 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 big number of customers over the past two years to actually test out this architecture and it has proven to be a really, really good and a really compared 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 roadmap from that first problem, the most critical one to a value oriented delivery of IT down the route. 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, tackles 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. Thank you very much. Thank you. Can I invite our speakers back on the stage, please? Yeah, we'll do that later. If we can get everyone back, we've got a microphone here, we can share. That's what I'll take. You can have the comfy seats. So, Dave Lounsbury, CTO, has got a few questions for you. So, somebody writes, okay, I'm sold. So, but how do I get this in my shop? You know, do I look for trained people? Will we get bids from cloud providers something else, you know, tool chains? How do you see this manifesting itself in the IT marketplace? Well, I think we're a bit early for that, aren't we? The first thing to do is to get involved. Absolutely. Where we are at this moment is clear possibility. These guys have identified the opportunity. I've tried to explain to you the momentum. The open group now holds all of the collateral. What we need now is help to fully berth what we've husbanded over the last two or three years and create through the open groups ecosystem a way of moving this forward. So, what we're looking for is increasing the momentum so that we can actually bring this fully to fruition. So, the key point is that it's not as fully baked as it might look. There's a lot of work to do and obviously the value of being engaged in the process, being involved, being able to influence it is still very, very strong. As I mentioned earlier, I do have my mic. Okay. Working. The work we've done so far, I guess proves the point and we've got a lot of guidance material. We now would like to get into the phase of normative standardization which then drives product adoption when we ultimately get to the value. But even today, just using the guidance of the reference architecture as this kind of map that I was talking about earlier is value in and of itself. At least I can assure you from various different customers who've improved their way of looking at the value chain and having the various different functions working with each other already tremendously without even any product type thing in the game. So there's actually already quite some value in there but ultimately, yes, we need to drive adoption in the market. That's what the next steps is all about. We'll have to give our look at the roadmap for our IT for IT solutions and pros and data interventions. We are already guided by this architecture so we don't have ready solutions yet but it helps us think through what the logical order is of replacements of our applications, what kind of database we need to create and also start working on across the sources of data in that context. So it already provides handrails. Obviously it doesn't really produce a finite or finalized product but it does a lot already for you. I think with quite immediate payoff. I think people, the reason we're here today launching this with the Open Group is because we see this as a pervasive issue. It's one that we've all been working on individually as well as together and this is about the world is getting continually more complex. Actually the more people that we can plug into that both from the software point of view, the service provider point of view but also from the end user point of view as well. Actually hopefully we can turn this into a standard because life's only going to get more complicated. There'll be more things popping up all over the place and if we can find a way to integrate those around a common taxonomy, around a common data model, hopefully we're in a plug and play world for everybody. So this sounds like a good initiative but is this only for a really large IT shop like Shell or will smaller companies benefit from this and if so, how? Well again, I can start since we've been working with customers using this reference architecture. Let's say you might be able to get the biggest effect with larger customers but it's very much applicable to any size customer and we have been using it almost with any size customer in the market. Actually, if you look at one of our fellow consortium members, Munich Ray for example, it might be a good example because even though they're a very big company from a revenue perspective that the way they do business, actually the IT is very, very focused around very few critical applications and business processes that they drive, like for example, underwriting in the re-insurance industry but they use it in exactly the same fashion in their organization and a good example of the diversity of applicability that we can thrive here. I mean, we work with lots of very large corporates, they've all got this complexity problem. It's a big problem for all of them but actually as you say, as you start to look to smaller organizations, they're often more extensively sourced, they're often using all services and they've all got the integration problem that we spoke about so this should be applicable on all levels, I would have thought. Can I look at our supplier community, both IT and non-IT, they need to talk with us so partly it's IT talk so it's immediately relevant for the smaller players in our ecosystem to get their minds around this integration challenge as well. I think that the models that Daniel and Hans presented sum it up in terms of the shifting ecosystem that is IT. At the end of the day, the standard is gonna help us work together to choreograph all this so it's almost, you know, there's an analogy with the music that the first speaker made this morning but the world is just gonna continue to get complicated so the standard will have an increasing value as that process of innovation unfolds. But I think the key thing is that you're talking about small organizations, there are gradations of small so small, very small organizations, it really is gonna be not that interesting but relatively small organizations relative to Shell, yeah. For a small 50 person standards organization that they can see all of the phases in the reference model and what you do already. We have a complex infrastructure, yeah. So how is the work of IT for IT different from the work of COVID under ISACA and how to manage and govern the enterprise IT? Again me, okay. So first of all, there will be a very good track session in the afternoon with Charlie sitting over there and Lars sitting in the back, the famous Scandinavian chief architect that I introduced earlier. And they will talk about the positioning of IT for IT in very detail with ITEL, COVID and other standards safe not to forget here but in general. So we are really about the information model underneath. We're not about the process side of the house. We embrace those definitions of capabilities and KPIs on top, we do. But what we wanna build is how the data actually moves in that value chain, what is owned, where we can change things, how you integrate those things underneath, which is not specified neither by ITEL nor COVID nor ISO. I'm laughing a bit because I was talking with Carol yesterday about what kind of questions can we expect. This is one of them. So I'm very happy that you're here to elegantly respond to that, Carol. Thank you. Yeah, that will be covered in more depth. I would add to that by saying that they're highly complementary. So we're not trying to reinvent the wheel here. But again, back to the notion of choreography and so on, making these things work together. So governance is a key part of the IT for IT work. But in the session, you'll have Charlie Betts and Lars Ross and explain the relationship a lot more fully. And again, we're at a stage of maturity where in the collaboration portal, we already have assets that can be picked up by people, a white paper on the relationship between ITEL and the IT for IT forums work, so that you can see exactly where we are in terms of our own perception of positioning. So we've got some substance which we would be very keen to share with you. Have you given any consideration yet to how IT for IT may play a role in other of the activities going on at the Open Group, particularly things like the Open Platform 3.0 work? There's a lot to think about there. There's some obviously connections at the end of it in dependability through assuredness, measuring those things. Architecture will come through the Open Platform that the integration of social mobile, Big Beta, Cloud, Internet of Things, all of those things will have some relevance. And like any other forum, the IT for IT forum will be encouraged to have meetings with other forums of the Open Group and share opportunities with each other. In addition, I didn't have it on the slide but I didn't really talk to it. But the reference architecture, when we started building that out, we were certainly using concepts and methodologies out of the Togov definition and we're using Arcumate to actually specify the level two and three of the reference architecture. I do also think that there might be a good opportunity for communication between IT for IT and Togov to maybe add a couple more aspects into the Togov methodology. Maybe I'm dreaming here but a lot of what manageability means, so non-functional requirements in IT, I think could better be architected in the very front to make life a lot easier downstream. So if we bring the concepts of security, manageability into architecting applications from the start on, we may make operations downstream a lot easier. Not my cat though. We're trying to get to the final slide just so we can cover that. Communication is a challenge but Martin's cat is very beautiful but no longer with us, I think, is it? So have you got that last slide, Martin? So we just cover that. One last question, Dave, because we've got to keep people on time. Have you considered the convergence of IT and operational technology in the IT for IT model? And the new IT and operational technology organization has to handle both traditional enterprise IT and operational technology tasks such as control systems and SCADA and things like that and the interfaces in between. Is that part of the model you guys are looking at? The answer is yes, there's another white paper on the way that we address DevOps, Agile and the concepts that surround it. Our subject matter expert is very well known, it's Charlie Betts, who's the author of the book on this material. He relies in his book on an analogy with those of us that have builders in the house. We are now making shoes for the cobbler's children, we're catching up and those concepts are built into the underpinning ideas that have been driving IT for IT in the last 12 months or so. So the answer is yes, and again, we have materials on the collaboration portal that people can see. I think it's fair to say that the genesis of this has come out of corporate IT, if you'd like to have me manage that better. Yes, if you start looking at Internet of Things, if you start looking at sensors, et cetera, et cetera, one of the reasons for launching this as an open group forum is precisely so that we can start to expand and escape of it as well. So yes, there's a lot more that we could do, I'm sure. I have to imagine that Shell has concerns about more than a few SCADA and operational control systems in its IT portfolio. Absolutely. Okay, thank you. Thanks, Dave. So the slide up there does tell us a little bit about what's going on this afternoon and tomorrow in the open session. So tracks this afternoon are open, the session tomorrow is open, and then the next six months is where the work starts. If anyone wants to get involved and participate in this, whether it's to learn to be part of the process or to influence the direction and the content, if you're a Platinum or Gold member, you have entitlement already. If not, then you can join as a Silver member of this forum. If you're already a Silver member, you might want to go to Gold. But everyone is very welcome. This is the launch event. We're hoping that people join. And we're looking forward to, again, another successful customer-driven activity, such as we've had in the past with the open group. Now before you guys leave the stage, the final part of the launch, if we can do a few presentations, that would be very nice. I'm going to move that way down, Steve. You can help Steve, but the first thing is that Steve's got to help me because the first presentation is to yourself as the chair. So thank you very much. So if I hand that one to you, and it's a Chiruti... It's a very nice pen. It's a nice brand. Thank you very much indeed. You're welcome. So... There's a number of people we'd like to thank, so we'll go through this in the remaining three minutes that we have. So, Chris, if you'd like to award to Hans on your right. Well done, Hans. Thank you for everything you've done in supporting this. To Daniel. Well done, Daniel. Thank you very much. To Gail. To Gail. Great amount of work. Charlie Betts from AT&T. Charlie, are you there? Come and get something. You've done a huge amount of work here. Is that what you're saying? I'm Richard Arnink from... What's that say? Acmea. Acmea being new members of the Open Group because of this activity. Dwight David from HP. Come up. There's Dwight. I need some glasses. This is how I pass my glasses. I used to get accused of being able to write and put microfiche out of business, but... So that's Sue Desidero. Desiderio. There you go. Oh, I should have known that. I didn't need to read that. Philippe Genest from Exentia. Great work. Linda Kavana from HP. Lars Rossen from HP. Awesome. Kees Fendinbrink from HP. And finally, the person that is responsible for this trouble. The evil genius. The evil genius. Carl Fenceeland from Shell. Well done. So the Open Group IT for IT forum is now officially launched. Well done. One other person to recognise, of course, is Martin Kirk, the Forum Director.