The Architect’s Guide to Digital Banking

Are you a CIO/CTO/Architect trying to make sense of different technology approaches to your Digital Banking Transformation? Check industry insider’s view on what’s going on.

Disclaimer: Views in this article are my own based on the involvement in the Digital Transformations projects from Tier-1 to neobanks across the globe over last 6 years as a Solutions Architect at Mambu (Cloud Core Banking Engine) and Backbase (Omnichannel Digital Banking Platform).

Most Banks today are involved in Digital Transformation, whether it is implementing point solutions, undergoing an end-to-end transformation, or launching parallel business models. McKinsey research shows that:

"70 percent of complex, large-scale change programs don’t reach their stated goals."

Selecting the right approach today is even more complex for CIOs, CTOs and Enterprise Architects given the similarities of the offerings combined with TCO and “time to market” business goals.

Let’s leave vendor marketing and “out-of-the-box” functionality for analysts like Gartner and Forrester to focus on. If we look under the hood of technology approaches from popular Digital Banking platforms, we try and answer one common question:

"Buy or Build?"

Vendors and Platforms

Historically Banking was not on the cutting edge of technology and adopted the solutions that were proven by other Enterprises, hence most Digital Banking offerings today are derived from traditional Web and Mobile development platforms:

• Digital eXperience Platforms
• Low-code Platforms
• Pre-built Applications

Digital eXperience Platforms

DXP is an umbrella term that Forrester introduced for Horizontal Portals and Web Content Management Systems (IBM WebSphere, Adobe Experience Manager, Backbase CXP, Liferay DXP, Sitecore, and others).

Historically Portals were designed for aggregation of standalone applications into a single user experience and architected around the ideas of Websites, Pages, and Widgets. Today UX is based on Journeys and Single Page Applications, which do not map nicely to Portals concepts.

As portals are generally stateless, you may need to add a BPM or Middleware layer in your architecture to handle state for omnichannel scenarios. Mobile is also commonly a second-class citizen, as after experimenting with Hybrid approaches, today vendors are building standalone Native SDKs as side products.

Avaloq, Backbase, and some others also provide Model Bank solutions (pre-built Portals, Widgets, and Mobile apps) on top of DXPs.

Low-code Platforms

Temenos was one of the first entrants into Digital Banking with a Low-code solution by acquiring Edge IPK in 2012 and renaming it into Temenos UXP.

Since then Low-code is on the rise with vendors like Appian, Pega, Mendix, OutSystems, and Kony becoming leaders for Mobile Application Development (MADP) and High Productivity Application PaaS by introducing Visual Designer tools that generate omnichannel experiences as well as underlying Processes and APIs.

Kony is also one of the industry agnostic vendors which offer a Model Bank reference implementation.

Pre-built Applications

A number of vendors like Malauzai question the added value of using development platforms compared to traditional Java or .NET applications that can be customized on the project level.

One such example is IND Group which was acquired by Mysis in 2014. This Hungarian FinTech, servicing more than 30+ banks at that time, was using a deep customization approach and delivering projects at low cost with a short time to market.

Pivoting to the enterprise was the main concern for Misys as their business model was typical for core-banking vendors: subscription heavy. This was in contrast to IND’s project model approach at the time. After the acquisition, it was decided to rebuild the solution making it more granular and maintainable, and it still has to catch up with the flexibility and market momentum of its predecessor.

Oracle, on the other hand, successfully managed to revamp their offering in just a couple of years building their Model Bank with lightweight Oracle Jet technology.

Comparing the “-ilities”

Instead of complex and easily biased RFP process used by both Banks and Industry Analysts, we are going to group vendors based on the underlying platforms and evaluate how those stand against business and technology requirements of tomorrow.

Ignoring software aspects that are subjective (e.g. “usability”) or depend on the implementation (e.g. “performance”), we focus on the ones that are enforced by the architecture design.

Large image

Seamlessness

Ease of creating new customer journeys across multiple channels.

Low-code platforms are shining here as they are built for designing processes and interfaces in a visual way. Many of those are also Omni-channel and generate native UI for both Web and Mobile.

Portals were architected for isolated applications and are stateless by design. This means making a process “omnichannel” requires underlying services to manage the journey state: BPMs, Middleware, bespoke development, etc. This is only for the Web. For Mobile experiences, you would need to build separate UI per platform (iOS or Android) or use a subpar responsive Web experience.

Pre-built would usually provide out-of-the-box journeys. Want to build something outside of the scope of the Model Bank? You’re pretty much on your own.

High: Low-code. Medium-Low: Pre-built, Portals.

Manageability

Level of business agility to manage the platform without the involvement of IT.

Low-code and Pre-built solutions do not offer any tools for Business users to manage the platforms, while Portals provide Page Editors which allow Marketing and Product departments to introduce content changes or launch new campaigns.

However, the real way for Business to get agile is the organizational transformation that involves multidisciplinary teams and DevOps as a culture, not as a department. One great example is McKinsey’s case of ING’s agile transformation which allowed rollout of new features on daily basis.

Medium: Portals. Low: Pre-built, Low-code.

Configurability and Customizability

Ease of changing the Model Bank or introducing new functionality.

There is a big discussion on what should be considered configurability or customizability. We’re leaving it up to developers to decide whether they prefer writing code or using visual tools.

What is important to understand however is the level of reuse of Model Bank functionality. For Low-code it is quite high as you could make changes to the Model Bank on component level. For Portals, you need to make a decision on the widget level whether to adopt it or build a bespoke one.

Low-code solutions make it possible by introducing an abstraction layer over the Web and Mobile platforms APIs, however as Joel Spolsky remarked:

All non-trivial abstractions, to some degree, are leaky.

Many Portals and Pre-built vendors provide some kind of “Extensibility Points” for certain UI Components and Services. The idea behind this pattern is to increase the adoption of default functionality in case only parts of the business logic needs to be modified. The downside you get is an over-engineered UI and Integration layers, that are also hard for the vendors to improve, as described by Martin Fowler in Continuous Design:

In particular, up-front designs often include “extensibility hooks” for future design changes. This approach makes continuous design harder and should be avoided.

This method doesn’t just overcomplicate the Model Bank code. It also bloats it with deprecated APIs kept there for backward-compatibility. An alternative approach would be using Composition design pattern over Inheritance or Extensions.

High: Low-code. Medium: Portals. Low: Pre-built.

Upgradability

Effort and risk of upgrading the Platform and Model Bank.

There are 2 main components that need to be maintained by the vendor: the Platform and the Model Bank. For Low-code and Portals, upgradability of the core Platform is usually not an issue as it is black-boxed.

Upgrading Model Banks is a different story.

Low-code vendors provide Model Banks just as a foundation — as soon as you’ve changed anything, you’re on your own. With Portals and Pre-built, your UI and Service extensions are usually managed separately. This allows you to upgrade to newer versions of the Model Bank. The reality is, however, that an update of any component requires QA of all functionality as extension APIs commonly leak the implementation details.

Next to that Portals and Pre-built are usually using 3rd party frameworks for Web and Mobile with their own lifecycles that could affect your implementation (up to a complete rewrite). An infamous example is the deprecation of Liferay Alloy when Yahoo closed YUI project. Many vendors that implemented AngularJS 1 are also deciding today what to do with it, as Google introduced Angular 2 — a backward-incompatible version of the framework.

Medium: Low-code, Portals, Pre-built.

Where to start?

Use the “-ilities” for your selection process — all architectures have tradeoffs, as Fred Brooks once said:

"There is No Silver Bullet"

If you plan to get an “Uber for Banking” experience off-the-shelf, adjust your expectations. Keep in mind that Uber employs over 100 engineers just for iOS, and neobanks, like Monzo, have multiple teams working on different parts of their app.

Prioritize the “-ilities” that are matching your team skills and technology strategy. Don’t run for the latest buzzwords — if Google is using Microservices, it doesn’t mean you have to. Even one of the main evangelists, Martin Fowler, argues that point, as it costs extra premium:

"You shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile."

Digital Transformation is not an end result, but an ongoing process. While Model Bank’s capabilities or vendor’s commitment to delivery may affect the final decision, it is still important to understand the limitations of the platform that would define your roadmap.

“Don’t bring me problems, bring me solutions”

While we were quite critical of different architectures, there is no universal solution. If you are interested in building banking architectures that are

• Evolutionary
• Composable
• Resilient
• Cloud-native

Subscribe for the updates.