Being Good at Banking
A bank needs to be good at banking. Technology is essential, but so are the enterprise abilities, operating arrangements and disciplines that make good banking possible.
Banks invest substantially in technology, transformation and organisational change. Yet delivering a new system, process or operating model does not necessarily mean the bank can achieve what it set out to do.
Enterprise Ability Architecture (EAA) approaches investment and change from the business perspective. It starts with what the bank needs to accomplish, determines the abilities and performance required, and establishes the architectural foundations needed to make them possible.
The objective is not simply to deliver change, but to establish abilities that produce lasting business value.
Start with the Business Need
Understanding what the bank needs to achieve before deciding what to change
Business needs arise from problems to solve, opportunities to pursue and obligations to fulfil. They may be recognised through strategic decisions, operational experience, changing market conditions or regulatory developments.
The first task is to understand the job the bank needs to accomplish and the outcome that would represent success. A proposed system, process change or organisational solution should not be mistaken for the underlying need.
In 1979, a bank described how lending officers needed to consult different departments to understand a customer's existing accounts. The problem was not the absence of a Customer Information File. It was the effort and delay involved in assembling information for lending decisions.
Understanding that distinction allows EAA to investigate the abilities the bank actually requires, rather than simply implementing the first proposed solution.
Define the Required Ability
Establish what the bank must be able to achieve and the performance required
Once the business need is understood, the next step is to determine what the bank must be able to do to fulfil it. This is the required enterprise ability.
An ability must also be defined by the conditions under which it needs to perform. Timeliness, accuracy, completeness, capacity, cost and reliability may all determine whether it can deliver the intended business outcome.
In our lending example, the bank needs to be able to retrieve and assemble relevant information about a customer's existing banking arrangements. But how quickly must it do so? How complete and current must the information be?
These requirements influence the capabilities and architectural arrangements needed. A manual solution might be sufficient for one level of performance, while another could require shared information services and more extensive integration.
Architecting the Right Response
Determine the capabilities and arrangements needed to achieve the business outcome
Once the required ability and performance are understood, EAA examines how they can be achieved. This begins with the capabilities the bank already possesses, what is missing, and how existing capabilities could work together more effectively.
The investigation extends across organisational and technology boundaries. EAA identifies shared requirements, dependencies and architectural alternatives before determining where investment or change is needed.
In our lending example, the bank could improve manual information gathering, develop a lending-specific information service, or establish shared customer information accessible to several business functions.
Each option may satisfy the immediate need, but with different costs, limitations and future opportunities. EAA evaluates these trade-offs against the required business performance and the wider interests of the bank.
New Abilities, New Opportunities
An investment made to solve one problem can create value across the bank
Establishing an enterprise ability can create opportunities beyond the problem it was originally intended to solve. Information, services and capabilities developed for one purpose may also enable other business activities.
EAA examines these possibilities across the enterprise, helping the bank recognise where existing abilities could be reused, extended or combined to create additional business value.
In our lending example, establishing a Customer Information File enabled the bank to recognise customers across their accounts. The same foundation could also support improved customer service, more effective relationship management and targeted commercial development.
Each opportunity may introduce further requirements, but the original investment has created possibilities extending beyond its initial purpose.
From Architecture to Performance
The right capabilities must also work together to deliver the required business outcome
Establishing the right capabilities and architectural arrangements does not guarantee that the bank will achieve its intended outcomes. Performance depends on how people, processes, information, technology and decisions work together under real operating conditions.
Operational Systems Engineering (OSE) complements EAA by determining how these arrangements must function to achieve the required performance reliably. It brings operational behaviour, constraints and engineering principles into the design before problems become embedded in the operating model.
In our lending example, a shared customer information service may exist, yet lending decisions can still be delayed by incomplete records, duplicate identities, slow updates or unresolved exceptions.
OSE examines these operating conditions and engineers the mechanisms needed to achieve the required performance. Operational experience then informs further improvement, including changes to the underlying architecture where necessary.
Keeping the Bank Fit for Purpose
Enterprise abilities must evolve as business needs, opportunities and operating conditions change
The abilities a bank needs today are not necessarily those it will need tomorrow. New business opportunities, changing customer expectations, regulation, technology and operating conditions continually reshape what the bank must be able to achieve.
EAA provides a continuing discipline for examining emerging needs, reassessing existing abilities and identifying where investment, integration or architectural change may be necessary.
Banking's evolution from individual account management to Client Lifecycle Management illustrates how successive business needs have generated new abilities and dependencies over decades.
EAA helps the bank examine these developments as a connected whole, recognising when existing abilities remain sufficient, when they need to evolve, and when entirely new approaches may offer better outcomes.
Being good at banking is not a fixed destination.
It requires continually understanding what the bank needs to be able to do and ensuring its abilities remain appropriate for the business and the world in which it operates.
First Published: 08-Nov-2026