Ecosystem Enabled Banking Part 1: Defining the scope

Ecosystem Enabled Banking Part 1: Defining the scope

I recently published a paper on what I now call "Ecosystem Enabled Banking", which is my view and approach for undertaking a successful progressive modernization with a focus on implementing capabilities from an ecosystem of ISV and Fintech partners to accelerate time to market, drive future flexibility and reducing risk. Whilst the focus is on the modernization journey, this approach lends itself just as well for building a new digital bank or any other green-field solution.

As part of my regular "Morning coffee with P?l" blog posts on here, I thought I would explore aspects of this approach a bit further, and share some of my thinking with you all. I will not set a structured schedule for this, but there will be follow on posts in this series.


What is Ecosystem Enabled Banking

Let us start from the beginning...

The pandemic and economic changes have pushed banks to quickly adopt digital technologies, highlighting gaps in their operations and tech setups. Initially, banks focused on improving their online customer services, which was important but not enough to fully tap into their business potential.

To stay ahead digitally, banks are now focusing on two main strategies: using advanced technologies like automation, cloud computing, and AI extensively, and ensuring these technologies work well within their own organisations and with external partners.

However, creating a top-notch digital banking experience goes beyond just having the latest tech. It involves redesigning how the bank operates to allow different software and services to work together smoothly and securely.

This shift requires a deep change in how banks are structured and operate, especially to stay competitive and profitable. As banks upgrade their systems, they need to think about working with a variety of tech and service providers to bring about positive change quickly and safely, making sure they get a good return on their investments.

Additionally, we are seeing a shift from banks implementing a single vendor solution to cover all needs, or to undertake a large internal custom development effort. The trend is a shift towards a more modular and multi-core solution.

This is where Ecosystem Enabled Banking comes in.

Banks need to think about their business and IT architectures differently, and focus on their unique differentiation from their main competitors. If we are honest 90% if not more of what a bank does is generic to the industry, and is aligned with just operating as a bank. And this is also the same for their IT landscape. the remaining 10% is where they differentiate from other players. But to date most of the investment and focus by the banks has been on that 90%. We need to flip this over, and ensure that whilst the legacy must be modernized, the end result has the bank focused the future investment on the 10% that drives their differentiation in the market, and customer value.

Here is where I find we hit the first point for discussion. Setting the scope for the future.


Any journey is successful if you have no destination!

Whilst there is a full end-to-end structure to the Ecosystem Enabled Banking approach, I will for today only focus on the very initial part of this journey - setting your destination and planning the route for getting there. In Ecosystem Enabled Banking we talk about the Business and IT Capability Model as your destination.

I can not stress how critical this phase is for the continued success of the journey about to be taken - you must set a clear point of arrival which is well defined and structured. We might change our directions during the journey, but the point of arrival should remain constant. But do not constrain yourself here, set the destination as the city and not the address, we can get to the detailed address as we get closer to the city.

When I work with banks in the early phases of setting the scope for a progressive modernization, the first thing I tell them is "forget about your existing legacy for now". I have often seen organisations getting constrained in their thinking by focusing on their legacy. There is great value in evaluating your legacy systems and processes in regards to your future, but now is not the correct time, we will get to this later.

I recommend that you start with a clean slate, and define what the future of the bank looks like from a business perspective, and this will be used to define the journey we will take and the critical criteria for follow on decisions associated with your new IT landscape.

Here we come to another critical element, whilst we are looking at an IT transformation, this must be a business driven agenda with clear business ownership. I have seen a lot of transformation projects fail due to being seen as a pure IT project with limited or now business drivers and ownership.


Great results are directly correlated to the amount of prep done.

Let me ask you a question, and be honest with the answer,

"Do you have a well defined business capability model and a related IT capability model that fully represents the future state of your organisation?"

Most incumbent banks that I have supported, have clearly defined strategies, but they do not have a well document and true representation of their IT capabilities that are aligned with current and future business drivers.

They absolutely have a wealth of architectural documents, but are they current and aligned from business capabilities to operations?

This is a generalized statement, I have worked with some banks that have a well defined capability model, and a strong scope for their point of arrival. But most times, some work is still required.

There is no one correct answer to how a bank should define and document their business and IT capability model, but my strong recommendation is to use the industry framework provided by Banking Industry Architecture Network (BIAN), which is becoming the defector model adopted across the industry by leading banks, system integrator, consulting companies and software vendors. This gives us a common language to use and also helps in potential RFI and RFP processes.

BIAN offers a structured blueprint specifically designed for the banking sector. It outlines various Service Domains, each representing a unique, essential business function with responsibility for the full cycle of its respective business activity. Together, these domains comprehensively encompass all facets of banking operations.

The Service Landscape in BIAN is arranged and categorized into broader Business Areas and then into more specific Business Domains. There are two primary frameworks for organizing this information: the matrix view and the value chain view. For the Ecosystem Enabled Banking, I generally favor using the matrix view as it gives a good Component Business Model perspective on the bank.

BIAN Service Landscape value chain view

In general I advice to use a more adopt rather than adapt approach to modeling the future state of the bank with BIAN, but often we will customize the high-level BIAN Service Landscape to reflect the banks management structure, lines of business, and specific products in scope.

As already mentioned, I often find that a bank will have documented at both the business level and IT level a view of the transformation requirements and scope, often using a generic approach to business and IT architecture. My recommendation is to use this as input (if not already aligned to BIAN) and at a minimum do a mapping or overlay to a BIAN based Component Business Model.

I will not dive any deep into how to use BIAN and the structure of BIAN today, there is enough content available on the internet for that (or ask me to come and help you define your capability model with BIAN), and I might do a post on it in the future. The main element for today is to make sure that we define the future vision of the bank in regards to the domains under evaluation for modernization, and in a way that drives value from day one.

I have employed this approach successfully with a number of banks to drive the initial definition phase for the core modernization for retail banking, corporate lending modernization projects and several banks seeking to drive expansion with new capabilities within SME banking.

So, the first step in any transformation or modernization journey is to document the future state of your bank in the form of a business capability model (in the context of the modernization, no need to go crazy), without any limitations or constraints from your exiting operations and legacy systems. The more time and effort you spend here, the less issues you will have down the road. And if you do select to use BIAN, you get the technical capability model almost for free...


What next

The next step is to undertake the analysis of the defined capability model in regards to a number of key areas, such as:

  • Build vs Buy vs Consume
  • Configuration-led vs Engineering-led offerings (including low-code and no-code offerings)
  • Architectural principles
  • Legacy Analysis (Legacy anchored or legacy replaced)

But we will dig deeper into these steps in a later blogpost.

If you are keen to explore further or know more, then please reach out and we can have a coffee and a chat.

要查看或添加评论,请登录

P?l Krogdahl的更多文章

社区洞察

其他会员也浏览了