Community
Will the adoption of agile architecture methods prepare banking systems for Digital or are existing architecture & design (A&D) strategies in banking becoming obsolete?
I have been working in banking architecture & design teams for over 20 years now and I have never seen the level and demand for change so high. This is driven mainly by the aspiration to move to new Digital banking business models. The Digital phenomena has been described in many ways but my favourite definition is that Digital is simply a new way of doing Business.
The most fundamental change is a combination of new technology associated with the ‘power of the Customer’ and the need for every muscle and sinew of the business to be operating to deliver what the Customer wants now, will/might want tomorrow, delivered where and when the Customer wants it. The other drivers of change are the new entrants, the FinTech community, which is creating new sources of competition right across the banking landscape. Of course regulatory change continues but it’s the race to Digital fuelled by new technology that is now centre stage.
Architecture teams are at the forefront of this change so how are architecture teams responding? One of the most common responses by the architecture community is to go Agile. Agile architecture is about the introduction of flexibility, extensibility, future proofing, (and other less interesting ility’s) within the architecture. Agile architecture fronts agile development methods with business embedded team structures, incremental development methods (employing DevOps and PaaS development and testing environments), the development of service catalogues, typically Service Oriented Architecture (SOA) based, that are packaged to be consumed within self-service, on-demand portals and Apps that are also developed by the bank. This all sits in-front of or around the core legacy systems that are not going away any time soon. That's a topic for a different blog.
The promise is that this will lead to faster and more easily delivered change and maintenance of systems. That outcome of course is all relative to what banks can achieve today given their legacy heritage and is unlikely to compare with delivery throughput that will be achieved by new Fintech start-ups. I tend to agree with this approach if you assume that the way banking services will be consumed by the Digital economy will be similar to the model developed for the Internet or early banking mobile apps. However with Digital I feel that there is more fundamental change happening and I believe agile architecture et al alone may not go far enough.
Introducing a new way of working is not going to work if your ladder is up against the wrong wall in the first place.
It seems to me that we need to consider that current architecture & design strategies need a rethink or at least some re-alignment. They are focused on what I consider to be inside out thinking and that form of thinking is becoming obsolete in the context of a pure Digital economy.
Our current architectures patterns are focused on describing the systems related to specific process and functions needed by the bank to deliver its products to Customers. They typically describe what goes on inside the 4 walls of the bank to service the Customer and typically deliver specific predefined, static entry and exist points, the banks own delivery channels, Internet, Phone, mobile apps. These prescribe how a Customer or other party is allowed to access their data held by the bank. Agile architecture will deliver more flexible solutions faster for the bank but that’s not only what the Digital economy is demanding.
A true/pure Digital business model demands total outside-in thinking, with for example a ubiquitous access model, focused on high value outcomes, on the channel/platform of the consumers choosing, where the consumer has control over how, where etc they use their banking data. Digital is in fact creating a new distribution channel that is not controlled by the bank e.g. Apple Pay, Apple Watch, Zapp, Android Pay, even non-banking pervasive Apps such as Uber.
These platforms will want to integrate financial products and data within their App in a manner of their choosing. In this context the architecture and design team need to consider that the way the consumer / new Digital Channel may choose to use the banks products and resources is not yet fully defined. Yet the bank needs to offer attractive propositions into that channel that consumers will want to use. This is a design mind-set that bank architects are not accustomed to applying. In this model the focus needs to be on the ‘raw’ resources (e.g. data sets) the bank holds and how these raw resources can be integrated into a higher value outcome based solutions (e.g. get a taxi, research and buy a new car) for Digital customers. That’s not the way the bank builds service and product propositions today.
Total outside thinking is about building useful service points (external API gateways) for this Digital channel where the bank does not control the full use case, front to back. It’s also about integrating new outcome based value at these service points to make the bank more attractive to the channel, for example by enabling the automated transfer of ownership of a new car once the payment for the car is completed.
Architects will need to think about managing the architecture as a resource platformor as often described as 'the bank as a platform', to deliver to this new Digital channel. That’s a world apart from what is happening today. If the architecture team were asked to build a service catalogue for this new model I believe it would look very different to the SOA service catalogues being developed and managed today.
Let’s look at what is happening to Data. Data within banking architectures is organised into highly normalised and partitioned data sets, typically by product. Todays model allows for further optimisation and partitioning, of the mainly transactional data, to support data analytics and management reporting into many terabyte sized data warehouses.
The amount of data generated by the Digital economy is increasing dramatically, dwarfing anything seen to date. The demand for banks to manage many petabyte sized data warehouses is not far away.
The Digital environment will demand data management strategies to incorporate data emerging from the Internet of Things (IoT) where devices will incorporate buy buttons, external open and linked data environments and an organisations partners data sets. This data will have a significantly different data profile with much of the data unstructured and un-normalised. It will simply be inconceivable for an organisation to be able to (or want to) house and manage all the data needed in order to derive useful Customer insights and deliver competitive propositions. Continuing to build even bigger data warehouses cannot be the future, it will be difficult enough to manage the data set needed to control the operational Business.
These increased volumes, profile, location and behavioural changes of data in the Digital environment demand different data management strategies. An organisations data strategy needs to start to consider how to exploit these disparate data sets without having to load it into normalised data warehouses, consider usage of intelligent algorithms that will be operating on data sets both inside and outside the organisation, algorithms that will be able to work on data that is not normalised or structured, or live within your formal data governance model as they are today.
Analysis of any aspect of existing architectures in the context of the emerging Digital economy leads to similar conclusions. All change, all change!
This content is provided by an external author without editing by Finextra. It expresses the views and opinions of the author.
Eimear Oconnor COO at Form3 Financial Cloud
07 November
Kyrylo Reitor Chief Marketing Officer at International Fintech Business
06 November
Konstantin Rabin Head of Marketing at Kontomatik
Alexander Boehm Chief Executive Officer at PayRate42
Welcome to Finextra. We use cookies to help us to deliver our services. You may change your preferences at our Cookie Centre.
Please read our Privacy Policy.