How To Use Sign in Banking

How to industry sign banking use

is Matt Lancaster he is the global lead for lightweight architectures at Accenture the global lead of lightweight architectures come up here a big guy he's talking about how they've used event-driven systems to transform some core banking and how financial services are innovating quickly with this tech already so if we can take a couple of things for granted just as industry trends and I want to take us a little bit outside of the technology for a second and just talk about the bit the sort of business drivers that are behind a lot of this stuff and why and in many cases we need to move to an event-driven future and in a lot of traditional industries otherwise they're going to be disrupted cannibalized and something else is going to come out of them right so there's there's this accelerating trend to for every company to become a software company especially in financial services where the the product was already sort of at arm's length in many cases our friend from from Capital One earlier can can probably tell us tell us quite a bit about that as well and then just you know creating more interactive systems creating new financial products and actually getting those out to the marketplace quickly responding to regulators in an agile way right all of this stuff has become an increasing challenge as they they have adopted what I like to call the the architecture of the Gordian knot right literally everything is there are these big monoliths that are that are all interdependent and intertwined and kind of gross so we need to make sure that we that we shift to nicely decoupled event-driven systems that can be released quickly you know microservices functions all that all the good stuff we've all talked about right the challenge and in a pretty traditional industry in that case is that you have systems that not only are 30 years old or 40 years old in many cases but that have been continuously developed for 30 or 40 years a lot a lot of the early adopters of computing in the in the 60s 70s and 80s built a lot of this these big mainframe systems a lot of complex business rules and business logic and logic that has been sort of updated slowly for an evolving regulatory environment and an evolving product and environment an evolving way that customers expect to interact with the bank right and a lot of this logic has been there for a long time or has been updated and you don't necessarily know what touches what right the it's sort of the our standard DevOps problem where how what's your unit test coverage on this code we don't know somewhere close to 0% right so how do we actually build really interesting cool products on top of that remain relevant in the marketplace but still you know still have to deal with the the the anchor behind the speedboat so to speak so a couple a couple of things to keep us keep us grounded we can't replace a legacy with greenfield quickly even though we don't like to but we do need the ability to build on top of what is already there to move fast so that that's going to become one of our core business problems to think through and our core technical problems to think through in terms of you know customers demanding better experience as we all know that that stuff and the regulations here to stay we can't we can't get around that so you know when we talk about things like continuous deployment continuous delivery that doesn't necessarily exist in highly regulated industries because you have to literally have someone to sign off on certain things right so so you have to work that into the process as well so so let's actually talk through this so we have here's the business situation of nearly every bank on the planet right now you have mainframes that are still running a large amount of the backend business logic a large amount of the business is actually run through that so trillions of dollars of transactions mainframe costs are going up every year right steadily generally about five percent a year that's a Gartner number that's not mine then we have an explosion of different devices in different channels to actually interact with your financial information through so not only through your phone your tablet your laptop but also different services like like like a lot of the a lot of the stuff that will help you find a credit score or help you plan for for certain savings and stuff like that those are all accessing your banking information right it's actually getting that stuff out of there means getting more information out of that mainframe environment in many cases and and and we're kind of stuck in a catch-22 in the industry which is write operations costs just as much as read operations and we all pay the the mainframe vendors for the privilege of using our own systems right so that's one of those major cost areas that we can actually attack immediately and get a bit of breathing room to to start to innovate on top but how do we unlock the data from that environment and then we also have very slow innovation in many cases a lot of that stuff like I said before you know the architecture is all put together the teams are structured in such a way that it's very difficult to to get anything done and you end up having sort of security theater environments that don't necessarily make our infrastructure and architecture more secure it just makes it more difficult to do our jobs so I'm not going to cover all of that right now what I do want to want to talk about is a particular business case so I had a team in Austria that this was this is a little some of the technologies a little dated because it was 2014-2015 but I think it's a really interesting business case if how to move to micro services how to move to a really event-driven streaming architecture and still sort of coexist and build the plane in the air with the existing systems so one of the things we took for granted is that we're not going to rewrite and extract all of that business logic right away it exists in the mainframe so the right activity at least in at least in phase one of the overall program the right activity needs to stay worth that right so anytime we anytime we actually make a transaction it needs to go back through the mainframe needs to go back through all that nasty business logic and actually post somewhere right but for read activity we don't actually have to go back to db2 right we don't have to go back to the big database we can do something more interesting which so what we ended up doing in that in that situation was put a little little reader sitting on top of the commit log bb2 right so all day all databases are really only three things right there the the data and big binary blobs that are sitting in various storage partitions the actual application logic of the database and then there's a big essentially glorified text file that is the set that is actually the single source of truth for the database whether it's Oracle or db2 or any of any of the old sequel databases right it's it's just a big insert insert update read etc all those operations are stored in that commit log you play back from it when you roll back etc etc so if we read the changes directly to the commit log and we sit it really close and we read replicate those changes out to in this case it was Hadoop I probably would do it with something more interesting today but read replicas out out to Hadoop by the time the record was unlocked by db2 most of the time it was already it was already replicated out at sub-second replication for for inserts or for changes to the to the legacy database so now we have a full replica of that database that we can start to do interesting stuff too because we haven't in a really fast data environment right so all of this stuff is sitting on top of HBase building so we can build some micro services running off the same JVMs because HBase is pretty its CPU from the nodes so we can sort of have co-tenant architecture there these folks were in their own data centers and in in rented data centers because the regulations in the EU prevented them from being in the public cloud that may no longer be true soon enough and we'll be able to use a lot of cool AWS stuff but for for the time being it was locked in there and their existing environments so one of the other interesting things here is that since we can stream this data out suddenly all of those transactions we can feed to an event log and then we can start to attach and do more and more and more interesting things with it we'll get one into one of those particular business case this is just a second so when we did this it actually took about seven months and eight people right to pull all of this out I'll share some of the business results of it in a second which which were actually really really interesting one of the things that happened in the middle of the this program was that a new EU regulation came down that had much more stringent fraud detection requirements for for-4 basically your commercial banking transactions right so most of the competition set for for our client was running around with their you know running around like the world was on fire because they were only given 7 months to implement this this new fairly stringent fraud detection regulation and you can imagine in that world that's that's actually a at least to their traditional waterfall mindset with really big release cycles and five months in many cases in digression integration testing cycles four core system changes that's a huge huge deal so we were actually able to do that in three and a half weeks because we just read the changes on the new on the new data environment read in UI changes from the mobile apps and from the from the web and then looked for fraudulent activity and then and then paint and then that we're able to kick people out from there right so we used our read copy of the data to do to do a new business function that wouldn't have been possible without essentially sort of graphing a nice event-driven architecture nice set of micro services on top of the legacy architecture and sort of slowly starting to build value on top of that right and and it was actually kind of interesting because when you when you look at it if somebody is accessing their accounts in Vienna and they they're following sort of their normal patterns they're probably just fine right they're accessing it from Thailand and they're behaving really weirdly about filling out a mortgage application you may actually want to engage you know pull the pull the pull the emergency brake there right so so actually being able to look at that data and look at where they're at we have all of that is essentially data exhaust of right activity and then the read copy that we have right so we can suddenly start to do much more interesting things so on top of that some of these micro services started to extract business logic for new products business logic for making modifications to existing products to make them a bit more more friendly and more user experience friendly we can slowly extract that stuff out of the mainframe because we've isolated a lot of the big mainframe components such that it becomes a routing problem to move around them as opposed to actually changing anything in COBOL that somebody somebody who's now ninety and retired in Florida wrote right so so some some interesting stuff can go on there and the happy accident of this or the actually the original business case the the the speed to market and all that was the happy accident the original business case was just reducing mainframe cost within that first seven month project the the mainframe cost was reduced by fifty percent because we reduced the CPU load on the mainframe by fifty percent just because we rerouted all of the read transactions that no longer needed to be there right so that the project paid for it the first project paid for itself and paid for the second project in just reduction in effects right so the the message that I want to leave you with with that is that in any industry right there's really clever things that we can do with the tools that we have at hand with a lot of the patterns that we've been talking about all day a lot of the technologies to not only create new innovative things not only to essentially you know sort of flip how we're doing the user experience and the digital engagement of a lot of these customer facing systems it can also be a cost play and it can also be a time to market and and sort of you know mature product play right that that becomes a very very powerful thing when we're trying to negotiate for money for a few shekels from the business in many cases well you know if we do this we can also reduce costs and have it and have a 12-month payback period that starts to become music to a CFOs years right so that got us to thinking what if we could replicate this kind of success on top of multiple mainframe ish or big J EE or big sort of traditional monolithic environments alright so how would we actually design a reference architecture where we could have a repeatable process to build on top of that and and right now it's mostly focused in the banking world have a few I have a few folks who are working with actually implement this but it should look strikingly like a lot of the things that we've already discussed today you can see a set of microservices that are handling rest transactions but they're only communicating with the backend through an event stream kind of sounds like an event sourcing pattern right you have a set of utility services that are listening to the event stream and then acting upon the acting upon the rest of the system and then we're able to actually you know have real-time analytics real-time say next best offer so if you can imagine that the real-life scenarios of this if you're filling out a mortgage form but we can tell halfway through that you don't actually qualify for what you're filling out we can give you something that you do qualify for and potentially keep you as a customer because we're listening to the events that are coming off of you filling out that form or we can have a customer service agent literally share the same screen with you because we're just capturing the Dom events right because all of this is you know there's their synchronous transactions as far as submitting forms what-have-you but most of it is is streamed over either web sockets or MQTT or what-have-you so a couple of other interesting things that come out of that so it's specifically in the in the financial services world but I suspect in many other places as well there's there's a really strong almost religious attachment to the concept of a session right you need that sort of transaction integrity right I see I see laughing from the other banking guy here it's like yeah that they they Isis pecked that some of the some of the the older VPS and many banks have an altar somewhere in there somewhere in their house where they sacrifice to the session gods right and and so but they actually have a point right because you need to be able to guarantee transaction integrity you need to be able to play it back you need to be able to send transactions in order to regulators so that they know everything's on the up-and-up there's there's a lot of there's a lot of heavyweight behind that and and frankly that's that's that's sort of how you know it's how a lot of the backend business processes work so we we need to have you know nice double handshake acid compliant transactions in many cases but what is that what is the concept of sticky sessions leave us with with our services with the rest our architecture it has a massive trade-off right we we find it very very difficult to to be scalable to be distributed to have developers work on isolated pieces right so so what we're doing here that's a little bit difference is we have this thing up at the top that we that we called the reactive API gateway already been talking to the the serverless folks about doing a little bit of integration with with what they're doing but well what we care about here is number one that we can apply standard sort of API gateway which policies regex security policies etc to streaming connections as well as rest in a really really lightweight way and keep track of what c stomer or what node the particular set of transactions is connected to and be able to order those play them back in order send send them out across the stream etc without having any concept of sticky session in the rest of the system so we used probably one of my favorite sets of technology is that in the enterprise world I haven't gotten to use a whole lot I got to I tend to be a powerpoint engineer these days a lot and I got to actually write some Erlang code for the first time in like three years and I was super happy about it and then my whole organization was like hey can you come up for air and actually answer our questions and do stuff it's like I'm coding it's fun right but we wrote that in an elixir built a lot of interesting stuff there we're keeping track track of the transactions vsc Rd T's so you know keeping them keeping them ordered getting getting them tagged to a particular customer I always like to call it a customer centric architecture because everything's based around the customer transactions whether it's commercial or or whether it's it's you know personal commercial banking or whether it's you know business banking etc the other interesting thing here is that this read replication system we've sort of industrialized that a little bit so that we can get get data out of the legacy system and oftentimes the the communication pattern back with the mainframe is will drop us if it's if it's queue based will drop a single message on the queue and do sort of a micro batch or communicate with it over actually hooking into the transaction manager which is actually fairly fairly parallelized itself it's just an internal communication mechanism so we can do a couple of different things but what that ultimately does for us is separates out the different the different sort of core pieces of the back-end architecture and allows us to you know treat them separately right and when we start to pull out functionality and and deliver incremental value to the business right when they ask for X to be done in X amount of time with different systems of record etc we can pull that pull that stuff out eventually sort of reroute away from the mainframe and maybe three or four years down the road have the have the holy grail conversation in in most traditional enterprises which is maybe we can shut this thing off right so one of the one of the big things to kind of kind of talk through there I have another another client we're doing this in the hospitality space a couple of my colleagues back there familiar with where we're already two years down this journey and we've turned off half of the mainframe environment and two years from now we'll be able to turn off the rest of it right but but it was largely through the initial set of cost savings that we're able to bring in the initial set of sort of speed to market or in some of their new products integrating new brands doing new experiences for some of their hotel hotel brands that were focused toward toward younger customers where they you know we all expect a little bit more high tech approach so moving reservations and loyalty to a set of to a set of set of services sitting in front of a big kafka stream and then eventually hooking that into the rest of the customer facing system so we can make really interesting intelligent decisions like maybe if you're coming close to the hotel and you're ready to check in that day we can check you in and have somebody greets you by name rather than you walking up to the desk and you it's always funny and in sort of the coded business speech that a lot of these folks have when you walk up to the front desk and somebody says hi how are you doing can I see your ID it's really code for who the hell are you and why are you here right which is not a very hospitable interaction if you think about it right at break it breaks the the immersiveness and kind of the customer experience in that space if we if we can use all of the intelligence that we have to actually you know talk to you and know who you are and already have you checked in already have your rewards amenity ready etc etc we're using the same event-driven paradigm that we're talking about in terms of the the technology side of it to to sort of hack the business side of it as well right the colleague who's here that's I think one of his favorite things to say around this is maybe we can get rid of the front desk entirely right why do we need queues in real life when we can have parallel streams and just serve people quickly get them what they need and get them on their way so you know how would we think about hooking onto those back-end systems in other industries and other places using some of these concepts of the the standard reference architecture pulling pulling pulling out pulling out some of the the business functionality piece by piece right putting it into whether it's functions or micro services I think in that case most of the time it really doesn't matter right as long as long as we have a good set of patterns and we've usually chosen a few technologies that we're gonna gonna coalesce around I see a lot of these these efforts fail both in the startup space and in an enterprise where when we move to micro services it becomes the Wild West and there's 75 different technologies that everybody everybody is picking up you know there's a bunch of stuff sitting on lambda there's a bunch of stuff that some guy and that that is in the basement of one of the offices written wrote in roading golang for some reason and then there's there's a bunch of node stuff in a bunch of legacy net stuff and then suddenly there's there's 80 different pipelines for all of this and you have you have docker you have you know your event gateway you have all kinds of different stuff to manage the spaghetti that you've just built for yourself you know there's there's good solid patterns that we can attach a few technologies to and then and then sort of industrialize and repeat right and the the I think the hardest thing here is moving in this direction once once we get once we get the the right technology sitting on top of the legacy applications and in many ways in the legacy business right is to you know the technology is one leg of the three-legged stool we have to we have to figure out how to make sure that the delivery process and the engineering systems are in line but I think more importantly we need to to work with the business folks and actually get them working in the same way where they're focused on the individual product areas rather than you know there's these big sort of integrations it's not an easy thing right but when we can when we can initially deliver okay here's your cost savings here's your 12-month payback period on the initial project now we can now we can deliver in two weeks to a month for fairly large pieces of functionality that it used to take you years to get you suddenly get folks that start to start to question their old religious beliefs right and then you slowly bring them in to new projects and then you get evangelists that can come down from the shining city on the hill that you just built and and convert the rest of the masses and so and suddenly we're all living in a world that we want to live in where this this technology isn't just the fringe stuff that we can all get excited about in the bleeding edge it's actually the the suddenly becomes the new core business systems that you know Sunday can become Sunday again because we don't have all the nasty outages and and whatnot with that traditional error prone systems are susceptible to I mean you guys at Nordstrom you've probably never had a big big outage of core retail systems anywhere around like Black Friday or anything like that never happens you know it's it's one of the great things about about moving in this direction is we take so much load off of the traditional systems that is cost savings that's great but we're also acting as a back pressure valve right when you have a synchronous load environments or you have services that you have to stand up for a short period in a short period of time if you're building that on technology that was fundamentally designed to lock threads until it tips over you're gonna be in for a bad experience if you have more customer influx than you want if you build it on something that's naturally designed to scale out then then you're building for resiliency and sort of rather than protecting from failure which is the old mindset you're essentially embracing failure and then and then letting it letting it only affect one or two folks right so looks like I'm running out of time here so any any questions or comments or horror stories from from anybody else hmm that's a longer conversation but the first part of the answer which is it's just the most cop-out piece I promise then I can get into more of it but it's carefully but I think one of the one of the thing one of the soapbox is I often get up on is that we've forgotten some of the brass tacks stuff that we used to do in technology really well like domain-driven design and some of the some of the other fundamentals if we separate out those big nasty pieces of the mainframe into core business areas then we do we do have to do some code analysis and see where things are ticking but we can usually rope it off to a pretty pretty good degree of certainty and then then extract it piece by piece into new services and as and as we do that rather than route those particular transactions back to the mainframe we just intercept it and route it to the new services and then it slowly gets replaced and strangled off and it's replaced and strangled off with things that have all their unit test coverage that have the definitions have done and can actually be completed right and so so you get this sort of combinatory effect where you can start to tackle more of these a little bit more confidently then you can attack the really big ones that are spidered everywhere right and then eventually that not you you you cut it to death by strands and then you can unhook it oh yeah absolutely absolutely I have a client I have a client in the UK who they had they had a major system issue they had to bring back an 85 year old woman from retirement to to look at the system and actually fix the problem because she was one of the original authors she was the last one left from from about 30 people that had actually built it and and had they not been able to do that they would have had to rebuild a good portion of it and this is this is a big big retailer so you can imagine how screwed they would have been had they been down for more than two days right especially around the November time frame so absolutely there's a big Doomsday Clock and I think the the hesitancy is that a lot of folks have tried to move to this a couple times and they failed because they tried these big bang big replacement projects where they can turn a key what we're talking about is is is implementing the Strangler pattern we have my marketing folks have a nicer term for it which we call it hollowing out the core right because Strangler pattern sound sounds sounds slightly slightly serial-killer ii but you know Joe hopefully we'll all be able to move in this direction as we move forward and keep in mind some of the business case stuff because it really can convince the folks who don't necessarily understand the nitty-gritty of of event sourcing and what-have-you any other questions all right thank you very much Matt [Applause]