Accountability

Party

The party pattern captures the notion of the entity that we encounter in our day-to-day lives: a person or an organization. It gives us an abstraction common to both a person and an organization. A party usually has an address, an email address and a telephone number. This 'party' entity can be a person or an organization. We can see that in our day-to-day life, we are dealing with not only individuals, but also organizations as a whole. For instance, if a person gets treatment from a hospital, that person is having a relationship with the hospital, not with any particular person of the hospital. Actually, in many data models, this concept has various names, like 'player', 'legal entity',etc.

Example: Consider a person John Smith and a bank XYZ Bank, in which he has an account. The person John Smith, the personal banking division of XYZ Bank, the XYZ Bank by itself are all examples of parties.
Example: A company (e.g.IBM) having an account in XYZ Bank. Here, as far as the bank is concerned, the company is a 'party' though it is an organization in particular.

Organization Hierarchies

Generally, we have the situation that a company is divided into hierarchies of responsibility. For example, consider a company that is divided into regions and each region consists of divisions and so on. The organization might have several such hierarchies. Such a concept could be modeled as shown below:

First, let us understand the model, then review its merits. The main class here is 'Organization Structure Type'. This captures the hierarchic relationships between organizations. A specific hierarchy would be an instance of this type. Thus, we have 'typed' the relationship. The hierarchy example illustrated above would be an instance called 'sales organization'.
Note that the model elements that are specific to an organization are the subclasses of the class 'Organization'. Everything else remains the same.Also, note that there is a 'Time Period'. This is used to record the changes in the organization structure over time. The main advantage of this model, is that it facilitates 'reorganization' of hierarchies very easily. We just have to change the rules. This stems from the fact that we have attached the 'Rules' to the 'Organization Structure Type'. Hence, if an organization feels that it has to change the hierarchic relationships between the constituent organizational units, it just needs to change the rules. This is actually the most-encountered situation in companies. Companies reorganize more often than add new organizational units in the hierarchy. Maybe the names might change, but that just means having a name attribute and changing it.
From this, we get a modeling principle: Design a model so that the most frequent modifications of the model cause changes to the least number of types.

Examples:

The service team for the product X of ABC Inc., reports to the sales office at Chicago. This would be modeled as an organization structure whose parent is the Chicago sales office, subsidiary is the service team and organization structure type is line management.
The same service team reports to the HR office of ABC Inc. This would be modeled as another organization structure whose parent is the HR office, subsidiary is the service team and organization structure type is HR management.

Example of a Rule:
Rules, in this model, are with repect to a particular Organization Structure Type. So, each instance is associated with its own set of rules. Consider the Organization Structure Type 'sales organization'.
Rules for this type could be " If subsidiary is a division, then the parent must be a region", "If subsidiary is a sales office, then the parent must be a division", and so on.

Accountability

In the Organization pattern that we saw above, the main aspect is that of an organization having a relationship with another (e.g. one is the parent of another) for a time period according to a defined rule. Now, we can ask ourselves, "Can there be similar relationships among people or among people and organizations?". This is always worth considering. For example, a stock broker who maintains the stock accounts of his customer is responsible to him. This gives rise to the pattern, Accountability:

The model uses Party now in place of Organization. This allows us to cover a wide variety of interparty responsibilities, like management, employment, contracts, and so on. This is evident from the following examples:
Example: John works for Bankers Trust. This can be modeled by an accountability whose commissioner is Bankers Trust, responsible party is John, and accountability type is employment.
Example: John is also the manager of Personal Accounts Department. This can be modeled as an accountability whose type is manager, with John responsible to the Personal Accounts Department.
Example: Bankers Trust has a contract with Joe & Company to do accounting services. This is an accountability whose type is the accounting services, the responsible party is Bankers Trust, and the commissioner is Joe & Company.

The advantage of this pattern is that whenever one of the parties change, we just have to change some attributes of 'Party' class. For example, consider the second example above. John is the manager of a particular department. If he quits, and someone assumes the job, we just change the 'Party' attributes, like name,etc. Another advantage is that we are recording the duration of the accountability. So, we know who was responsible for what during a specific time duration.

Banking Patterns Home Page If you have comments or suggestions, email us!