BIAN Exam Syllabus & Starter Package

The Financial Services ecosystem in turmoil

Disruptive technology is changing the playing field for consumer services in general and financial services in particular. Not only technology 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.

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, supported by an agile organization and ICT platform. Adaptability to new regulations, service requirements, new market players and stakeholders drives the speed and dynamics of the financial world.

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.

In order to be adaptive in rapidly changing circumstances, financial institutions need an agile banking and ICT architecture on an enterprise level. BIAN supports financial institutions in elaborating such a target architecture and in a step-by-step migration towards that target.

The Banking Industry Architecture Network and its mission

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 the business and application architectural layers and the behavior, services and information viewpoints.

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.

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.

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.

The BIAN foundation Certification

The BIAN Banking Architecture Foundation exam leads to the official BIAN Foundation certification by the Banking Industry Architecture Network. It is carried out by Van Haren Learning Solutions.

The BIAN Foundation Certification exam tests the candidate’s knowledge of the BIAN Reference Architecture for the Financial Industry. This includes the BIAN standard, aimed at interoperability in the Open Finance economy. By successfully passing the BIAN Foundation Exam, candidates will achieve the BIAN Foundation level certification which assures they have been audited and have successfully mastered the required BIAN Foundation level.

The foundation level includes their ability to describe the added value BIAN wants to provide to the financial industry and its service providers. It includes the knowledge and understanding of the design principles and elements of BIAN’s Reference Architecture for the Financial Industry. It includes understanding of the ways this Architecture can be used to reduce integration cost, maximize interoperability and improve the manageability of the enterprise. It includes an understanding of the relationships between BIAN and other standards.

The BIAN certification exam is intended for professionals in the financial services industry such as:

• Enterprise- and Solution Architects;
• Consultants and Senior Consultants;
• Tooling providers, software solution providers, integrators and 3th party service providers.

Key Benefits of the BIAN foundation certification are:

• It enables professionals to leverage the benefits of BIAN;
• It increases the knowledge and general skills of professionals regarding financial services and enables the creation of more transparent ICT systems:
• It provides professionals and their organizations with a competitive advantage;
• It is a hallmark for the professionalism of banking professionals and banking architects.

The BIAN foundation Certification exam

The knowledge of the candidates will be tested through a multiple-choice exam. An overview of the exam characteristics is given in Table 1.

All exam candidates will get access to the online exam environment and will need to answer 60 multiple-choice questions within 60 minutes.

70% of the questions need to be answered correctly (or at least 42 of the 60 questions) to pass.

Questions can have one to many correct answers. The number of correct answers is not always indicated in the question. Negative questions (… NOT…) are included. Candidates are advised to read both questions and possible answers with care.

The candidate will receive the result immediately after the exam. (Digital) Access to your certificate will be given once you have passed.

Registration for the exam can be done by purchasing a participation certificate at www.vhls.global.

The candidate can take a number of trial exams, but only one actual certification exam. Taking trial exams before attempting the actual certification exam, is highly recommended.

Table 1 overview of BIAN foundation certification exam characteristics

Number of questions:                                     60
Time (minutes) for the exam:                      60 minutes
Passing grade:                                                 70%
Open/closed book:                                         Closed
Language:                                                        English
Exam format:                                                   Online
Type of question:
Multiple choice One to many possible correct answers Negative questions included

BIAN Certification levels

The BIAN Banking Architecture Certification will consist of two levels.

The Foundation level, described in this syllabus, tests the knowledge and understanding of BIAN’s Architecture and of its possible use.

The practitioner level will test the candidate’s ability to apply BIAN in a certain field of expertise. This level is still being elaborated.

The BIAN foundation Certification in the Bloom Taxonomy

The BIAN Banking Architecture Foundation Certification audits candidates at the Bloom Levels 1 and 2.

This means (according to Bloom’s Revised Taxonomy):

• Remembering: Bloom Level 1
• Understanding: Bloom Level 2

BIAN Foundation Certification Scope

The learning objectives state what the candidate needs to know and be able to do. Achieving these objectives is expressed by passing the BIAN Foundation Certification exam.

For the Foundation Certification the student needs to demonstrate:

• Having an understanding of what BIAN is and being able to describe the purpose of BIAN and its design principles.
• Being able to describe BIAN’s added value for the financial services industry.
• Being able to describe and recognize the elements of the BIAN architecture and their role in different contexts.

To test these learning objectives, the scope of the BIAN Foundation Certification encompasses following subjects.

Overview of the BIAN foundation certification exam

The candidate’s knowledge will be tested on the topics enumerated in Table 2. Each topic has a different weight. The number of exam questions testing that topic will be chosen according to this weight.

Table 2 BIAN foundation certification exam topics and their weight

Exam Specification                                                                        Weight %

Introducing BIAN and its Framework                                       10%

BIAN: Principles and approach.                                                10%

Explaining the BIAN Architecture                                             35%

HOW TO APPLY THE BIAN STANDARD, general abilities          15%

HOW TO APPLY THE BIAN STANDARD,
applied to layers and transversal views                               25%

BIAN AND TOGAF                                                                        5%

Introducing BIAN and its Framework

The candidates need to remember and understand the characteristics of BIAN and its offering.

The BIAN association, its vision, mission, goals and benefits 

BIAN’s vision, mission and goals have already been described in the introduction.

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.

Positioning BIAN in the standards landscape

BIAN is a content standard.

It uses the ArchiMate and UML languages to document its Reference Architecture for the Financial Industry, but does not prescribe the use of a modeling language to users of this Architecture, nor does it prescribe a documentation tool.

There is a major synergy between BIAN as content framework and TOGAF as architecture methodology, but BIAN does not prescribe specific methodologies or techniques.

As a content standard, BIAN is semantic: it offers business definitions and describes WHAT needs to happen/be known, not HOW or WITH WHAT this needs to be implemented. BIAN is implementation and technology agnostic. BIAN is exhaustive: it offers a definition of business functions, service interactions and business objects. It covers all activities on an architecture and design level.

BIAN has a strong working relationship with other standard bodies and aligns with existing standards where relevant and possible. 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.

How BIAN evolves: a member-driven architecture

The development of the BIAN architecture is iterative, relying on the active contribution of industry participants to build consensus and encourage adoption.

BIAN’s Architecture is elaborated by working groups, each focusing on a specific area and aspect of the banking architecture. Working groups always have member banks as members, not only service providers and academic partners.

Members as well as non-members can communicated proposals for changes and additions to the BIAN Architecture.

The BIAN Framework is a toolbox

The BIAN Framework is a “toolbox” that contains its Reference Architecture for the Financial Industry as well as means to support its adoption.

BIAN offers an open digital repository, which contains its Reference Architecture for the Financial Industry and an API portal, that provides access to the Semantic API descriptions and the Swagger Files.

The BIAN website offers publications that provide guidance in understanding and using the BIAN Architecture and standard. The information contained in these guides, white papers and webinars is summarized in the first and second edition of the book “BIAN, a framework for the Financial Services Industry”.

A typical BIAN adoption journey is described

BIAN offers training and certification for professionals and is working on certification for vendor products.

The Reference Architecture for the Financial Industry is partly meant as standard: Service Domains, Service Operations and their Semantic APIs and Business Objects are applicable and “canonical” for all financial institutions1 . Business Capabilities, Business Scenarios and Wireframes are archetypical examples, not meant to be generally applicable.

BIAN’s Architecture is based on Agile principles

BIAN offers a “capability based” Architecture. Contrary to a process-based architecture, this focuses on unique, Mutually Exclusive, Collectively Exhaustive building blocks of “abilities to provide outcome”. These can be combined in orchestrations supporting any banking functionality.

A business and logical application architecture, based on this “building block” approach, is “agile”. It can support the business agility required in the rapidly changing financial ecosystem.

BIAN’s Reference Architecture for the Financial Services Industry is elaborated according to agile principles:

• Separation of concerns
• Loose Coupling
• Reusability
• Encapsulation
• Interoperability
• Service Orientation

Applying the Reference Architecture for the Financial Industry results in architectural “simplicity”, as opposed to the complexity most financial institutions suffer from. A complexity that causes high maintenance costs, low flexibility and cumbersome migration trajectories.

Changing architecture thinking: building blocks versus process-based architecture

BIAN introduces “capability-based” thinking, in stead of the usual “process based” architecture thinking. BIAN’s building blocks are the “ingredients” that enable an architect to design an agile architecture for a financial institution, that can support any “stakeholder journey”. This can be compared to the way a town planner designs an effective town plan, based on the “ingredients” such as homes, roads, parks… This town plan is deigned to support any “journey” through the town in the most effective way.

The BIAN Metamodel

A model is an abstract representation of reality. A metamodel defines the constructs and rules for creating such models. An architecture model consists of a set of building blocks and their relationships. The metamodel defines the types of building blocks and the possible relationships between them. The architecture model can be managed in an architecture repository, according to the metamodel. According to the metamodel, the architecture model can then be exploited, to produce “architectural artefacts” that can provide information for stakeholders.

The BIAN Metamodel defines the types of building blocks BIAN uses to capture the reality of a financial institution in an architecture model. It also describes what artefacts BIAN produces to support financial institutions

The Service Landscape

The BIAN Service Landscape is a representation that organizes the BIAN Service Domains. The Service Domains are grouped into Business Domains, which are subsequently grouped into Business Areas. This creates an access path that facilitates finding and accessing Service Domains.

The Service Landscape is not intended to represent a design blueprint for any bank.

Service Domain and its pattern

The Service Domain is a core concept in the BIAN architecture.

A BIAN Service Domain represents the smallest functional partition that can be service-enabled as a discrete and unique business responsibility. All BIAN Service Domains taken together make up a “peer set” with each performing its own specific business function or purpose. Together, interacting through their Service Operations, they can cover all of the functionality required by a bank.

A Service Domain is constructed according to a pattern that ensures its uniqueness. A Service Domain fulfills its role by executing a Functional Pattern on instances of an Asset Type. Each Service Domain combines a single primary Functional Pattern (e.g., manage, design, operate) with an Asset Type (e.g., a piece of equipment, a customer relationship).

Control Record and Information Profile and their pattern

The complete collection of business information governed by a Service Domain when implemented as a stand-alone service center, is described by the Service Domain Information Profile. The Service Domain Information Profile consists of information on two levels:

• Information at the level of service domain used for the control and management of the Service Domain as a service center.

• Information at the level of the Service Domain’s role execution. This is covered by the Control Record instances.

The Control Record structure is based on a ”pattern”.

The Control Record represents a set of business information that reflects all information created during the fulfillment of the role of a Service Domain A Service Domain fulfills its role and responsibility by the execution of a Functional Pattern on an instance of an Asset Type. Hence, the Control Record represents the information about the Asset Type combined with the information that is central to the execution of the Functional Pattern: the Generic Artifact.

The Service Domain is responsible for executing the Functional Pattern and managing the Control Record accordingly, during the entire lifespan of the Asset instance. It can manage one Control Record, or a whole set.

The Control Record can be further decomposed into Behavior Qualifiers according to a Behavior Qualifier Type. A Behavior Qualifier Type is a type of information that refines the Generic Artifact, according to a refinement of the conceptual behavior of the Service Domain (i.e., the Functional Pattern).

Business Object Model and its approach and patterns

The BIAN BOM (Business Object Model) is elaborated by modeling the information needs of every BIAN Service Domain, as expressed in its Control Record, according to the “Business Object Modeling approach”. The resulting individual Service Domain Business Object Models (Service Domain BOMs) are consolidated into the BIAN BOM. The “Business Object Modeling approach” ensures the consistency of the BIAN BOM.

Two key notions in the BOM approach’s way of thinking are “business concept” and “business object”. Being able to make the distinction is key.
The Business Objects are discerned and modeled according to two patterns.
The BOM content pattern is an abstract information model, valid for any business. It contains the Business Objects and their relationships, that make up any business, on a high abstraction level. This model can be made more specific for a particular business context.
The BOM structure pattern, enriches the content pattern by indicating the types of classifications that can be applied to Business Objects, their relationships and attributes.

Service Operations and Semantic API and their patterns

Every Service Domain offers a collection of Service Operations. The purpose of an offered service is characterized by an Action Term which is a fundamental unit of behavior. A Service Operation offered by a Service Domain is made available to the environment through an access point called a Semantic API Endpoint. The collection of the Semantic API Endpoints of one Service Domain is represented by its Semantic API.

The Message, containing the information exchanged in a Service Operation, as described in its Semantic API Endpoint, refers to the Information Profile of the Service Domain, or any of its constituent parts. This information content can also be expressed as a view on the Business Objects, as defined in the BIAN BOM.

The Service Operation and its Semantic API can be used to define and design Application Services and APIs. A machine-readable Swagger File can be generated from the Semantic API. The Semantic API Swaggers can be extended to create executable APIs.

Business Scenario and Wireframe

BIAN Business Scenarios and Wireframes provide practical examples of how Service Domains can interact. They are not part of the BIAN standard but are included in the BIAN Framework because they provide a powerful mechanism to illustrate, by example, the roles and interactions supported by the Service Domains.

A Business Scenario is a depiction of how BIAN Service Domains might work together through Service Operations in response to an event. These Service Operations realize the Service Connections between the Service Domains, required to produce the desired outcome of the Scenario. Business Scenarios are not process descriptions. They do not imply a specific execution order.

A Wireframe is a depiction that shows the Service Connections between a selection of Service Domains.

The service dependency between two Service Domains, one offering the service and one consuming the service, is called “First Order Connection”.

Business Capability

A business capability represents the bank’s abilities and capacities to realize its banking strategies and to create value in its ecosystem. Business capabilities are an instrument for a bank to define its banking strategy. BIAN defines Business Capabilities that can be used as such or can inspire a bank’s own business capabilities.

A BIAN Business Capability can be described as a collaboration between Service Domains. A BIAN Business Capability is “served” by a series of Service Domains and each Service Domain can be a building block for more than one Business Capability.

BIAN as Common Frame of Reference: ambition levels

The BIAN Architecture offers a MECE2 collection of elemental, semantic building blocks for a bank’s activities, information and services, canonically defined. Thus, it is well positioned to be used as “common Frame of Reference” for the functionality offered by the business organization and application platform. This characteristic can be used on different ambition levels:

– As common language to facilitate understanding between speech communities.
– The business and application landscape can be overlaid on the BIAN-based Frame of reference, in order to uniquely identify the functionality provided business organizations and processes and by application(platform)s. This is a powerful tool for evaluating, comparing and optimizing business and application landscapes, and for clarifying the links between these landscapes.
– Features such as requirements and performance measurements and assessments can be documented using the BIAN building blocks as anchor point.
– Documentation of existing or target solutions can be “labeled” and organized according to this Frame of reference, using the Service Domains as anchor points for documentation. Repositories can be “indexed” with the BIAN building blocks, facilitating their exploitation.
– The principles and building blocks of the BIAN Architecture can be used as basis for a conceptual reference architecture, steering new developments and the optimization of the business and application landscape

Tailoring

The BIAN Architecture can be tailored to the bank’s specificities and needs.

Its descriptions can be detailed, Service Domains and Business Objects that are not relevant for a specific bank can be omitted (“select”). Service Domains can be merged or split or added, Business Objects can be abstracted, decomposed and specialized (“customize). A bank can use its own Service Landscape structure.

All types of tailoring are possible, as long as the principles and patterns that underpin the BIAN Architecture are respected. Tailoring should stay on the semantic, conceptual level and not be confused with documenting implementations.

Gradual introduction

BIAN can be introduced step-by-step “in time and space”. A bank can start by using it on the lowest ambition level, as “common language”. It can evolve to using it as common Frame of reference to systematically explore and map the functionality if the business organization and the application platform. Finally, it can use BIAN as basis for a conceptual Reference Architecture, steering new developments and optimizations of the legacy platform.

The BIAN Architecture provides a MECE collection of stable, well-delimited partitions for a bank’s activities and information. This supports an area-by-area introduction.

A holistic overview on the enterprise

Enterprises often consist of different “speech communities”. The enterprise blueprint, depicting the responsibilities of the entire enterprise as well as those of its divisions, lines of business… and other subdivisions, can be expressed in terms of Service Domains. This provides a common, speech community-independent language and Frame of reference to enterprise management. This Frame of Reference can be of use to link Strategy and Operations and facilitate the “Steer, Operate, Assess and Change” cycle.

The expressions “blueprint” and “Frame of Reference”, although slightly different in meaning, need to be considered as synonyms in the context of the exam.

Management, in its “steer and govern” responsibility, is supported by different disciplines, such as strategists (steer), architects (operate), performance managers (asses) and investment and change portfolio managers (change). BIAN can be used as “common language” and “common Frame of reference” by all these disciplines. This makes it easier to communicate among each other and to provide management with a holistic view on the enterprise.

The BIAN Framework supports Banking Strategy Management (steer) by offering archetypical Business Capabilities in a Business Capability Landscape. Service Domains are elemental, stable capability building blocks that serve these Business Capabilities. The strategic positioning and requirements of the Business Capabilities can be projected on the Service Domains.

The Banking Strategy is supported by the Business strategy (business layer) and the Information System Strategy (application and technology layer). Service Domains, as stable capability building blocks, that can be flexibly combined in numerous ways, are the instruments for these strategies. Service Domains are realized by actual “systems” such as business processes or functions, applications… Systems that represent the actual operations of the bank.

Strategic positioning of and (increasing levels of detail of) requirements to these systems can be documented per Service Domain. Performance assessments can be documented on the same scale. This information can be “passed down” through the architecture layers, as these are all 3 mapped on the BIAN Frame of reference. The availability of (strategic) requirements and assessments on the same scale, facilitates the detection of areas that need investments or changes. The scope of such initiatives can also be expressed in impacted Service Domains.

The common Frame of reference facilitates the communication between different disciplines (such as architecture, performance management and change management). It can improve the communication within these disciplines. This results in an improved quality of their deliverables.

This Common Frame of Reference is also obtained by enterprise management, by expressing the enterprise blueprint in BIAN language. It is used to communicate information from different points of view to them. This facilitates management to acquire a holistic view on the enterprise.

Business layer

The support BIAN provides for the different architecture layers and viewpoints corresponds to the same pattern, resulting from BIAN’s general abilities and its support for a “holistic view” on the enterprise. We will treat these types of support in more detail under this subject (BIAN for the business layer) and mention them more shortly under “application layer”, “information and data” and “interoperability”.

Specifically for the business layer, the organogram can be expressed in Service Domains.

BIAN can be of use on business architecture level in following fields:

• The Service Landscape and its Service Domains (or a tailored version the bank made) serves as common Frame of Reference.

It can be used to explore the business landscape: The business landscape (organizational units, processes, business functions…) can be overlaid on this BIAN-based Frame of reference to uniquely identify the functionality that is performed.

This enables a one-to-one comparison of the functionality present in different organizations. It enables the detection of duplications, reveals gaps… As such, it contributes to the assessment and optimization of the business landscape.
It can be used to assess the synergy/complementarity in merges and acquisitions.

Requirements and performance information can be documented along a Service Domain structure. This facilitates the assessment and comparison of “business systems” and the detection and scope delimitation of investment and change proposals.

If business documentation is “labeled” with the Service Domain that is realized (and the documentation repository is indexed accordingly), this supports the search for projectstakeholders and the impact analysis of change initiatives.

• Service Domains can be used as building blocks for conceptual reference architecture patterns. Such patterns. These patterns prescribe what (reusable) business functionality is involved when embedding new functionality in the end-to-end enterprise. The principles the BIAN Architecture is based on, can be adopted too.
• The BIAN Architecture provides a stable, friction-free partitioning of a bank’s business functionality. This supports architecture governance (“divide and conquer”), as it enables the delimitation of architecture responsibility areas.

Each Service Domain partition receives a strategic value and risk evaluation, based on the Service Domain’s contribution to the bank’s strategy. This is “inherited” by the elements of the business landscape that are realizations of this Service Domain.

BIAN can be of use on business design level in following fields:

• Requirements can be documented per Service Domain. This promotes “service business capability building block” thinking instead of monolithic process-support thinking.

It facilitates the search for service providers within the organization as well as without: If business service providers document their service offering on the same Service Domain scale, comparison with the business requirements is more straightforward.

• Service Domains can be used as high-level process steps, facilitating the cooperation between process managers and the search for the best service provider for each process step. Though BIAN’s Business Scenarios are not process descriptions, they can be used as inspiration.

Application layer

If business and application architects share the common BIAN Frame of Reference, the communication between them will be improved. The evaluation of the coverage of the application platform will be facilitated as well as root-cause analysis of business problems and impact analysis of ICT issues. The scope definition and impact analysis of projects will be more reliable.

BIAN can be of use on application architecture level in following fields:

• The Service Landscape and its Service Domains (or a tailored version the bank made) serves as common Frame of Reference. This Frame of reference can be used explore, compare, assess and improve the application landscape.

It can be used to assess the compare application platforms in merges and acquisitions.

As Requirements and performance information is documented along a Service Domain structure, the assessment of application systems is made easier and the scope and impact of investment and change proposals originating on the application layer will be more clear to management.

• The technology landscape cannot be directly mapped on Service Domains, but as it is linked to the application landscape through configuration information, the contribution of its elements to “functionality building blocks” can also be explored and evaluated. The business contribution of projects originating on this layer becomes more clear as the project-scope can be “translated” to the “common BIAN language”.
• Service Domains can be used as building blocks for conceptual reference application architecture patterns. BIAN’s Architecture principles are sound application architecture principles.
• The BIAN Architecture supports architecture governance (“divide and conquer”) and the application support can receive a strategic value and risk evaluation per for Service Domain partition.
• Legacy applications can be optimized and their life-cycle prolonged by overlaying them on the Service Domain Frame of reference. This shows candidates for “application externalization”. This can mean that the functionality is eliminated and replaced by a service call, or – if the application is selected as “master”: the functionality is either isolated in a separate servicecomponent, or service-enabled through “wrapping”.
• Service Domains provide stable, generic application component boundaries (one Service Domain or a cluster of closely cooperating Service Domains).
The Business Scenario and/or Wireframe technique can be used to detect an delimit such “clusters”.

BIAN can be of use on application design level in following fields:

• Requirements can be documented per Service Domain. The “Service Domain-index” supports the search for reusable application components and the search for suitable vendor software or application service providers.

Service Domain (clusters) as “mould” for application component delimitation is relevant, for all “sophistication levels” of application architecture style. Whether it be a “direct to core” exchange of services on one application platform, a “wrapped host” exchange through EAI facilities4 or a “distributed architecture” where canonical services are exchanged in a cloud-based environment.

Information and data

The “BIAN-based Frame of Reference for information and data is not the Service Landscape and its Service Domains, but the BIAN Business Object Model (BIAN BOM). This BIAN BOM can be detailed and tailored to a bank’s specificities, similarly to and preferably together with, the tailoring of the Service Landscape.

BIAN can be of use on architecture level in following fields:

• The BIAN BOM and its Business Objects (or the “Bank BOM”, the tailored version the  bank made) can be used explore the information landscape. It can uniquely define which information is created and used in what process and by which organization.
• It can be used to explore, assess and improve the “data at rest” (data stores) and “data in motion” (data flows and services) landscape, by indicating duplications and gaps.
• The value and risk of business information – hence of the data that represent this information on the application layer- can be expressed per (group of) Business Object(s).

BIAN can be of use on design level in following fields:

• A first draft of information Requirements can be derived from the Control Records and/or Service Domain BOMs of the Service Domains that are involved in the solution.
• The “Business Object-index” supports the search for reusable data stores and data flows.
• The BIAN BOM or “Bank BOM” can be detailed to become a “canonical data model”. This canonical data model supports the creation of a “Business Intelligence” environment where all data available in the enterprise need to be navigable

Interoperability

“API” (Application Programming Interface) and “application service” are used as synonyms for the sake of this exposé.

The “Service Domain Frame of Reference” can be extended with the detail of Service Operation. The “Service Domain / Service Operation Frame of reference” provides a MECE collection of stable, elemental building blocks for any application service.

BIAN can be of use on application service architecture level in following fields:

• The “Service Domain / Service Operation Frame of reference” can be used as an organizing Frame of reference for the application service catalog. Each application service can be labeled with the Service Operations it realizes
• The catalog, organized in this way, can be used to assess and improve the application service landscape.
• It can be used to steer the use of application services.
• Application services, aligned with the boundaries of Service Domain and based on the BIAN Service Operations, provide stable service boundaries. Service users, switching from one implementation to another, can expect changes to be limited to the immediate vicinity of the interface, without propagation to business functionality.
• The stable nature of the BIAN-based application services, facilitates a gradual optimization of the application portfolio.

BIAN can be of use on API design level in following fields:

• Service boundaries of application components can be derived using Business Scenarios and Wireframes. The Semantic API descriptions provide detail about the Service Operations that are exchanged.
• The information content of the service exchanges can be enriched with content of the “canonical data model”, based on the BIAN BOM.
• BIAN provides Swagger Files, as a programming “stub”. This should not be confused with actual executable software.