I was listening to someone talking about monolith versus microservices structures recently, and they likened it to an old car versus a new one. Old cars were made of metal and welded together into a solid machine where, if any part breaks, you have to replace the whole machine. The machine is unwieldy, slow and hard to change. A new car is moulded and put together as a network of components. Each component is independent of the machine, and can be therefore switched out quickly and easily and replaced. The machine is fast, easy and speedy to change.
Nice analogy, and speaks to two themes that I would advocate for any organisation.
The first is how to organise your developer team. I always fall back to the discussion with one start-up who uses Amazon’s two pizza approach as their focus. Each Amazon development team is structured to a size where they can be fed with a maximum of two pizzas for lunch. For Jeff Bezos, small teams make it easier to communicate more effectively, to stay decentralised and moving fast, and encourage high autonomy and innovation. This is so obviously the case today in an API marketplace structure that it demands such decentralised approaches.
The second theme is how a bank should structure. A bank has historically controlled everything in their value chain, and tightly coupled that chain. Banks do not trust decentralisation, but want close control as that allows them to secure everything. Security and control avoids risks and exposures, so a heavy metal machine is far better than a light plastic one. But if a bank continues to try to control the value chain then, as I’ve written many times, it will make them slow and resistant to change which, in today’s Open Banking world, will signal irrelevance and obsolescence.
For these reasons, a bank needs to decentralise their internal structures and open their eyes to external opportunities to source components of their value chain through APIs.
Now I know that many banks are doing this, especially the usual suspects who market themselves as technology companies offering digital banking. For example, many banks have innovation labs and development portals like those of Citibank and Deutsche Bank. A growing number have API (Application Programming Interfaces) marketplaces like those of BBVA and DBS (nearing 200 APIs) .
This shows the eagerness of the banks to change, and the fact they are changing. However, I have heard several comments from some of these banks expressing concern about the alignment of their digital innovation initiatives and the lines of business they are trying to change and serve. This stretches to the heart of why I talk about the major risk in banking today is a lack of digital leadership.
Many bankers are asked if they’re working on Open Banking and APIs and many may start by a frown, wondering what the hell you’re talking about, whilst others may be aware, but they don’t see it as their turf. It’s being dealt with by the CIO.
This is why I keep saying that digital is a cultural and business transformation programme, and not a project or a function. Digital yes, involves opening up through APIs and SDKs (Software Developer Kits) but, far more importantly, is aligning the changes to the products, services and line of business needs, and getting those line of business leaders to be aware, involved and articulating the change to their teams, clients and customers.
Without the latter, it’s a bit like throwing technology at a wall. It just breaks.