BIAN Business Object Model Framework
BIAN Business Object Model
In today’s competitive marketplace, executive leaders are racing to convert data-driven insights into meaningful results (IBM Institute for Business Value; see Referenced Documents). A Data Architecture Management capability[1] is now the key differentiator in creating value for businesses. A qualitative Enterprise Information Architecture (EIA) is a prerequisite for qualitative Data Architecture Management.
Recently, BIAN is applying the Business Object Modeling (BOMing) approach in the banking domain to develop a Business Object Model (BOM) for the financial industry (BIAN BOM).
The existing banking data models and standards such as ISO 20022, IFX, and SWIFT™ are focused on defining the messages exchanged between Application Program Interfaces (APIs). These messages are views on the core business objects in banking (such as bank products and services, bank agreements and arrangements). The existing standards do not focus on structuring and defining these information building blocks in any structural or understandable way for business people. BOMing creates a precise conceptual basis for BIAN to fill this gap in understanding business semantics (business concepts). It supports the creation of a BOM as part of the Information Architecture. The BIAN BOM provides the financial sector with a reference model for Information Architecture that can be customized to individual needs.
The BOMing approach is being applied to model the information needs of every BIAN service domain. The resulting service domain models are integrated into the BIAN BOM, a reference model for the EIA of the financial industry.
The ownership[2] of each business object is attributed to one service domain.
The BIAN business objects will be detailed into fully attributed information entities, accompanied by unambiguous definitions. As such, the control records of the BIAN service domains, containing the information required for the service domain, and the input/output messages of the service operations, will be defined as views on the BIAN BOM, as represented in Figure 5-1.
The BIAN BOM business objects are expressed as ArchiMate business objects.
Business Object Modeling: The Approach
BOMing is a way of thinking, complemented by two abstract reference models that are used as patterns for the actual BOM of an enterprise or domain.
In the following sections, we will explain the way of thinking and the content and structure patterns that constitute the BOMing approach.
Business Object versus Business Concept
Two key notions in the BOMing way of thinking are “business concept” and “business object”. Being able to make the distinction is key.
A concept is whatever can be thought of. A business concept is a concept that is of importance to the business; i.e., something business wants to be informed about.
In order to fulfill the information requirements of the business, business concepts need to be identified. Each business concept should be defined unambiguously by means of a business definition, in order to avoid misunderstandings between involved parties. Each business concept will be referred to by one or more names.[3] The name of a business concept is often called the business term. The business term is a representation of a business concept by means of a word or ordered set of words.
The business glossary contains the business concepts, ordered by business term and definition.
In order to inform businesses concerning the concepts in which they are interested, data needs to be captured and managed. Business concepts, however, are not the building blocks for the Information Architecture required to steer an effective Data Architecture.
The building block of the business Information Architecture is the business object. It is a mutually-exclusive, collectively exhaustive unit of information. Business objects relate to each other, and thus constitute the BOM.
A business object is also business concept, or an abstraction thereof;[4] hence, it also needs to be named by a business term and unambiguously defined in business words. It is also part of the business glossary.
The BOMing approach presented here is used to produce unambiguous definitions for business concepts; a prerequisite for distinguishing business objects from business concepts that are “views”.
For example, “customer” is clearly a business concept. Any organization will be interested in the parties it serves. However, it is not a business object. A “customer” is a “party” (business object) that buys “products”. The same party can have a “supplier” and “co-worker” role.
Content Pattern
The BOM content pattern, represented in Figure 5-2, is an abstract information model, valid for any business.
It is made more specific for a specific business context or domain.
Only the core business objects that are most important for a financial institution are described here:
-
Businesses distinguish themselves from others by the products (type of goods and services or a coherent package thereof) they offer to internal or external customers; a service is a valuable functionality that fulfills a need or a requirement
-
The sale of a product or provision of a service is concluded by an agreement with the customer – agreements with suppliers and authorities enable the business to offer its products to the market
An agreement is a formal or informal common understanding between two or more parties, concerning one or more subject matters expressed in a set of arrangements, terms, and conditions.
-
An agreement is composed of a number of arrangements, where one party engages him/herself against another party to give, to do, or not to do something (the subject of the arrangement)
An arrangement always consists of:
-
A “subject matter” which can be every “thing”
-
An “act” to do, not to do, to give or not to give some ”thing” (the subject matter)
-
Parties: it is a “party” who makes the promises to do, not to do, to give or not to give something for/to a “counter party”
-
-
A party is an individual or an organization
Parties are of interest to a business because of their (potential) involvement in agreements.
-
A (party) role is the responsibility or involvement of a party in a specific business context
Together, they form a balance to which these parties commit to achieve. Agreements and arrangements are the core notions of a “commitment system”. This system manages the promises that a business makes toward its stakeholders and ensures promises can be fulfilled. A commitment system does not in itself fulfill any promises or commitments. It makes certain that it is possible to do so. “Commitments” or “promises” are the source of income for a business according to Knaepen and Brooms, 2013 (see Referenced Documents).
-
The fulfillment of one or more arrangements of an agreement can be triggered by giving an instruction to do or to give something – an instruction is a request to do something; the commitment made in an arrangement
The instruction will be accepted for execution only if the conditions, as agreed, are met.
-
Instructions trigger transactions needed to fulfill the arrangements
Instruction and transaction are the core notions of a “Fulfillment Management System”, where the commitments made are actually fulfilled.
A transaction is the act to do “something”. It can either be the conclusion of an agreement (establishing arrangements), or the execution of the commitments specified in an arrangement.
-
When a transaction affects the position on an account, an account entry must be made on the appropriate account
-
An account is a measuring state on which movements in value or amounts of assets, rights, and obligations are registered
A financial account is a specialization of “account”: an administrative financial state where the amounts of financial transactions are registered in debit or credit, resulting in a balance.
-
An account entry is the record of a movement in value or amounts of assets, rights, and obligations
A financial account entry (or booking) is the record of a financial transaction on a financial account. It results in an increase or decrease of a balance.
-
Structure Pattern
The BOM structure pattern (represented in Figure 5-3) enriches the content pattern.
A business object can be subject to classifications, resulting in a “business object type” business object, that contains the classification classes (e.g., a party can be of “gender type” male, female, or X).
A business object will most probably have relationships with other business objects, resulting in a “business object relationship” object (e.g., a party will have involvements in agreements). This relationship object can in turn be classified by a “business object relationship type” object (e.g., involvement types “buyer”, “seller”, “sales person”, etc.).
A business object is described by “business object descriptors”, of a “business object descriptor type” – which will not appear in the BOM diagram, but rather as attributes of the information entities, detailing the BOM.
The BOM content pattern, enriched by the BOM structure pattern, provides a powerful support for BOMing. Firstly, because it provides a powerful support for an unambiguous definition of a business concept, and secondly, because it provides a completeness check for each model.
Thus, both the quality and speed of the Information Architecture work will be improved.
A modeler systematically asks the following questions:
-
What is the business concept?
Is it a (specialization of) a content pattern object (a party, agreement, or arrangement)? Or is it a classification thereof? Or maybe a relationship between objects or classifications thereof? Or a descriptor?
Thus, the structure pattern supports the derivation of the BOM from the multitude of business concepts relevant for the business domain.
-
What (specializations of) content pattern business objects are relevant for the business context?
How are the content pattern relationships specialized here? What other relationships exist between the relevant business objects? What classifications are relevant?
Thus, the content pattern, extended by the structure pattern, supports the completeness of the BOM.
-
What are the descriptors (e.g., identifiers, lifecycle status, other attributes)?
Do we have descriptors of all relevant types?
Thus, the structure pattern supports the completeness of the detailed information model.
Classification Mechanism
Classification is a mechanism to order or group business concepts according to specified criteria. Business concepts can be classified according to multiple viewpoints, because different stakeholders look at business concepts differently. These viewpoints may depend on function or profession (for example, finance has a different view on a customer than marketing) or level in the organization (the board of directors will classify company activities differently from a shop worker).
From an Information Architecture perspective, it is important to distinguish two types of classifications:
-
A taxonomical classification is a mechanism to classify concepts from the perspective of the nature of the concept
A concept can only be classified to one and only one class of the taxonomical classification. The characteristics that are used in the rules categorizing the instances of the concepts into a taxonomical class are inherently describing the business object. For example, individuals can be classified according to their gender as a “male” or “female”. Each instance can only be classified as “male” or “female”. Taxonomical classifications will require a “type” object, but can also lead to specializing business objects, as they are based on specific characteristics.
-
A functional classification is a mechanism to classify concepts from the perspective of functional interest
Most classifications are from a functional perspective. For example, an individual can be classified according to their role in an agreement; e.g., buyer or seller. A “buyer”, as a party, does not have specific characteristics distinguishing them from a “seller”. Hence, a functional classification will result in a “type” object, but not in a specialization.
Example Payments
In a credit transfer, several service domains are involved. We will simplify matters by looking solely at the current account of the payment originator (i.e., the party that has the role “payment originator” in the payment order).
The service domain “Current Account” is the owner of the “Current Account Agreement” information,[5] which bundles arrangements regarding, for example, the promise of the bank to transfer funds when asked to do so (i.e., the “Credit Transfer Service Arrangement”) and the related promise of the customer to pay for that transfer according to the “Pricing Arrangement”. This service domain makes credit transfers possible (or impossible, if the “Current Account Agreement” is blocked).
The “Payment Order” service domain checks the acceptability of an instruction to transfer funds; i.e., it checks the conditions for the fulfillment of the promises made in the agreement.
The “Payment Execution” service domain takes care of the transactions required to execute the “Payment Order”.
One of the account entries required to adequately register these transactions is the “Current Account Booking” on the “Current Account”.[6]
