So, my talk is called Space the Rusty Frontier, or as the program committee like to call it Rust in Space, which I actually like that name a little better. So, this is not gonna be a super technical talk. This is more of the story of the company that I work for and how we have come to use Rust and why we like using Rust in the different places that we use it. So, don't expect any deep technical dives, which honestly is a kudos, I think, to the Rust team in that we didn't have to do any deep technical work with Rust to make it fit into our product as is it was good and it worked. So, this is more of a high level how we got there and what we do with it. So, just a little background on me. I've spent most of my career working on embedded Linux systems, writing some form of C and C++. So, I feel like I spent a lot of time in the wilderness of C trying to find my way out and trying to figure out is there a better way to do this, you know, wrestling with tooling and really weird bugs and all the things that come with that environment. So, using Rust is a breath of fresh air for me, but I spent a lot of time not using Rust and I understand the issues that come up with other languages and other environments. The company that I work for, we are called Cubos and we build software solutions for satellites. So, we operate in what you would call the new space sector, which is, I think, kind of started by SpaceX and this commercialization of space and now you have all of these different startups appearing and we want to position ourselves to really help those companies operate their satellites or their spacecraft really well by providing quality software products that they can use instead of them having to reinvent all this software every time they go about doing a mission. So, our goal is to make space more accessible and we do that by lowering the barriers of entry associated with software in space. Now, what we found is that with a lot of these companies, you know, they're made up mostly by electrical engineers and aerospace engineers, which makes a lot of sense, right? A spacecraft is this complex piece of hardware that you have to be very careful about and it operates in space, so clearly you want a lot of knowledge around those two things, but often the software is kind of left till the end or maybe it's like a poor doubly who doesn't really write a lot of software is now in charge of writing all the software to run their satellite and that's not a really fun position to be in when, let's say, your satellite launches in two months so it's like, go, go, go, get it all done. So, we want to provide tools to empower these people and increase their chances of success with their missions. We have two products that we work on to do that. The first one is called Major Tom and this is just our mission control software. I won't talk about this one too much today because it's not really the focus of this talk. It's a Ruby on Rails back-end with React front-end, pretty standard web app. It's what you'd use on the ground to receive data from your satellite and send commands up to your satellite. I understand there's a pretty big overlap in this community and the Ruby community so I thought it'd be neat to highlight that we do use Ruby on our other product and we are also looking for engineers to help with this product so if this seems interesting to you, please come talk to me after this and we'd be glad to talk to you. The main product that I work on and the thing that will be the focus of this talk is what we call CubeOS. It's a little confusing because the name of our company is Cubos, the name of this product is CubeOS. Part of why we name it that way is because it is the complete flight software system and it's a flight software framework as well. For the systems that we support, we package a custom Linux distribution that supports the hardware and then various pieces of middleware that are custom tailored to satellite-specific needs, drivers that are pre-built for peripherals that satellites will use, and then a framework for our customers to build on top of as they implement the logic for their missions. So we try to provide as much of the software as possible to make it as easy as possible for our customers to get up and going. And this product is also, I would say, like, 95% open source. There are a few bits that are proprietary that hardware vendors don't want us to release because it reveals some details about the hardware, but for the most part, all of this can be found on GitHub, which I love getting to work in an open source product and getting to be here as part of an open source community with this awesome language and using it in an open source product. I think it's a really cool synergy of those two things. So let's talk about how we got to Rust. I think we have to step back a little bit first and recognize that at the base, satellites are all just really fancy embedded systems. They usually have some form of constraint. Now, maybe they operate in a pretty exotic environment like a little different than most of our embedded systems here on Earth. It's just a little, and some of the hardware that's connected to them is a little different, but in the end, when it comes to writing the software, you're essentially working on an embedded device. So in the beginning, when I first started working on this project about two and a half years ago, we were targeting just free RTOS and building an abstraction layer around free RTOS, and what this meant is that everything was written in C because that's what you do if you're writing embedded systems and that's certainly what you do if you're building on top of free RTOS. So writing C abstraction layers and then trying to figure out what is the tooling that we need to deal with our module dependencies for doing testing, for building, all these things, trying to pull this all together and put it under one unified front for our customers to work with because that's not really something that exists in the C world. There are a lot of different tools that do a lot of different things, but not always a lot of unity among those tools and a lot of continuity between them, so we need to build a lot of that. But being a startup, trying to figure out our identity and what our product was and what to do with it, eventually over time, you find that things change and along came Linux and really changed things for us. So we found that as we talked to more hardware vendors, we realized that the flight boards they were offering, they were pretty powerful. They could run Linux and a lot of the customers that we were talking to, they did not have the needs of a real-time operating system. They didn't need those type of constraints or that type of timing, so we started thinking like, well, if we don't need to be doing that and we can run Linux, why wouldn't we just run Linux and have all of our applications run in Linux? It's so much easier to program in Linux. It's so much easier for us to find developers and our customers to find developers to work in a Linux environment and it opens the door for all sorts of other languages to be used. When we were building on Friartos, C was basically the only choice. I've seen some work in building Friartos modules in Rust, which is really cool, but it's pretty rare. For the most part, you're going to be writing in just C, but if you move to Linux and a more Linux-based architecture, you really open the door to other languages and this move for us, which started happening early last year, is really what started opening the door to even consider using Rust. The other thing was just thinking about C and its place in our product and in the industry. At different conferences where we would talk about our software, we would often get very pointed questions about how do you deal with the error rates of C? How do you deal with the dangerous side of C? How do you make this safe for people? There was one person who asked me a lot of questions and his answer was always, well, you should use Ada. Well, it's not exactly that simple to just use Ada, but him asking these questions really got them bouncing around on our head thinking, okay, is this really the best thing for us? Then starting to consider who our customers were and what is the best thing for them? What can deliver the best product for them? When your customers are a bunch of people that, yeah, they can write software, but they are not necessarily professional software developers, so C is easy for them to pick up, but is it really safe for them to pick up? Is it really the right thing for them to be running with? Can they make the best choices with C? Not having a lot of training and a lot of practice writing software and we started to realize that maybe the answer is no, maybe C was not the best choice for us. I think it's good to answer this question, why not Ada at this point? Because in the aerospace industry, Ada is a really popular choice and I think as a language, it actually has a lot of good to it. I spent some time tinkering with Ada as we're wrestling with this question of should we use C, or what's better, what's worse? And as a language, it's cool. The community I found is mainly hidden behind closed source barriers. We could not find a big thriving open source community, which is something that we wanted to be able to align with, but really the killer for us is the licensing situation with Ada. As far as I can tell, there's one company that kind of supports the Ada compiler and the main libraries, so you have two options. You can either purchase their commercial license or use their open source license, and that compiler and all the standard libraries are under the GPL, so then everything you write is then GPLed, which neither of those options really worked that well for us as a company trying to produce a commercial but also open source product. So that really nixed Ada for us. So the thing that really made us jump into Rust was GraphQL. This is probably last fall, last summer. We were really wrestling with this idea of what do we use as an application protocol between the different services on our system. And we really like this idea of GraphQL. There's strongly typed alternative to Rust, which would let us expose a schema of commands and queries, and then really be really selective about what we actually did with it. And we found that in the C world, there was like one or two GraphQL libraries, but there wasn't a GraphQL engine that really worked with the HTTP server, and I really didn't want to write that myself. That just sounded awful when there were so many implementations already in other languages. And we saw that Rust had great support for GraphQL, fit in with the type system that Rust had, worked well with the HTTP server, so did some tinkering with that. It seemed good. We did kind of a bake-off internally between C, Rust, and Python to see what direction we wanted to go in with our core flight software. And in the end, for a variety of reasons, Rust won out. So at this point, I can say pretty confidently that at Cubos, we don't write new C. There are C products that we still maintain. Uboot is the main boot loader we use, which is written in C, and we will not be rewriting Uboot and Rust, because that's not a good idea to try to do that. But when it comes to new software that we're writing, it's all written in Rust, and I am basically a full-time Rust developer now, which I think is just the coolest thing in the world. So now I'm going to talk a little bit about what I call the joy of Rust. There are just different things that we've come to appreciate about Rust. Some of these things were ideas that won us over before we started using Rust, and others were things that we have just discovered as we've gone and now really appreciate. So to start with high-level tools, low-level performance, I find that with Rust, between things like traits, modules, the whole enum system, options, results, the whole standard library, Rust helps me think about software when I write it in a much more natural way than C does. I often found that with C, as I tried to take my thoughts about software and translate them into the language, it's going from high-level design to, okay, how do I organize this around how the computer organizes memory, because that's kind of what C does. That's kind of hard to make that translation, but with Rust, it was always, and has been much easier for me to, I guess, more naturally express myself in the software, which is so cool to be able to do. I think it helps with design so much, but we don't lose on performance, which is even better. So you kind of get the best of both worlds, right? And then that's the point of this. Now, I do want to say real quick that I'm not here to bash C. That is just the context that I come from. That is my history and my background. I'm not boo-hooing C. I think there are places still where it's useful, but I think there are a lot of places where we tend to default to it, and maybe we should question that in the future. So the next great thing about Rust, the compiler protections that we get. And I won't go into this too much, but just the strong typing and the memory management and the way the compiler will protect you and just really yell at you and get on to you if you're doing bad things and just knowing that if I can please the compiler that my code probably isn't going to seg vault, it's probably not going to have some weird pointer errors.  Knowing that if our CI system passes, our code is probably mostly good. It will mostly work. It may not do what we want it to do, but it's not going to do the wrong things in a bad way. And that's just great. Okay, error handling. This is one of our favorite things about Rust. Gosh. We love that we can actually handle errors using Rust. The idea that there is a result type that can return either my data or an error type is so cool that I can propagate those errors back up to the top level through all my call stack. It's even better. And the fact that that can be done with the lowly question mark, it's just genius. It's so great that we can do this. We are patiently watching the error handling story following failure, trying to figure out, okay, where is this going to go using the latest versions? But yeah, we just love that this is a thing that gets so much attention. The core part of the Rust story, and for us, it is a core part of how we write software, is to be able to handle errors gracefully and report them well. Documentation. Documentation is something we take pretty seriously at Cubos. We write a lot of it, and we love that cargo has built in support for Rust doc and building those docs. But even more so, we love that we can embed Rust in our docs and compiler will tell us if those examples are still relevant, if they still work. So it helps us keep our documentation to be a living artifact, a living part of the code. And that's super valuable, especially as a company that is building a product intended for use by other people. The whole point of the product I work on is that I shouldn't have to write code for other people. They should be able to use my code for other things. So documentation, working examples, this is all super important for achieving this goal of empowering other people. And just this ability to compile the examples in our docs seems so small, but really is a big deal for us that we can keep this stuff all in check. And lastly, at least for now, the whole tooling story for Rust has been huge for us. The fact that within the cargo tool through different plugins and through its existing capabilities, you can build, test, cross compile, build your docs, format your code. Gosh, how cool is that? It's all in one tool, and it's all built by the same community. I'm not like going across the other regions of the Internet looking for some random GCC tool chain to do my cross compiling. It's all hidden behind one tool and we didn't even have to write that. That is something that the Rust community is doing and building and maintaining. So, thank you for that. We love it. It's so great. It makes our lives so much easier. And honestly, it's a lot of what we are trying to do previously with our C API, our C SDK. So, seeing it done in Rust in a way that exists already really well and that we can easily extend it through the cargo plugin system is just great. All right. So, let's talk a little bit about where we use Rust, call this Cuboress Corrosion.  So, in this kind of a high level systems diagram of what it will look like with a satellite talking to our ground service. So, on the top we have Major Tom and the Gateway and both of those would sit on the ground, you know, below your radio receiving data. And then this very large gray box that says Flight Software. Those are all the things that run on the satellite. And I think I can say pretty good confidence that most of these are written in Rust at this point. There are a few pieces that aren't written in Rust. We have some Lua floating around in there and some Legacy C and a little bit of Python. But the goal is that everything we write within this diagram will be in Rust. And the goal is that when we deliver this software to our customers that we know we've written it in Rust, we've done our testing, we've looked at it very thoroughly and we've been doing a solid product for them to build on top of. Now, maybe our customers write in Rust, maybe they don't, but the pieces of our software that we have built that they rely on, they are going to be rock solid and part of that is because we've chosen to use Rust to write them. So, speaking of customers, does Rust mix well with our customers? This is an ongoing question. I think one that we will find the answers to over the next few years is we slowly explore this. But what we've decided to do is give our customers the ability to either write in Rust if they want to. And some of them do, and they're very excited about using Rust, which is really encouraging and affirming for our decision to go that way. But for those that are less familiar, we do let them use Python. It runs alongside Rust. And part of how we make that inter-operate is in our architecture all those different boxes are actually different processes. So we create network boundaries between each process, and that means we don't really have to worry about mixing languages. As long as everything speaks the same UDP, GraphQL mixture that we have, we don't care what's talking to our Rust services. We just have everything bounded at the network layer, and then the Rust services are responsible for sanitizing whatever comes in and making sure it's safe. So whatever our customers write, they can't take down their own satellite. We make sure of that. They can screw up their own stuff, but the things that we write that let them control the satellite, they cannot harm, which is great. All right, so kind of the last part of this is some challenges that we have faced as we use Rust and I think some of these challenges also are pretty relevant to the aerospace industry in general and maybe some of the more fringe industries that we want to see Rust get pushed out into. Industries where maybe trust is a little harder to gain or environments are a little weird. So the first one, and this kind of hits us pretty hard is the compiled binary sizes. Is that a debug Rust binary? It's going to be pretty large. Release Rust binary is going to be smaller and you can strip it down to be even smaller, but still we found they tend to be a little bigger than the C binaries and that's something that we have to kind of reckon with on a daily basis as we do development on these satellites. So imagine you have a satellite on your desk and you're working with it but the only way you can talk to it is over a serial link and it's operating like 115200 VPS and you have a one and a half megabyte binary you have to transfer over and that's your only way of doing it. So that's kind of slow. It's going to take a little while to send that over. Now that's like best case scenario. Now imagine we take that satellite and we put it up in space and now it's talking to a radio over that serial link but the radio is actually even slower than the serial link. Let's say half the speed and let's say like you can only talk to it for like three or four minutes every ten minutes. So you've lost a lot of bandwidth at this point and this one and a half megabyte binary suddenly is taking a really long time to transfer over. We don't have a good solution for this one yet. We're still reckoning with this. We may look into the idea of binary diffs or something like that when it comes to updates but this is just a thing for us that we will have to deal with as updating software and satellites is a real need and something that we really want to offer to our customers. User learning curve this comes back to the whole idea of for us it's the customer but really it's any new user of Rust there is certainly a learning curve to getting into the language and I think it'd be easy for someone to argue that C is much easier to learn but is C safer to learn? I don't know about that. I think we pay a lot up front when we learn Rust for the safety that it gives us but sometimes we have to convince people that it's worth doing but I will say we really appreciate the Rust community and the work they've done on the docs, the Rust book has been great. All the different resources for learning Rust are just excellent and have been so helpful for us as a team to get there and I think you know the more we can do to give people those stepping stones to learning Rust the easier it will be to bring in these people. Language maturity. So I haven't run into this as much but I have a feeling that as Rust tries to push more into let's say the traditional aerospace industry or maybe just traditional embedded wherever that lies what you find is that there is a lot of institutional inertia and institutional trust in old things and old tools and new things are not good because they're new but old things are good we know they work and they're old and figuring out how to overcome this is pretty challenging and it can be a hard sell when you're like yeah my language has been around for like half a decade a little more than that you should use it, you should trust it I know your code base has been around for like 15 years but trust me this is okay. It's not a good quick solution to this one I think the best solution though we have to stick with Rust and keep working on it and keep pushing it forward we can't abandon it we have to see the long game of Rust and that in the long term I think it can and will become a very acceptable default for systems languages but we just have to give it that time to age and mature and gain the trust of different industries tool chain maturity this is one that hits a little closer to home when it comes to embedded systems so if you go to the Rust Forge website they have the list of supported platforms and it's actually really cool to see all the different platforms that are supported by Rust in the different tiers but what you'll notice is that the tier one guaranteed to work does not have most of those platforms most of them are in tier two or tier three and I think as we push more into different exotic pieces of hardware and I say exotic exotic could mean like a power pc which to most of us is pretty antiquated but in the aerospace industry is honestly like pretty standard when you get to a bigger mission that needs like a rad hard CPU power pc is pretty common so to say right now like okay yeah you should use Rust it's guaranteed to build like all that stuff it's guaranteed to build it's not guaranteed to work for some people that won't be good enough so we need to continue to push these tool chains in these platforms to have better and better support and the more that we can say are guaranteed to work the better buy-in I think we will get as people try to use Rust in these more exotic or antiquated platforms lastly ecosystem maturity I think this and the tool chain maturity language maturity a lot of these are just things that happen with time but I think this one in particular is the one that's most in the hands of everyone in this community the one thing that we do a lot at Cubos is testing and when looking for a testing framework in Rust it's like okay mock testing in crates.io what do we get out of these six different libraries some of them are unstable some of them are nightly so which one do I pick out of all of these and maybe some appear to be supported really well maybe some got up to a great start but now it's like does someone maintain it I'm not really sure trying to figure out what is the best choice sometimes is tough I think as a community we need to take steps to be better contributors not just users I think the more that we can contribute back to the crates that we want to use and I think a lot of people do this it's not really something I started doing but it's something I really feel like I should do I can't just be up here saying these critical things and not taking steps to fix them I'm part of this community too so the more that we together can contribute and hold up and support these crates I think the quicker the ecosystem as a whole will mature and better and better options will appear for people to use as they build on top of Rust so closing thoughts we at Cubos we really like Rust I don't think it's too much to say that we have taken a decently large gamble on the language and the ecosystem now our product is a framework we have chosen Rust as the primary language for that framework so I think that's a pretty strong statement that we believe in Rust and we believe in its future and we are thankful for Rust and all the different libraries and the people that support it and want to continue working with this community and hopefully growing together so thank you for the great gift of Rust and given to so many people and lastly if you want to check out our flight software it is up here on GitHub so please go out at my Rust tell me I'm a terrible programmer please help me get better give us suggestions that's all thank you


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.  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.  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.  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.  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.  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.  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.  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.  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.