12.1 Multi-Organization Unit Requirement Pattern

12.1 Multi-Organization Unit Requirement Pattern

Basic Details

Related patterns:	Extends multiness; refers to user authorization
Anticipated frequency:	Zero or one requirement
Pattern classifications:	Affects database: Yes

Applicability

Use the multi-organization unit requirement pattern to specify a type of organizational construct that the system must be able to support, whether that be units of a specific type or a more complex structure (such as a hierarchy).

Do not use the multi-organization unit requirement pattern to enumerate the organization units themselves (such as listing actual companies or departments).

Discussion

A typical business is a much more complex organism than a typical system gives it credit for. A system is often regarded as merely a mass of functions used by a mass of users: flat and amorphous. But those users must be properly organized along the lines of the business itself, and the ways in which that's done has a significant impact on the functions themselves. Neglecting organizational structure during the specification of a system is likely to lead to unsatisfactory results and ongoing operational difficulties, which might never be traced to their ultimate cause. Note that we're talking here only about the organization structure as it affects the system when it's in production; the structure of the team that builds the system is irrelevant.

An organization unit is any subset of an organization that makes it easier to manage. It is a flesh-and-blood collection of people you can go and visit, such as "the finance department." An organization unit type is an abstract organizational concept-such as "department"-of which organization units are instances. Here are a few common examples of organization unit types: company, office, branch, department, subsidiary, and region. Relationships between organization unit types define the structure of the organization as a whole. Organization unit requirements concern themselves with organization unit types.

Organization units known to the system needn't be limited to the organization(s) whose business the system handles directly. Occasionally, a system must represent units of other organizations (such as agents, subcontractors, and other business partners), especially if their employees use the system. If so, bear in mind that each organization is likely to have its own structure. Consider all the organizations that might use the system and work out what structural variations are needed to suit them.

Working out an accurate model of the structure of the organization(s) in which the system is likely to be installed is important, and it's invariably neglected. A system that doesn't properly represent its business environment can run into various problems, some of which are never tracked back to this as the reason. Whenever a fundamental feature is not properly built in to a system, there's a temptation to deal with any resulting difficulty by using a half-baked fix (because it's too late and too daunting to do it properly)-like a mechanic who mends a broken down car but who's not in a position to rectify basic flaws in its design. Over time, the system becomes riddled with ugly workarounds and grows old prematurely.

Organizational structure isn't properly studied and specified for several reasons, and they're all unjustified. First, it might be regarded as simple and obvious-in which case it'll be easy to describe, so there's no excuse not to do it (though it often turns out to be less simple than it seemed). Second, at the opposite extreme, it might look too hard: convoluted and illogical, which is all the more reason to figure it out. If you can't cope, how are the poor users going to cope with a system not built to fit in with the structure they have to work within? Third, if the system is a product that will be installed in a wide variety of organizations, their structures will be unknown, giving yet more reason to work out how much variation they're likely to have and to accommodate it. If you don't, you're likely to lose sales, no matter how great the system is-probably without even knowing why. Fourth, structure isn't functional: everyone worries too much about what systems do and not enough about how they're organized. Fifth, no one thinks to bother. Systems will improve if they take organizational structure more seriously.

The structure of an organization isn't always uniform or consistent. A company might have several offices that organize themselves very differently. A nice neat hierarchy, with a fixed number of levels everywhere, often isn't good enough. We might encounter complex reporting lines too, or multiple departments with the same purpose in different offices. If you aspire to build a system that fits the way a company works, you need to understand what constituent parts it has.

If the system will be installed in multiple places, specify what types of organization unit each installation must cater for, even if there is a higher level of organization above them all. Alternatively, making the system aware of the higher level of organization can give you the flexibility to decide how many installations to have, thereby allowing the business to choose based on operational and cost considerations, rather than being dictated to by the system's design.

Content

There are two kinds of multi-organization unit requirement. The first kind defines a particular type of unit and should contain:

1. Unit type name. Identify the specific type of unit (for example, "department" or "branch").

2. Unit type definition. Define precisely what is meant by this type of unit. (For example, what is a "branch"?)

3. Parent unit type (if any). Include this if it's not a top-level organization unit.

4. Characteristics. What purpose does this type of organization unit serve? What impact does it have on the system? Concentrate on aspects that affect individual functions-especially access restrictions, and information display and selection criteria.

5. Expected number of instances. For a type of organization unit at the top level, give an absolute number (such as how many companies); for lower-level units, indicate how many per higher unit (such as how many departments per company).

The second kind of multi-organization unit requirement asks for the ability to define an organizational structure dynamically (by configuring it in the system). This kind of requirement should contain:

1. Structure Describe what sort of abstract arrangement of units we want (for instance, a hierarchy, the most common). If something more complicated is needed (such as being able to set up a different structure for each company, or dual reporting lines), explain how it fits together and what it's for.

2. Characteristics This is as in the first kind of requirement. It's sensible, when allowing the structure to be configurable, to accept that all types of units have the same characteristics as far as the system is concerned (such as the items of information held about each unit type: ID, name, manager's name, and so on).

   One characteristic we should ask for is the ability to define a name for each type of organization unit. For example, if we support any three-level hierarchy, what does each level represent? Without names, there's no way to display any of these things in the terms users are familiar with.

Template(s)

The first template here is for specifying a particular type of organization unit. The second template is for specifying the ability to configure an organizational structure in a flexible manner; it's deceptively sparse because the intricacies of what you want must be expressed in the «Structure description».

Open table as spreadsheet

Summary	Definition
Multi-«Unit type name»	The system shall support multiple «Unit type name»s [per «Parent unit type name»]. [For the purpose of this specification, a «Unit type name» is «Unit type definition».] [«Characteristics statement».] [«Number of instances statement».]
«Structure summary» organizational structure	It shall be possible to define an organizational structure «Structure description». [«Characteristics statement».]

Unlike the base multiness requirement pattern, there is no separate template for a requirement that makes provision for multi-organization unit-because by the time you've made provision for it, you've done the bulk of the work.

Example(s)

Open table as spreadsheet

Summary	Definition
Multi-company	The system shall be able to support multiple companies simultaneously in the same running installation. For the purpose of this specification, a company is an independent legal business on whose behalf the system conducts processing. Each company will have its own employees who use the system; they are to be aware only of the company for whom they work. (The specifics of this are covered in other requirements.) One installation of the system might be asked to accommodate up to a dozen companies.
Multi-department	The system shall support multiple departments per company. Each employee is primarily concerned with the activities of the department in which they work but might have reason to deal with the work of other departments. A company is likely to have between four and ten departments.
Three-level organizational hierarchy	It shall be possible to define a hierarchy of organization units of up to three levels, such that each employee works directly in one particular unit (at any level in the hierarchy). The name of the type of organization unit at each level in the hierarchy shall be configurable (for example, "company," "office," and "department"). The purpose of this hierarchy is to allow functions to tailor what they display according to the organization unit the current user works in.

Extra Requirements

An organization unit requirement could deserve extra requirements on the following topics:

1. Access control See the user authorization requirement patterns (in Chapter 11, "Access Control Requirement Patterns"), including their "Extra Requirements" subsections, which point out various extra topics to make life more interesting.

2. Bureau for multiple companies Running a bureau service for multiple independent companies can involve its own complications, such as the activities of one company degrading the performance of another, calculating each organization's system resource usage, and software introduced by one interfering with (or even spying on) another. If any of these apply to your system, investigate and write requirements for them.

3. Reorganizing Does the system need to worry about the structure of an organization changing? See the "Reorganizing" subsection that follows.

4. Unit IDs Uniquely identifying an organization unit can be fiddly, especially if the whole structure is configurable. If you don't want to run the risk of the development team devising some logical-but-hideous solution that users will hate, write a requirement for something friendlier. You could also consider a requirement that bans the hard-coded interpreting of unit IDs, because that effectively renders them unchangeable and creates a fragile state of system atrophy. (And don't be so naïve as to assume such practices aren't widespread.)

Reorganizing

An organization is apt to change its structure from time to time, and the larger it is, the more scope it has to rearrange its parts. Also, the more levels of management, the more often a unit at the bottom is affected by new management initiatives. Systems typically make no provision whatsoever for such changes, for several reasons: reorganizations are assumed to be rarer than they actually are, they're something for the future, no one gives them a thought, and they're just too hard. Start by considering how likely future structural change is. How frequently has it happened in the past? What sorts of reorganizations are likely? How drastic? Might the company acquire or shed or merge operating units? How easy should it be for the system to react? What sorts of change are worth worrying about?

Finally, if our system supports configurable organization structure but doesn't have a miraculous in-built ability to bring everything into line when that configuration is changed, then we should prevent it from being changed. The following example requirement does just that:

Open table as spreadsheet

Summary	Definition
Organization structure non-modifiable	It shall not be possible to reconfigure the structure of the organization within the system after it has been set up initially. The purpose of this requirement is to prevent changes for which the system is incapable of properly handling the implications.

Considerations for Development

Bear future changes in organization structure in mind, and do what you can in the design to make the impact less traumatic. Often there's not much that can be done. The area to bear most in mind is the database design so that data is tied to a particular organization structure as loosely as possible.

If you're going to cater for flexible organizational structures, decide how to identify each one: a suitable ID scheme.

Martin Fowler's Analysis Patterns book (1996) has analysis patterns for organization hierarchies and organization structure.

Considerations for Testing

Multi-organization unit support doesn't manifest itself directly: there's no single place where you can find it. It might affect many functions, so you must work out what they are and check that they all work as the multi-organization unit requirements say they should. (It can save time if you test all the multi-organization unit requirements together.) Here are some topics to look out for:

1. Inquiries, reports, and other functions show only information pertaining to relevant unit(s).

2. Access control: that a user can't see units they shouldn't. (See the user authorization requirement patterns in Chapter 11 for further information.)

3. Selection criteria default to the user's own organization unit(s).