BIAN Service Landscape, Version 7.0
The metamodel of the BIAN Reference Model modeled in the ArchiMate language is visualized in Figure 3-1 and will be explained further later in this document.
The BIAN Reference Model is referred to as the “BIAN Service Landscape”.
The BIAN Service Landscape is a reference framework, defining larger business areas and slightly finer-grained business domains into which the full collection of identified service domains can be organized. The key point is that it is intended to be a reference framework for organizing the service domains – it is not intended to represent a design blueprint for any particular type of bank. Such blueprints and the techniques for assembling them are covered elsewhere.
A diagram of the BIAN Service Landscape is shown in Figure 3-2.[1]
Business Areas
A business area is formed by a broad set of capabilities and responsibilities and is positioned at the highest level of the BIAN Service Landscape hierarchy. BIAN business areas are used to decompose the functions of financial institutions. This decomposition is primarily driven by business understanding and complemented by business, application, and information-specific needs.
BIAN has identified (amongst others) the following business areas as part of the BIAN Reference Model of business areas and business domains:
-
Reference data
-
Sales and service
-
Operations and execution
-
Analytics
-
Business support
A business area is a collection or a grouping of business domains. It is too coarse-grained to treat it as a capability. It is a concept for navigating through the BIAN Reference Model. In the ArchiMate modeling notation this corresponds to the “grouping” concept; see Figure 3-3.
Business Domains
A business domain is a coarse-grained, non-atomic business capability. It is defined by banking Enterprise Architects to decompose the banking business into a set of mutually-exclusive, collectively exhaustive business capabilities representing the capacity to execute business functions. Business domains are linked to certain skills and knowledge, which are clearly identifiable in the banking business.
Figure 3-4 shows the business area “Operations & Execution” subdivided into a number of business domains. A business domain can be subdivided into more specific business domains. The example only shows a few business domains within the business area. It shows that the business area “Operations & Execution” is subdivided in to the business domain “Product-specific Fulfillment”, which in turn is subdivided into three more business domains; “Loans & Deposits”, “Investment Management”, and “Trade Banking”.
A business domain is a coarse-grained functional capability that is of practical use for developing the strategic banking architecture. The business domains define the segments of a bank as seen by banking business architects from a purely functional and architecturally technical perspective.
A business domain corresponds to the ArchiMate capability, as shown in Figure 3-5.
Business domains are part of the BIAN Service Landscape, which is originally represented as illustrated in Figure 3-2.
-
A business domain belongs to exactly one BIAN business area
-
A business domain can be decomposed into two or more detailed, non-atomic business domains, as illustrated in Figure 3-4
The ArchiMate representation of the business domain is illustrated in Figure 3-6.
These coarse-grained “business capabilities” are composed of “atomic” or “elemental” service domains.
Service Domains
A service domain is an elemental or atomic functional building block within the BIAN Reference Model. A service domain is a capability or capacity to manage the full lifecycle of an asset. It can be seen as a service center with the role to manage the full lifecycle of assets of a certain type.
A service domain is elemental or atomic in scope. This means that the capability is not further decomposed into more detailed capabilities.
Service domains are mutually-exclusive and collectively exhaustive. There is no functional redundancy between the service domains.
A service domain is the most fine-grained capability within the BIAN Service Landscape. A service domain offers its services to other service domains. This allows service domains to fulfill their services by delegating the execution of some functionality to other service domains. The interaction between the service domains realizes the business activities that make a bank a bank.
A service domain corresponds to the ArchiMate capability, as shown in Figure 3-7.
A service domain is a component of exactly one business domain. Figure 3-8 illustrates the composition of the business domain “Loans and Deposits”.
Each service domain offers a set of services. These services are called service operations. A service domain is a set of service operations that together manage the full lifecycle of an asset.
A BIAN service domain combines an asset and a use. The technique used to isolate a BIAN service domain is to apply a functional pattern on an asset-type. A functional pattern is a set of predefined and standardized action terms that will operate on the asset type.
BIAN has defined functional patterns, action terms, and a hierarchical classification of the assets (tangible and intangible) that may make up any bank.
Each service domain combines a single primary functional pattern (for example, maintain reference details, or define and execute a plan) with an asset or entity type (for example, a piece of equipment, or a customer relationship).
These building blocks of the service domain are represented in Figure 3-9 and will be explained in more detail in the following sections.
Action Terms
BIAN has identified a standard set of actions that characterize the different types of service operations. Each service operation executes exactly one action. There are currently 16 standard detailed actions terms.
The full list of action terms (represented as ArchiMate business functions) is shown in Figure 3-10.
An action term is represented by an ArchiMate business function.
Functional Pattern
A collection of action terms that together form a recurring type of behavior is called a functional pattern. BIAN, Version 7.0 identifies 18 functional patterns, as shown in Figure 3-11.
The set of action terms that make up the functional pattern are visualized in the functional pattern matrix, as shown in Figure 3-12.
A functional pattern corresponds to the ArchiMate business interaction.
Generic Artifact
Every functional pattern is acting upon something. Because a functional pattern is at a very abstract level, the artifact it acts upon is also abstract. This is called the generic artifact. For each functional pattern BIAN has defined one generic artifact, as illustrated in Figure 3-13.
A generic artifact corresponds to the ArchiMate business object.
A control record represents the information required for a service domain to deliver its services. It is the log of information about the lifecycle of an asset type when accessed by a functional pattern according to, or resulting in, an instance of a generic artifact.
If, for example, the asset type is “Current Account”, the functional pattern is “Fulfill”, and the coupled generic artifact is “Fulfillment Arrangement”, then the specific control record is “Current Account Fulfillment Arrangement”.
The name of the control record is the concatenation of the name of the asset type and the name of the generic artifact. The service domain “Current Account” will deliver services related to the “Current Account Fulfillment Arrangement”.
A control record can be seen as the information of the lifecycle of a “qualified asset type” where the qualifier is the generic artifact. It is represented using the business object component in the ArchiMate language.
Service Operations
A service operation is the externalization of an action upon a qualified asset type. It is an elementary service.
In the example of the service domain “Current Account”, the service domain is capable of performing “intiateCurrentAccountFulfillment”, “executeCurrentAccountFulfillment”, etc. which are the action terms aggregated in the functional pattern and applied to the control record.
The “Current Account” fulfillment services, or service operations, are derived from the functional pattern action terms. Services are organized into service groups. The service groups are standardized as:
-
Setup
-
Origination
-
Invocation
-
Reporting activities
In the example of the service domain “Current Account”:
-
Setup of the service domain “Current Account”:
-
Record
-
-
Origination of the “Current Account” fulfillment:
-
Initiate
-
-
Invocation of the “Current Account” fulfillment:
-
Execute
-
Request
-
Terminate
-
Update
-
-
Reporting of the “Current Account” fulfillment:
-
Notify
-
Retrieve
-
Service operations are represented as ArchiMate business services.
An overview of the service domain can be represented as shown in Figure 3-14.
Input/Output Message
Service operations within a service domain can be accessed through clearly-defined interfaces. Every service operation needs a minimum input to be able to deliver the service. This input is a message type which is called the input message. The service will be realized by some internal processing, possibly delegating some tasks to other services. As a result, the service will deliver a result that is expressed in an output message. The concept of the message is visualized in the metamodel diagram shown in Figure 3-15. When applying this metamodel to create a model, the business object “Message” will be made specific by named messages such as “Invoice” or “Payment Request”. A message which is an input message for one service operation can be the output message from another service operation.
Messages are represented as ArchiMate business objects.
Pre/Post-Condition
Before a service starts the processing of fulfillment, it will evaluate if the conditions are fulfilled in order to accept and start the service. These conditions that are controlling the status at the beginning of the process are called the pre-conditions. This is not the only check that is performed. The service will also check if the status of the involved objects at the end of the process is acceptable. These conditions are called the post-conditions. These conditions are illustrated in Figure 3-15.
Pre/post-conditions are represented by ArchiMate requirements.
