In a previous article, we talked about using web semantic technologies such as OWL and SBVR to create conceptual models of a business. In this article, we explore an example of using a Business Information Architecture to solve a business/IT problem. The architecture exercise helped clarify thinking about the possible solution forms and served as a model for the corresponding IT application and data changes.
The Problem Case and Solution
A bank had decided that it needed to have more sophisticated financial product offerings and to be able to get them to market more quickly. The business analysts in the product development organization had studied the problem for some time, and concluded that they needed a product development and management system. Some process flows had been developed, but they were struggling a bit with the concept of complex products, and the bank was getting anxious.
The approach we took was to help them build a conceptual model of complex products. This model would allow new products to be defined by combining existing products and specifying the business rules that would describe the features and functions of the combination, overriding the features and functions of the base products where necessary.
Using the conceptual model, the team was able to construct some experimental product combinations. Because the conceptual model could be analyzed, it was discovered that some of the combinations contained contrary specifications that would make it infeasible to issue a product to a customer or that would not produce a profit for the bank. These types of problems would usually have been discovered later in the product development process when the profit and risk analysis was performed or when the market segmentation for the product was analyzed.
An interesting product that appeared to have a large impact on the applications and data was the “offset loan”. These loans are popular in countries that do not allow tax credits for certain loans such as personal property mortgages and which do tax interest and capital gains on investments. The loan combines a set of deposit accounts with a loan account such that the loan balance is reduced by a fraction (possibly 100%) of the sum of the deposit balances when calculating the interest payment on the loan. No interest is paid on the deposits, but the investor saves the difference between the loan interest rate and the deposit interest rate for the offset amount of the deposits, and there is no taxable income from the deposits. This product attracts deposits from customers who are considering or already have a loan, increasing the volume of business at the bank.
In a typical bank, deposits are considered to be one line of business and loans are another, so such a product must be jointly managed. This separation also extends to the IT applications; the applications and data for balancing and posting deposit interest are separate from the applications for balancing and posting loan interest. Merging the deposit and loan applications and data to implement this product was seen as having a very large cost and substantial risk. The team created a Business Information Model for this product and explored various process and data models for interest posting. The models showed that a solution could be obtained by creating an activity that runs after the loan and deposit accounts are posted and balanced in the normal way. This activity works with an offset account that it linked to the loan and deposit accounts. The current balances for the loan and deposit accounts are inputs. The activity figures out the interest credit on the loan and posts an interest credit, lowering the interest due. Statements are created after this processing is complete. The actual solution was a bit more complex, of course. A subsequent impact analysis showed that this approach required the least amount of change to the existing applications and data. The solution was implemented and functioned correctly. See Figure 1 for an example diagram that combines the process and information concept views. For familiarity, BPMN notation is used, but this is not a BPMN model.
How the Business Information Architecture helped
It is often the case that an architecture approach will focus either on the process or on the data. Solving this problem required treating the process and data together in the same model. Having a BPMN model or an Object Role model would not have helped. The Business Information Model included both process and information elements. It used an ingenious information lifecycle representation borrowed from work on intelligent robotics to demonstrate that the solution form would work.
The Business Information Model was unambiguous in its meaning, unlike a natural language requirements document. It could be subjected to a logical analysis to see if different parts of the model were in conflict with each other. Additionally, the model provided a basis for the business discussion about internal revenue and profit allocation between the respective lines of business. The Business Information Model was not quantitative, but spreadsheets and other quantitative analysis tools could be created from the information in the model and the potential for misunderstanding that resulted in an erroneous quantitative model was reduced.
The model was used to create graphics to present to the bank’s executives so that they would understand how the new product development facility would work.
Summary
A Business Information Architecture model was used to resolve a business and IT problem. The model was clear and unambiguous about the solution design and could be used in the definition of requirements and design for the IT organization. A Business Information Model does not replace a process model or a conceptual data model; instead, it provides an IT neutral description of a possible business design and allows some automated analysis of that design. Process models are still needed for resource requirement, service time and bottleneck analyses. Object Role models are still needed to drive data schema design. We see the Business Information Model as a foundation that provides a common set of concepts through which the process and data models can be integrated.
