The developer-driven bank

Building on yesterday’s blog (Do bank’s need a CIO?) , the key misunderstanding is the role.  Most banks thing the CIO is there to run the technology.  They’re not.  That’s what they used to do.  That’s not the job for the future.

First and foremost, the person leading technology developments in any incumbent bank of any longevity needs to be a Change Agent.  That is because their first job is to change the core systems to open sourced structures based upon cloud, analytics, APIs and AI.  That’s a big job and something I’ve blogged about lots before, so I’m not going to go on about it again today.  The real question is what happens after that job is done?

Well, I got a great insight on this from my friend Sergii Danylenko of PrivatBank.  A technology firm that happens to also offer banking.  As CMO, Sergii is promoting the banks services globally based upon a digital core system in the Cloud, offered as hundreds of APIs in a microservice architecture.

Pardon?

From Wikipedia, for those who are unaware:

Microservices are a more concrete and modern interpretation of service-oriented architecture (SOA). As in SOA, services in a microservice architecture (MSA) are processes that communicate with each other over a network in order to fulfill a goal. Also, as in SOA, these services use technology-agnostic protocols. Microservices' architectural style is a first realisation of SOA that has happened after the introduction of DevOps, and this is becoming the standard for building continuously deployed systems.

Unlike SOA, microservices services are small and the protocols lightweight. The benefit of distributing different responsibilities of the system into different smaller services is that it enhances the cohesion and decreases the coupling. This makes it much easier to change and add functions and qualities to the system at any time. It also allows the architecture of an individual service to emerge through continuous refactoring, and hence reduces the need for a big up-front design and allows for releasing software early and continuously.

Not the best definition, as it is a little too technical.  What it’s really saying is that you need to break apart all the processes that need to be done and make them tiny apps.  These apps are developed individually and put into the network.  Thanks to standards, all these tiny pieces can then be put together into a bigger whole that is easy to maintain and is robust, mainly because it’s just tiny bits that are being changed and maintained, not some huge monolithic structure.

Now that’s very different to the old bank systems I’m used to dealing with.  The old systems I dealt with involved thousands of line of code, and needed heavy change controls as any code update could ripple across the whole system and break it.  In a microservice architecture, it’s the other way around.  You can change anything, anytime, because they’re all independent, separated and distributed.

This concept was discussed in depth in the Andreessen Horowitz podcast last week.

The podcast is an interview with  Adrian Cockcroft, fomer Cloud Architect at Netflix.  He talks aboutg the move from DVDs to streaming, and how that forced a massive change in their technology structure.  The key to this interview is that businesses are now being built on a microprocess.  Take Stripe.  Stripe is just a checkout API that simplifies things for merchants.  Yep.

Analysts estimate that the company processes about $20 billion in transactions a year. At that rate, it’s revenues would be close to $450 million as of 2015. In 2013, revenues would have been closer to $43.5 billion given its transaction levels. It is able to support transactions in more than 100 currencies globally.

Stripe is venture funded so far with $280 million raised from investors including Visa, Thrive Capital, Khosla Ventures, Founders Fund, General Catalyst Partners, Sequoia Capital, Allen & Company, Y Combinator, SV Angel, Aaron Levie, Chris Dixon, Elad Gil, Peter Thiel, Elon Musk, and Andreessen Horowitz. Its last round of funding was held in July 2015 when it raised $90 million in a round led by Visa at a valuation of $5 billion. In December 2014, the company had raised $70 million at a valuation of $3.5 billion, having grown from a $1.75 billion valuation round held in January 2014.

Not bad for a microservice.

In other words, there is a FinTech view that believes we can uncouple all the functions and processes from the products and providers and offer them as microservices that, through DevOps, Cloud and APIs, can be reimagined into any business model and structure you like.

During the interview with Adrian, there are some key messages:

• Functions are now the major companies
• There are no more cathedrals, just bazaars
• Apps are now the infrastructure
• Developer driven design is key
• There is no central monolith - it's all micro-as-a-service
• If you're working as a developer in a waterfall organization, it's soul destroying
• When developers own the design of their product, it's far more agile and fun

These messages are ones banks need to listen and learn from, as many banks I deal with control things top-down.  The idea of distributing control to developers would be heresy.  And yet, this is what must be done.  A key discussion point in the middle of the podcast illustrates the key:

Because there is a little piece of PCI compliance required in this tiny little corner of the monolith, the entire monolith is now subject to PCI compliance, SOX compliance and all these things. By splitting it up into pieces (a developer driven microservices architecture), you can be extremely agile and very innovative. The bits that have to be safe can be extremely safe and, looking at the attack surface, you are keeping very tight control of what can go wrong. If you connect into the databases, you've got single purpose connections into the database that are doing one thing. You can start to control every access level there as well.  What used to be policy controlled by the operations people, as what they thought was a safe sandbox for the developers, is now the other way around. 

This idea of developer driven infrastructure is something that is turning things around.

What I am seeing is big banks have their existing policy frameworks and rules, and they're trying to apply it in the new world. It looks the same, so they're happy because they're compliant.  But they no longer have the policy separation that they think they have, because it's all totally reprogrammable. It's then just an illusion that you are conforming to the policy.

A lot of these things were Ops controlled. The Ops controlled the data centre and then the networks in the data centre, and now it's all developer defined and software constructs controlled by your Cloud APIs. If you're updating it ten times a day, there isn't enough time to have ten meetings a day with Ops to do the hand-off. What we've been seeing is people just running it themselves. The only person that knows the exact state of the system is the developer that has just updated it. That sounds scary until you realize that each of them is controlling a very small piece of the system, and the aggregate behaviour of the system turns out to be more robust and reliable. 

Does your bank distribute control of your systems to all your developers in a microservice architecture?  I doubt it for the reasons given yesterday but, if your bank is to be relevant in a world of marketplaces, platforms, microservices and open sourcing, then that’s exactly what you need to do.

More on this in the third part of this blog.