BIAN – a fanboy’s view
Banking Industry Architecture Network (BIAN)
- The Banking Industry Architecture Network (BIAN) established in 2008, is a collaborative not-for- profit ecosystem formed of leading banks, technology providers, consultants and academics from all over the globe
- The Banking Industry Architecture Network is created to establish, promote and provide a common framework for banking interoperability issues and to become and to be recognized as a world-class reference point for interoperability in the banking industry
- Derived from the larger TOGAF standards, BIAN is specifically developed for the Banking and Finance industries. Uses Archimate for Enterprise Interactions and UML/BPMN modeling for Service level.
- Banks such as PNC, UBS, BB&T, Citi, ABN-AMRO, Wells Fargo, JP Morgan Chase and Santander among others are members of the BIAN community. Suppliers like IBM, Cognizant, Accenture, FIS, Envision etc. are also already part of BIAN and known contributors. JP Morgan Chase and Salesforce are the latest entrants to BIAN joining as Board members in July last year.
Why do Banks need BIAN ?
- Improve operational efficiency within and between the Banks and provides the opportunity for capability and solution reuse.
- More standardized and optimized development and integration of software solutions.
- With concepts like PSD2 among others, Banks are facing challenges that require availability of their data to 3rd parties like the merchants. The traditional banking architecture cannot sustain this growing demand. Therefore, it is required to decompose their business and IT Landscape into several interlinked units.
- The Covid pandemic is an accelerator for all industries including Banking to become nimble. There’s growing realization among traditional big Banks that in order to be relevant in uncertain and changing times, they need interoperability, API-fication, and hence, BIAN.
- Composable solutions like Mambu and nCino though ahead of the curve, still need BIAN standardization in order to be part of the bigger interoperable community.
Inside BIAN
Famously described as “Bank on a page” , BIAN Service Landscape 9.0 structures all Bank capabilities in the following hierarchy:
Business Area
Business Domain
Service Domain
Source: BIAN Service Lanscape 9.0
M4 Value Chain(next page)
• Multi-level Lines of Businesses • Multi-Channels
• Multi-Products
• Multi-levels of Management
A Business Area is a grouping of functionalities.
These group of functionalities are fine-grained into Business Domains.
A Business Domain is a top level activity within a Business Area. It is however still too coarse grained to develop into software.
One level below and at the implementation is the Service Domain that has an associated API.
Service Domain is an atomic component, a capability that encapsulates management of a specific asset type.
E.g. A Service Domain called “SavingsAccount” will represent a Savings Account and has an associated
API that provides all the functionality that deals with a Savings Account.
There are about 300+ Service Domains in the BIAN Service Landscape which are mutually exclusive but collectively exhaustive, which means that there is no redundancy of data or functionality.
Adoption of BIAN — the “How-to” part
- •Taking a leaf from our existing API implementation methodology, we can have :
- Experience APIs : Fine grained representation of a user interaction. Corresponds to a Specific User function.
- Process APIs: Orchestration for System APIs and to act as a façade.
- System APIs: As per BIAN specifications and leverage the BIAN Object Model. Entry and access to a System of Record(SOR). Every System API should perform only a single function, hence providing modularity and abstraction for the SOR.
In order to avoid Vendor lock-in, we must build our own System APIs as per BIAN Standards.
The System API will be required to abstract out the Vendor’s proprietary API (unless the Vendor themselves have a BIAN compliant API)
Getting Involved
- Educate: BIAN Certification
- Contribute: Working Groups in BIAN