Organization Structures - Martin Fowler

1 1 Organization StructuresIt seems that remarkably early in our lives we become familiar with organizationalstructures. The classic management hierarchy appears on an org chart early in ourcareer, but even by then we ve already come across the notion in plenty of places. Soin a way it shouldn t be surprising that Organization Structures crop up frequentlyenough in business software too. I recognized many organizational patterns severalyears ago and ever since they keep turning up good way to start thinking about modeling Organization Structures is to think ofthe obvious way. Imagine a company where people work in departments, which areorganized into divisions. Figure shows an explicit model for this where each part ofthe structure is a separate Structures have two main disadvantages. They don t work well if there ismuch common behavior between the kinds of Organization . They also embed the cur-rent organizational categories into the design.

2 Should some bright spark decide to addregions between divisions and departments, you have some modificaitons to do. Figure explicit, and obvious,organizational 1 12 Faced with these problems, the obvious move is to create a supertype for the orga-nization, which leads you to Organization Hierarchy (7) in Figure The organizationhierarchy works best when you don t have much different behavior between the orga-nization sructures. It also allows you to stay very flexible if new kinds of organizationsappear. If you do have some varied behavior you can use subtypes to pull this down. Making a supertype for the Organization is a pretty obvious move, another com-mon, if less obvious, supertype is Party (5): a supertype between the Organization andperson, leading to Figure Often you find that there isn t much difference betweenthe hierarchic association between organizations and the association between personand Organization so you can pull these associations up to the supertype (Figure ).

3 Figure hierarchyFigure Party to an Organization hierarchyOrganizationparentchildren 1{hierarchy}Organizationparentchildren 1{hierarchy}PartyPerson3A hierarchy like this is a good choice for many organizations, it certainly capturesthe usual org charts pretty well. But as organizations get larger then you tend to see anumber of different kinds of links between your parties. This might be matrix styleorganizational Structures where people are organized by job function and geographiclocation at the same time. Obviously one way to do this is to create a second partyhierarchy, but this only goes so far. You don t want your party festooned with situation leads you to Accountability (17), where you make the interpartyreleationship an object in its own right, typed according to the kind of link you needto have (Figure ). Accountabilities represent the most powerful, and also the mostcomplex way of dealing with organizational strucutres.

4 So like most of these powertools, you don t get them out unless you really need them. But when you do account-abilties give you a very flexible way of handling all sorts of relationships. When you have accountabilties there are often rules that say what kinds of partiescan be connected together. You can use a Knowledge Level (32) to capture and enforcethese hierarchy on PartyPartyparentchildren 1{hierarchy}OrganizationPerson4 Figure Accountability for the Organization structuresOrganizationPersonPartyAccount abilityAccountabilityType 1 parent 1 child 1 Party Type 15 PartyAn abstraction of people and organizational unitsExample: A telephone utility s customers may be individuals or businesses. Many aspects ofdealing with customers are the same, in which case they are treated as parties. Where theydiffer they are treated through their a look through your address book, what do you see? If its anything like mine youwill see a lot of addresses, telephone numbers, the odd email all linked tosomething.

5 Often that something is a person, however the odd company shows up. Icall Oak Grove Taxi frequently, but there s no person I want to speak to I justwant to call a cab. If I were to model an address book, I might choose to have people and companies,each of which have postal addresses and telephone numbers, but the resulting dupli-cation is painful to the eye. So I need a supertype of person and company. This class isa classic case of an unnamed concept one that everybody knows and uses butnobody has a name for. I have seen it on countless data models on various names: per-son/org, player, legal The term I prefer is party, and I ve been glad to see that over the last few years it sturned into a fairly standard it workI usually define party as the supertype of person and Organization . This allows me tohave addresses and phone numbers for departments within companies, or even infor-mal any behaviror that is common to people and organizational units on Party, onlyput things particular to one or the other on the subtype.

6 When you put behavior onthe subtype, think about whether it makes sense on the supertype, often you may besurprised how well things fit on the supertypeWhen to use itThe obvious case to use Party (5) is when you have people and organizations inyour model and you see common behavior. However you should also consider thispattern when you don t need to distinguish between people and organizations. In thiscase it s useful just to define a party class and not to provide the you see parties playing different roles in a business, you ll often see one of the rolepatterns in play. Coad in particular is a big fan of Role Object (116). It s a common pat-tern with party, but isn t one to turn to blindly, but take a look at Role Object (116) formore discussion of that main point of this pattern is to look for it to see if you have common behavior,and if so to use the name Party for that supertype. The name has become quite widelyused these days, so choosing that name helps in HierarchyRepresents the hierarchy of organizational units within a businessMaking it workHierarchies are a common structure in organizations.

7 This is because they reflect anatural and common technique for human beings to deal with complexity. Modeling ahierarchy is thus a common thing to do, yet it is both easy and 1{hierarchy}Associated CoffeeMakers: Organizationsales : Organizationpurchasing :OrganizationBoston sales :OrganizationLondon sales :Organization8It s easy because you can show it with a recursive association, my old data modelteachers called it a pigs ear . However the recursive association does not tell thewhole story. In most cases there is one parent, but how about for the one at the top?Hierarchies also have rules, such as the fact that you can t have cycles (your grandpar-ent cannot be your grandchild). There is no standard notation for dealing with this inthe UML. I use a constraint {hierarchy} on the association to suggest what is goingon. Even the {heirarchy} constraint, however, is strictly imprecise. It doesn t tell youthe difference between a tree (one top) and a forest (multiple tops).

8 If this is impor-tant to you model you should say what it is, most of the time I find it isn t that the sketch I use the terms parent and children. Naming these association rolescan be tricky. Parent works well with most companies, but child isn t as good as sub-sidiaries. However I ve come to the view that children is the best name. The use ofparent and child is a very useful metaphor when discussing hierarchies, or indeed anyother kind of directed graph structure . I can use such phrases as sales in London is acousin of purchasing in Java and, although it sounds wacky, you can easily figure outwhat I mean. The metaphor gives us a useful vocabulary which is worth the fact that itoften sounds a little to use itYou need to use this pattern when you have a hierarchic corporate structure thataffects the software you are using. hierarchic: because the pattern handles a hierarchy not anything more your needs are more complicated you can tweak the pattern (there are somesuggestions below) or use Accountability (17) instead.

9 Affects the software: because you only need to capture the corporate organizationif it really affects what you are doing. It s important to ask yourself what wouldhappen if you didn t capture the hierarchy. If the consequences are not painfulthen it s not worth carrying the cost of the links (and above all the costs of main-taining the links). Remember that it s easy to add this pattern in later to anexisiting list of organizations or parties. GOF fans will note that this pattern is an application of the GOF composite pat-tern, although a somewhat degenerate one as the composite and leaf classes aren tpulled out. Certainly you should consider using composite when you implement it,and bear in mind that it s quite common not to have distinguishing behavior betweencomposites and leaves in this don t need to limit yourself to a single hierarchic association. If an organiza-tion has different Structures for regional vs functional management, you can use a pair9of hierarchies as in Figure This allows sales in the London office to have sales asits functional parent and the London office as its regional parent.

10 Of course as you getmore hierarchies this will get messy, and this is the point where you ll want to useAccountability (17).Similar logic can lead to abandoning the heirarchy in favor of a more general graphstructure to allow you to have multiple parents. Here I would be more cautious. Askyourself whether you really have different kinds of parents that should be distin-guished. In many cases you ll find that multiple hierarchies or Accountability (17) willserve you better. Once you lose the single parent, you lose the ability to easily aggre-gate up the hierarchy, in particualar you won t be able to use Aggregating Attribute(14).Sample ImplementationThe key thing about implementing this pattern is to get the right kind of interface onthe classes. This means providing the right mix of operations to navigate the structurehow you need it to be this sample implementation I m using the static variable as a Registry (2) fororganizations.