BIAN 2nd Edition – A framework for the financial services industry E-Book

BIAN eV

• Herausgeber: Van Haren Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 337

Veröffentlichungsjahr: 2021

Beschreibung

The Banking Industry Architecture Network (BIAN) is a global, not-for-profit association of banks, solution providers, consultancy companies, integrators and academic partners, with the shared aim of defining a semantic standard for the banking industry covering all banking activity and almost all of the well-known architectural layers. BIAN’s Reference Architecture for the Financial Industry provides its users with a set of building blocks that, when used in different combinations, can support all of the functionality and information a bank needs for both its internal functioning and its collaboration with partners in an Open Finance and Open API economy. BIAN’s Reference Architecture for the Financial Industry is freely available on the BIAN website. This website also provides a wealth of information on both the theory and practice of the standard. So why this book? Importantly, it summarizes all of the above information and guides the reader through it on a step-by-step basis. It provides the reader with a thorough understanding of BIAN’s architecture and how it can be used to support an organization on its journey to becoming an agile business organization and developing an application platform. BIAN is a semantic standard. It provides business building blocks and defines them in business terms. It provides a business view on both the business and application architectures. This second edition not only includes the more recent deliverables, it also takes a stepped approach through the different topics. It aims to be more appealing to a business audience by addressing the building blocks of BIAN and their possible use in business terms, whilst also including many real-life examples of BIAN’s usage. As such, it should not only appeal to application and business architects, but also to their managers, their business partners and other stakeholders who work closely with them. The first part of the book focuses on the theory: BIAN’s organization, the principles and patterns on which its architecture is based, and its building blocks. The second part of the book explains – in methodology-independent terms – how BIAN can be applied in different architectural layers by different disciplines, in co-operation with architects. This part of the book includes a number of practical examples intended to improve the reader’s understanding of the building blocks of the BIAN architecture and encourage them to apply it for the benefit of their own organization. The final part of the book should inspire the reader even further by clearly illustrating the synergy between the content that BIAN delivers and the architecture methodology provided by TOGAF.

Leseprobe

Other publications by Van Haren Publishing

Van Haren Publishing (VHP) specializes in titles on Best Practices, methods and standards within four domains:

- IT and IT Management

- Architecture (Enterprise and IT)

- Business Management and

- Project Management

Van Haren Publishing is also publishing on behalf of leading organizations and companies: ASLBiSL Foundation, BRMI, CA, Centre Henri Tudor, CATS CM, Gaming Works, IACCM, IAOP, IFDC, Innovation Value Institute, IPMA-NL, ITSqc, NAF, KNVI, PMI-NL, PON, The Open Group, The SOX Institute.

Topics are (per domain):

IT and IT Management

ABC of ICT

ASL®

CMMI®

COBIT®

e-CF

ISO/IEC 20000

ISO/IEC 27001/27002

ISPL

IT4IT®

IT-CMFtm

IT Service CMM

ITIL®

MOF

MSF

SABSA

SAF

SIAMtm

TRIM

VeriSMtm

Enterprise Architecture

ArchiMate®

GEA®

Novius Architectuur

Methode

TOGAF®

Project Management

A4-Projectmanagement

DSDM/Atern

ICB / NCB

ISO 21500

MINCE®

M_o_R®

MSP®

P3O®

PMBOK ® Guide

Praxis®

PRINCE2®

Business Management

BABOK ® Guide

BiSL® and BiSL® Next

BRMBOKTM

BTF

CATS CM®

DID®

EFQM

eSCM

IACCM

ISA-95

ISO 9000/9001

OPBOK

SixSigma

SOX

SqEME®

For the latest information on VHP publications, visit our website: www.vanharen.net.

Colophon

Title:

BIAN 2nd Edition – A framework for the financial services industry

Author:

A publication of the BIAN Association

Contributing authors:

Martine Alaerts, Patrick Derde, Laleh Rafati, Guy Rackham

Reviewers:

Rajiv Dhir, Associate, Mundo Cognito Ltd

David Gilmour, Associate, Mundo Cognito Ltd

Cecil Jones ABD, CCP, PMP, MBA, Lean IT Professional, Vice President, JP Morgan Chase

Wang Meng, Architect, Shanghai Pudong Development Bank

Piyush Mittal, Client Partner, Global Banking and Financial Services, IBM

Gerard Peters, Enterprise Architect Director, Financial Services Global BU, Capgemini

Hans Tesselaar, Executive Director, Banking Industry Architecture Network

René De Vleeschauwer, Partner, Envizion

Roel de Vries, consultant, De Vries Consulting (chapter 2)

Text editor:

Steve Newton, Galatea

Publisher:

Van Haren Publishing, ’s-Hertogenbosch, www.vanharen.net

Lay-out and DTP:

Coco Bookmedia, Amersfoort – NL

ISBN Hard copy:

978 94 018 0768 5

ISBN eBook:

978 94 018 0769 2

ISBN ePub:

978 94 018 0770 8

Edition:

Second edition, first impression, July 2021

Copyright:

© BIAN Association and Van Haren Publishing, 2021

Trademarks:

ArchiMate is a trademark of The Open Group.

FIBO as ontology is a joint effort of the EDM council and the Object Management Group.

IFX is a trademark of the Interative Financial eXchange (IFX) Forum.

ISO20022 is a trademark of the International Organization for Standardization.

SWAGGER API is a trademark of Smartbear Software Inc.

TOGAF is a trademark of The Open Group.

This document is provided “as is”, and the BIAN Association and its members make no representations or warranties, expressed or implied, including but not limited to, warranties or merchantability, fitness for a particular purpose, non-infringement, or title; that the contents of this document are suitable for any purpose; or that the implementation of such contents will not infringe any patents, copyrights or other rights.

Neither the BIAN Association nor its members will be liable for any direct, indirect or special, incidental or consequential damages arising out of, or relating to, any use or distribution of this document unless such damages are caused by wilful misconduct or gross negligence. The foregoing disclaimer and limitation on liability do not apply to, invalidate, or limit representations and warranties made by the members to the BIAN Association and other members in certain written policies of the BIAN Association.

Foreword by the chairman of the BIAN Board

Why this book?

It’s been over 10 years now since some influential players in the financial services industry joined forces to stop the ever-growing cost for IT integration. The Banking Industry Architecture Network was born.

So, after 10 years of hard work by all members in our community, we bundled all of the knowledge and insights into the first BIAN 2019 edition of this book. As BIAN is continuously evolving and improving, so the BIAN book is also evolving and improving. Hence this second edition.

There has never been a more exciting time to be part of the financial services industry. Whether you’re a traditional player, a FinTech enterprise or a tech enabler, emerging technology and game-changing regulation is driving unique opportunities in the sector. Most banks embrace these new challenges by collaborating with rapidly emerging FinTechs, exploring the boundaries of their technological environments. It also gives the banks a unique opportunity to migrate away from their existing, and sometimes very outdated core systems, and move into a fully digital new world supported by industry standards.

This book covers all aspects of architecture for the financial services industry. It should support all those involved to help their organizations to enter a truly digital world.

Besides our original service-oriented view, the authors have also included our latest insights on enterprise architecture and provided you with guidance in the fast-evolving API arena.

I hope you will find what you need to perform your architecture role at its peak.

Enjoy reading!

Steve Van Wyk

Global Chief Information Officer at HSBC

Introduction by the Executive Director of BIAN

The Banking Industry Architecture Network (BIAN)

The Financial Services Industry Architecture Network (BIAN) is a global not-for-profit association of banks, solution providers, consultancies, integrators and academic partners with the shared aim of defining a semantic standard for the financial services industry covering almost all of the well know architectural layers1.

Who is this book intended for?

This book is intended for those enterprise, business and solution architects in the financial services industry (FSI) who are interested in applying the BIAN industry standards in their organization. The authors of the book expect the readers to have knowledge of business and/or ICT2 architectural principles and methodologies.

For those architects and organizations familiar with the TOGAF framework, we have added a chapter describing how one can apply the BIAN standards with this development framework.

How to use this book?

This book will provide you with an in-depth knowledge to understand the full construct of BIAN artifacts, how to apply them and how you can contribute to help the standards fulfill your organization’s needs. We will start with a short introduction of the BIAN organization, its goals, the deliverables and the future state.

Due to the constant development and evaluation of the BIAN models, additions to this publication will be publicly available at the BIAN homepage (www.bian.org).

The Banking Industry Architecture Network

The Banking Industry Architecture Network (BIAN) was formed in 2008 by a group of banks and solution providers with the shared aim of solving the integration issues by defining a semantic service operation standard for the financial services industry. At a later stage other standard bodies joined, as did some academic partners. BIAN’s expectation is that a standard definition of business functions, service interactions and Business Objects that describe the general construct of any bank, will be a significant benefit to the industry. When compared to a proliferation of proprietary designs, such an industry standard provides the following main benefits:

■ It enables the more efficient and effective development and integration of software solutions for banks;

■ It will significantly lower the overall integration costs;

■ It improves the operational efficiency within and between banks, and provides the opportunity for greater solution and capability re-use within and among banks;

■ It supports the current need for more industry integration and collaboration by the usage of open and standardized APIs;

■ It supports the adoption of more flexible business service sourcing models and enhances the evolution and adoption of shared third-party business services both on-premise and in the cloud;

■ It supports FinTechs and RegTechs to gain an easy insight in the complex FSI structure.

The BIAN Financial Industry Reference Architecture’s development is iterative, relying on the active contribution of industry participants to build consensus and encourage adoption. BIAN coordinates the evolution of the BIAN Financial Industry Reference Architecture on behalf of its membership with regular version releases to the industry, and seeks feedback to help continually expand and refine its content.

The Banking Industry Architecture Network Service Domain Landscape

BIAN Service Definition Working Groups govern Service Domains3. Each Service Definition Working Group has an associated area of business expertise. The scope covered by individual Working Groups is defined in their charter so that collectively, Working Groups cover the whole landscape with no overlaps between them. The governance for Service Domains within an area of business expertise is assigned to a Working Group. The Working Group is then responsible for the initial specification and any subsequent updates to its assigned collection of Service Domains. This implies the content creation is driven by the BIAN members using their experts’ expertise.

The Banking Industry Architecture Network and Open APIs

In 2018 BIAN launched their Open API Sandbox environment with a continuously increasing number of API descriptions. This open-for-all environment (www.bian.org/deliverables/bian-portal) is true open source, encouraging the industry to enhance the content provided by BIAN so it becomes easier to adopt. The BIAN API definitions are 1:1 aligned with all underlying models and we are capable today of generating the Swagger definitions and the microservices code directly out of our repository to ensure a world-class consistency.

We try, as far as possible, to align with the ISO 20022 definitions in order to increase the overall usability.

Just recently we enhanced the portal with new features and content so it is a real source of information for all who undertaking an ‘Open Banking’ journey.

The Banking Industry Architecture Network and Open Data

Driven by the growing importance of data as the lifeblood of effective decision-making, BIAN started developing the BIAN Information Architecture or “BIAN BOM”, (which stands for the BIAN Business Object Model).

The objective is to develop a standard Open Financial Services Conceptual Data Model. Where possible, BIAN aligns with existing standards such as ISO 20022 and FIBO.

BIAN applies a specific methodology to create Service Domain Business Object Model diagrams. All the identified Business Objects and the relationships between each other are consistent within and between the Service Domain Landscape.

Hans Tesselaar

Executive Director

Banking Industry Architecture Network

1 See Appendix A2.1 “Architecture layers and aspects”.

2 Information and communication technology.

3 The core building block for the definition of business functions, service interactions and Business Objects that describe the general construct of any bank.

About this second edition

The content of this second edition is a fully revised version of the first edition of BIAN, that was published in 2019 (BIAN Edition 2019).

The theory and principles of the BIAN Framework and its application in practice, are now treated in two separate parts of the book.

The most recent additions to the BIAN standards are the Semantic API descriptions and the Business Object Model (BOM). These are treated in more detail. The application of the BIAN Framework in different contexts is treated more extensively and has been illustrated with lots of (semi-)real-life examples.

Following topics have been added: the newly developed “BIAN adoption journey” and the Business Capability Model.

Contents

FOREWORD BY THE CHAIRMAN OF THE BIAN BOARD

INTRODUCTION BY THE EXECUTIVE DIRECTOR OF BIAN

ABOUT THIS SECOND EDITION

PART IINTRODUCING BIAN AND ITS REFERENCE ARCHITECTURE FOR THE FINANCIAL INDUSTRY

1 INTRODUCING BIAN, THE ORGANIZATION AND ITS REFERENCE ARCHITECTURE FOR THE FINANCIAL INDUSTRY

1.1 The Banking Industry Architecture Network, mission and vision

1.1.1 The Banking Industry Architecture Network

1.1.2 BIAN: vision, mission and Service Landscape

1.1.3 BIAN’s Reference Architecture for the Financial Industry

1.2 Principles of The Reference Architecture for the Financial Service Industry

1.2.1 Challenges for the financial industry

1.2.2 Agile. . . the silver bullet?

1.2.3 BIAN and agile architecture principles

1.2.4 BIAN is changing enterprise architecture thinking

1.3 Positioning the BIAN standard

1.4 BIAN, the organization

1.4.1 How the BIAN Architecture evolves

1.4.2 The BIAN Framework, a toolbox

1.4.3 BIAN Open Digital Repository

1.4.4 BIAN certification

1.4.5 BIAN adoption journey

1.5 Test yourself questions

2 EXPLAINING THE BIAN ARCHITECTURE

2.1 Notation of the BIAN Architecture Model

2.2 The BIAN Metamodel

2.2.1 Role of the BIAN Metamodel

2.2.2 Overview of the BIAN Metamodel

2.3 The Service Landscape

2.3.1 Business Area level

2.3.2 Business Domain level

2.3.3 Service Domain level

2.3.4 Service Landscape diagram

2.4 BIAN Service Domain

2.4.1 Functional Pattern

2.4.2 Generic Artifact

2.4.3 Asset Type

2.4.4 Service Domain representations

2.5 BIAN Control Record and Service Domain Information Profile

2.5.1 Control Record

2.5.2 Behavior Qualifier

2.5.3 Behavior Qualifier Type

2.5.4 Service Domain Control Record Diagram

2.6 BIAN Business Object Model

2.6.1 Business Object versus Business Concept

2.6.2 BOM content pattern

2.6.3 BOM structure pattern

2.6.4 The Service Domain BOM Diagram

2.6.5 BOM abstraction levels

2.6.6 BOM - ISO 20022 mapping

2.7 BIAN Service Operation and Semantic API

2.7.1 Nature of the Service Operation: Action Term

2.7.2 Subject of the Service Operation

2.7.3 Semantic API

2.7.4 Swagger File

2.8 The Service Domain Overview Diagram

2.9 BIAN Business Scenarios and Wireframes

2.9.1 Business Scenario

2.9.2 Wireframe

2.9.3 Service Connection

2.10 BIAN Business Capability

2.11 Test yourself questions

PART IIAPPLYING BIAN

3 INTRODUCTION TO PART II, APPLYING BIAN

4 WHAT BIAN CAN DO: GENERAL ABILITIES

4.1 BIAN as Frame of Reference

4.1.1 Common vocabulary

4.1.2 Common Frame of Reference

4.1.3 Adding features

4.1.4 Organizing and exploiting documentation

4.1.5 Building blocks for a reference architecture

4.2 Tailoring BIAN

4.2.1 Detailing specifications and models

4.2.2 An organization-specific Frame of Reference

4.3 BIAN can be introduced gradually

4.4 Test yourself questions

5 BIAN FOR A HOLISTIC ENTERPRISE VIEW

5.1 Defining and architecting Business Capabilities

5.1.1 Business Capabilities for strategy

5.1.2 Service Domains for architecture

5.2 Assembling an enterprise blueprint

5.3 Enterprise blueprint as/or a Frame of Reference

5.3.1 Defining and documenting strategy direction and requirements

5.3.2 Charting and evaluating the “operations” landscape down the stack

5.3.3 A uniform and stable base for performance management

5.3.4 BIAN for investment and change portfolio management

5.4 Testimonial

5.5 Test yourself questions

6 BIAN FOR THE BUSINESS LAYER

6.1 BIAN for business architecture

6.1.1 A Frame of Reference for the business landscape

6.1.2 Elaborating the organogram

6.1.3 Charting and assessing the business landscape

6.1.4 Governing the business architecture

6.1.5 Building blocks and principles for a reference business architecture

6.2 BIAN for business investment and change portfolio

6.2.1 Supporting mergers and acquisitions

6.2.2 Business change portfolio

6.3 BIAN for business design

6.3.1 BIAN for business process management

6.3.2 BIAN for business requirements

6.4 Test yourself Questions

7 BIAN FOR THE APPLICATION LAYER

7.1 BIAN for application architecture

7.1.1 A Frame of Reference for the application landscape

7.1.2 Charting and assessing the application landscape’s coverage

7.1.3 Utilities vs Service Domains

7.1.4 Governing the application architecture

7.1.5 Building blocks and principles for a reference application architecture

7.1.6 Assessing and improving the application landscape

7.2 Linking the technology landscape to Service Domains

7.3 BIAN for application investment and change portfolio

7.4 BIAN for application systems

7.4.1 End-to-end solution architecture

7.4.2 Creating “the system”

7.5 BIAN and application architecture styles

7.6 Test yourself questions

8 BIAN FOR INFORMATION AND DATA

8.1 Tailoring the BIAN BOM

8.2 The BIAN BOM for information and data architecture

8.2.1 Frame of Reference for the information and data landscape

8.2.2 Evaluating and improving the data landscape

8.2.3 In aid of the BI environment

8.2.4 BOM for information classification

8.2.5 Linking to data technology

8.3 Business cases for the information and data investment and change portfolio

8.4 BIAN for information and data on system level

8.5 Test yourself questions

9 BIAN FOR INTEROPERABILITY

9.1 BIAN as organizing Frame of Reference for the application service portfolio

9.1.1 The Service Domain / Service Operation Frame of Reference

9.1.2 Organizing the application service catalog

9.2 BIAN supporting application service landscape management

9.2.1 Steering the use of application services

9.2.2 Evaluating and improving the application service landscape

9.2.3 Changing and migrating the application (service) landscape

9.3 BIAN for future-proof APIs

9.3.1 Delimit service centers and services

9.3.2 Elaborate API specifications

9.4 Testimonial

9.5 Test yourself questions

PART IIIBIAN AND OTHER STANDARDS

10 BIAN AND TOGAF

10.1 A short introduction to TOGAF

10.2 BIAN and the ADM phases

10.2.1 Preliminary phase

10.2.2 Phase A: Architecture vision

10.2.3 Phase B: Business architecture

10.2.4 Phase C: Information systems srchitecture

10.2.5 Phase D: Technology architecture

10.2.6 Phase E: Opportunities and solutions

10.2.7 Phase F: Migration planning

10.2.8 Phase G: Implementation governance

10.2.9 Phase H: Architecture change management

10.2.10 Requirements management

10.3 Test yourself questions

11 ALIGNMENT WITH OTHER STANDARD BODIES

11.1 ISO 20022

11.2 OMG & EDM Council

11.3 The Business Architecture Guild®

11.4 Test yourself questions

APPENDICES

APPENDIX 1: BIAN ADOPTION JOURNEY

APPENDIX 2: TERMINOLOGY AND CONCEPTS

A2.1 Architecture layers and aspects

A2.2 Zooming levels for architecture

A2.3 Terms and abbreviations

APPENDIX 3 FEEDBACK TO THE TEST YOURSELF QUESTIONS

Feedback Section 2.11

Feedback Section 4.4

Feedback Section 6.4

Feedback Section 7.6

Feedback Section 8.5

Feedback Section 9.5

Feedback Section 10.3

Feedback Section 11.4

APPENDIX 4 LITERATURE AND SOURCES

INDEX

Figures

Figure 1-1 Darwin applies to the financial ecosystem too

Figure 1-2 Service orientation - layered view

Figure 1-3 A BIAN Service Domain is a component for an agile architecture

Figure 1-4 Comparing enterprise architecture and city planning

Figure 1-5 A well-designed city plan can support any journey

Figure 1-6 Migrating to a well architected application landscape

Figure 1-7 BIAN as “common language” between other standards and regulations

Figure 1-8 BIAN validation process

Figure 1-9 BIAN’s toolbox to create an agile banking architecture

Figure 1-10 Landing page of the BIAN Digital Repository (version 9)

Figure 1-11 The BIAN adoption journey, overview

Figure 2-1 The role of the BIAN Metamodel

Figure 2-2 BIAN Metamodel, overview

Figure 2-3 BIAN Service Landscape, Matrix view

Figure 2-4 BIAN Service Landscape, Value Chain view

Figure 2-5 Three elements defining the structure of the BIAN Service Landscape

Figure 2-6 BIAN Metamodel, Service Landscape view

Figure 2-7 BIAN Metamodel, Service Domain view

Figure 2-8 Functional Pattern - Generic Artifact Mapping

Figure 2-9 The Current Account Service Domain, its Asset Type, Functional Pattern and Generic Artifact

Figure 2-10 BIAN Metamodel, Control Record Model view

Figure 2-11 “Party Reference Data Directory Entry” Control Record

Figure 2-12 Party Reference Data Directory Entry Control Record and its Behavior Qualifiers

Figure 2-13 Break down of a Control Record into Behavior Qualifiers and Sub-qualifiers

Figure 2-14 Party Reference Data Directory Control Record Diagram

Figure 2-15 Metamodel for the Control Record Diagram

Figure 2-16 BIAN Metamodel, Business Object view

Figure 2-17 BIAN BOM content pattern

Figure 2-18 Applying the BIAN BOM in payments

Figure 2-19 BIAN BOM structure pattern

Figure 2-20 Payment Order BOM Diagram

Figure 2-21 Example of abstraction levels in the BIAN BOM

Figure 2-22 The scope of the ISO 20022 Business Model

Figure 2-23 BIAN Metamodel, Service Operation view

Figure 2-24 Action Terms per Functional Pattern

Figure 2-25 Current Account Service Operations work on different levels of the information profile

Figure 2-26 Current Account Semantic API and its Endpoints

Figure 2-27 BIAN Semantic API Endpoint format

Figure 2-28 Service Domain Overview Diagram for Current Account

Figure 2-29 BIAN Metamodel, Business Scenario and Wireframe view

Figure 2-30 An example of a BIAN Business Scenario Diagram

Figure 2-31 An example of a BIAN Wireframe Diagram

Figure 2-32 An example of a BIAN Service Connection, related to its Service Operation

Figure 2-33 Customer Management Business Capability Decomposition view

Figure 2-34 BIAN Metamodel, Business Capability view

Figure 2-35 Business Capability Model, top level

Figure 3-1 M5 Banking Group’s “Group Synergy” strategy

Figure 4-1 BIAN as a common Frame of Reference

Figure 4-2 Using BIAN as Frame of Reference to find and compare candidate solutions

Figure 4-3 M5 Banking Group’s generalization of the loan product fulfilment Service Domains

Figure 4-4 M5 Banking Group’s very own Standing Order Service Domain is split off from the Current Account Service Domains

Figure 4-5 The first components of Mfour Bank’s ”new” application platform (late 1970’s) mapped on the BIAN Service Landscape

Figure 5-1 Different disciplines in search of a common language and Frame of Reference

Figure 5-2 The common Frame of Reference provided by BIAN, enables a holistic enterprise view

Figure 5-3 Business Capabilities are served by several Service Domains that can serve several Business Capabilities

Figure 5-4 Service Domains are the linking pin between strategic business capabilities and the architecture that realizes them

Figure 5-5 Three steps in developing an enterprise blueprint

Figure 5-6 Assigning the responsibility for Service Domains in the ArchiMate language

Figure 5-7 The “bank on a page” for a line of business is its view on the common Frame of Reference

Figure 5-8 Examples of performance measures

Figure 5-9 Using the enterprise blueprint as a common Frame of Reference for change management,

Figure 5-10 M5 Group’s strategy: assessments lead to requirements, both attributed to Service Domains

Figure 5-11 Blueprint of M5 Banking Group’s “Group Services” entity, with assigned responsibilities

Figure 6-1 The responsibilities of an accounting department and a loan sales process clarified

Figure 6-2 Business pain-points visualized on the “bank on a page” of a BIAN member

Figure 6-3 Maturity rating per Service Domain, represented on the “bank on a page” of a BIAN member

Figure 6-4 Strategic requirements per Service Domain presented as a heat map on the “bank on a page” of M5 Banking Group

Figure 6-5 Service Domains cooperate in patterns, enabling a secure, controlled delivery of financial services

Figure 6-6 Process steps expressed as Service Domains facilitate the selection of business partners

Figure 6-7 The requirements for Service Domains and for their interactions are specified

Figure 6-8 Business Scenarios are consolidated into a Wireframe, a holistic view on the requirements,

Figure 7-1 Mapping Service Domains on application components reveals the variety of business functionality they support – and identifies duplications

Figure 7-2 A potential Service Domain duplication issue is mitigated by the data integration architecture

Figure 7-3 The “bank on a page” of a BIAN member being used to communicate an aspect of the application architecture strategy to management

Figure 7-4 Conceptual reference architecture pattern for secure customer access

Figure 7-5 Mzero Bank’s monolithic Loan application is decomposed step-by-step

Figure 7-6 Wireframe for the end-to-end embedding of a payment solution

Figure 7-7 Mapping of the “Reuse” candidates and a vendor offer (“Buy”) on the Service Domains required for the new Group Payment application

Figure 7-8 Requirement coverage comparison of candidate Group Payment systems for one Service Domain

Figure 7-9 A software product, as a cluster of three Service Domains, internally remains “uncluttered”

Figure 8-1 Information realization view

Figure 8-2 Labelling of data stores with BOM Business Objects reveals problems

Figure 8-3 Data Integration ensures the duplicated Party information remains consistent

Figure 8-4 High level information model for the Payment Group Service of the M5 Banking Group

Figure 9-1 The Service Domain / Service Operation Frame of Reference facilitates the search in M5 Banking Group’s application service catalog

Figure 9-2 API coverage heatmap on the BIAN-Service Landscape,

Figure 9-3 Testimonial: delimiting and prioritizing the development of future-proof APIs

Figure 9-4 Business Scenarios provide business context and information content to the service exchanges

Figure 9-5 Mapping of Mfour Bank’s party information services on BIAN’s Semantic API Endpoints

Figure 9-6 A bank’s BIAN-based API development and governance toolbox

Figure 10-1 The phases of the TOGAF ADM

Figure 10-2 TOGAF’s “zooming” levels imply an iterative approach to elaborating architectures

Figure 10-3 The Enterprise Continuum according to TOGAF and the position of the BIAN Reference Architecture for the financial industry

Figure 10-4 The Enterprise Repository according to TOGAF

Figure 10-5 BIAN’s contribution to the enterprise architecture toolbox

Figure A1-1 Stage 1 of a BIAN adoption roadmap: Evaluate BIAN

Figure A1-2 Stage 2 of a BIAN adoption roadmap: Build pilot case

Figure A1-3 Stage 3 of a BIAN adoption roadmap: Pilot BIAN

Figure A1-4 Stage 4 of a BIAN adoption roadmap: Adopt BIAN

Figure A1-5 Stage 5 of a BIAN adoption roadmap: Evolve your Architecture Practice

Figure A2-1 A bank consists of three different layers

Figure A2-2 Viewpoints on a bank: Architecture layers and aspects

Figure A2-3 Zooming levels: divide and conquer a wide scope and a great complexity

PART IINTRODUCING BIAN AND ITS REFERENCE ARCHITECTURE FOR THE FINANCIAL INDUSTRY

What to expect

This part of the book aims to create an understanding of the BIAN Framework.

This entails two objectives:

Firstly, the reader should understand the philosophy upon which BIAN’s Reference Architecture for the Financial Industry is based and the “constructs” (techniques and organization) used to create its elemental, mutually exclusive, collectively exhaustive building blocks.

Secondly, the reader will obtain an overview of what BIAN has to offer to facilitate the adoption of this Architecture. BIAN’s framework is a “toolbox” that supports financial institutions in their journey towards an agile architecture. BIAN’s Reference Architecture for the Financial Industry is the core of this framework.

Readers in a management position as well as business and application architects, need to understand the unique characteristics of the BIAN Reference Architecture and the toolbox supporting its adoption, that distinguish BIAN from other standards.

Business and application architects need a solid understanding of the principles that the Architecture is based on and of the type of “building blocks” that make up this Architecture.

1     Introducing BIAN, the organization and its Reference Architecture for the Financial Industry

This chapter introduces the BIAN organization and its Reference Architecture for the Financial Industry and how BIAN supports financial institutions in the adoption and application of its framework.

BIAN provides the financial industry with a “Reference Architecture” as a means to realize its mission and vision (Section 1.1).

To survive in these challenging times, where technology and regulations drive a drastic change in the financial ecosystem, banks need agile systems that can provide the required business agility. BIAN’s Reference Architecture is based on agile principles and supports a financial institution in the elaboration of, and migration to, an architecture that provides that necessary agility (Section 1.2).

The characteristics of the BIAN Reference Architecture provide it with a unique position compared to other standards (Section 1.3). BIAN aligns with all relevant standards. It has the ambition to provide a “common language” between different banking standards and regulations.

The BIAN organization (Section 1.4) provides a framework consisting of its Reference Architecture as well as publications, training and a certification program that support individuals and organizations to adopt its Reference Architecture. This framework evolves and keeps in touch with the reality of the financial industry through co-creation by its members, coordinated by BIAN.

■ 1.1 THE BANKING INDUSTRY ARCHITECTURE NETWORK, MISSION AND VISION

The BIAN organization was created to support financial institutions in their journey to an agile banking architecture on both an enterprise and solution level.

BIAN, the “Banking Industry Architecture Network”, offers a Banking Reference Architecture Framework that is an enabler to become an adaptive financial institution, conformant to the principles of an agile enterprise architecture.

1.1.1 The Banking Industry Architecture Network

The Banking Industry Architecture Network (BIAN) is a global, not-for profit association of banks, solution providers, consultancy companies, integrators and academic partners with the shared aim of defining a semantic standard for the banking industry covering almost all the well-known architectural layers.

The Banking Industry Architecture Network was formed in 2008 by a group of banks and solution providers with the shared aim of defining a semantic Service Operation standard for the financial services industry. At a later stage other standards bodies, like ISO and FDX joined, along with some academic partners.

The BIAN Association strives to enhance the flexibility and agility of financial services systems by improving the integration of these with an architecture that is based on services.

1.1.2 BIAN: vision, mission and Service Landscape

BIAN’s vision and expectation is that a standard definition of business functions, service interactions and business objects that describe the general construct of any bank will be of significant benefit to the industry.

The central objectives for ICT in the banking industry are to provide flexibility, to lower the ICT and operational costs of the bank and to help banks mitigate the risks and seize the opportunities associated with technology innovation.

BIAN’s mission is to provide the world with the best banking architecture framework and banking standard. BIAN provides a trusted roadmap for constant innovation.

The goal of the BIAN Association is to develop the most important content, concepts and methods in interoperability, supporting the aim of lower integration costs in the financial services industry and facilitating business innovation and agility by:

■ Providing an architecture framework with all of the necessary elements, tools and methodologies for a sustainable operational model through the adoption of, and alignment with, available market standards;

■ Focusing on the definition of semantic services and/or API-definitions to improve the semantic integration of the financial services landscapes;

■ Enabling the financial services industry to develop and run a loosely coupled environment successfully;

■ Gaining acceptance from the members of the BIAN Association and the industry of the way the requirements will be implemented by both financial institutions and solution suppliers, resulting in the defined services becoming the de-facto-standard in the financial services industry.

1.1.3 BIAN’s Reference Architecture for the Financial Industry

BIAN’s Reference Architecture is a collection of architecture artifacts that makes up its industry standard. The main fundamental building block within the BIAN Reference Architecture is the “Service Domain”.

The BIAN Service Domains define financial services-specific semantic services. The Service Domains are the cornerstone upon which to achieve agile flexibility.

BIAN’s Service Landscape is the term used to refer to the collection of Service Domains that are defining the functional capacity building blocks within the banking industry.

The value of BIAN is the standardization of those functional services based on a well drafted architecture with elements carefully chosen from industry best practices.

It is the ambition of the BIAN Association to achieve a consensus on the service definition among leading banks and providers in the financial services industry, which in due time should lead to standardized services.

When compared to an increasing number of proprietary designs, a dedicated industry standard, like BIAN, provides the following main benefits:

■ Created by industry experts from around the globe;

■ Regular updates following the market developments and industry needs;

■ It enables a more efficient and effective development and integration of software solutions within the bank and between banks;

■ It significantly lowers the overall integration costs;

■ It improves the operational efficiency within and between banks and provides the opportunity for greater solution and capability re-use within and among banks;

■ It supports the current need for more industry integration and collaboration through the usage of (open) APIs;

■ It supports the adoption of more flexible business service sourcing models and enhances the evolution and adoption of shared third-party business services;

■ It supports FinTechs and RegTechs to gain an easy insight in the complex financial services industry structure.

Banks can use BIAN to define their bank-specific agile architecture, supporting the interoperability of information and information services between participants of the financial industry eco-system. BIAN can also be used to optimize the interoperability of information and information services within the organization.

■ 1.2 PRINCIPLES OF THE REFERENCE ARCHITECTURE FOR THE FINANCIAL SERVICE INDUSTRY

The financial industry, with banks, real credit institutions, pension and property management companies, is one of the most digitalized industries in the world. Digitalization is evolving and changing fast and so is the financial ecosystem. Financial institutions are in need of support for agile digital transformation in an open finance ecosystem. It is BIAN’s vision and mission to provide such support.

1.2.1 Challenges for the financial industry

Financial industry in movement

The industry as a whole is facing one of the most challenging evolutions in history. Change is happening faster than ever. Disruptive technology is changing the lives of consumers in small but extraordinary ways. Today, virtual assistants schedule appointments, while smartwatches monitor our sleep patterns and voice command technology turns off our house lights.

Banking needs to fully participate in this evolution. Advancements in technology have increased demand for accessible and convenient solutions that meet a consumer’s banking needs. On top of that, the industry is aware of a new disruption that is brewing – one that will once again transform the industry over the coming years.

It is not only technology that is changing the scene. New regulations are changing the playing field dramatically. They force financial institutions to disclose financial information to Third Party Providers (TPPs), providing access to financial services to new players and facilitating the competition of FinTechs and RegTechs in the financial playing field. Regulations impose security requirements to protect person-related data. After the worldwide financial crisis in 2008, regulators are requesting comprehensive financial and risk reporting, including data lineage requirements.

Besides the drivers mentioned above the unforeseen disruption caused by COVID-19 extremely impacted the behavior of all parties involved in our industry. We are moving from “Cash” to “Cashless” and from “Face2Face” to “Virtual”. This all sets additional demands on technology and therefore on Architecture.

Boosted by COVID-19, regulations, RegTechs and FinTechs, the interoperability of financial data and services via “Open Linked Data” and “Open Banking APIs” is rapidly becoming an indispensable requirement for creating innovative financial services. It facilitates all types of customer journeys, from buying bread to buying a house, from commuting to and from work to planning to travel for leisure or business. In every journey where financial and trusted services are needed and trust is required, banks are seeking to be the preferred partner.

To remain the preferred partner in this changing financial ecosystem, financial institutions need to be information-driven, having the right data, of the right quality, at the right time at the right place, in the possession of the right party. Information that comes from a trusted source of truth. Next Best Offer, context specific offers, risk profiles. . . based on data that is unique to the financial sector, help financial institutions make informed decisions and remain the trusted partner that helps customers make informed decisions.

Financial information requirements and financial services are changing at a very high speed. The financial ecosystem is continuously changing, at an ever-increasing pace. This requires an adaptive and agile banking business. Adaptability to new regulations, service requirements, new market players and stakeholders drives the speed and dynamics of the financial world.

The financial industry services and data must become more transparent, secure and open. The financial services need to be tailored and deeply integrated into consumer’s lives, seamlessly, with information created on the spot by Artificial Intelligence Systems and offered at the right time at the right place to the right person.

Financial institutions partner with other ecosystem players, offering services that will extend beyond banking. The financial industry will provide services in a hyper networked service-oriented “Open API economy”, where multiple ecosystem players participate in collaboratively fulfilling the financial needs of the customer.

In this changing ecosystem, financial institutions want to remain “trusted custodians of financial services and customer assets4”.

Legacy complexity

Financial institutions were among the first to automate their businesses and are now among the most digitalized service providers. They have pervasive but often complex legacy ICT platforms, with lots of duplication of functionality and data. Monolithic systems, stovepipe systems, are connected through point-to-point connections with numerous interface adapters. These legacy systems are a barrier to reacting in a timely and cost-effective manner to market and ecosystem changes. Their complexity results in inflexible/unresponsive systems, inflated enhancement, increasing maintenance and operational costs, and an inability to rapidly leverage advanced solutions, technologies, approaches and business models.

To survive in an industry with high investments in digitalization and low margins, financial institutions are searching to lower the integration and interoperability costs, while being able to respond very quickly to change.

1.2.2 Agile. . . the silver bullet?

Figure 1-1 Darwin5 applies to the financial ecosystem too

The traditional way of realizing big transformation projects, changing the “current state” through a big “waterfall” project to a new “future state”, is no longer viable. The current state is constantly changing and the future state is a moving target. Big change programs are too slow in delivering outcomes. Continuous improvement, transformation and change capabilities at all levels of the organization are required.

Additionally, the traditional enterprise architecture approach that focuses on technical solution architecture is no longer sufficient to meet the needs of today’s financial institutions. Today’s enterprise architects are responsible for designing intelligence into the business and operating models, identifying ways to help their organization use data, analytics and artificial intelligence to plan, track and manage digital business investments.

Financial institutions are finding better and more rapid ways of developing software by co-creation. In-house development is combined with outsourced development and third-party software solutions.

BIAN offers a Reference Architecture for the Financial Industry that enables gradual transformation of legacy platforms, rapid response to changing demands and cooperation with partners.

BIAN offers an architecture that provides agility. However, agile is not equal to “doing Scrum”.

“Agilityis apersistent behavioror ability of an entity that exhibitsflexibilityto accommodate expected or unexpectedchangesrapidly, follows theshortest time span, and useseconomical, simple, and quality instrumentsin adynamic environment”6

This high-level definition applies to at least three main areas of agility:

■System agility: being agile in the organization’s operations (business and ICT operations);

■Process agility: being agile in the development and change processes;

■Business agility: having agility as a strategic focus, based on the financial institution’s process and system agility.

In order to be adaptive in rapidly changing circumstances, financial institutions need an agile banking architecture on an enterprise level. BIAN supports financial institutions in system agility, through an agile enterprise architecture. Together with a bank’s process agility, this enables the required business agility.

1.2.3 BIAN and agile architecture principles

BIAN’s Reference Architecture for the Financial Industry is developed according to agile principles.

Separation of concerns

Complex systems can be unraveled by defining sets of responsibilities that are elemental and non-overlapping. The responsibility areas are layered7 and capability8 based. The capabilities are “components”, concentrating functionality in specific places.

This ensures that the impact of changes remains as local as possible. Also, a limited number of people need to be involved in decisions about changes.

Loose coupling

The “components” identified by “separating concerns” are “loosely coupled” if they have a low number of dependency relations between them. Each component will fulfill its responsibilities by offering services, with minimal dependency on the services of other components. There is a high internal coherence of functionality and data, which facilitates analysis and understanding of the component as such.

Changes are kept within the component and propagation of the changes throughout the system is avoided.

Reusability

Components are “reusable” if they can be used in multiple situations and are independent of the status in an end-to-end process. Reusability is fostered if elements can easily be lifted out of their context and plugged in elsewhere. The design of the components is done with the objective of independency and reuse. This is a strategic choice. It requires the use of common standards for connections between components, such as a common vocabulary, common data, common service definitions and common documentation structures.

Encapsulation

A component is “encapsulated” if each component has its own internal data structure and process definitions to realize the offered services. The services of the components are made available to the environment by means of clearly defined interfaces which hide the internal complexity from the ease of use for the requester of the services.

Interoperability

Components exchange information and functionality services as if there are no boundaries between the components. An information system, a business function or other element, is connected to the rest of the architecture landscape by using clearly defined interfaces based on standards9 and designed by a contract specifying the service level arrangements.

New or changed business processes can thus be assembled as an orchestration of such components.

Service orientation

Components deliver services to each other. Business functions offer and consume internal and/or external business services. In a digitalized world, business services are supported by applications which offer and consume internal and/or external application services (Figure 1-2)10. Direct access to the data is not allowed but needs to be requested through a service.

The advantage is that when someone needs information, there is no need for knowledge of the internal structure of the data and the internal process realizing the service. Changes to this internal structure can be hidden from the user of the service.

Figure 1-2 Service orientation - layered view

BIAN’s Reference Architecture provides building blocks for an agile architecture