 So, from the Bank of New Zealand, Roger Donaldson. Hei, there. So, we started our journey toward open shift with a business problem. We have, we started out looking at an area of our business that was giving us trouble, which was our small, medium business customers trying to join us and trying to draw down on loans, which is quite critical for small business customers. And we found it wasn't working very well. On average, it was taking about six hours just to open an account in terms of staff time required. And it was quite an error-prone process. We were having to go back to our customers, ask them the same questions over and over again. And it was all a bit rubbish. We sort of drilled into that and we said, OK, why is this? Is it a problem with our staff? Is it a problem with our processes? And it turned out that the answer was that it was nothing to do with our staff. It was that we were giving them bad tools. The tools we were giving them aren't very good. They don't follow the customer conversations. And what's more, there's too many of them. So, we found that just to join the bank, we were asking our frontline staff to use 19 separate applications with repeated data entry across all of the applications. So, that is a horrific experience for the frontliners and it flows through to that bad customer experience, which then you ask the question again of, well, why is that? And when we started looking into that, we had built a lot of big balls of mud. Very traditional, unified ESB, services all deployed into the ESB, applications that try to do everything that have a heavyweight deployment model. Because of this, we have a low release cadence. We don't trust ourselves to make change and as banks tend to, we then put a lot of change management processes to try and protect ourselves from breaking things, from releasing things that have got problems. This means we have lots of applications at this point in the quarterly release cycle, where even a small change can take, once you've signed off on testing, can take a month to get into production. So, at that point, if you're a developer and you've been told we've got a new regulatory requirement or the market's changed and we need to push something out, it looks easier to stand up a whole new application than to modify an existing one, which is not really ideal. So, at that point, we need to get more comfort with change, which means small, reliable changes. That lends towards the microservice-style pattern, pulling everything into 12-factor-style applications so that you get comfortable and if you can make change reliably, you can then go faster. If you know that what you're doing is the right thing, that it's not going to break in production, then your developers are comfortable, your testers are comfortable and, importantly, your business owners, your change managers, your security people are all comfortable. One of the things when we talk to people who have done this that was quite critical is that you have to have a platform that supports the style of application development because if you don't, instead of having a few big balls of mud, you have dozens, hundreds of big balls of mud, small balls of mud, so you make the problem worse, not better. So, out of that, we picked on OpenShift as a container platform. We wanted the orchestration, we wanted Kubernetes, we wanted as a packaged app so that we could run quickly rather than learning Kubernetes from scratch, rather than learning containers from scratch, rather than learning how to build effective pipelines from scratch. We stood up a dev team to refactor one of our problem-child applications. We stood up an ops team stand-up OpenShift, and we pulled in some externals, partners like OSS in Section 6. We got from nothing to proof of concept in six weeks. We showed the proof of concept to the bank directors. They looked at it and said, this is how banks should work. From there, we got to production in eight weeks. In the old world with this application, it took a month to do a release to production, no matter how small the change was. In the new world, we were hitting three releases per week, so that's a massive increase in productivity, and that's purely a function of how confident we were that we could now make changes without breaking the world. From there, we've gone strength to strength. We've got more and more people on the platform. We have several hundred developers working on OpenShift now, and we're just building out our second-generation platform with a 10,000 pod capacity. That's me run out of time. Thank you very much for your attention.