🍿 💮 ♣️ Reference model BIAN. What new and useful for the corporate architecture of the bank does it offer? 👩🏽‍🌾 🤞🏿 👩🏽

BIAN ... how little is there in this sound for the heart of a Russian ... Yes, it was not by chance that I paraphrased the famous classic. In Russia, the popularity of the BIAN reference model is still low, especially in comparison with the Enhanced Telecom Operations Map (eTOM) model, which is widespread in the telecommunications industry, which is ahead of its development. Meanwhile, the BIAN model is developing, improving and gaining popularity outside of Russia and in the international banking industry community.

I will no longer distract the reader with lyrical digressions, I will only say that a review of the BIAN model and accompanying documents of the standard are in my first article on BIAN, here I’ll try to tell how BIAN can be useful for business managers, business architects, corporate architects, solution architects, IT specialists and all other people interested in managing the entire architecture of a financial enterprise. And also about his key useful transformations, in my opinion.

What's new and interesting?

BIAN has become more affordable

One of the most important and cardinal changes that happened with the BIAN reference model , in my opinion, was its translation into the Archimate notation . It has become easier to read. The developers of BIAN, apparently, could not help but recognize the need to use standard notation to describe it in order to further disseminate it in professional circles . The perception model has become clearer to architects, as it is described in a language that is understandable to architects. Thus, the version of BIAN 8.0 is presented in the language of ArchiMate 3 . The model is in the public domain . By registering at www.opengroup.org , everyone can independentlyDownload a description of the BIAN model and all its components in Archimate notation.

BIAN implementation in API

Another important point worth mentioning is that the Independent Nonprofit Association of Standards ( Banking Industry Architecture Network (BIAN) ) maintains and updates the API repository for its landscape business domains.
BIAN developers are committed to creating an affordable repository of high-quality APIs and microservices to help banks quickly and cost-effectively upgrade.
The source files for the API from the repository are also published and available for download after registration on the portal (if someone has difficulty registering, try registering in the incognito mode of your browser).

Next, we will examine in more detail the BIAN metamodel in Archimate notation and its implementation as an API.

BIAN metamodel in Archimate notation

In this part, I propose to consider the current structure of the BIAN landscape in Archimate notation based on a document from OpenGroup . This document offers options for flexible, lean, and stable development of banking architecture using the ArchiMate and BIAN languages.

So, let's start with the description of the BIAN metamodel .

Landscape Elements BIAN

Figure 1. Overlay of the BIAN Service Landscape on the metamodel

The BIAN Service Landscape landscape is hierarchically formed from the following key basic components:

Business Area - Green
Business Domain (Business Area) - Orange;
Service Domain - Blue.

The Business Area in terms of Archimate is expressed by the Grouping element . The Business Domain and Service Domain are reflected in the diagram by the Capability element .
According to the rules of notation, Capability is used to represent at a high level the current and desired capabilities of the organization in relation to its strategy.

The Business Area (Business Area) is positioned at the highest level of the hierarchy of the BIAN landscape and is used to highlight and group in blocks of key areas of development in financial institutions.
BIAN identified the following business areas within the BIAN reference model:

reference data;
sales and service;
operations and execution;
risks and compliance (+ analytics);
business support.

Business areas (Business Domains) architects of banking enterprises define as the decomposition of the banking business into a set of mutually exclusive, in their totality completely exhausting the business opportunities of the enterprise. Business areas determine the bank segments considered by architects of the banking business from a functional, architectural and technical point of view.

A Service Domain is an elementary or atomic functional building block within the BIAN landscape.
Each service domain offers a set of services (Service Group). This set includes Service Operations. A service domain is a set of service operations that together manage the entire life cycle of an asset (Asset Type).

2. BIAN

Functional Pattern, Asset Type Action Term

The main technique used to “isolate” the BIAN service domain (that is, to distinguish it as an atomic, indivisible unit of the landscape) is to apply a Functional Pattern to a resource (Asset Type).
If we look at the definition of Archimate elements, we will see that Business Interaction is used for Functional Pattern , and a business object is used for Asset Type .

Asset Type - any tangible or intangible thing on which the bank has the right of ownership and / or influence, and has one or more integral uses or purposes that create commercial value.
Functional pattern- a behavior or mechanism that can be applied to any resource in carrying out commercial activities (for example, design, direct, manage, register, etc.)

Figure 3. Dedicated functional templates

BIAN also defined a standard set of actions ( Action Term ) characterizing various types of service operations. Each service operation performs exactly one action.
A complete list of Action Term (represented as ArchiMate business functions) is given below.

Figure 4. Standard set of actions ( Action Term )

A set of actions (Action Term), which together form a repeating type of behavior, is called a functional template.
The BIAN standard provides a very convenient and intuitive matrix of communication between functional patterns and standard operations:

Figure 5. Communication of functional patterns and standard operations

That is what is the main idea? We can design and implement almost any bank activity through a given, limited set of operations!
Each service domain at the same time contains only one main functional template with one type of resource. And we get a resource to which we can apply this or that template. Moreover, the number of templates is also certainly not very large in comparison with the number of business domains on the landscape!
Further, we see from the BIAN metamodel that a functional template that aggregates a certain set of standard operations and implements the service operations (in purple is indicated in the figure below), included in the service group that also implements the service domain functionality:

Figure 6. Relationship of functional patterns and service operations
And, as we already explained above, a set of service operations jointly control the entire life cycle of a certain resource ( Asset Type ).
In total, we get the connection: Service Domain - service domain (the functionality that we need for business) -> Asset Type - the specified resource of the service domain (with which we will work to implement our task, for example, mortgage loan) -> Functional Pattern - functional template (behavior characterizing actions with our resource). "

Generic Artifact and Control Record

Now consider another group of metamodel elements, indicated in the figure below by highlighting.

Figure 7. General artifact and control record The
functional template is a rather high level of abstraction (it is also clear from the metamodel that it is implemented by more specific service operations, but I will talk about this later when we consider the connection using a specific example).
And so the artifact that it directly affects is also abstract. It is called a generic artifact ( Generic Artifact ). For each functional template BIAN identified a common artifact, as shown below:

Figure 8. A set of common artifacts

Control Entry ( Control Record) is the information necessary to solve the internal problems of the service domain. This is a kind of log of information about the life cycle of a resource that is accessed by a functional template in accordance with an instance of a common artifact or as a result of which it is created.
If, for example, the resource is “current account”, the functional template is “ fulfillment ”, and the associated common artifact is “ Obligation ”, then the specific Audit record is “Obligation to fulfill (tasks for) the current account.”
The name of the audit record is a combination of the name the resource and the name of the common artifact. The service domain "current account" will provide services related to the "organization of the execution of the current account."
A control record can be considered as information about the life cycle of a “qualified resource”, where the qualifier is a common artifact.

Figure 9. Example domain " current account "

Service operations

“Service operation” is a specific action performed on a given resource. This is an elementary service.
In the service account “ current account ” example , the service domain is able to execute “intiateCurrentAccountFulfillment”, “executeCurrentAccountFulfillment”, etc., which are the action terms aggregated in the functional template and applied to the control record.
Those. if we superimpose service groups on a matrix with operations, it will be clear what actions we need to perform with our resource:

Figure 10. Example of superimposing Action Term on a Service Group
Service operations for executing a “current account” are derived from the conditions of the functional template. Service operations are organized into service groups.

Message and Condition

Service operations are only possible through clearly defined interfaces. Each service operation requires an event to be able to “deliver” the service. This event will be a type of message called an Incoming Message. A service operation will be implemented through some internal processing, possibly delegating some tasks to other service operations. As a result, the service will issue a response as an outgoing message. A message that is an input message for one maintenance operation may be an output message for another maintenance operation.

Figure 11. Incoming / outgoing messages and service execution conditions

The service domain also describes existing dependencies on other domains.
In particular, an example of a list of service domains from which we expect to receive an incoming message:

Figure 12. An example of communication with other domains for the “Current Account”

Total, we examined all the elements of the BIAN metamodel. And it's time to move on to the implementation of the BIAN model on the API. But before doing this, I want to draw attention to the fact that the model contains much more representations of its description. There are both object description, sequence diagrams, wireframes and others.
I invite readers to familiarize themselves with them by reference .
And also with a comparison of the Togaf model and framework .

Implementing the BIAN Model via API

As mentioned above, the BIAN developer community develops and regularly replenishes the repository of REST services that comply with the principles of the BIAN standard.
For acquaintance, it is necessary to register on the portal , go to the repository and either download the source files, or go to the console for familiarization.

Figure 13. Example of navigating through repository API BIAN

In console mode may read the documentation in Swagger:

Figure 14. Example of Navigation API BIAN repository for service domain Current Account
either to work with code:

Figure 15. Access to the original API file storage BIAN

For simplification understanding how to use the APIs, you can read the document. I invite readers and developers to already master this part of working with BIAN independently, or to participate in a webinar, which will be held in the near future, where there will be an opportunity to get first-hand information and ask questions at the end of the webinar .
The main content will be presented at the webinar and the changes, improvements and extensions introduced to the BIAN standard in the latest edition will be highlighted.

Possible approach to the application of the standard

I will describe the top-level approach of using the BIAN reference model:
The main thing that you should pay attention to is that the model suggests not using a process approach, but a microservice one.

Those. the landscape is a certain set of high-level bricks (service domains),
each domain has its own set of tools (service operations)
to work with certain artifacts (resources).

And we are already assembling the process we need from these bricks. But we are also helped in this by the already designed set of sequence diagrams, wireframes, object model.
Those. through these representations for many communication processes have already been designed.

It is possible for the company to:
1. study the landscape in detail, highlight on it visually (in color, frames or in another way) those domains that it needs for its functional purpose (it is possible to superimpose and understand the system level in which systems the data is duplicated, For example, this is one of the difficult questions, in my opinion, that arises when designing a microservice architecture, and the BIAN model suggests thinking about this at a business level).
2. Study the BIAN metamodel to understand how each domain works (I hope this will help my review, which I did above on the metamodel).
3. Download the necessary APIs from the portal (or first make sure that the required set is already present).
4. Explore other representations of the BIAN model.
4. Draw a migration map taking into account the current architecture in the company for its transition to microservice.

System architect,
© Irina Blazhina

Reference model BIAN. What new and useful for the corporate architecture of the bank does it offer?