Skip to main content

Abstraction in Financial IT - How far can and should we go?


Abstraction is a fundamental concept in software engineering. An abstraction is a simplified version of something technical (with unwanted details omitted), which allows to hide away complexity via a simpler "interface" and is the main tool of a software engineer to cope with the ever-increasing complexity. Normally every programmer/user would need to resolve the complexity individually, but through the abstraction (creating a sort of black box in which the complexity is concealed) it is done for him.
It is therefore not surprising that in recent years we have added dozens of abstraction levels in the implementation of software products. These abstractions provide several advantages, like reduced complexity (easier and simpler), improved productivity (higher efficiency, easier reusability and reduced time to market) and a better encapsulation (increased inter-operability and easier replacement). With all those advantages, it is no wonder that abstraction has such a widespread usage.
Abstraction is everywhere in computer engineering, e.g.
  • Computer programming abstractions:
    • Machine code: the ones and zeroes are an abstract representation of the electromagnetic signals flowing through the wires and computer chips.
    • Assembler: hides away the machine code, allowing a programmer to work with a more intuitive set of commands
    • Programming language: different programming languages exist with different levels of abstraction. These programming languages abstract away the complexities of an assembler, allowing a programmer to work with higher-level instructions (like e.g. for-loops and if-then-else conditions), which can represent dozens of assembler instructions. E.g. 1 line of Ruby code will be transformed by the compiler to a small novel in machine code. These abstractions make the code easier to read, simpler to write and much more efficient (a few commands give the same result as dozens of lines of a lower-level language).
      Picture below gives an overview of the abstraction levels of different programming languages (http://www.codecommit.com/blog/java/defining-high-mid-and-low-level-languages) with red being a low level of abstraction and green a high level of abstraction.
    • Within a programming language, some features like subroutines, modules, polymorphism…​ allow a programmer to create his own abstractions within the program.

    • Where a programming language typically allows to implement any type of application, there are also DSLs (Domain-specific languages), which provide further abstraction, but are also specialized to a particular application domain.
  • Infrastructure abstraction:
    • Virtual machines: allow to abstract away a physical machine in order to create a number of virtual machines
    • Operating systems: abstract away all complexities of interacting with in- and outputs (like screen, keyboard, mouse, printer…​), memory management, disk and file management, networking…​
    • Docker containers: abstraction at the application level layer that packages code and its dependencies together.
    • Container management systems (Kubernetes): acts as a sort of operating system for distributed systems, allowing to abstract away a group of servers and manage them as 1 (cluster).
  • Cloud provider abstraction: cloud providers are continuously adding abstraction levels, making the architecture more and more "cloudy":
    • Hardware abstraction: cloud providers first started to abstract away the underlying hardware resources, allowing users to pay-as-you-go for services such as storage, networking, and virtualization, i.e. Infrastructure as a Service (IaaS).
    • Managed services: gradually cloud providers moved the abstraction levels up to managed databases (like AWS Aurora, RDS or Dynamo DB, Azure’s Cosmos DB or Google’s Bigtable), managed monitoring and logging solutions (e.g. Amazon CloudWatch), managed container management systems (like Amazon EKS, Google Cloud Kubernetes Engine or Azure Kubernetes Service), pre-loaded application software like web servers or CRM solutions…​
    • Serverless: allows to abstract away servers completely, making functions run as a service (i.e. hardware resources are only attributed at the moment of the execution of the function), e.g. AWS Lambda, Google Cloud Functions, Azure Functions or IBM OpenWhisk
    • Specialized abstractions, like Machine Learning abstractions (e.g. GCP TensorFlow or Azure Machine Learning), sending communications like SMS’es and mails (Amazon SNS), CI/CD pipelines (e.g. AWS CodeCommit, CodePipeline, CodeStar and CodeDeploy) or even abstracting away manual tasks, i.e. crowdsourced labor (via Amazon Mechanical Turk).
  • Solution architecture abstraction: within a solution architecture, software engineers also try to componentize the application landscape in smaller (and hopefully simpler) blocks, which are a maximum encapsulated from each other. This gave rise to different architectural principles, like ESBs and SOAP and more recently to the micro-service based architecture. In this architecture, processes are encapsulated into a micro-service, which is a black-box and communicates to the outside world via a well-defined and usually simple interface, called an API.
  • …​
Typically, every new abstraction which is created, gives rise to the creation of new abstractions to hide the new complexities introduced by the new abstraction layer. E.g. the rise of Kubernetes has resulted in dozens of new abstractions like pre-defined Kubernetes setups (like Kops, Bootkube…​), serverless setups based on Kubernetes (like Kubeless, Knative, Fission), shells and dashboards, service meshes (abstract away complexity of services communicating which each other, i.e. security, routing, monitoring, tracing…​)…​ Each of these tools build a layer of abstraction on top of Kubernetes, providing a simplified "interface" on a complex feature of Kubernetes.
We could even say that every application provides some kind of abstraction layer on top of existing abstraction layers. The difference is that a business application will be on the top of the abstractions, while infrastructure tools are situated at lower levels and are therefore also used by multiple business applications. For example: you can build a website by hardcoding the HTML, but you can also use a CMS (Content Management System) to manage the content of the pages. The CMS in itself is however not a business application, but the website created with the CMS can be.
But even higher up the stack, abstraction can be a useful tool. Business processes and products can also gain from abstractions, as they facilitate faster innovation and easier collaboration. Banks can abstract away their complex back-office processes and complex product characteristics via easy APIs and product factories, allowing easier creation of new products and adaptation of existing business processes. They can also use external abstractions offered by SaaS solution and Fintechs to rapidly provide new user experiences.
With abstraction levels built one on top of the other, you can easily ask yourself, where does it end? The ultimate goal of course is that any person with a business idea, but no IT background at all, can built a complex IT system, meeting the strictest non-functional requirements. Low-code platforms like Mendix, Outsystems, Kony Quantum, Microsoft PowerApps…​ provide a step in this direction, but there is still a very long way to go, which brings us to the downsides of continuously adding levels of abstraction.
With each abstraction comes also opinions, assumptions and restrictions (i.e. enforced scoping constraints). Typically, the developer of an abstraction layer will create an opinionated system, i.e. based on several best practices he will implement the specifics on the lower level. The result is that someone using the higher abstraction level has automatically lower flexibility. If your usage fits well the applied best practices and constraints, the abstraction level is ideal, but if not, the abstraction level comes at a significant cost. Adding an abstraction is therefore always a compromise (i.e. you gain speed, but lose flexibility), meaning there is an optimal level of abstraction, which is dependent on the end goal.
With each abstraction, people also lose insights. When learning a new topic, it is important to continuously zoom-in and out on the subject to explain and understand the subject at different levels. When someone explains a topic only at the lowest level, you will lose yourself in the details. However, if the message remains too abstract, the subject will feel fluffy and not very concrete. Due to the increased level of abstractions, people tend to think about system only at a higher-level level, which will pose issues at a certain moment. This is where the law of leaky abstractions comes in. Any abstraction will ultimately leak, meaning that at some point something will go wrong and you will only be able to fix it by digging into the lower level operations.
As the above demonstrates, abstractions are a powerful tool, when used consciously. In banking, unfortunately the modern abstractions are not very well introduced yet. Banks are still built on top of legacy software implemented with lower-level programming languages like Cobol, very little to no usage of cloud solutions and still very monolithic, not very-well encapsulated architectures. Furthermore, from a business point of view, the products and services are organised as silos with little to no abstractions.
As indicated above, any technological evolution comes with new abstraction opportunities. With the banking sector being in such fast evolution the last few years, opportunities for abstractions are everywhere. Companies that can introduce the (technological) abstractions of modern technology stacks in a controlled and efficient way in existing large banks will have massive opportunities in the coming years. E.g. core banking transformations, (partial) migrations to the cloud or gradual conversions of the bank monoliths to a microservices based architecture.
But there are also opportunities in more specific banking-oriented abstractions. Every bank topic or service, which is complex to understand or use for employees and/or customers, gives an opportunity for an abstraction layer. E.g. complex processes like investing, credit risk management, fraud detection, hedging…​ should also be abstracted away, so that the end user can express his desired outcome rather than having to understand all the details of the underlying processes.
Labels:

Comments

Post a Comment

Popular posts from this blog

Transforming the insurance sector to an Open API Ecosystem

1. Introduction "Open" has recently become a new buzzword in the financial services industry, i.e.   open data, open APIs, Open Banking, Open Insurance …​, but what does this new buzzword really mean? "Open" refers to the capability of companies to expose their services to the outside world, so that   external partners or even competitors   can use these services to bring added value to their customers. This trend is made possible by the technological evolution of   open APIs (Application Programming Interfaces), which are the   digital ports making this communication possible. Together companies, interconnected through open APIs, form a true   API ecosystem , offering best-of-breed customer experience, by combining the digital services offered by multiple companies. In the   technology sector   this evolution has been ongoing for multiple years (think about the travelling sector, allowing you to book any hotel online). An excellent example of this
45 comments
Read more

Are product silos in a bank inevitable?

Silo thinking   is often frowned upon in the industry. It is often a synonym for bureaucratic processes and politics and in almost every article describing the threats of new innovative Fintech players on the banking industry, the strong bank product silos are put forward as one of the main blockages why incumbent banks are not able to (quickly) react to the changing customer expectations. Customers want solutions to their problems   and do not want to be bothered about the internal organisation of their bank. Most banks are however organized by product domain (daily banking, investments and lending) and by customer segmentation (retail banking, private banking, SMEs and corporates). This division is reflected both at business and IT side and almost automatically leads to the creation of silos. It is however difficult to reorganize a bank without creating new silos or introducing other types of issues and inefficiencies. An organization is never ideal and needs to take a number of cons
6 comments
Read more

RPA - The miracle solution for incumbent banks to bridge the automation gap with neo-banks?

Hypes and marketing buzz words are strongly present in the IT landscape. Often these are existing concepts, which have evolved technologically and are then renamed to a new term, as if it were a brand new technology or concept. If you want to understand and assess these new trends, it is important to   reduce the concepts to their essence and compare them with existing technologies , e.g. Integration (middleware) software   ensures that 2 separate applications or components can be integrated in an easy way. Of course, there is a huge evolution in the protocols, volumes of exchanged data, scalability, performance…​, but in essence the problem remains the same. Nonetheless, there have been multiple terms for integration software such as ETL, ESB, EAI, SOA, Service Mesh…​ Data storage software   ensures that data is stored in such a way that data is not lost and that there is some kind guaranteed consistency, maximum availability and scalability, easy retrieval and searching
26 comments
Read more

IoT - Revolution or Evolution in the Financial Services Industry

1. The IoT hype We have all heard about the   "Internet of Things" (IoT)   as this revolutionary new technology, which will radically change our lives. But is it really such a revolution and will it really have an impact on the Financial Services Industry? To refresh our memory, the Internet of Things (IoT) refers to any   object , which is able to   collect data and communicate and share this information (like condition, geolocation…​)   over the internet . This communication will often occur between 2 objects (i.e. not involving any human), which is often referred to as Machine-to-Machine (M2M) communication. Well known examples are home thermostats, home security systems, fitness and health monitors, wearables…​ This all seems futuristic, but   smartphones, tablets and smartwatches   can also be considered as IoT devices. More importantly, beside these futuristic visions of IoT, the smartphone will most likely continue to be the center of the connected devi
16 comments
Read more

Neobanks should find their niche to improve their profitability

The last 5 years dozens of so-called   neo- or challenger banks  (according to Exton Consulting 256 neobanks are in circulation today) have disrupted the banking landscape, by offering a fully digitized (cfr. "tech companies with a banking license"), very customer-centric, simple and fluent (e.g. possibility to become client and open an account in a few clicks) and low-cost product and service offering. While several of them are already valued at billions of euros (like Revolut, Monzo, Chime, N26, NuBank…​), very few of them are expected to be profitable in the coming years and even less are already profitable today (Accenture research shows that the average UK neobank loses $11 per user yearly). These challenger banks are typically confronted with increasing costs, while the margins generated per customer remain low (e.g. due to the offering of free products and services or above market-level saving account interest rates). While it’s obvious that disrupting the financial ma
7 comments
Read more

PFM, BFM, Financial Butler, Financial Cockpit, Account Aggregator…​ - Will the cumbersome administrative tasks on your financials finally be taken over by your financial institution?

1. Introduction Personal Financial Management   (PFM) refers to the software that helps users manage their money (budget, save and spend money). Therefore, it is often also called   Digital Money Management . In other words, PFM tools   help customers make sense of their money , i.e. they help customers follow, classify, remain informed and manage their Personal Finances. Personal Finance   used to be (or still is) a time-consuming effort , where people would manually input all their income and expenses in a self-developed spreadsheet, which would gradually be extended with additional calculations. Already for more than 20 years,   several software vendors aim to give a solution to this , by providing applications, websites and/or apps. These tools were never massively adopted, since they still required a lot of manual interventions (manual input of income and expense transaction, manual mapping transactions to categories…​) and lacked an integration in the day-to-da
5 comments
Read more

Can Augmented Reality make daily banking a more pleasant experience?

With the   increased competition in the financial services landscape (between banks/insurers, but also of new entrants like FinTechs and Telcos), customers are demanding and expecting a more innovative and fluent digital user experience. Unfortunately, most banks and insurers, with their product-oriented online and mobile platforms, are not known for their pleasant and fluent user experience. The   trend towards customer oriented services , like personal financial management (with functions like budget management, expense categorization, saving goals…​) and robo-advise, is already a big step in the right direction, but even then, managing financials is still considered to be a boring intangible and complex task for most people. Virtual (VR) and augmented reality (AR)   could bring a solution. These technologies provide a user experience which is   more intuitive, personalised and pleasant , as they introduce an element of   gamification   to the experience. Both VR and AR
9 comments
Read more

Low- and No-code platforms - Will IT developers soon be out of a job?

“ The future of coding is no coding at all ” - Chris Wanstrath (CEO at GitHub). Mid May I posted a blog on RPA (Robotic Process Automation -   https://bankloch.blogspot.com/2020/05/rpa-miracle-solution-for-incumbent.html ) on how this technology, promises the world to companies. A very similar story is found with low- and no-code platforms, which also promise that business people, with limited to no knowledge of IT, can create complex business applications. These   platforms originate , just as RPA tools,   from the growing demand for IT developments , while IT cannot keep up with the available capacity. As a result, an enormous gap between IT teams and business demands is created, which is often filled by shadow-IT departments, which extend the IT workforce and create business tools in Excel, Access, WordPress…​ Unfortunately these tools built in shadow-IT departments arrive very soon at their limits, as they don’t support the required non-functional requirements (like high availabili
15 comments
Read more

From app to super-app to personal assistant

In July of this year,   KBC bank   (the 2nd largest bank in Belgium) surprised many people, including many of us working in the banking industry, with their announcement that they bought the rights to   broadcast the highlights of soccer matches   in Belgium via their mobile app (a service called "Goal alert"). The days following this announcement the news was filled with experts, some of them categorizing it as a brilliant move, others claiming that KBC should better focus on its core mission. Independent of whether it is a good or bad strategic decision (the future will tell), it is clearly part of a much larger strategy of KBC to   convert their banking app into a super-app (all-in-one app) . Today you can already buy mobility tickets and cinema tickets and use other third-party services (like Monizze, eBox, PayPal…​) within the KBC app. Furthermore, end of last year, KBC announced opening up their app also to non-customers allowing them to also use these third-party servi
9 comments
Read more

Eco-systems - Welcome to a new cooperating world

Last week I attended the Digital Finance Summit conference in Brussels, organized by Fintech Belgium, B-Hive, Febelfin and EBF. A central theme of the summit was the cooperation between banks and Fintechs and more in general the rise of ecosystems. In the past I have written already about this topic in my blogs about "Transforming the bank to an Open API Ecosystem ( https://www.linkedin.com/pulse/transforming-bank-open-api-ecosystem-joris-lochy/ ) and "The war for direct customer contact - Banks should fight along!" ( https://www.linkedin.com/pulse/war-direct-customer-contact-banks-should-fight-along-joris-lochy/ ), but still I was surprised about the number of initiatives taken in this domain. In my last job at The Glue, I already had the pleasure to work on several interesting cases: TOCO   ( https://www.toco.eu ): bringing entrepreneurs, accountants and banks closer together, by supporting entrepreneurs and accountants in their daily admin (and in the f
9 comments
Read more