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
54 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
28 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
18 comments
Read more

PSD3: The Next Phase in Europe’s Payment Services Regulation

With the successful rollout of PSD2, the European Union (EU) continues to advance innovation in the payments domain through the anticipated introduction of the   Payment Services Directive 3 (PSD3) . On June 28, 2023, the European Commission published a draft proposal for PSD3 and the   Payment Services Regulation (PSR) . The finalized versions of this directive and associated regulation are expected to be available by late 2024, although some predictions suggest a more likely timeline of Q2 or Q3 2025. Given that member states are typically granted an 18-month transition period, PSD3 is expected to come into effect sometime in 2026. Notably, the Commission has introduced a regulation (PSR) alongside the PSD3 directive, ensuring more harmonization across member states as regulations are immediately effective and do not require national implementation, unlike directives. PSD3 shares the same objectives as PSD2, i.e.   increasing competition in the payments landscape and enhancing consum
1 comment
Read more

Trade-offs Are Inevitable in Software Delivery - Remember the CAP Theorem

In the world of financial services, the integrity of data systems is fundamentally reliant on   non-functional requirements (NFRs)   such as reliability and security. Despite their importance, NFRs often receive secondary consideration during project scoping, typically being reduced to a generic checklist aimed more at compliance than at genuine functionality. Regrettably, these initial NFRs are seldom met after delivery, which does not usually prevent deployment to production due to the vague and unrealistic nature of the original specifications. This common scenario results in significant end-user frustration as the system does not perform as expected, often being less stable or slower than anticipated. This situation underscores the need for   better education on how to articulate and define NFRs , i.e. demanding only what is truly necessary and feasible within the given budget. Early and transparent discussions can lead to system architecture being tailored more closely to realisti
Post a Comment
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

An overview of 1-year blogging

Last week I published my   60th post   on my blog called   Bankloch   (a reference to "Banking" and my family name). The past year, I have published a blog on a weekly basis, providing my humble personal vision on the topics of Fintech, IT software delivery and mobility. This blogging has mainly been a   personal enrichment , as it forced me to dive deep into a number of different topics, not only in researching for content, but also in trying to identify trends, innovations and patterns into these topics. Furthermore it allowed me to have several very interesting conversations and discussions with passionate colleagues in the financial industry and to get more insights into the wonderful world of blogging and more general of digital marketing, exploring subjects and tools like: Search Engine Optimization (SEO) LinkedIn post optimization Google Search Console Google AdWorks Google Blogger Thinker360 Finextra …​ Clearly it is   not easy to get the necessary attention . With th
9 comments
Read more

Deals as a competitive differentiator in the financial sector

In my blog " Customer acquisition cost: probably the most valuable metric for Fintechs " ( https://bankloch.blogspot.com/2020/06/customer-acquisition-cost-probably-most.html ) I described how a customer acquisition strategy can make or break a Fintech. In the traditional Retail sector, focused on selling different types of products for personal usage to end-customers,   customer acquisition  is just as important. No wonder that the advertisement sector is a multi-billion dollar industry. However in recent years due to the digitalization and consequently the rise of   Digital Marketing , customer acquisition has become much more focused on   delivering the right message via the right channel to the right person on the right time . Big tech players like Google and Facebook are specialized in this kind of targeted marketing, which is a key factor for their success and multi-billion valuations. Their exponential growth in marketing revenues seems however coming to a halt, as digi
11 comments
Read more

AI in Financial Services - A buzzword that is here to stay!

In a few of my most recent blogs I tried to   demystify some of the buzzwords   (like blockchain, Low- and No-Code platforms, RPA…​), which are commonly used in the financial services industry. These buzzwords often entail interesting innovations, but contrary to their promise, they are not silver bullets solving any problem. Another such buzzword is   AI   (or also referred to as Machine Learning, Deep Learning, Enforced Learning…​ - the difference between those terms put aside). Again this term is also seriously hyped, creating unrealistic expectations, but contrary to many other buzzwords, this is something I truly believe will have a much larger impact on the financial services industry than many other buzzwords. This opinion is backed by a study of McKinsey and PWC indicating that 72% of company leaders consider that AI will be the most competitive advantage of the future and that this technology will be the most disruptive force in the decades to come. Deep Learning (= DL) is a s
10 comments
Read more