Organization Structures - Martin Fowler

[Pages:25]1

Organization Structures

It seems that remarkably early in our lives we become familiar with organizational structures. The classic management hierarchy appears on an org chart early in our career, but even by then we've already come across the notion in plenty of places. So in a way it shouldn't be surprising that organization structures crop up frequently enough in business software too. I recognized many organizational patterns several years ago and ever since they keep turning up again.

A good way to start thinking about modeling organization structures is to think of the obvious way. Imagine a company where people work in departments, which are organized into divisions. Figure 0.1 shows an explicit model for this where each part of the structure is a separate class.

Division

Department

Person

1

1

Figure 0.1 An explicit, and obvious,organizational structure.

Explicit structures have two main disadvantages. They don't work well if there is much common behavior between the kinds of organization. They also embed the current organizational categories into the design. Should some bright spark decide to add regions between divisions and departments, you have some modificaitons to do.

2

parent 1

Organization

{hierarchy}

children

Figure 0.2 Organization hierarchy

Faced with these problems, the obvious move is to create a supertype for the organization, which leads you to Organization Hierarchy (7) in Figure 0.2. The organization hierarchy works best when you don't have much different behavior between the organization sructures. It also allows you to stay very flexible if new kinds of organizations appear. If you do have some varied behavior you can use subtypes to pull this down.

Party

Person

{hierarchy}

parent 1

Organization

children

Figure 0.3 Adding Party to an organization hierarchy

Making a supertype for the organization is a pretty obvious move, another common, if less obvious, supertype is Party (5): a supertype between the organization and person, leading to Figure 0.3. Often you find that there isn't much difference between the hierarchic association between organizations and the association between person and organization so you can pull these associations up to the supertype (Figure 0.4).

3

{hierarchy}

parent Party

1

children

Person

Organization

Figure 0.4 A hierarchy on Party

A hierarchy like this is a good choice for many organizations, it certainly captures the usual org charts pretty well. But as organizations get larger then you tend to see a number of different kinds of links between your parties. This might be matrix style organizational structures where people are organized by job function and geographic location at the same time. Obviously one way to do this is to create a second party hierarchy, but this only goes so far. You don't want your party festooned with hierarchies.

This situation leads you to Accountability (17), where you make the interparty releationship an object in its own right, typed according to the kind of link you need to have (Figure 0.4). Accountabilities represent the most powerful, and also the most complex way of dealing with organizational strucutres. So like most of these power tools, you don't get them out unless you really need them. But when you do accountabilties 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 parties can be connected together. You can use a Knowledge Level (32) to capture and enforce these rules.

4

Accountability Type

1

Accountability

Party Type

1

1 child 1 parent

Party

Person

Organization

Figure 0.5 Using Accountability for the organization structures

5

Party

An abstraction of people and organizational units

Party

Person

Organization

Example: A telephone utility's customers may be individuals or businesses. Many aspects of dealing with customers are the same, in which case they are treated as parties. Where they differ they are treated through their subtype.

Take a look through your address book, what do you see? If its anything like mine you will see a lot of addresses, telephone numbers, the odd email address... all linked to something. Often that something is a person, however the odd company shows up. I call `Oak Grove Taxi' frequently, but there's no person I want to speak to -- I just want 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 duplication is painful to the eye. So I need a supertype of person and company. This class is a classic case of an unnamed concept -- one that everybody knows and uses but nobody has a name for. I have seen it on countless data models on various names: person/org, player, legal entity....

The term I prefer is party, and I've been glad to see that over the last few years it's turned into a fairly standard name.

6

Making it work

I usually define party as the supertype of person and organization. This allows me to have addresses and phone numbers for departments within companies, or even informal teams.

Put any behaviror that is common to people and organizational units on Party, only put things particular to one or the other on the subtype. When you put behavior on the subtype, think about whether it makes sense on the supertype, often you may be surprised how well things fit on the supertype

When to use it

The obvious case to use Party (5) is when you have people and organizations in your model and you see common behavior. However you should also consider this pattern when you don't need to distinguish between people and organizations. In this case it's useful just to define a party class and not to provide the subtypes.

If you see parties playing different roles in a business, you'll often see one of the role patterns in play. Coad in particular is a big fan of Role Object (116). It's a common pattern with party, but isn't one to turn to blindly, but take a look at Role Object (116) for more discussion of that issue.

The 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 widely used these days, so choosing that name helps in communication.

7

Organization Hierarchy

Represents the hierarchy of organizational units within a business

parent 1

Organization

{hierarchy}

children

Associated Coffee Makers: Organization

sales : Organization

purchasing : Organization

Boston sales : Organization

London sales : Organization

Making it work

Hierarchies are a common structure in organizations. This is because they reflect a natural and common technique for human beings to deal with complexity. Modeling a hierarchy is thus a common thing to do, yet it is both easy and complicated.

8

It's easy because you can show it with a recursive association, my old data model teachers called it a "pigs ear". However the recursive association does not tell the whole 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 grandparent cannot be your grandchild). There is no standard notation for dealing with this in the UML. I use a constraint {hierarchy} on the association to suggest what is going on.

Even the {heirarchy} constraint, however, is strictly imprecise. It doesn't tell you the difference between a tree (one top) and a forest (multiple tops). If this is important to you model you should say what it is, most of the time I find it isn't that vital.

In the sketch I use the terms parent and children. Naming these association roles can be tricky. Parent works well with most companies, but child isn't as good as subsidiaries. However I've come to the view that children is the best name. The use of parent and child is a very useful metaphor when discussing hierarchies, or indeed any other kind of directed graph structure. I can use such phrases as "sales in London is a cousin of purchasing in Java" and, although it sounds wacky, you can easily figure out what I mean. The metaphor gives us a useful vocabulary which is worth the fact that it often sounds a little odd.

When to use it

You need to use this pattern when you have a hierarchic corporate structure that affects the software you are using.

? hierarchic: because the pattern handles a hierarchy not anything more complex. If your needs are more complicated you can tweak the pattern (there are some suggestions below) or use Accountability (17) instead.

? affects the software: because you only need to capture the corporate organization if it really affects what you are doing. It's important to ask yourself what would happen if you didn't capture the hierarchy. If the consequences are not painful then it's not worth carrying the cost of the links (and above all the costs of maintaining the links). Remember that it's easy to add this pattern in later to an exisiting list of organizations or parties.

GOF fans will note that this pattern is an application of the GOF composite pattern, although a somewhat degenerate one as the composite and leaf classes aren't pulled 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 between composites and leaves in this use.

You don't need to limit yourself to a single hierarchic association. If an organization has different structures for regional vs functional management, you can use a pair

 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download