 OK. Good afternoon, everybody. My name is Emma Hammond. I'm the Global Paz platform owner at Fidelity International. Just before we get started today, I need to give you a little bit of background about Fidelity. We are a privately owned company founded in 1969 and in fact we manage over $272 billion of money of our clients that range from sovereign wealth funds, pension funds, corporate banks across the globe. We take our business very seriously, as you might expect, and in today's market we're using our strength to put technology and our customers at the heart of everything that we do. Like many companies, Fidelity is undergoing transformation. We're starting to break up the super tanker application releases, the monolith, very large applications, moving away from siloed technical teams into polyskilled engineers, encouraging our business to see that small changes done frequently and safely at low cost is where all the action is. Last year we were very lucky to present at Summit on how we've deployed multiple cloud foundries across multiple different data centers using a software defined network. We now have over 45 applications running on our platform. The next 20 minutes is designed to take that one step further and talk about the culture and the evolution of the team that run the platform. We are a unique team at Fidelity, the first DevOps team responsible for the entire PAS hardware and software stack with all its associated services. Look out for us today. We're all wearing these rather dodgy T-shirts. In fact there's some over there. Incidentally we're fairly here on mass today because we know that Cloud Foundry is going to be looking after things for us whilst we're away but I think that's for another talk. So it's my pleasure to be here today. I'm very proud to be here. A little bit nervous as you can probably tell. My thanks go to the foundation for giving me this opportunity to come and talk to you. As global PAS product owner at Fidelity I find myself in a very difficult position since writing the title of this talk because not only now have I got to stand up here and not trip over and not forget what I need to say. I have to, I guess, come clean about a few things. So the first confession is about three years ago when I was working in an infrastructure and architecture engineering team, we recognised that a Cloud Foundry PAS was the next logical step in further developing our cloud strategy and our adoption of cloud based agile software delivery at Fidelity. We came to this conclusion ahead of our business and developer community and in doing so we put the cart before the horse, so to speak. Typically I'm told that it happens the other way around. The business want to have faster, cheaper, high quality deliveries and they put that pressure on their development community for them to find an answer to that requirement. So from a Fidelity PAS ops engineering teams perspective our journey therefore is very much based on showcasing the benefits of Cloud Foundry, the platform itself and encouraging adoption of that platform to our business and developer colleagues. In reality the biggest challenge for us as a team that run the platform is not just the platform itself but is about encouraging our developers to do the right thing, to write good quality, cloudy applications that make the most of what the platform offers to have a good PAS experience. So working with Cloud Foundry and the platform itself has turned everything that we know and have done to date upside down on its head. So as engineers we had to be prepared to be disrupted, to think differently about how we built it but also compelled to want that cloud based agile software delivery enough to be the actual disruptors within our company. So as you know PAS is this evolving ecosystem. If you imagine it in your hand, bear with me on this one, if you imagine it in your hand it's this special and pure entity, it's this constantly evolving ecosystem. If you enter into your PAS journey thinking that you need never change then you're going to very quickly suffocate and kill your PAS, throwing all of its advantages away with it. If you work in a brownfield site such as the one that we have at Fidelity, this becomes even more of a challenge. So the first thing that we did was to start with a product owner. Okay so being a product owner for a strategic platform, a financial company like Fidelity wants to run all of its applications in the future, I'd better know my stuff right? Okay so one might argue you need to know about SSL encryption. You need to be a fully hands-on engineer and know about core algorithms, cloud controllers. It's true I do come from a programming background but the real kick I get from working in this industry for over 20 years now is from building teams and challenging the status quo. So depending upon how you look at it, some people would say I'm a troublemaker, some people would say I'm a strategist. So I think it might be old age because unfortunately my brain can only take so much now. So here's the second confession. I leave the engineering of the technical stuff to those in my team who are far more capable than me in knowing exactly what to do and how to do it to create the things that we need for the platform. Yes we have an engineering anchor in the team which is a swappable role but I'm not a hands-on engineer. In fact it's safer that I'm not because my track record for forgetting passwords, I can see you laughing. My track record for forgetting passwords is indicating enough that I should back off, let others in the team play to their strengths. We are one team, all equal bringing our own skills and experience to the table. Mine appears to be buying biscuits, a lot of them. Listening to someone in the team when they've had a really bad day and generally being fiercely protected about the PAS service and my team so we can flourish amongst disbelievers. So let's talk about disbelieving. How does Cloud Foundry change the way in which we think about risk, about security and about change? In order to answer this for a positive future outcome we have to look at our past. We have for years been constantly challenged to meet a vast amount of requirements from many other teams. Change management, security, risk, audit, production support, service management, disaster recovery, the list goes on. Traditionally we plan changes, days, weeks, sometimes months in advance and we plan these changes with lots of Excel spreadsheets, I'm hoping this is resonating with many people in this room. Lots of gant charts which I've never quite understood and we do this because we believe that it de-risks the impact of that change whilst we get everybody's approval to make it. We believe that having a two week lead time change on a production change somehow mitigates the risk of that change. Let's go one step further, we'll make the change at the weekend. It's safer to do so, right? It's more cost effective to do it. We can still be agile, right? Okay, so, I jest. To be fair, these teams believe they're doing the right thing and historically have evolved to be the very much needed safety gatekeepers of our production systems. The safety created by previous experience of system failure, human error. The fear of something going wrong and perhaps, dare I say it, in some cases, a general lack of trust. This is what I call scar tissue. It's the baggage. This is the baggage that we carry around us from one place to the other. It's the baggage that we have to consider to get from one side of the room to the other. We, similar to lots of other companies, address this by employing ITL experts, application service managers, project managers. We share the responsibility across multiple shoulders in the belief that to do so we are better protected. We spend thousands of dollars on software. We restrict system access. We impose segregation of duties through role based access. In the process, we've created a thou shalt can't ethos. The department of no exists. Yes, I can resonate with that one. In fact, we have a fear of causing an outage and in fact, perhaps even losing our job. So, the reality of disbelieving is that change is expensive. Our past is all about being fearful of change and it takes so much energy and costs to deliver something in production that sometimes 30 different people have agreed to. We have systems that take weeks, even months to get agreement for to make those changes from all of those interested parties. The impact assessed and de-risked. Sometimes it's deemed too risky to change. I'm in disbelief. It's a sad place to be in an otherwise exciting industry that we can't fix this issue when there is so much technological change and in a very competitive marketplace. So, the third confession. I believe. I believe it's possible to look through the lens in a different way to find an alternative solution that helps people from getting nervous. We start small and we start simple. We start by encouraging developers to take responsibility for their configuration and code in all environments working to a product owner model. Then we give them self service. We build trust. We trust the technology, we trust in its execution and we trust the team. The ability to do this is probably the most important quality a product owner can have. Over the past two years, we have been looking to tip the traditional way of working upside down. We have to free our minds like Neo in the matrix. So the fourth confession is that we have sought professional help. We can't do this on our own. So, working with companies like Pivotal and Engineer Better who have helped coach us, we have been able to show our colleagues that through common sense and practical use of simple tooling, we can challenge everything. We can show that change is easy, safe and cheap through simple steps of using cloud foundry and pipelines. We can offer self service to developers in both non-prod and production environments without losing control of our infrastructure, without increasing risk or cost or auditability or security. We can trust cloud foundry to scale up, to auto heal and alert when something goes wrong. We can upgrade our cloud foundry platforms during the business day without impact. This we can even do without asking any of the application owners for approval. We offer the most secure, most up-to-date system at Fidelity because of this. We make production firewall changes to the Paz software defined network during the day without a change ticket. And we give this to self service to developers and product owners. It's no longer our configuration that we have to manage for them. We give self service to developers and product owners to deploy their code as well when they like. It's no longer our deployment to manage for them. We advocate a product team philosophy is the key to unlocking high quality responsive application and behavior to have the best Paz experience. Moving away from admin tasks driven by service and change tickets, we can spend more time engineering cool stuff like Chaos Gallego. We run a multi-tenant shared platform on the same hardware. You're safer running in a container so you can let it manage itself. Cloud Foundry does what it says on the tin. It's happy days and it all starts with a product owner. We are showing, through example, following best development practices that high quality code, robust pipelines and a logical test coverage when combined with automation, innovation and self service are powerful allies to have when challenged by the disbelievers. The reality is that we shouldn't have to dodge these bullets. And if a developer and a product owner are willing to take responsibility for their application, it becomes a winning combination to successful cloud adoption and agile rapid software development delivering quality functionality to our business. The fifth confession. We do, as developers do, we eat our own dog food. We take responsibility for the platform and we enable it to be serviced through these pipelines. We treat infrastructure as code. We do TDD through pairing. In fact, 90% of what we do is done through pairing. In this way, we're able to very quickly share ideas and knowledge, deliver higher quality products and keep our team size tight to a small and equal number whilst continually delivering MVPs, refactoring our code whilst we learn how and what our customers need. So how does running Cloud Foundry and a Paz change the way in which we build teams? I was lucky enough to be able to choose my team, causing trouble, scoured fidelity, looking for the best like minded team players who might not necessarily have all of the right technical skills, but who had the right attitude and that they were able to leave their scar tissue, their baggage at the door. Some question my choices. Surely I would take the most experienced guy if I wanted to innovate and create a robust and strategic and funky new platform. No, I went looking for the lean travellers, the ones who really wanted to make a difference. I've watched the team grow. I'm very proud. And I've seen you grow. Each member of the team being genuinely excited about new technology and learning new skills, working in this DevOps manner to achieve a high quality platform. But there's a but. Rome wasn't built in a day and transformational change is very challenging. And there are occasions when we really do feel like walking away. We feel sometimes that we are a small voice in an otherwise crowded room. So the sixth confession is all about patience. Today every company is currently at a different level of cloud adoption and agile development maturity. Some people get it, some people don't. The reality is that a company such as Fidelity is changing. It may take us a while to achieve, but we've made a great start. And Cloud Foundry being part of an open source community and through building partnerships with others have greatly helped us. And will continue to help us on that journey. So one thing that would definitely greatly increase our levels of a patience and understanding. We talk about empathy to successfully evangelize change within our enterprise as a ping pong table. We don't have one yet. So maybe that's an extra confession. So I'm drawing to a close. So before I find a very, very large genetic. My penultimate confession is that it's okay. It's okay to get things wrong and it's okay to change our minds. If we're strong enough to admit that we got it wrong, we can learn and adapt. We gain more strength through knowledge. If we accept that it's okay to change our minds, we end up delivering something quicker as we made a decision based on the information at that time. In this way we can try things very quickly and we can learn from them. Most importantly we can innovate. This alternative way of working in an otherwise traditional enterprise gives us as a pazox team tremendous agility enabling us as a team to switch tracks quickly and cheaply. So my last confession, perhaps a strange one when we are supposed to be and required to be professional at all times is that we have fun and we do have a laugh. Some of us spend more time at work than we do with our families and at home, so we really ought to make it count. So if you're not having fun, you're probably in the wrong job. So it seems customary to close presentations in this way. So thank you. You've been a very kind audience. There's been no booing or at least I haven't heard it down here and you haven't thrown anything that's at least not landed on the stage. So thank you. But if I have inspired you then we are in fact hiring. So thank you very much and enjoy the rest of the conference.