Does a composable banking future spell the end for programmers?

I’m not sure when I officially joined the “oldie” camp, but I had a sudden realisation I was in that camp when I got involved in a discussion about “low/no-code” development platforms recently.

As industries merge, the need to mix and match software continues to grow

Before I define it, it’s worth understanding a bit of the history behind coding. At school, I was shown how to code in machine code using punch cards. This is categorised as 1GL (first-generation language programming). At college, I wrote a cross assembler for the 6502 processor which got me into programming in 2GL, also known as assembly language. Life got a whole lot easier when I wrote in Pascal and Basic and then Cobol. These were 3GLs. An example of 4GL is SQL, basically nonprocedural languages. These languages are used to tell the computer what to do and not how to do it. Finally, we have 5GL, also known as natural language. These can translate human instructions into code that executes and are designed to make the computer solve a given problem without the programmer.

I would strongly argue that low/no-code is neither a 5GL or even 6GL, as many of these platforms don’t use language as such and are much more visual in their development approach.

Low/no-code platforms often have a well-defined boundary and context within their given problem domain, so configuration becomes a relatively simple task to execute, whereas customisation beyond the boundary becomes more complex, requiring traditional programmer intervention within the new tool. Salesforce (for CRM), Pega (for RPA/workflow), and SAP (for ERP) are examples demonstrating this principle. Gartner would later define these as composition technology “precursors” within their magic quadrant product category, not pure play application composition platforms.

I’m not sure exactly when “low/no-code” came about, but my research identifies Excel being the first example of a no-code platform. For me, it was in the late 80s on an IBM 4700 using a development platform called Application Map Generator (AMG). This solution allowed you to separate user interface definition, rules/logic, and text. Its goal was to maximise reuse and make it easy to create screen-based solutions. It worked very well for character-based interfaces.

Fast forward 15 years to 2001 when I co-founded a company that created a development platform that allowed you to create multi-channel apps (supporting offline, web, mobile, and portal) without writing code. Internally, we called it a zero-code platform. However, we were not alone and there were other similar platforms, some with stronger rules engines, some focused on workflow. Essentially, each platform had its nuances and points of differentiation.

Around this time, Gartner coined the term “citizen developer” for the users of such platforms, and later in 2015 it extended the phrase to integration, stating IT departments, line of business (LOB) developers, mobile application development (AD) teams, application teams, and even business users were “citizen integrators” who leverage the capabilities of these platforms to develop, execute, and manage integration interfaces (or “integration flows”) in the cloud.

These platforms appealed to smaller companies that needed more from their scant IT resources, and the tech talent shortage drove the rising demand for such platforms out of off-the-shelf necessity and urgency. In bigger organisations, they also appealed to areas of the business that didn’t get priority access to IT resources. However, most struggled to replace mainstream development in 3GLs like Java or .Net. Mostly, it was IT departments that would cite inflexibility of the platforms and a lack of available trained resources. Other questions raised included:

1. What about source control and reuse?
2. Will it work with automated testing?
3. Can we bring/embed our own code if we reach limitation?
4. What security standards does it conform to?
5. Regarding extendibility, can we develop or use third-party user interface widgets?
6. Can it scale?

I could add more, but I’m sure you get the gist that IT teams wanted to protect their skill sets and expertise and not be locked into a proprietary toolset or long deals with third-party vendors at all costs.

Fast forward to now (20 years on… gosh, I am old!) and we come to the current business landscape where “software is eating the world” and hence there is a “war for talent” in IT. At the same time, technology is moving at a pace and keeping up with new capabilities is hard.

In the world of composable banking, however, the focus tends to be much more on outcomes and business value rather than how you get something done and the tools and technologies used to get there. The speed of reaching production release has become much more important. As such, buy before build becomes the mantra for reusable components, and now composing before coding to “orchestrate” these components is much more efficient.

In banking, smaller banks have benefitted from incumbent core vendor solutions that are “configurable”, allowing business users to define products like loans or deposit accounts. The larger banks still tend to prefer ultimate flexibility, which generally boils down to the ability to code anything that is not possible in the core solution.

Composable banking platforms are increasingly providing their own low/no-code development solutions to help orchestrate their platforms. This should lead to greater productivity and time to market while taking the heat off valuable IT resources, which most companies will claim they never have enough of. IT departments have become more comfortable with tools to manage workflows, business rules, and banking product definitions. They have been less comfortable, certainly in large banks, with user interfaces or “integration” tasks, where the “vision” of the API economy has still yet to yield the nirvana state of promised realised benefits.

Like most platforms, development platforms have moved to the cloud. Better bandwidth and better browser support is making cloud-based development much more feasible and accessible. For example, platforms like Appeggio, Betty Blocks, and Bubble.io make it possible to create solutions with no code. Such solutions have templates and reusable components to fast-track the development of any new solution. They are cloud-based and not only automate the development but also the deployment, whether that’s to mobile phones (via app stores) or to servers hosting a web solution.

Working with legacy systems and on-premise for data sovereignty solutions are more challenging tasks for them, it should be noted. A key feature is their ability to manage non-functional requirements so users do not have to develop for performance, scalability, security, and resilience. These non-functional requirements alone can account for a 40% saving over traditional development approaches that use code.

Some tools have AI in the background trying its best to understand user intentions. Their goal is clear: you don’t need to be an IT professional to build and deploy enterprise-grade apps. This doesn’t mean you don’t need IT resources. It just means you can keep your resources focused on the urgent and high-level tasks like sourcing or creating reusable components.

For me, the maturing of such platforms couldn’t come a moment sooner as there has always been some inevitability towards a smarter and faster way to automate business. As industries merge, the need to mix and match software continues to grow, as we are witnessing with embedded banking. I’m not saying that programming is dead, I’m just saying that low/no-code allows us to improve productivity when we put it in the hands of the next generation of emerging tech talent. We can also improve time to market in a world where it is challenging to constantly find good programmers and maintain business agility similar to the way that AWS abstracted itself over the data centre both in terms of marketing “the cloud” as a concept and functionality in terms of business outcome.

So, while low/no-code has and will continue to have its critics and limitations, largely from the incumbents and the developer community, I see an inevitable evolutionary path emerging towards composable platforms that will be to code what cloud IaaS (AWS, GCP, Azure) was to the data centre.

About the author

Dharmesh Mistry has been in banking for more than 30 years and has been at the forefront of banking technology and innovation. From the very first internet and mobile banking apps to artificial intelligence (AI) and virtual reality (VR).

He has been on both sides of the fence and he’s not afraid to share his opinions.

He is CEO of AskHomey, which focuses on the experience for households, and an investor and mentor in proptech and fintech.

Follow Dharmesh on Twitter @dharmeshmistry and LinkedIn.

Read all his “I’m just saying” musings here.