Does a composable banking future mean the end of programmers?

0

I don’t know when I officially joined the “oldie” camp, but I suddenly realized I was in that camp when I recently participated in a discussion about “low/no- coded”.

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

Before defining it, it is worth understanding a bit of the history behind coding. In school, I was shown how to code in machine code using punch cards. This is categorized as 1GL (first generation language programming). In college I wrote a cross assembler for the 6502 processor which introduced me to programming in 2GL, also known as assembly language. Life got a lot easier when I was writing in Pascal and Basic and then Cobol. They were 3GLs. An example of 4GL is SQL, basically non-procedural languages. These languages ​​are used to tell the computer what to do, 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 for the computer to solve a given problem without the programmer.

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

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 perform, whereas personalization beyond the border becomes more complex, requiring the intervention of a traditional programmer within the new tool. Salesforce (for CRM), Pega (for RPA/workflow) and SAP (for ERP) are examples demonstrating this principle. Gartner would later define them as “precursors” in composition technology within their Magic Quadrant product category, not as pure play application composition platforms.

I’m not sure exactly when “low/no-code” appeared, but my research identifies Excel as the first example of a no-code platform. For me it was in the late 80’s on an IBM 4700 using a development platform called Application Map Generator (AMG). This solution allowed you to separate UI definition, rules/logics and text. Its goal was to maximize reuse and facilitate the creation of screen-based solutions. This worked great for character-based interfaces.

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

At that time, Gartner coined the term “citizen developer” for users of these platforms, and later in 2015 extended the term to integration, indicating IT departments, industry developers (LOB), mobile application development (AD) teams, application teams, and even business users, were “citizen integrators” who leveraged the capabilities of these platforms to develop, run, and manage integration interfaces (or “integration flows”) in the cloud.

These platforms attracted small businesses that needed more of their limited IT resources, and the shortage of tech talent drove the growing demand for these platforms out of necessity and out-of-the-box urgency. . In larger organizations, they also tapped into areas of the business that did not have priority access to IT resources. However, most have struggled to replace traditional development in 3GLs like Java or .Net. It is mainly IT departments who cite the lack of flexibility of the platforms and the lack of trained resources available. Other issues raised include:

  1. What about source control and reuse?
  2. Will it work with automated tests?
  3. Can we bring/integrate our own code if we reach the limit?
  4. What safety standards does it comply with?
  5. Regarding extensibility, can we develop or use third-party UI widgets?
  6. Can it evolve?

I could add more, but I’m sure you understood that IT teams wanted to protect their skills and expertise and not be locked into a set of proprietary tools or lengthy agreements with third-party vendors at all costs.

Fast forward to now (20 years later…god, I’m old!) and we come to today’s business landscape where “software is eating the world” and so there is a “war for talent” in IT . At the same time, technology is changing at a rapid pace and it is difficult to keep up to date with new capabilities.

In the world of composable banking, however, the focus tends to be much more on results and business value rather than how you do something and the tools and technologies used to achieve it. The speed of achieving production output has become much more important. As such, buying before building becomes the mantra for reusable components, and now composing before coding to “orchestra” those components is much more efficient.

In banking, smaller banks have taken advantage of solutions from major incumbent vendors that are “configurable”, allowing business users to define products such as loans or deposit accounts. Big banks always tend to prefer ultimate flexibility, which usually comes down to the ability to code anything that isn’t possible in the base 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 relieving valuable IT resources, which most businesses will claim they never have enough of. IT departments have become more comfortable with tools for managing 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 not yet reached nirvana state promised realized profits.

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

It should be noted that working with legacy and on-premises systems for data sovereignty solutions is a more challenging task for them. A key feature is their ability to handle non-functional requirements so users don’t have to scale for performance, scalability, security, and resiliency. These non-functional requirements alone can represent a savings of 40% compared to traditional development approaches that use code.

Some tools have an AI in the background that does its best to understand users’ intentions. Their goal is clear: you don’t need to be an IT professional to build and deploy enterprise applications. That doesn’t mean you don’t need computing resources. It just means you can focus your resources on high-level, time-sensitive tasks like sourcing or building reusable components.

For me, the maturation of such platforms couldn’t happen any sooner because there has always been some inevitability towards a smarter, faster way to automate business. As industries merge, the need to mix and match software continues to grow, as we see with integrated banking. I’m not saying programming is dead, I’m just saying 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’s difficult to consistently find good programmers and maintain business agility similar to how AWS abstracted itself from the data center 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 criticisms and limitations, largely from incumbents and the developer community, I see an inevitable evolutionary path emerging towards composable platforms that will consist to code what cloud IaaS (AWS, GCP, Azure) was in the data center.


About the Author

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

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

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

Follow Dharmesh on Twitter @dharmeshmistry and LinkedIn.

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

Share.

Comments are closed.