Atom Bank: Building a Bank on the Cloud (Cloud Next ‘19 UK)
Hello. Everyone. Really. Happy to see so many people here, today to. Talk through the. Journey at some banks being on in terms of building a bank on the cloud. Feedback, half session he's probably seen the slide. My. Name is Ron about Acharya I'm the chief, technology officer, at Assen Bank and I'm joined with so. Reg Williams, I run our UK and Ireland architecture, practice okay. We're. Going to talk today really, around. Our. Journey, moving. To the cloud using Google and arvy architecture, to leverage Google a. Lot. Of you probably aren't familiar with atoms so we, thought we would start with a bit of background around Adam so. Adam from. A concept, was came. About April 2014, we. Were given. A restricted. License in June. 2014, to actually build, the. First, bank in the UK about was app only we. Launched April 2016, with a fixed rate saver and a. SME. Proposition. This. Was on iOS following. A few months we launched. A Android, app. Towards. The end of 2016. We launched a mortgage proposition. Effectively. Right now we're roughly, two billion on both sides of the balance sheet both savings, and lending. And. More. Recently for. The likes you know in terms of this discussion we, signed. A contract with Google in February and launched. Our initial. Workloads, in Google in August. This year. So. I just kind of explained that you know we are a live working bank we. Went live in 2016. But. Last year we started a journey to actually move to the cloud and. Actually, we architect a bank so you can kind of wondering why, did we do that if we can do things like have two billion on both sides of balance sheet so. When we incepted, the bank. There. Wasn't a real clear guidance, from the regulators around the use of cloud so, as, a. Bank you're kind of constrained by a level of guidance. But. As we were creating Bank we were very clear in the future we wanted, to embrace. The use of cloud and other technologies, that were coming through so. We, took an opportunity last, year to create a program work to basically. Start. Building, a new Bank alongside. The. Bank we really have. And, what we're going to talk about it's really that program will work that we've been going through for. Us is very important, because we. Have a vision of where we want to take a bank and how we want to serve our customers we want to really drive benefits, for our customers, give, them the service, and products that they. Need and, want and we. Felt this was best served, by us, moving to cloud and creating, a stack. That works in the cloud to, really convey. His benefits. Quite. Often you can go right. What. Other challenges were kind of trying to face and some of the challenges we have are being felt by a, lot, of other banking. Institutions. So. If you think about where. We started from so originally, because. We couldn't use a cloud we, leverage, third-party, data centers if, you go down that model it's a model it's not a vendor, go down that model what, you'll find is basically that. Doesn't. Give you the flexibility, of agility you need because you are data center eccentric, similarly. Enough you're. Caught quite often the challenges find this view using batch processes, rather than real-time event. Data processing. Also. That. Whole model around, data centers and suppliers you kind of often see, over, resilience, and third parties, where effectively, they. Are running. Core functions, for you and because it's a commercial relationship what, you'll find is you, know you, want to change something there's. An impact assessment there's a change request raised you have to prove the change with Chris some, of them goes and buys some hardware some of them installs it some of them configures. It with operating, systems those. Software, that, takes time that takes a lot of time so. We knew from, our perspective, from both of a cost and a speeds perspective. That, we wanted to be more self-sufficient and, actually, leveraging, cloud helps, us do that so. Our. Response to all these challenges, was to create what we call the atom banking machine which really is around the, technology which is our platform our people, and data.
Because. End of the day you, could have the world's best technology but, if you haven't got the people to use it properly in a way that gives you agility. Then. You, know you just got some technology, and a, horse of a bank is, really data input. In terms of its customers, in terms of payments etc so, if you don't actually manage to fuse those three things together you're, not gonna be successful in this journey. So. The very high level we're creating a fatal. State-of-the-art. Banking. Platform which. And the bedrock of that is leveraging. The Google cloud and. What we want to do is create one of the most advanced. Banking, machines in the industry so we're, using fort, machine which, will be a cloud native smart, contract based, core. Banking platform, so. I've. Been in banks where basically you might spend a year developing a product here. Basically through. Configuration, which is really code, effectively, you could define what. A product looks like in days, and weeks, obviously. There's more things to do outside of defining the product and so launching it but, you're taking the pressures away from product development by virtue of leveraging this sort of technology, again. We're also injecting. Event. Streaming for the user caf-co into our platform and again. Using the benefits of cloud, and DevOps to give us the agility across, our estate. What. We're trying to do is create. A plug-and-play partnering, model leveraging. Api's and, event. Based architecture. To basically, give. Us a level, of segregation between. Getting. Vendor locking so basically, historically. In banking platforms, in, a. Lot of banks once. You integrate a third party you can locked into that for third party because it's likely missing heart surgery, tried to move it out quite. Often organizations fall. In and out of love with various vendors but, can't do anything about it because it. Will take you years to kind of decoupled, that relationship, and we didn't want to fall into that and. One of the key important points here also is for. Us we wanted to be in control not vendors so, we've also been increasing, our own capability. And capacity within, the bank to, take control of more of our engineering, so, things like our own app development, which was already there but we bolstered the size of the team my integration, things. Like Casca our ability. To configure our own products on fort machine etc we're, all going to do that in-house, the. Benefits, of this would be speed efficiency allow, us to innovate an experiment, without actually, before it started up costing the earth and, also, we're, doing most of this through a level of configuration, within atom, itself. But. Journey we've been on. Effectively. We started last year where, basically we, went on an RFP process with, the usual suspects, as you would think and. We. Went. Down the route of selecting. Google and. Accenture. To help us provide us with some initial capability to. Create our own capability. And also start making progress on, our. Delivery, journey and it, was quite important, for us to do that because we didn't want to just. Organically, grow and take a lot of time and not make progress we wanted to basically organically. Grow make progress and, what Accenture did to help us was basically.
Gave. Us some people who. Knew. The. Right well, and wait the right ways of working to kind of take us forward in the short term embed, that ways of working while, we recruited. People in as well so. We've created our DevOps capability. We. Started doing design, for, various, phases of, the, transition, of building this Bank and also decommissioning. The old Bank right. Now we've. Finished, phase zero and within. The next few weeks we'll, be completing. Phase one then. Throughout next year we're closing off phase. Two and we're looking at phase three as well and at. The end of phase two we would have actually. Launched. Our, full, stack of our new Bank and, phase freeze. Really just closing down. The. Old Bank within a datacenter effectively, so, you, know we're. The next few weeks will have a hybrid bank let's say old world new world and then we'll be adding more component, ori into, the, cloud and using, South Services in view of shutting, down the old bank in, a safe manner when we're ready. In. Terms of our transformation. We. Talk I use the word partner, and. Part. Of our journey has been also to differentiate, between suppliers, and partners because, supplies quite often you have a transactional, relationship with, if they do something as a contract, etc but. We've been looking for partners because, partner, partnership is more than a contract where basically. You. Have someone on your side who is looking to help you succeed and what. We looked for with, relationship, with Google particularly. Is having, a long-term partner, who, is actually there to help us succeed and you know we are here today as part of no, promoting. To help Google has given us as well in our journey as well, from. Accenture standpoint, as well we, were looking for a partner to help us on our transition and from day one it was kind of you, know helped us to create a capability, but we want to be self sufficient and, and. You know eccentric, kind of helped us do that yeah, I mean I'd add on, that but these. Guys set, the bar very high. Coming. Into this work and you will go on and see you know infrastructure, as code soup-to-nuts. In, terms of building these environments, on the cloud dev and test and production. And. Of course we were we've been delighted to help build that capability inside Adam. But. This it's particularly. Interesting. In that this Bank has taken that business approach to bring a proposition, to market quickly and employing, a lot of on-premise. Capability. And then refactor. Onto the clouds as. Part of their future growth strategy, which, obviously for, our organization, as well is something that we see a lot of our bigger clients, wrestling. With right they've got years, of technical debt and they're trying to work their way through all of that so for. Us it's a really important, partnership. To. Work together to be successful to. Help learn in the in the market what power we will address some of the key challenges around, that problem, and moving stuff off large, monolithic, systems. Of record on traditional, IT and, move on to the, fast new. Cloud-based. Infrastructure. We. Talked about we it was essential, for us to build her own capability. And part. Of this was really trading upskilling so obviously, we're. Running Bank we've got people but we wanted most people to start, embracing, Google. What. Google helped us do actually is part of e investment, and the. Partnership. They. Invested. Trading. Into a team and not just at him but also into. Accenture. We're required so, extent, extent has got some, good people and things that on areas like AWS, way. I have a good background in delivery but. Also just gave him up and ready to help us on Google was, part of the investment Google, put into bit miss journey as well which was really refreshing to see. Been. On recruitment again through, discussions. With Google and Accenture, and our, own kind of equipment function, we started. Building our own a team team from. A DevOps perspective, as well to be capable of running, a, full, sack bank. Culture. Was quite important, go back to the point around you know you can select with all the tools you want to but if you haven't got the people to run it in the right way tools, at all. So. Accenture. Board in a. Experienced. Scrum. Master, an, agile coach and then, we very, quickly, created. The. Right working approach, of, a high cadence delivery, approach where basically we're using, sprints to basically develop. Via. DevOps. But. Key capabilities, of the infrastructure. And the ability. To deploy our applications, in a repeatable and a robust fashion yeah, we. Talked a bit more about what batch it means shortly. Then. Let's part of a journey as we, are a bank moving. To the cloud. Know. We. Just can't do that without consulting the. Regulators, as you would expect so the regulators job is to make sure that, a, bank, works. In a way that doesn't harm its customers, or broader.
Country, The National Infrastructure because banks are part of national infrastructure so. We went into a discussion with. The regulator about. And, it's. Worthwhile kind. Of just talk about some the high-level discussion, points oh. But. There's something called sis gate which, is part of the FCA, handbook and this read talks about if you, have a material outsource. There's. Certain provisions that need to be in the contract around, audit. Rights liability. Etc, so to make sure the bank has the right sort of contract, for. Material outsource so, we had to make sure we had a contract with Google that allowed us, that. Level of coverage, similarly. At the same time EBI guidelines, from, cloud outsourcing, we, have to make sure we add. Things. Around exit, strategy etc etc all, bottom, doubt that we could demonstrate that, we actually knew how. To control the contract. More. Interesting discussions, we had with regulators. Were around things like data residency, and data sovereignty so. Obviously, we're. A bank got. Customer data got payment data etc so. It, was essential, that the, regulator understood, that we understood, where. Data was going to reside so none of our data is going to be outside of Europe, it's. Going to be hosted. Primarily. In London and we've. Got a failover site in another location in Europe as well, when. Data sovereignty is really around who controls, the, data and who can see it and we have to demonstrate an understanding, of how but. Data would, be held in Google and that. Google could actually see, it because quite often there. Is a lot of noise and Industry really, around you. Know cloud providers, big, organizations, being able to use, other, people's, data without permission. Google. Can't see our data in terms of the way the encryption works etc, etc. We. Talked about exit plan if you're going to make a material move, it respect to visit cloud or any other provider you. Need to understand, if it doesn't go well how. Do you move away to someone. Else or something else then. Governance, the governor's point was really the regular regulator. Wanted to understand. Do. You as an organization understand. What, you are saying you're going to do and have you gone through the right levels of approval internally. And mitigated. Risk. We, had to basically show. Goat the, governance process and, get, our. Board, the, Assam Bank board to, attest to the fact that. We. Have gone through the right process and, the right risks are mitigated and, we, have the right controls in place to run a bank on the cloud effectively. So. Where will we end up with our journey so we'll. Have a new banking platform this. Will have. Capabilities. Where, we could define products very quickly using, things, like vault machine we'll, have a real-time data stream layer which will basically allow us to. Create. Actions and real-time events so things like know if. A certain type of payment happens we can send out a notification if we wanted to in real time not relying on batch and, provide in the future of real-time customer insights etc. All. Of which importantly, is under atom control so our team, will be making changes and running the, show the bank rather than being overly, reliant on third parties obviously, we're going to need for some of our services use, things like SAS where we believe that's, the right thing but, fit for areas, that are very important. For the bank we want to be in control and. Once we have this in place we'll be able to decommission, our legacy systems and what. That means is we'll, be able to create a very, superior, customer. Experience right, products and services, at Pace and the right cost point because, what we want to do is basically use. Technology, to automate as much as possible. So our operating costs are low which, therefore means that we could basically price, products, for our customers at, a more. Appropriate pricing, try it and get them the most value as possible. So, we talk to what we're here at, a Google conference so, it's worthwhile talking about what's, worked well with, Google I talked. A lot about partnership, earlier. Right. From the outset we said we wanted a partner because, 50 percent of our journey is really around having. A partner because. You, will have bumps from your journey any. Journey. You will do but it's really around having someone you can work with to get over those obstacles and, that's what we have found in our journey with Google. Support. For upskilling again we talked about the training investment which was great and also access to other Googlers as well when you have point, problems and again you know that, doesn't go into discussions, around the contracts you just say can we get some help someone.
Appears Answers. Questions, we move on we're. Already seeing that the benefits, around the agility to scalability. And resilience will come on to that a bit more later. Cost. Is under our control quite. Often with banking constrained, around number of environments you can have in a more traditional approach. We. Can spin up environments, very fast and we'll talk a bit more about that but. There's a cost to it but we control it we could also shut down those environments when we don't need to and, then we've, got the benefit of basically the evergreening, and trying, to keep things in support because, it's like if I think about our. Current. Banking stock that. We have live we have to coordinate various. Patch releases security, releases etc etc but. Behind the scenes. Google. Is working on that and you just have to kind of allow Google just to take care of that for you which minimizes. The. Activities, you have to coordinate effectively and, the risk around that. Some. Lessons learnt from this journey so. Security's, a big part of a bank, one. Of the security, capabilities. Within Google is ce mec which is customer, managing encryption keys. We're. Leveraging risk because we want to be on. Control, over keys as much as possible in terms of, instantiation. Rotation, etc etc what. We found was ce mec initially, wasn't rolled out a core across all, the regions as, we assumed, it would be but for us it's been rolled out where we need it to be now so that's great and also, there's, a road map of where ce mec will be available within the various different, services, of. Google. And we. Just need to kind of understand how best we could use what functions, that were available that weren't C Mac +1, seemed it would be available to, allow us on our journey to go live. There's. A point here around lack, of geographical. Separation within, the UK region, so. If. You're familiar with with, Google. Regions each google region typically has free zones. What. We found was some. Of those zones were quite close together for a bank because we've got certain rules around draw. Graphic dispersion, so effectively, if you wanted to do a disaster, recovery scenario, you. Can't have a. Two. Day Center too, close together effectively right so those loans on fact three days centers, by. Getting Google are working on that but part of our deployment. Model we've taken care of app and, issue. Anyway, so we're, kind of good to go but, contracts, took a while longer to establish, again we talked about the type of contracts we need for a bank sis ke ba Gardens, compliant, but. We've got very end what was refreshing was. Google. Worked with philosophy that process obvious to get our contract, but use there, as a lessons learnt process, and created what they call v FS. Addendum, so next slam around a bank wants to contract with Google would be more. Efficient in terms of leveraging, the timeline etc. But. For us also is really understanding a roadmap we talked about ce mec what's available when. You. Then you get a better view of, your. Journey and. What we can use when when you got certain, criteria. Of service, wired. So. In. Terms of benefits already realized, I talked about journey where we've done phase zero and we're about to go live with phase one. Already. We built our in-house capability, so it's fair to say that Accenture, is not with us anymore so in terms of their job helping. Us build our capability, that's been established we've got our own sres. To. Basically take take us forward. I'll, lead, time for, provisioning. Environments, a significant, reducing and we'll explain, what that means and again, we, are getting. The. Value of what we called Enterprise agility, and I'm going to demonstrate, what. That kind of means to us right now so, historically. Using. A third-party data center model we, probably would have taken circa.
At. Best around 41, weeks to create, another, environment of a full stack Bank right. Now we, could do that under a week so five days. And. We do this. You. Know leveraging, the, capabilities in. Google where on day one we, effectively create our base, networking. And our. Based. Identity. Access management capabilities. And our DNS, using. Tools like vault Packer terraform. Across. Day two and free we basically, using, infrastructure, as a code deploy. The. Network infrastructure, as well as we call. Software. Architecture, and. It's worth saying type. Of truly more using we're. Using it so it's repeatable and fast and as, a bank we only have processes, that we know if we use it in one environment it will work in another environment because, they're the same effectively, the same process. In. The last two. Days is really around. Functional. Testing and making sure everything. Is running then, we hand it off to a. Project. A team to do the work they need to do after that are developing new features etc. Etc. Another. Example we'll talk about when we talk about into possibilities our ability, to release change. So. Over the last few weeks we've been taking. A change that's just been developed smoke testing it in a development, environment putting. It through a QA or a test environment then put it into production in the same day we've, done this multiple trying at times and when, I say changes, we. Might do multiple, times but each change. Is a baseline of change so you could be talking about 50 or 100 individual. Changes incorporated. That's going live and, we'd be building out our. Production. Environment which is live internally. For us right now you. Know on a daily basis and adding more changing as we need to in view of going live over the next few weeks in, terms of our true. Customers, externally. Here's. A quick video of one of the other benefits we've got as well as going. Through, going. To cloud so we've got our old app on the left-hand side and our, new app on the right-hand side and. Through. Running work, close in Google the latency, is removed and we're, finding as you can see on the app on the right-hand side it's. Running a lot faster. We. Have built a new app and. This is the first time we're showing externally, in terms of elements of this look and feel it. Runs first and not just because we've built it natively but. Also the, actual interactions. Over the cloud the, latencies were moved because traffic is is private well the, latencies are removed but the traffic is prioritized. Over Google compared, to data center traffic etc over, the Internet so we, get the benefits of that as well so, in, reality we on. The new app we're talking about with 6 or 7 seconds, faster, on our la bonne journee. Okay. We're just going to pick up and cue so. When I am, indeed the last man standing. From. Accenture it's been a real. Privilege to work with. A team on the ground at a sandbank you. Know they came to us two years ago and. As. I said earlier they set a really high bar in terms of what they wanted to automate, and. How their, vision of driving. Their future Bank on Google cloud platform. You know how they wanted to roll that out through. Essentially, building. Out the infrastructure, the, base infrastructure, on you Google, cloud platform building, all the DevOps pipes to. Initially, play out the middleware, stack so, that they could run a kind of hybrid model, between old you know existing, on-prem core. Bank and new and existing. App I think in in at least one transition state and then, move on to new app on, to old Bank and the new app on to new bank right all facilitated. Through. You. Know full infrastructure, as quote as code based, environments. On Google cloud platform running. Terraform. And ansible. Primarily. Right. Across a full middleware stack dilash will not name but it's quite a lengthy list of all the sorts of usual. Suspects. In a modern cloud native, architecture. And I. Wanted. To bring. It up a level. Because. This is the thing that I I I'm. Speaking to I speak to a lot of clients around, their. Ambition, for. Moving to cloud native high. Speed, at, scale. Successful. Implementations. Of, you. Know financial, services solutions, products. Retail, solutions, really that's right cross right across the market unit and a, thing that we've observed is.
In. Fact it's we haven't observed it's not news well-known, and anybody who's read fred brooks would note would recognize the term diseconomy. Of scale right. It's intuitive, to all of us of software engineers so the bigger something gets the, harder it gets to scale the more expensive per, line of code it is the more lines of code you have so. This. Like this graph is actually based on some industry data and it really shows you that if you can break down a hundred thousand Abe projects. Into, ten discrete 10,000 des projects, that are not connected to one another that. Have only, production. Dependencies. Right. Then. The benefit is as much as potentially, 40,000. Days forty percent how. About that for a business case for micro services if you're ever wondering right, because, the reality is all of that technology is, it's. Not just you, know it's easy to get into a kind of sweet. Shop mentality, with this stuff if I use api's and I use pads and I use cloud and I've got a bit of agile oh I've, got DevOps too and I bang all that stuff in over the next 18 months bang, gonna be able to tell I'm. Gonna be able to realize all of the the potential in terms of faster time-to-market lower, cost of ownership better, quality and quite, a lot of my. Clients are finding. That that isn't true actually. What they're doing is adding more, technical, debt. Shadow. IT cottage. Industries, losing, control of their parts, of their a state. As a result and that but the key thing it's not getting the value out right. They're still going to mount to market every 18 months. Maybe. This group this is not familiar but for, me it's a deal that we live this every day right more, or less in you know in big organizations big. Organizations, characterized, by having 40, years of, technical. Debt, so. The. Right way so what we want to be doing is operating in the top zone we want to get away from boom and bust IT cycles, big investments, in change. You. Know rack up some new middleware the latest and greatest last, year it was ESB. This year it's API manager, next year it was something else right and and, and. Ironically a lot of our clients have got all of it between, the, north face and the south face it's like the Jurassic, Coast of middleware going, all the way down to the systems of record right and and. That. Is that, is itself adding drag. So. It's like one of those awful you, know conditions. You can get wherever you try and intervene just do something about it you make it worse, okay. We want to be operating up in the top zone with agility and and. Doing, getting away from that kind of boom and bust thing into sort of incremental transformation. So. You, know across all of our clients we're all talking about the same stuff right what's hot. Pads. Is hots running, running, a kubernetes. Platform. So, that I can modular eyes my code and scale, it out and give, it to different teams is obviously, really hot, api's. Has been hot for a while use, contract, based interactions. Between your systems to, isolate them from one another you. Know that's that's, quite hot or. Extremely hot and, what. Else is on here and as we've been talking about today infrastructure. As code automating. Your pipelines, taking you. Know the quality you get out of delivering, something a thousand. Times, through the full-stack means. That by the time you go into production you know that stuff runs like clockwork you. Know that's got a real business benefit and that's obviously very hot. Data. Lakes just a sidebar on data Lakes a lot of people have been moving that's starting to address the data removing the data around it's quite common to, see architectures, employing a. Big data. Sink. To. Stream, information, out of your older legacy, systems and then put read api's on the lake and then surface that up onto your through your online channels, it's a sort of tactic, to, get around some of the the drag in the legacy so, we said that's you, know that's that's. Kind of fairly heati it's quite hot so, a lot of it going on. There's. A risk around some of that come on to in terms of it being a bit of a cul-de-sac, unless. You are really dealing with the right path the update path because. Ultimately it's another cache strategy, really but. The key point is still got months and not days we. Still have. Digital. Channels that are not truly 24/7. And, still rely on you, know update, cycles, that can take many hours particularly, if there's you know complex, systems on the back end. We're. Not seeing enough on or, I I don't think there's enough progress, necessarily. In and around the data I think, there was a survey read recently that seven said 78%, of CIOs. Feel their organizations, are not exploiting, their, data properly, and so.
There Are lots of projects in flights that. Deal with moving data around but, really the in, terms of business, value being driven from that data that it's not quite such a not. That's not quite such a good story and and. Ultimately, this is a bit closest to my heart because I'm a delivery guy at the end of the day. We've. Still got too many dependencies, riddling, our Gantt, charts in all of the software, projects. We're trying to put live we haven't really achieved, that, program, to project. Program. To product. Pivot. That. We talk or a good game around, right. Lean teams Spotify, model yada yada yada but actually we still if you look at any of the work we're doing have big Gantt charts with lots of dependencies, running through, the organization. So. This work to do now the one thing I've put in green is called real-time because I think actually that's that. Is you. Know there's never a silver bullet Frank wouldn't believe me if I said that but I really, want to leave you with the impression that eventing. Is a key, part. Of the success strategy, for, scale as well. As for business, value because you can have business events as Ron I was talking about but, it can be in the DNA of your architecture, which, will fight some of these diseconomies, of scale and, will allow you to pivot more effectively, so. Come on to that so I think I've probably covered that the key point is you, you can spend a lot of money going to the cloud and still end up end up with a pretty brittle application. Right. It'll. Be quicker to get life, you. Can change it faster, but, you've still got to have quite a large, organization. Wrapped around it to do anything, front. To back that, could delivers value to your clients and. I, characterize, that as DevOps, and agile and to. Some extent cloud are essential, but not sufficient, you, need to be thinking about the architecture, we really need to stand up as our architects, in the room and take responsibility, to. Work with art with our teams to define architectures. That will work nicely, on the clouds will, allow our organization, to scale. We. Talked about that in Accenture as digital decoupling, and. And because obviously you know typically, the clients who come to Accenture aren't greenfield clients that have got the luxury of putting all this stuff out there. From. Scratch right, the typically, organizations, that have a load of legacy and technical, debt quite complex organisations, and. We we, advocate taking a value driven approach to modernizing, which, basically means you. Know. Prioritizing. Your portfolio, and, prioritizing. Based on some KPIs, that you are really clear about upfront things. Like average. Cadence. Into production right, total. Software development, size by man-days because that should be getting smaller per release over time. You. Know and, of course all the quality stuff that's in there my. Own pls in, when I when I talk about this is to say you know the enterprise architects, stand up because you should be inheriting, this stuff this is what Enterprise Architecture is really about is, helping. Your organization's, to drive a portfolio, of change that. Will move the needle on your speed to market and your cost of change. Event-driven. Architecture, I've talked about. This. Is the secret sauce this you know I've been working in architectures, where the api's are quite brittle there's, lots of them that, you have a contract dependency.
Through The stack you can be using modern api's and still be quite brittle and the events allow you to reintroduce new functionality, without changing, any of the other functionality, right. And those events could be events could be mini this could be pub/sub right but similarly that those sorts of patterns I think we we can see more of in our architectures, and that, will allow more graceful cost-effective. Rollout. Of capability. Or. Layers. To ecosystem, builds on that I've. Particularly. I don't notice it in financial services but quite a lot of the companies I've worked for they. Are found not prepared to move the data right, so the micro. Services are proxy and it's, sitting above at, the top of that Jurassic, Coast synchronously. Plumbing, all the way down you. Know 40 feet of concrete into, the db2 mainframe, at, the bottom and then if they want to do something experience, layer they add extension, columns in db2 and then. It comes all the way back up in the pin a dependency, graph through the middleware up to the top right. So. If, your micro services layer it looks a bit like that that's you're, not going to drive value you are still doing, one, speed IT if, you don't do anything about the data, you. Tell yourself you're doing something else but, really if you don't move the data around you're doing one speed IT so I'd leave you is think about moving from layers to ecosystem, freestanding. Systems. Of engagement, differentiation. Record, have, their own databases, and talk. To each other in a loosely coupled fashion naive are events but you've actually probably created it made it worse by adding another layer yeah. So. So. I'm. Not pretending that's easy but these are the kinds of things that I think will drive value if you if you if you're thinking about architecture, automate. Everything. We've. Talked a lot about infrastructure, as code I think, the. Next step for. Atom, is. To really go soup-to-nuts on the automation in the service, management and really get into being an SRE, managing. Their operations, and in the sre fashion we'll talk about that in a minute. Cloud. Native but portable, you. Know i'm, kubernetes. Is everywhere. Right, everybody's, talking about kubernetes, I'm getting into a lot of Combinator conversations. About which which kubernetes, and actually. What's the what's my cost of. Making that a bad decision at a point in time do we really understand how I how. Costly is it to reverse out of that and go in a different direction I mean, I think you know call out to what Google are doing enlightened. As usual with, anthos, and. The idea that maybe you can make a decision but hedge your bets a bit I think, is a really grown-up way to do it I think I you. Know the Red Hat OpenShift, stuff. Is simpler, than using native kubernetes, in my experience, so that's another good, option but you should be thinking about. The. Balance and the trade-off, between, exploiting. The. Proven technology, in the cloud with. Their, flexibility, to run multi cloud and move those workloads around. When. I say here be clear on your strategy for cloud native, cloud. Native is, a really overloaded term right, because. On. The one hand it means container, platforms, to, some people mainly infrastructure, II people, I. Probably, got that wrong you know what I mean almost.
Infrastructure, People. It. Means using the clouds features, right so I don't have to build anything I've got their own databases, natively, in the cloud I can use their AI services. It. Can mean that to write. To, me it means like building 12 factor apps so. That's. All that's all fine right but you need to understand in your organization, what what you're actually gonna for and not get confused around what you what, you mean by cloud native and what you're aiming to get from clouds, Nativity. I'd. Add one more which is relevant. Here we're using you. Know with Ronis. Team have been mainly. Focusing on golang, and. That's how and that's got enormous advantages. In terms of its deployment unit size and. Reduce, set of dependencies or no dependencies, it's a real it's a really I, think, an important, feature of running a lean and. Cost-efficient. Cloud, platform. And so there's another angle of cloud Nativity, is are you actually using a programming, language construct. That is tailored. For the cloud or are you just shoveling, loads of Java onto a JVM that ends up with half a gig micro service. Run-time so. So. To, bring it back. API. First Rana talked about the importance of api's to the architecture, at of its how not, only how the whole thing is going to be stitched, together but. Also it facilitates, the transition, states so. To gracefully get, from a from a from, an. On-prem version, to a hybrid version to a full cloud native version, an, event-based architecture. Loosely. Coupling the different components, as they are brought into production. Reducing. Development. Time dependencies. To avoid, big projects, emerging, which carry that that weight we. Talked about gay versus Java talks, about infrastructure, as code. You. Know where next its its build out the story through operations, weaving, our experience, has been the, bit we didn't automate was the bit that added load a load of drag which is kind of shucks we knew could. Have thought of that at the beginning right yeah the, bit we don't do is the bit that causes the drag so suddenly it becomes all about the. Change process, right. The service management process you wrap around building, your environments, commissioning, your your, changes, and all that stuff because we didn't want to make that you can spin these things up in a minute in a minute or two but. If we're on spreadsheets, and emails for the next three weeks trying to work out what we're doing next that kind of is a wasted, opportunity. So. There's more work to. Do around that Bronner. Did you want to pick up on mob not-so-nice do it. Yeah. So. Basically, this boils down to integrating, juror and and ServiceNow for us, right. There's a bit more to it than that but, but, you know having. A having a seamless, transition between a ticket, for a change and unrolling. That into a backlog, for a development team and then, bringing it back into your, release management processes, this. Is the front, line of automation in my view because. That because then you can really bring the whole thing together and start. Then built using that as a springboard to build out more. Of, a kind of, more. Focus on automation in run and in operations, and really bring that kind of site reliability. Set. Of practices, to. The fore so. That's, that's. Broadly where that the journey has been with. With, with, with Adam. And and. They're. Gonna do lots more exciting, things to come yeah it's probably what it's what probably worth pointing out so. Some. Of the tooling sacks we talked about like. Terraform. And volt so, if you think about static, architecture, versus dynamic architecture. Or. Dynamic, infrastructure, so. Old-world, when. You got static architecture, in a datacenter you kind of using tickets to coordinate, manual, workflows to, get stuff done in. The new world what. You want to have is people more, in control of just you know the press of a button we've. Got an environment, being provisioned or a change happening, and so whilst you can still instigated, by a ticket and what we're talking about, we'll use tools, like ServiceNow, to, be. Be mechanism. Of instigating, ticket but that will integrate quite, seamlessly, with the automation, capability. To. Allow you to kind of put provision. Or change into an environment create a new environment to, kill. It can rhyme about you don't need any more right and those. Tools will manage that workflow but, the bulk of the work which, used to be manual it's.
Gone Because, you're doing it through your. DevOps, via saris etc etc yep. And knowing what's in your environments, actually is that day so the CMDB, side, of the. The. Feedback, loop into yours into your config, management, database is a really important feature of that integration, as well so. Final thoughts so. From. Our journey, we. Started. A journey and we, really, needed to kind of really think about what will the outcomes we're looking for, and. Quite. Often you saw a journey and then you kind of have to remind. Yourself, why. Are you doing something and for us is really we, wanted to be able, to create the products and services we want for our customers, and to create, a bank that can. Operate at lower cost by leveraging technology to automate, as much as possible and, the automation wasn't just about cost because you know we're a regulated entity we, don't really want like making mistakes so. By having automation, where you have repeatable, processes, it, minimizes, the human factor of making. Mistakes. Yet, DevOps nodular sensual, but not sufficient, hope I made the point you know architecture. Is really important, you can have them you can have the best DevOps and the best agile but if you've got big monolithic, blob you're. Not going to drive agility. So. I mentioned a number of times to new tools, tools. At alright so do. Not forget the investment, in people and culture quite, often it's, not thought, about for. Us it. Was through, the journey a. Lot. A lot of work has happened getting. People. Together breaking, down silos across different, teams to have a more agile way of working and. Creating a culture of using, the tools in the right way to. Create, outcomes, rather, than trying to do use. The. New tools in the, way we were using the old tools which, effectively wouldn't give you the results you need which is cont point reg was talking about as well so you, know, it's. About the tools the architecture. The people the culture, to get you the outcome you need, but. I thought before about suppliers and partners for, us is very important, we're using this journey to basically. Lock. In two partners, we want to work with to give us a capability, and not, really focus on a purely transactional relationship.
Because. One, you know like, I said before you. Know you will undoubtedly, have you, know blips on your journey. Even. When you in live service but it's really about having a partner to work with for you to, kind of get over that in the, best way possible for, both sides. And. The last one just. To re-emphasize the, point again I think, if we this. Is not merely, purely around the Aten but I think in many examples, if. We'd started again we had the opportunity to go back a year 18 months would have done more right, we'd. Have gone well that was great but all the bits are left out with the bits that still slowing me down so, the, one thing I would leave you is that have wherever you are on your on your roadmap and see if you can do more if. You haven't got to the infrastructure, automate, the infrastructure, right. If, you've got if you plan to automate the infrastructure but you go I'll deal with service management next, year you know this kink this can take time and by and you really don't have the time so you. Know automate, that to get your operational, automation, in place, think. About how far you can push the envelope yeah, I think I think building. On that you're. Never going to be done in terms of you'll have a much you have a view of a milestone you and for, a journey and go right I hit that milestone but you're not really done because you've. Gone through a journey you've automated a number of things spinning to go right but still more to do right and if, you stop. Doing that you'll. Stop, getting, further benefits, that you can for the automation and for a bank is important, because the more you could automate into, a repeatable, process the less mistakes, you make the, less issues you're you'll. Effective. Proliferate into your customers, etc all create more work within the bank as well so you know you just, can't think about projects.
Done Or milestones here you have to think about what's next. So. I think that's us thank. You. We. Could do a couple of questions now or we can we can, we'll hang around at the side to have. A chat any. Burning ones that you want to, raise. Yeah. Yeah at the front here oh sorry, excuse me just one minute yes please so, with. Any questions. About concentration. Risk when you spoke with regulators I. Think. For us because we were looking at. Google. Which, were slightly at. That point in time different, in terms of other banks were looking at a degree s there, was discussions, but the focus was because. We're. Going to Google how do, we see it operating. Obviously. As, part of, various. Discussions, internally. We have to think about you know lock-in. Etc, etc, but. Reg talked about a good point around anthos, and ability. To the. Strategy, of Google to kind of be able to move. Between different providers, or move back into on-prem. So. That was interesting but at, the point where contracting, and force wasn't really. An option so we looked, at basically an option. Of how we, can move away from Google if we had to that's, because we. Were need we, needed to have a documented, exit strategy, okay. And and there was one question from the lady here. Um. This. Was, absolutely fascinating, and really, really useful for me I work. For a financial institution one, of the incumbents, and it's. Extremely. Difficult to get them to actually move. Toward, being, account native, it. Should be very interesting to understand. How. You walk, to with your, executive, board, to, get that buying to. Move towards, this vision okay, so. It's. Quite interesting exam I was on a. F, s panel yesterday, at. Google and same question came about so think, it was part of my job as, one of the executives, of the company or, an X Co to help. Educate. My colleagues about why, we're doing it and how we're gonna do it so, I did a number of teaching sessions at X Co which talks about what is cloud different flavors of cloud etc, and the benefits, and some of the drawbacks, similarly. We did that on DevOps and SOE etc, talked about operating model changes and that. Was to get buy-in so when we talked about discussions through a regulator, those, discussions, are led by you, know one of my colleagues Chris box Chris who's, our chief risk officer, so. He and I went to see the regulator's with, members of our team but. I needed, to be confident that he. Was. Happy. Yeah. Probably not the right word about but he understood. Where we were trying to do and we, had his approval yep. In terms, of he understood we're doing this in a very safe way we. Understood the risks we've, got controls, over, any risks, the mitigations, etc, and. One. Of the. Differentiations. I think I asked him is I. Didn't. Have to go through many hurdles it's, got a flat organization structure. And you. Know we also had sponsorship, of my boss the CEO to, kind of say yeah we'll be doing this and the board as well because. Rightly. OTT on set of Adam it was about we wanted to create a technology organization. That will give us the. Right capabilities, to. Support. Our customers really. Well so it, all fits together. But. I think the education, and communication, is key in terms of making sure all. The executives, of the bank understand, why you want to do this and how.
You're Going to do it and keep reminding them because, it's not a you, know quick journey if, you, know if you if you're not shutting down a data center, it, is somewhat a leap of faith and, on, that basis, it's gotta be sponsorship, from the top not, trying. To convince those in the organization. Who reminded otherwise or, at least clearly. If that's what circumstances, I don't burn it sounds a little hopeless but it's much harder to do to convince people when the business. Case kind of depends, on whether. You're actually retiring a data center or not other than that you can make the case you can do some of the things I did there a bit esoteric but, you can make them. But. It's not as clear so, you need sponsors here. Because. A lot of this for us was around speed and agility and, the cost benefits of that. I think. We're done are we we. All right to take another one no. We are we're out so we will be at the side and look, forward to talking to you then thank. Thank you guys.
2019-12-15 10:08
