 Good morning, good afternoon, good day everybody. My name is Chris Davis and it's my pleasure to introduce this, the second in a series of webinars on the IT for IT initiative at the open group. Our speaker today is a close colleague and friend, Jim Johnson from HPE. Jim's a client enablement architect in the software group at Hewlett Packard Enterprise and his background is in IT strategic planning, enterprise architecture and software development. He holds an MBA in quantitative business analysis and lives in Austin, Texas. I'm speaking to you from Florida on the east coast of the USA, you'll detect from the accent that I'm not a Florida native. I currently serve the university system here in the College of Business and it's my secondary role to serve as the chairman of the IT for IT forum in the open group. So my role today basically is to act as the chairperson for the Q&A session at the end. So without further ado, it's my pleasure to hand over to our subject matter expert for today, Jim Johnson. Thank you Chris and welcome everyone. As Chris said, the focus of today's talk is around the strategy to portfolio value stream. I hope that most of you were able to attend the earlier webinar that gave a background on IT for IT architecture in general but we'll do some catch up on that in the event that you weren't there that you should get oriented on where we are and the focus of our conversation. So the IT, this is a model of the IT value chain that we've developed. It's characterized by value streams across the top flow. These are really the direct functions of the value chain and they're supported by various supporting functions or indirect functions across the bottom. We think of these main value streams within the chain as characterized by plan, build, deliver and run. This is a bit of an evolution from the plan, build, run model that we in IT have been using for years to characterize what we do. We think the small change adding deliver is a very important aspect because it kind of symbolizes fundamental change in the way we organize to deliver IT services to our customers and that will be apparent I think as we go through it. The center of that value stream is really the reference architecture which is characterized by a service model that underlies it and ties it together and a service model is really the different, it's a life cycle of a service as it moves through those value streams, those value chains. It's initially a conceptual model so that it's kind of, I like to think of it as kind of the marketing plan for a service. It's trying to understand why you're offering the service, who your customers are, what's the value of this service to them, where and when do you want to offer it to them. So it's really highly conceptual in nature, it's really the beginnings of understanding how much it might cost to operate a service and what the benefits will be. So it really is their cost and a benefit reason to be undertaking the service or offering it in the first place. As it moves along its life cycle, it becomes more, you can be characterized more as logical models so these are, if you think of typical models you might do in software development or in project management of a development engagement. There are views of the service in terms of actually creating the capabilities that it's needed to operate. And then as it may be released and actually deployed into a production environment and begin operating or it may be staged in a service catalog for someone to subscribe to. Then it becomes a true physical service that's in the operating environment. And it becomes available for customers to subscribe to it. So it's the different viewpoints from different personnel all under the same animal, it's all a service model but it's a very different set of views of that model so the tools and models change as it evolves through its life cycle. And this is what we call the level one diagram of the reference architecture. The value streams are represented along the bottom so it kind of flows from strategy to portfolio through requirements deployed to request to fulfill and detect to correct. It looks like a very linear model but it's really a continuous flow and there's feedback all the way from beginning to end and that's one of the major features of it is this interconnectedness throughout the value streams. You kind of read this thing by the blue boxes are the functional components that act on the artifacts and the artifacts are these black boxes so they're life cycle data objects and they are tied together through the solid lines that represent relationships between the data objects. And the purple circles along the bottom are a special designation of data object and that's the service model backbone so that those conceptual logical and realized stages that we talked about are characterized by physical artifacts that are stored in a service model along the way. And if you strip off the functional components, you get a really nice view of the relationships between all these key artifacts and how you can trace from beginning to end or end to beginning these relationships by referring back to the service model backbone that runs along the way. And if you think about how difficult it is today in today's operating world to if you've got a physical CI and operations to be able to understand if there's say an issue with it or an incident even knowing what service might be impacted by that incident or even more difficult to understand what customers may be impacted. There's just a tremendous amount of work that we do in IT today to understand those relationships and make them available to us in operations. One of the really great aspects of the reference architecture is it defines out what are the essential artifacts and relationships that we have in IT that we have to deploy. We have to be able to understand. We have to capture and we have to instantiate the relationships between them that makes all that really possible. And then you can begin to think of all the systems of insight that you might be able to create when you can follow these relationships of your key controlling artifacts throughout the IT life cycle. So looking at the value chain again in order to value streams. Just very briefly, strategy to portfolio is all focused on planning. So it's about defining the objectives for a service and aligning them to the business strategy and various IT roadmaps. It's about optimizing the portfolio of services that IT offers for the business. It's about getting your demand documented and consolidated and prioritized and then creating and managing the set of requirements that can realize those demands. And analyzing all that and then choosing what's the right set of investments that IT should be making in any given period to respond to that demand. The requirements to deploy is all about focused on building or sourcing and turning the investment decisions into services. And we'll have follow on webinars that go into detail about requirements to deploy and request to fulfill is focused on the delivering and making those services available to a consumer and that's really all about focusing IT's relationships to customers through a catalog, through a catalog view that people can order known services with expected deliverables. And then detect to correct is focused on keeping those services running in production and that's the classic operational services that are familiar to most of us in IT today. And like I said, these are all this chain, this chain of combined value streams is all made possible by that reference architecture that ties them all together. So strategy to portfolio, it can be thought of as really kind of four major phases or aggregations of activities. The first one being aligning the strategy. So this is where we really focus on aligning what we do, what we operate, what we invest in in IT with business objectives, where it's all about aligning to business goals and IT roadbaps so that the investments are optimized in that they come out when the business needs them, the platforms are there at the same time and you're not duplicating investments where it's not necessary. So IT strategies are created and documented and the means that they are to be achieved are spelled out here in the strategy component. So to realize a portfolio is really most about understanding the portfolio and how it relates to the connect collection of financial assets so our individual portfolio stocks and bonds and bank accounts is kind of the analogy we typically use and so rationalize our portfolio of services is a similar kind of aspect. We want to make sure that our risk is managed and that we're investing in a portfolio that actually achieves our IT objectives that support the business objectives much the same way we want to invest in a portfolio of stocks and bonds that achieves our life objectives. So by modeling the relationships between services and the business architecture it's really a key aspect of being able to make those investment decisions. As we'll talk about later, the focus of IT or being driven to really focus on supply and business needs paramount rather than just running IT because it's the way we've always run it. So prioritizing the backlog is another major aspect. Demand comes from a lot of different sources. So we've got from the business change requests and enhancements, from the business and IT strategic planning we've got various investment initiatives and major policy decisions and from our production environment, our run side of things we've got problems and patches and security issues that have to be addressed. And then IT itself always has a set of technology modernization and transformation activities that it has to undertake just because the tools of the trade are constantly moving underneath us. They're constantly changing and IT organizations have to keep up with it. And then managing investments is focused on really deciding which of all these demands we really want to address at any given point in time. The number of demands and the backlog, there's no way you can do them all. And so you have to have some way to discriminate between them. So there's a lot of constraining factors on it. And obviously there's budget, there's the amount of risk that the organization is ready to take on. And that risk threshold changes with organizations, depending on where they are in the calendar or where they might be in their business cycle. The backlog has to be evaluated with respect to what new value will be lost by not doing something. So it's not just a decision of whether it's worth it. It's what's the opportunity cost for not doing things that have to be considered. And then resources are a constant constraint. So the availability of really scarce resources like technology, expertise, and domain specialists. So given all that, IT has to make a choice. And those investments that rise to the top then become proposals that can be acted on by the requirements to deploy a value stream. It helps to think about what happens in these activities by looking at comparing it to kind of our changing economic model. An analogy that is often used is that IT is rooted in the past in operating in a kind of a planned economy, where we ran things based on a big central plan. And we decided how much capacity we're going to allocate for a given application or service and when and where it's going to be offered. And we go execute that plan. And if our business moves in a different direction and there's more customers in a given place than we had planned, then we have the economic, we have something similar to bread lines where a commodity that is wanted, we don't have enough of it. Or we may have something similar to a lot of cars being built and sitting on a lot that nobody buys because there's not enough gasoline. The effectiveness of the plan is everything. Well, the ability or IT operating in that manner is quickly going away. We've got to move to more kind of the analogy of a market economy where we're delivering what the market wants when the market wants it. And so the way we did things in the past and say in aligning strategy where we'd have a big two-year plan where we'd have maybe quarterly reviews, but we would build a cost model from top to bottom and say, here's our plan. And we go forward and very only occasionally make changes to it. What we're going to be doing in the future and what we think the IT for IT enables is the ability to really collapse that planning cycle into much shorter aspects. So maybe quarterly rolling planning cycles with even a biweekly CEO review. I mean, it has to be really quickly adaptive. And the decisions are made based on the impact of the business instead of impact to the cost. So we want to really get the business stakeholders involved and react quickly so that, as I said, our model is more like a marketing plan where we understand what customers want and we adapt to it really quickly. In rationalized portfolio today, mostly, the decisions are made based on what do we have to do to support our core business and then what kind of resources do we have to get things done. And in the future, we really need to cater to the business needs and we're going to have to be organized in much more agile teams with services provided through multiple sources instead of just everything we can build and very flexible skills. And prioritization today so much is done based on what we have to do. Often, when you go through your budget and your plan, you're essentially 70% or 80% of your budget are devoted just keeping the lights on of what you're currently doing and what you have left over is something you might try to do some innovations with. Our focus is really on business process efficiency. And operationally, it's very much a focus on stability, almost a view that change is evil and so no changes in the next quarter or at least until after Christmas are all the kinds of policies that you're used to seeing. Where we want to get is really have innovation be the trump everything. And it'd be the center of our prioritization where we're really flexible and we accept sourcing and outside service where it makes sense and IT being really the broker of those services as much as they want to be a developer or an operator. And the focus really moves to managing the risk and security of these services rather than the day-to-day aspects of it. And again, customer impact, loyalty, revenue, those things that impact the customer should be one of the driving prioritization factors. And in managing the investment, today, we really have very little ability to actually look and see if the investments we made are actually realizing the benefits that we wanted. Our data collection for this is really it's kind of a spreadsheet-driven world in a lot of cases where you roll up information from department to department and put it together. Going forward, we really want to be driven by those top-down goals. So look at our investment portfolio and what benefits do we want to realize? How are we doing? Are we on track? Are the goals the same as they were when we launched this service? And we can only do that really by having a good set of KPIs tied in at a service and feedback coming in on that service on kind of a real-time basis. And it goes beyond feedback or the KPIs that we think of today. In the operational world, yes, we really want to know that we're meeting our service-level agreements or that our performance objectives are being met on a service. But we also want to know, is the customer benefit there? Are customers adopting it at the rate we thought? Are they paying for it what we thought they would pay for? Are they substituting some other service instead of using our service? So it's really a market-based view of how our investments are operating to help us decide what we invest in in the future. So again, here's that reference architecture view. And as we said, strategy to portfolio is really the first column. It's the smallest value stream in terms of how many functional components and data artifact it manages. And so as we look into it a little bit closer in the enterprise architecture component, this is where we really create the service architecture and relate it to the other dimensions of the enterprise. Like I said, the business architecture, the technology and information architecture, and those roadmaps and plans. The service architecture is the essential data object. It includes blueprints for the service, enterprise guiding principles that apply, and technology roadmaps that would impact this service. The service portfolio component manages the entire portfolio of services that are in plan or in production or in transition, or maybe have even been retired. So it's the authoritative source of the services that IT even knows about. So either they deliver it, or they broker it, or they may have in the past, or it's going to be offered in the future. It's the complete picture from a service standpoint. And so its key data objects are the conceptual service and the conceptual service blueprint. And we talked about what that conceptual service means and the information that's contained in it. So the portfolio demand component is where we log and maintain and evaluate all that demand. It's really the single funnel where we get a view to all that demand. So sources can include project ideation, service requests, incident management, continuous improvement, the sources from all over the organization. And the idea is to funnel them into this one function where we can have them all together in a single view. The portfolio backlog item is the key data object that it manages. And as you would expect, that represents what that demand entails, who's asking for it, when they want it, why they want it, et cetera. So the policy component manages the creation and the review and the approval and audit of IT policies. So that policy data artifact is a thinking of it as a central repository for storing and organizing all types of IT policies, so things like policy distribution and acceptance, exception processing, revision history, regulatory and security compliance rules, review periods. All those kinds of activities happen within the policy functional component. And then the proposal functional component is really, again, it's the authoritative source for the list of IT proposals. And these proposals may or may not result in scope agreements that lead to IT initiatives that actually get acted on. And the scope agreement really spells out the objective of this proposal. So things like the cost of it, what's the benefit, what are the key attributes of a proposal, when do we need it, who is going to deliver it, or who might deliver it. It's all about the goals for an eventual IT service project. This is a level two architecture, so this is a little bit of a deeper dive into those five functional components and their data artifacts. And it includes the relationship of those artifacts to its surrounding world. So the kind of grayed out boxes are either functional components from an adjoining value stream like requirement to deploy or detect to correct, or they're supporting functional components. So there's cost modeling, IT asset management. And at this level, you see some more details about the data relationships and indeed the information flow from other functional components. So you can see a cardinality between these key relationships. And you get a sense then of how one conceptual service may lead to multiple conceptual service blueprints, how policies relate to conceptual services and requirements. And it's this relationship, this core relationship, that I've talked about before is so important in being able to see and to end across the chain. So what are the benefits to IT and to the business of structuring strategy to portfolio and the way we operate IT? We've tried to summarize them here and we've talked about them before. So to some extent, this holistic view of demand across the PMO, your cloud and your enterprise architecture and your service portfolio being able to align to business priorities, so enhancing the business agility and speed that you can deliver innovation to the business is really one of the big drivers. Data consistency and just visibility of the data to just think how many places you have demand captured somewhere today in some form or how many places you may have proposals or ideas, policies. Policies are the mechanisms that we use to store policies or to evaluate policies are very widespread today with very few standards. Financial visibility, like we said, we want to be able to get real-time feedback on how our services are performing versus how they're expected to perform and what is their real-world impact to the business? So how are they contributing to business objectives and the achievement of business goals? Traceability is core to this whole thing. So those core, those key data artifacts being traced across their lifecycle. And then communication between IT, between sources of operations in IT, between operational groups, between IT and its business partners, it can take on a different measure when you've got all these other things, when you've got traceability, when you've got financial visibility, when you've got consistent data that you share, when you've got holistic views. Your communication with all these stakeholders becomes much more efficient, much more effective, and very much more satisfying, I think, to everyone. That's probably the word I was looking for. So we've identified a set of critical success factors and key performance indicators for strategy to portfolio in the area in service portfolio rationalization to really succeed at that. We've lined out some KPIs that need to be tracked and followed, specifically around the, you've got a formal service portfolio function, and you've got a process that you've got taxonomies for understanding the functional and technical redundancy and business value of a service, that your processes, you have processes for consistently evaluating and tagging portfolio entries that you do ongoing rationalization, and that your service and IT portfolio management are themselves rationalized. Service portfolio financial analysis, accounting records are produced on a regular basis, and the investment spent in each of these is monitored. These are just detailed things you can look and measure to see where you are from maturity standpoint on each of these critical factors. Service portfolio reporting and analysis, service portfolio needs to exist, and is there a basis for deciding which services are offered. Service investment tracking, the investments in each service is quantified in service portfolio, and it's reported on a prescribed cadence. The to improve customer satisfaction, are customer satisfied? Are you measuring? These are very simple things that we want to focus on and just begin to up our maturity in all of these levels. Critical success factors for stewardship of IT. Some of the things that you see often are CAPEX versus OPEX, software license percentage and use. Some things that you don't see very much are planned versus actual cost. Actually, rolling up all the cost to a service is probably something that is not done on a regular basis and certainly not across the entire portfolio of services. And understanding what is a cost to a customer is almost impossible to measure today for a lot of what we do. Security, obviously, is a very important factor. So what's the frequency of security assessments and what are the noted deficiencies in security standards? Some very simple KPIs, but have a look at them and judge yourself and just see where you stand on this. Then it can help you decide where to really get started on thinking about structuring your planning activities in alignment with the IT for IT architecture. And there's a lot more information at the open group. We've got a standard published out there and you can go download a document that goes into more detail about all these functions and strategy to portfolio. And I encourage you to do so. And Chris, I think I'll open up for questions at this time. Fantastic. Thank you, Jim. And thank you all for the questions that have come in. What I propose to do is to allow Jim a moment or two to get his breath back and just re-articulate exactly what you've just seen and then to go back towards the beginning of the deck and take the questions in a kind of a chronological order based on Jim's presentation. So Jim has introduced you to the first and arguably the thinnest of the four value streams that we use to conceptualize the IT for IT initiative. Also be aware, please, that the value stream orientation is a very, very high level view. And what Jim has attempted to do in a very splendid presentation is to zoom you from the sort of helicopter view that we would use to pitch to and demonstrate value to a CIO or another member of the C suite in an organization. The value chain and value streams are business orientations that they rapidly lock on to. And he has driven it down through the five levels of abstraction that we use. The reference architecture that you've seen him illustrate in the slides is roughly level three. By pushing down through the functional component level, through the data artifacts we get into, the data integrity required to maintain the CMDB to provide consistency in the data models in products and services that vendors, like HPE, Service Now, CA, BMC, and so on, all need to offer to bring this reference architecture into operation. So not so much a health warning, but just some perspective so that you understand that Jim has spoken merely of one of the four value streams that we use in IT for IT. So if I may, what I would like to do is to go back to the beginning. So in slide two, Salman asked, is there any similarity in the plan, build, run, monitor model of COVID to what we've done in IT for IT? Absolutely, Salman. The idea is that the reference architecture that we've articulated in this new open group standard through that process of abstraction can accommodate any process model through the reference architecture. So the purple line running through the slide that you see now is a little bit deceptive, A, because of its narrowness, and B, because of its richness. This will work in an environment where we are reliant on more traditional structured methods or in an organization that uses DevOps and more agile techniques. So we don't have an explicit process model in there. So this thing is very flexible, and what we've done with Porter's value chain is essentially flipped it on a horizontal axis to provide that sort of margin. So the values that are added are efficiency in the business of IT, as you've heard Jim explain, and agility. Okay, the second question, could you give us a little bit more on managing demand, Jim? Specifically, what steps could be taken to consolidate and prioritize in that prioritized backlog box third from the left? Can I take that one back to you? Yeah, so I think the key message is enabling a single view to the entire backlog. Today, demand is, like we said, that you've got service requests, you've got project proposals, you've got IT initiatives, you've got architecture changes, and they only come together once every planning cycle to a large degree, and they're considered in isolation until that time. So the idea is to have a view to all of those all the time in almost real time, and to be able to associate those with the services that they impact or that depend on them, and be able to trace from that service then back to the business drivers that you're trying to satisfy for the business in order to allow you to, on an ongoing basis, understand what goals are the customers asking you about, and what do they align to, and say is there momentum building in any specific service versus another so that you can continually turn that dial on where you're making your investments and where you're focusing. Yeah. Thanks, Jim. So Dave, I hope that answers your question. Another question was raised by Ead Hindi who asked whether or not enterprise architecture should be involved in the strategy to portfolio phases earlier, and I'll respond to that by reminding you all that this is a reference architecture. So what we provide is prescriptive, but not entirely fixed. So the huge benefit which Jim has begun to articulate is the flexibility and transparency of the insights that this provides. So we have folks from Westbury software working with us to provide the monitoring of KPIs, continuous improvement, and so on, so that's ongoing work for us. But remember that the emphasis here is on a reference architecture, something that has not existed before. This enables us to enable IT to be run like a business. Some research that was provided for us by Gartner estimates that in a $1 billion IT operation, that a cost improvement, a cost reduction of between five and 20% should be feasible through this. And the reason is because of the dynamism of this space. So virtualization, service orientation, which is becoming more and more endemic in the IT service management space, both from a technology provider point of view, and also the expectations of internal customers, make this a very key place that we need to be ourselves agile. And this is what the reference architecture enables. Yeah, if I could just expand on that a little bit. A lot of these visuals imply a process. And when we see an arrow pointing left to right, we're trained to see a process and like a flow of things. And the point to remember is we are not talking about processes here. And so if you were to take your strategy portfolio organization and build a process model, you would probably see stakeholders from enterprise architecture involved, front left in your process model. But it's not the way it's depicted here. Absolutely. So although it's prescriptive, it's prescriptive guidance. It doesn't actually regiment roles, responsibilities, and positions in the organization. So I hope that's clarified that. Several questions have arisen on the mapping to ITIL. We see this initiative as highly complementary to ITIL. This is the first time that there has been, and if you will, off the shelf, ready to use a set of prescriptive guidelines that can be brought into the business of IT. We don't see this as replacing ITIL. This is highly, highly complementary. This is driven by enterprise architects working in this space and is a TOGAP-driven initiative within the open group. So we have used TOGAP to drive the whole of our endeavor in building the IT for IT reference architecture. I wouldn't argue that we map to TOGAP. TOGAP is just a framework. This is a reference architecture for the business of IT. But it is very complementary to ITIL. We wrote, I wrote an appendix for the pocket guide for the IT for IT initiative, which compares and contrasts ITIL and IT for IT. So there are a number of similarities, but there are also some significant differences. So this is much more prescriptive and of use to both customer and vendor organizations. So I hope that's responded to most of the questions there. There are a few more that are just coming in on the screen, but I'm gonna ask you to step forward briefly, Jim, if I may, to the slide where you've got the strategy portfolio level two, the one where you get down into the functional components for a little bit more. That's the one. Again, this is now a more detailed view that demonstrates, if you will, the richness of the deeper levels of what in the old days we would call functional decomposition. So now we're pushing down through level three of five in our IT for IT collateral, towards the levels where the CMDB would exist and product and service specific specifications need to be made in order to maintain the integrity of the data. This is all about the data. So be aware that this detailed view complements very much the very high level, more helicopter view that we give with the value chain and the value streams. One of the questions that's just popped in, which I didn't have time to note and type a response to is what are the use cases of the IT for IT reference architecture? At the moment, the best response to that is Mary Jarrett's wonderful presentation from the Edinburgh meeting a few weeks ago when she highlights how IT for IT has been introduced worldwide across shells, very complex operations in exploration oil extraction, retail operations, financial services and so on and so forth. We also have use cases from organizations like Delta Lloyd, Accenture and various others which we share through the open group meetings. So those will be coming soon and we hope to build those more directly into the standard itself so as to articulate the opportunities to apply the reference architecture. Hugo asks, IT for IT is nicely evolving into the reference architecture of an ERP for IT. It embodies the best practices from modern IT. Is there a companion open source community attempting to create an instance of an ERP based on IT for IT? We're not aware of it but this is the open group. So the purpose of sharing all this in this webinar is to encourage and maintain the integrity of contributions from subject matter experts like yourselves but that primarily comes through involvement with the open group. So at the moment we have some 60 companies in the forum. We have seven major software vendors. I have altogether about 250 enterprise architects all of whom are senior subject matter experts like our speaker, Jim Johnson. And we estimate that to date some 20 to 25 man years of effort has gone into the material that you've seen briefly outlined specifically in relation to this one value stream this morning. And at the moment we are at the point of having the new standard downloaded around about 2,000 times. So there's obviously a great deal of interest in this because there is now the potential to spread the community and the ability to contribute to this initiative. So I hope that responds to the question about how to get into the conversation. And Frederick asks, are the contributors of this initiative working on a maturity model that would help IT departments to adopt this approach regarding the assets that they're managing. So virtualized assets like cloud and big data. The answer to that Frederick is absolutely yes. My colleague, Mike Fulton and Eric Vitter lead our adoption work group. And one of their efforts is to look at the maturity of both users, professional users of the IT for IT collateral, the materials. So people certification and continuing professional development of people. But we will also be looking at CMMI and trying to create some equivalents of that so as to certify organizations. And obviously we'll be certifying the products that conform to the IT for IT standard. Okay, I've got a question here that I'm not entirely sure I can respond to. Alan Baldo asks, could we please elaborate a bit on how the automation aspects that could be applied to this subject? I think I'll let you speak to that, Jim, a little bit in the context of what we call systems of insight. Yeah, that's one of the most exciting aspects of this is being, if you think about automation as we use today, say in operations management, where we have made a lot of progress in automating the process of understanding incidents categorizing them and even detecting incidents before the customer does and adjusting to them, you can begin to see where with the end-to-end data and relationships that are exposed through the reference architecture, you could envision an implementation where you have that kind of automatic monitoring in almost any of the processes that move your artifacts through the value chain or through their lifecycle. And so where automation could be most important, you could certainly envision in the future that happening. And that's one of the fundamental capabilities that I think the adoption of this standard set of artifacts and relationships exposes. Excellent, thank you for that, Jim. And without whizzing back to it, the third or fourth slide in the deck that Jim spoke to, where we talk about the conceptual service model, the logical service model and the realized service model. The service model backbone, which sits at the heart of our reference architecture, one of the primary contributions there are the systems of insight and the notion to continuously monitor and maintain visibility of costs is one of the major benefits. So I will close now as chair and thank Jim Johnson once again for a very, very enlightening presentation. And thank you all for attending and your illuminating questions. Simon and I will summarize those and make them our responses and the deck that Jim has presented to you available. Without further ado, I'll hand back to Simon. Thank you, Chris, and thank you, Jim.