Is Lego building the new way of creating applications in the Financial Services sector?

The dream of any product manager in the Financial Services sector has always been to come up with an idea for a new (or improvement on an existing) financial product or service in the morning and have it implemented in the afternoon.

Unfortunately the harsh reality is that adapting the IT solutions typically takes months, if not years. Despite years of evolution in software engineering and the best intentions of all involved parties, the speed of software delivery has not much improved (if not to say worsened) in the financial sector.
Introduction of new programming paradigms (Object-Oriented Programming, Event-driven Programming, Functional Programming…​), new implementation methodologies and organizational styles (Agile, DevOps, Extreme Programming, Development Anarchy…​), new programming languages (Go, Scala, Kotlin, Python…​) and new programming frameworks (Spring, Angular 2, React, Ruby on Rails…​) are the order of the day, but do not live up to their promises.

The reality is that there is no silver bullet and that building software is hard. Maybe the solution is therefore not just finding ways to accelerate software development, but instead avoid as much as possible programming itself. This brings us to another dream, this time the dream of the software designers or software architects, who want to build software which is reused across the organisation. Already in the 1960s, the term "modular programming" was introduced aiming to separate code in (smaller) blocks, called modules, which could potentially be reused. Just as the dream of fast, agile software development, this dream of reusability has also been around for quite some time. Unfortunately this dream has not become reality either: despite significant evolutions, reusing code is still rare in the financial services industry.

This lack of reuse can be explained by many factors: bad componentization of the software (i.e. bad interfaces, insufficient encapsulation…​), not knowing which reusable components exist in the organisation (or more general in the world), bad documentation of reusable components (i.e. how they can be called and what the component exactly does), new standards and technologies forcing to rewrite old components (e.g. in new programming languages)…​ just to name a few. But often the most important reason is that programmers adore to create their own solution, rather than reusing something existing.

Times are however changing. With the Financial Service industry undergoing one of the most profound transformations in its history, the challenges are immense: changing customer needs and expectations, a tsunami of new regulations, fierce competition of new FinTech players, the search for new revenues and cost reductions due to the historically low interest rates…​ These challenges will force banks and insurers to deliver more agile and with shorter time to market and force IT departments not to reinvent the wheel, but reuse existing components as much as possible.

Just like building Lego, a new business product or service should be built up from blocks, instead of creating the full product from scratch. However contrary to traditional Lego, the composition can happen at different levels:

• At the fine-grained level, we have the Lego building blocks. These are individual atomic components, which can be reused. As in Lego they can’t be broken down and have a clear connection mechanism, but they don’t provide a direct business added value. A typical example of such a reuse is the reuse of software libraries. Today there is a variety of sites, which allow to download libraries for any problem and for any programming language (e.g. Apache Commons, GitHub…​).

• At the mid-grained level, we have the Lego functional and technical blocks providing a specific feature and built up of the atomic Lego blocks. Here we should make the distinction between technical services and business services. Examples of technical services are service discovery (automatic detection of services), tracing and logging, monitoring, security, messaging…​ For all those services, several open source software packages exist, which bring best-practices to the table (e.g. ZooKeeper, ElasticSearch, Logstash, Kibana, KeyCloak, Kafka…​).
  For the business services, we should consider the internal micro-services available in the organisation (if the organisation has already evolved towards a micro-service based architecture). Such a micro-service provides one specific functionality, which is well encapsulated and has a clearly documented interface.

• Finally at the coarse-grained level, we have the entire Lego systems, i.e. a composition of functional and technical services providing an end-to-end product, also exposed by well documented public APIs. With the rise of Open Banking (i.e. banks exposing their services to other parties), the exponential growth of FinTech companies and the increasing list of API services provided by cloud providers (e.g. BigQuery from Google), banks have an almost unlimited choice of products they can assemble in a true API ecosystem.
  Today most banks are still providing only internal products and services to their customers, but if banks want to stop losing market share to FinTechs, they should partner up with FinTechs and other banks to offer all (internal and external) best-in-breed products and services to their customers.
  In other sectors, firms built up of APIs of other companies are already common good. Take the example of Uber. Today Uber has a market capitalization close to that of BMW, but at its base it is built up as a composition of multiple API services offered by other companies, e.g. geo-location is done by the operating system (iOS and Android), route calculation and maps are provided by MapKit and Google Maps, real time text messages are sent to customers by Twilio, payments are handled by Braintree, the receipt is sent via Mandrill and the services are hosted in the cloud on Amazon Web Services (AWS).

Despite those possibilities of reuse and independent of the level of the component assembly, the issue remains always to

• Know what exists, find the right library/service/system/API for your problem and find the necessary documentation to quickly understand the component.
  For the API ecosystem, this mainly consists of knowing the FinTech landscape. This search can be facilitated by FinTech communities, like e.g. B-Hive in Belgium.
• Integrate the different components in a well-working integrated solution. Also here software developers should avoid reinventing the wheel for managing the integration aspects, like managing communication between components, error handling, monitoring, service discovery, high availability management…​ Instead they should use a platform facilitating these glue aspects out-of-the-box.

When those issues are tackled and the building blocks from the different levels are correctly assembled, the need for programming can be significantly reduced and the speed of delivery can be exponentially increased.
This type of assembly-software-engineering allows banks and insurers to focus again on what they are good at, i.e. providing financial services rather than solving technical issues. At the same time it means that the organizational structures can be simplified. When programming efforts are minimized, small local teams (rather than complex organisations of multiple outsourcing vendors) composed of both IT and business people, can quickly create business added value.

Maybe by doing so, we can finally realize both the dreams of the product managers and the software architects.