Capability 1.0. Basic Banking Model

Capability 1. 0

The capability being sought from the current version of banking model is very basic. It is only the capability to connect the need of the borrower to borrow a certain amount of capital to the need of the provider to provide capital with an expectation of a return. 

Object Identity. Framework for deciding Identity scope

Let us now enrich each of these objects by describing them a little bit more.  The way to describe an object is to identify and list out its attributes.

Let us start from our first object – the Person object.

A Person has a unique identity. Therefore for any Person (Provider or borrower) we should be able to uniquely identify him/her.  The person will have to have a set of attributes for this purpose and these can be collectively called “Identification” attributes.  It is reasonable to assume that one would need to communicate with the person and hence the object should also reveal the details that would permit effective communication to occur.

The Person object’s identity will then look as follows

(1)         Person

a.    Unique Identification

b.    Communication identifiers

Intuitively we all know that the object Person will have more identity elements that describe him/her such as his relationship quality with the bank, the degree of trust that a bank can place in him and so on and so forth. Each of the identity element provides a capability to the system.  Therefore the best way to flesh out the identity of an object is to start with a basic system and then progressively demand more capability of the system. Then in response to that demand add identity and behavior elements that help provide the capability.  

Hence before proceeding any further, it is appropriate that we state the basic capability that is being sought from the object model being developed in this section. This capability requirement provides a scope to our object model. In other words this capability requirement provides a basis for developing the objects in the object model. 

Once the basic object model has been developed, we would then progressively demand higher capabilities of the system. For each such demand we would incrementally add to the object model to deliver that capability

For each capability we would also enunciate the roles that each object would be expected to perform in order that the system can deliver the capability expected of it. The role definition are an essential intermediate step to developing the object identity and behavior.

This would be the approach that we will use to design our core banking system.

Object Model: The basic objects in our model

7 nouns (distinct objects) that are immediately visible are

(1)         Provider Person

(2)         Borrower Person

(3)         Provided Capital

(4)         Borrowed Capital

(5)         Provider Pool

(6)         Borrower Pool

(7)         Connection

In the above list compound nouns have been used for some of the objects.  The rules that we defined stipulate that in case in our model there are objects with compound nouns and if a part of the compound noun is common amongst two or more objects then a new object must be created.  Applying this rule, the new object model will have the following objects

(1)         Person

(2)         Provider Person

(3)         Borrower Person

(4)         Capital

(5)         Provided Capital

(6)         Borrowed Capital

(7)         Pool

(8)         Provider Pool

(9)         Borrower Pool

(10)     Connection

Resilient Object Model. Rules for Identifying Objects

The question then is how does one identify objects such that each object has a unique capability. The trick to identifying such objects is to look at the vocabulary of the conceptual model and look for Nouns. Each noun connotes a distinct capability.

When the vocabulary of conceptual model uses compound nouns then the above rule for identifying objects needs to be modified a little bit.  A compound noun is usually of the form Adjective + Noun (example Pink ball) or Noun + noun (Tennis + Shoe). 

Let’s illustrate as to what is to be done, in these cases, through the example of two objects - Tennis shoes and Football shoes. Both of these objects share a noun – shoes. A commonality of nouns would imply that the two objects share some common capability. Our rule for objects is that there should not be any overlap of capabilities between different objects.  Hence there is a case to split the object 3 ways – Shoes, Tennis shoes and Football shoes. As explained in previous section the object Tennis shoes as well as Football shoes will inherit the common capability of shoes from the object Shoes.  In such an arrangement of objects if a change were to be made in the capability of shoes then it will need to be done in one place only, namely in the object called Shoes.

Resilient Object Model. Governing rule for Objects

Object model requires us to identify the key objects, their identities and their behavior.

In the design of a Resilient System, the governing rule for objects is that each object should deliver a capability that is distinct from other objects. If two objects – Say object A and object B - have common overlapping capabilities then a separate object, object C, should be created for the common overlapping capability.  Both object A and object B would acquire the capability of object C through inheritance. It is assumed that the reader understands the concept of inheritance.

This method of identifying objects creates an Object model that is resilient in the face of change. Such a system is resilient because with no duplication of capability across objects, any one particular change is localized to only one object and does not have to be repeated across objects. This containment of changes is what helps the system remain resilient and cope with the change

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.