38
whether to maintain the various business capabilities in-house, or simply consume them off the cloud as and when required.
“For those deciding to go with the latter, the good news is that there are a number of supportive factors in play – the availability of an increasing number of standardised APIs, and cloud solutions from software – and infrastructure – providers envisaged by BIAN.”
Key properties
Some key properties of the BIAN Service Landscape and Service Domains are that the BIAN model uses a very specific representation of business activity that differs from most prevailing models: rather than modelling end-to-end business processes that capture the linked sequence of actions needed to respond to a business event, the BIAN model seeks to identify the discrete business capabilities that are involved in the event, without prescribing when or in what sequence they may be engaged. Business applications developed from conventional process-based designs tend to automate well-defined or repetitive activities, like a factory production line.
The BIAN designs can be used to architect applications that act as loosely coupled, asynchronous service centres that interact through queue-based message exchanges, a design well suited to Cloud implementation.
Because the BIAN Service Landscape and its constituent Service Domains have the above properties, a banking business blueprint
THE BIAN SERVICE LANDSCAPE
• The BIAN Service Landscape contains the complete collection of business capabilities that might make up any type of bank or banking enterprise – these business capabilities are called BIAN Service Domains.
• The scope of a BIAN Service Domain is designed to represent a discrete and elemental business capability – the business role of a Service Domain is canonical, meaning it can be consistently interpreted in any deployment.
• The business capabilities defined by BIAN Service Domains can be implemented with an ‘encapsulating’ service boundary that allows them to be in or out-sourced through the Cloud as long as all of their service dependencies can be supported.
• The BIAN Service Domain establishes the scope and external service boundary for a business capability without defining how it may perform that role internally. The business purpose or role of a Service Domain – ‘what it does’ – is highly stable over time even though its internal mechanisms – ‘how it does it’ – will inevitably evolve as new techniques and practices are developed.
With open APIs soon to be a reality, banks must alter their back-end structures to accommodate for them
“
defined using BIAN Service Domains is canonical and common for all banking activity. Also, because the service boundaries of Service Domains are highly enduring, the model is stable over time. As the Service Domains encapsulate their internal working behind their service boundary, systems solutions that are aligned to this model can use highly distributed service enabled environments, such as the Cloud, to support a fully componentised and distributed business operating model.
A typical full-service bank will contain well over 250 different Service Domains and depending on its organisational structure, some of these Service Domains will have many duplicated instances.
Tesselaar says: “There is a conventional centralised Cloud service implementation – the Cloud-based service offers a virtual utility where each dedicated instance accessed by a bank is integrated with its locally operated systems. We use the standard industry Service Domain blueprint to connect a service provider with two banks as well as allowing those banks to source services with each other and a third bank, showing how the Cloud now can act as an operational service broker for in/outsourcing services between banks (and non-banks requiring financial service capabilities) and service providers.
“However, there are still changes required if banks are to truly embrace a PSD2 landscape – it will take more than just simply the sanctioning of open APIs. If banks are serious about outsourcing technology based on this information at a later date, they must first look at their own infrastructure and modify it so that it can support this new technology.”
A standardised framework
Today, the current architecture of traditional banks does not allow for collaboration of this type. If all banks are to set themselves up to prosper from the incoming sharing culture, a standardised framework across the entire banking industry is paramount, BIAN believes. This standardisation will allow for the synchronisation of APIs and IT systems across the landscape.
As Tesselaar says: “Banks can only make one move now. With open APIs soon to be a reality, they must alter their back-end structures to accommodate for them. They need to be implementing a uniform platform that will allow for the progression of the industry, leaving behind the archaic and inefficient architecture that is currently holding them back. It’s clear from the discussions I heard at SIBOS that collaboration is at the forefront of banks’ minds. The next move is to act on this and take the necessary steps to ensure this becomes a reality.”
www.ibsintelligence.com | © IBS Intelligence 2018
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52
