25 May 2017
Joris Lochy

92058

Joris Lochy - The Glue

1Posts 7,068Views 0Comments

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

07 April 2017  |  7069 views  |  2

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 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.

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 commmunication 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.

 

TagsMobile & onlineStart ups

Comments: (2)

Alexander Mifsud
Alexander Mifsud - Ixaris Systems Ltd - London | 10 April, 2017, 17:19

I couldn't agree more. One approach that the financial services industry seems to have overlooked up to now is Model-Driven Engineering which involves assembling models (in our case Payment Models) from such Lego blocks  (which are called Paylets). At the Open Payments Cloud hackathon in London this weekend, 9 teams of mostly non specialist developers were able to develop a range of applications that rely on complex payment flows simply by relying on a model-based approach.

  

 

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune | 10 April, 2017, 20:14

Reminds me of 20 years ago when I used to be working for an ERP company. We positioned our software as lego blocks versus competition's jigsaw architecture! 

It has become fashionable for banks to say that they're tech companies in the business of banking. They might reject assembly-based software development just because it'd make them "... focus again on what they are good at, i.e. providing financial services rather than solving technical issues.":)

Having worked in the software industry for over two decades, I totally agree with you that the biggest hurdle to reuse of software components is the programmers' emotional attachment to their solutions. But, alongside that, we must be mindful of the fact that many software buyers continue to believe that software provides competitive advantage to their companies, so the software owning company also tends to have a lot of "emotional attachment" to the solution.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Comment on this story (membership required)

Latest posts from

Joris's profile

job title Product Manager
location Diegem
member since 2017
Summary profile See full profile »
The Glue is a contemporary, new solution which enables financial institutions to quickly develop innovative financial services. I am responsible for: - Defining the functional product roadmap -...

Joris's expertise

Member since 2017
0 posts0 comments
What Joris reads
Joris writes about
Mobile & onlineStart ups
Joris's blog archive
April 2017 (1)

Who's commenting on Joris's posts

Ketharaman Swaminathan
Alexander Mifsud