Accountability and Affiliation

Hierarchies occur in many domains. Often we use the Composite Design Pattern to model hierarchies:

Accountability and Affiliation

There are two types of organizational hierarchies: affiliation hierarchies and accountability hierarchies.

In affiliation hierarchies components are objects representing organization units such as companies, divisions, departments, offices, leagues, battalions, colleges, etc. The parent-part relationship is called affiliation: organization X is an affiliate of organization Y, or organization Y is the parent of organization X. For example: the National and American Football Conferences are affiliates of the National Football League. Each conference has three affiliates: Eastern, Central, and Western Conferences. The conferences have teams as their affiliates.

In accountability hierarchies components are objects representing roles within an organization such as president, VP or marketing, Director of Sales, etc. The parent-part relationship is called accountability: role X is accountable to role Y, or role Y supervises role X. For example, in a university the provost is accountable to the president. The deans of each college are accountable to the provost, and the chairs of each department within a college are accountable to the dean of the college. Professors are accountable to their chairs, and students are accountable to their professors.

Reusable Accountability and Affiliation Models

The particular roles and sub-units within an organization might vary or change making it necessary to change the model. This can require several iterations of the development cycle which could conceivably take months to complete.

An interesting alternative is to create an abstract model in which accountabilities and affiliations are represented as objects connecting roles and organizations, respectively. We can add type checking to the model by adding objects for representing types of organizations, roles, accountabilities, and affiliations.

For example, we could represent a statement such as Professor Smith is accountable to Dean Jones as an object diagram:

Notice that the class diagram is so general and abstract that it never needs to change. Re-organizations only involve changes to object diagrams.

Also notice that we can think of the Prof-Dean AccountabilityType object as a representation of a rule that states: Professors are accountable to Deans. Type checking can be done as follows:

class AccountabilityType {
   RoleType supervisorType;
   RoleType supervisedType;
   Accountability makeAccountability(Role supervisor, Role supervised) throws Exception {
      if (supervisor.getType() != supervisorType || supervised.getType() != supervisedType)
         throw new Exception("Inappropriate accountability");
      return new Accountability(supervisor, supervised, this);
   }
   // etc.
}