Object Model. The Preferred representation for a Logical Model

There are many ways to represent a logical model.  The model preferred by me is the Object model. Other possible choices include Entity-Relationship diagram. 

Conceptual Model versus Logical Model

We have so far elaborated a part of the connection-pipe model.  The second attribute, the connection-type, still needs to be elaborated.  At this time, we could continue to elaborate the model or choose to move, whatever we have described so far, one step closer to a design format that can be more easily digitized.

I think it will provide a better understanding if instead of further elaboration of the conceptual model we move the discussion towards how to digitize the model developed so far.

Digitization means coding some logic.  The logic needs to be represented in some format before it could be coded.   Without the aid of an appropriate model for representing the logic it is quite likely that the code that will be developed may not be complete i.e. it may not cover all possible scenarios.  While we call the previous model (connection-pipe) a conceptual model we will call this class of model as “logical model”

A conceptual model helps us model the real life scenario so that we are able to go beyond the observable behavior and predict behavior that has as yet not occurred. 

A logical model on the other hand ensures that the conceptual model that we have developed is represented in a way that all the interactions conceived in the conceptual model are captured COMPLETELY.

The purpose of a conceptual model is to completely describe the real life BEHAVIOR.  The purpose of the logical model is to ensure that all the interactions possible in the conceptual model are completely described.  

Modelling a bank. Connection Paths

Having decided upon connection-pipe as the conceptual model, let’s start fleshing out the details of this model.  This section elaborates the connection-path attribute of our conceptual-model.

Connection path as the name suggests is the pathway that connects the borrowers and providers (lenders). There are a few possible pathways and I discuss these below.

(1)      Capital providers are directly connected to specific borrow request.  There are 4 subtypes possible

a.    One capital provider funds one borrower requests

b.    One capital provider funds many borrower requests

c.    Many capital providers together fund one borrower request

d.    Many capital providers together fund many borrower requests

This type of connection yields the Peer-to-Peer lending model of banking.

A pictorial depiction of these 4 cases is presented below

Type 1.d is the most generic one and if the system design implements type 1.d then all other are automatically implemented.  The job of the system design then reduces to implementing type 1.d

(2)         There is no direct connection between capital providers and borrowers.  The capital of all borrowers is pooled together and borrowers are distributed money from this pool.

This is the most common form of banking that is practiced.  However, this is the not only form as the subsequent pathways show.

A pictorial representation of this most common pathway is shown below

(3)         Providers and borrowers are connected through a common pool of funds that is distinguishable from all other pools. As in type 1 before there are 4 possible subtypes

a.    One capital provider pool one borrower pool

b.    One capital provider pool many borrower pools

c.    Many capital provider pools together fund one borrower pool

d.    Many capital provider pools together fund many borrower pools

A visual representation of these four pathways is given below.

Type 3 cases are the more generic versions of their corresponding type 1 cases.  In fact if the design of a system caters to type 3 cases then the corresponding type 1 cases are automatically implemented.

Type 3.d is the most generic one and if the system design implements type 3.d then all other type 3 (and type 1) are automatically implemented. 

Not only type 1 cases but also type 2 case is a specific implementation of a type 3 case where there is just one provider pool.  

The job of the system design then reduces to implementing type 3.d

(4)         In the 4^tht pathway the bank acts as intermediate processor to convert money given by producers to “businesses” that borrowers want to invest in. 

This is actually the Islamic banking model where bank is not allowed to lend money to borrowers (or rather not allowed to charge interest to them) but can assume joint risk or charge fees for services provided.

A visual representation of the pathway is given here

This is the most generic version of all the pathways discussed so far.  A design that implements this pathway will be resilient.  It provides for any form of business model that one can foresee into future.

It provides for Peer-to-Peer lending, Islamic banking as well as traditional Retail banking.  It goes beyond all of these and allows for models of banking where providers can choose what form of assets should their capital be deployed towards and allows them to earn returns commensurate to the risks that they are willing to take.

The conceptual model for a bank: The Connection-pipe model

The main objective of this blog is to design a resilient core banking system. 

In any design exercise, it is helpful to use a conceptual model.  A good conceptual model allows us to simulate/predict behaviors under conditions that have as yet not occurred. For example in Physics the model of gravity allows us to predict what would happen if a projectile were thrown with a particular velocity. 

The fact that a model is able to simulate/predict means that the information about the system is “codified” into the model. This property is extremely useful in System design.  The implication of this is that if we choose a proper model then the system that we build based on that model will be much more comprehensive then if we were to build a system based only on the observed behavior of the system.  This is because the set of observed behavior would always be less then universe of possible behaviors that a system may be exhibited to display in future.

From the discussion in the previous section, a connection-pipe seems to be a good conceptual model for banking.  Banking, or at least what we have discussed so far of it, is nothing more then an agency that connects Providers of capital to Borrowers of Capital. Therefore the connection-pipe model seems an appropriate model for banking

In the subsequent sections as we delve deeper into the nature of banking we will continue to test whether the connection pipe serves as an adequate model.  We will continue to improve upon the model.  If at some point of time we find that it no longer serves the purpose then we will abandon it in favor of a better model.

To design core banking then is to design the “connection pipe” that connects the lenders and the borrowers. 

There are two degrees of freedom available in the design of this connection pipe

(1)         The way the pipe connects between the borrowers and the lenders

(2)         The nature of connection between the participants and the pipe

We call the first the Connection-path and the second the Connection-types

The greater the flexibility a system provides in setting up Connection paths and Connection types the greater the resilience of the resulting system.