May 11 1999, Volume 2 - Number 7
Breaking organization models into more abstract levels offers you more flexibility and room to grow
Structuring Organizations
Terry Moriarty
Since my January 26 column (“Know Your Role,” p. 66), I’ve been describing the business
party and business party relationship patterns represented in the dynamic business model. I’ve claimed that you can use this pattern to depict any relationship that can exist between two parties, such as employment, ownership, household, and family membership and organization structure. But it’s useful to explore the business party relationship pattern in greater detail by illustrating how you can use it to support your enterprise’s organization chart.
The organization chart defines the scope of each internal unit’s responsibility. The highest level on the chart represents the chief executive officer (CEO), whose responsibility spans the entire enterprise. Throughout the organization, these responsibilities are sliced into smaller, more manageable chunks and delegated to lower-level business units. Each internal unit has a set of job positions assigned to the people who perform the tasks necessary to accomplish their unit’s responsibilities.
A job position has a specification defining the responsibilities associated with it. To fulfill its responsibilities, an internal unit may require different types of job positions, and different internal units may require positions with the same job specifications. For example, Bank of Wherever may decide to organize its information technology data management unit around its two major markets: international and domestic. Any data management organization requires at least four different job positions: data modeler, data analyst, database administrator, and manager. These jobs are allocated to an organization’s internal units according to the work distribution. In this scenario, because the bank does more domestic business, it allocates four data modeler positions to the domestic data management unit, but only one to its international counterpart.
When an internal unit is initially created, its job positions are unfilled. Over time, people take on each position within a business unit. The same person can fill several positions at a time. For example, at one large corporation, I was the manager of 17 data modelers and data analysts, but at a smaller bank, I filled the data modeler, data analyst, and manager positions.
You can classify internal units according to the types of responsibilities you expect them to provide. For example, all the units responsible for selling the bank’s services to customers are sales units, and customer care units provide ongoing support to the customer after the sale. Each business unit category has a specification that describes its responsibilities, the jobs that you can assign to it, and its reporting positions within the organizational hierarchy. For Bank of Wherever, branch, region, and division are all internal unit categories. There are business rules that specify how these unit categories can interact. A branch can report to a region or directly to a division. A region must report to a division. Every branch must report to either a region or a division. The job positions that you can assign to a branch include manager, personal banker, commercial banker, and teller.
The Literal Model
At least three different models represent these business rules. The literal model (see Figure 1) focuses on the business rules governing the ways units and people can report to one another by explicitly representing each internal unit category as a separate entity. If you transform this model into a database design, the business rules regarding organizational reporting structures will be hard-coded into the database structure. If the organization wants to change the business rules governing how it wants to organize itself, it will need to make changes to the database. For example, I worked for an upscale bank that decided to project a more professional image to its customers. The bank decided it had offices, not branches and clients, not customers. Although this seemed like a small change in terms, the impact was widespread on the application’s portfolio, which included data elements scattered across multiple databases with names that included the terms “branch” and “customer.” The bank decided that it was cost prohibitive to rename all the tables, columns, files, and data elements from branch or customer to office or client. However, all external references through screens and reports had to change. Changes of this magnitude can be viewed as an internal mini-Year 2000 effort.
FIGURE 1 The literal data model.
When you design an organization chart initially, the focus is often primarily on how to organize the sales force. Consequently, the internal unit categories defined are biased toward those required to support sales. So we see business rules stated in terms of branches, offices, regions, teams, divisions, and areas. These terms are meaningful from a sales perspective, but probably can’t accommodate the service, support, and administrative units within the organization. In fact, the internal unit classification scheme often changes from one line of business to the next. Although the division, region, and branch hierarchy works for Bank of Wherever’s domestic line of business, the international business organizes itself into a country, area, province, and office hierarchy. When an organization is faced with the need to integrate its information about its organization structure into a shared data environment, it often tries to compensate for the constraints imposed by its database by “shoe horning” the nonconforming units into the database’s hard-coded categories. Consequently, each domestic data management team becomes a branch because this is the only mechanism for depicting lower-level units on the organization chart.
The Internal Unit Model
As a defense against rapidly changing business rules affecting the configuration of the organization chart, modelers began to propose a more generalized model to support their enterprise’s organization structure.
(See Figure 2.)
FIGURE 2 Internal unit abstract data model.
We see the now familiar pattern that separates specification and actual entities. A specification entity provides the business rules that govern the behavior of the real-world instances assigned to the associated entity categories. An actual entity provides the information about the real-world entity instance. Every unit behaves according to the business rules defined for its specific category. Because the organization chart is a hierarchy, a single recursive relationship exists on the unit entity that identifies the parent unit for each one. A corresponding recursive relationship on the unit category entity represents the business rules that govern how units can report to one another.
The internal unit model provides many advantages over the literal version. The information systems no longer inhibit the enterprise’s ability to restructure itself to meet market conditions. Likewise, the model can easily accommodate changing the names of unit categories, adding new ones, or redefining the business rules that define the boundaries among the unit categories. Each functional area can define the organizational structure meaningful to it. With this model, Bank of Wherever’s data management unit can organize itself into teams rather than branches.
The Business Party Relationship Model
The third option for supporting the organization structure is the business party and business party relationship model (see Figure 3),
FIGURE 3 Organization structure configured in the business party relationship pattern.
which represents an additional level of abstraction from the internal unit model. As we know, an organization is a group of people that bands together for a specific purpose. A legal entity is the collection of employees, vendors, and shareholders that works together to participate in some manner in society — as a business concern, government agency, association, or other community group. An internal unit is just one slice of the legal entity that assumes a subset of the organization’s total responsibilities. For example, the data management unit is a collection of people that assumes the job positions of data modeler, data analyst, and database administrator as necessary to manage the organization’s data resources. Consequently, an internal unit and a job position are just another business party.
The reporting relationship between two internal units fits the business party relationship pattern, in which one unit assumes the role of parent and the other has the role of subordinate. By representing internal units as business parties, you can easily represent the other roles that a unit may play within the organization. For example, if any of your units provide a service to your other units, then the unit receiving the service behaves just like any other customer of the providing unit. The business party pattern already knows how to represent “customer-ness” through the roles the business party assumes. No special structures are required to represent those customer relationships that occur among internal units. Furthermore, units have contact points, in terms of addresses, phone numbers, and email addresses, just like any other business party. By including the internal unit and reporting structure entities as subtypes within the business party and business party relationship hierarchies, units inherit all the data and behavior common to all business parties. Because the internal units inherit the properties of business parties and business party relationships, the business analysts and information systems designers are free to focus on those business rules that are unique to internal units and reporting structures.
The data model supporting an organization’s structure was probably one of the first patterns to emerge. Let’s face it, reorganizations run rampant in most organizations as they attempt to tweak, tune, and align themselves to respond to the changing market conditions. So we had to do something to insulate our applications from the impact of changing reorgs. The evolution through each level of abstraction has been driven by the need to achieve higher levels of flexibility in our information systems so they can readily respond to changing business environments. Each model evolution lets the business accommodate a wider range of business rules. Given the choice among the alternative data structures I’ve discussed for the same business rules, shouldn’t you choose the one that can support the business area’s as well as the enterprise’s needs?
Unfortunately, the designers of line of business information systems may feel that the literal model is sufficient for their stakeholders’ needs. They may believe that any analysis beyond their client’s stated requirements is engaging in “scope creep.” This type of myopic thinking is what lead to the islands of data that most enterprises struggle with today. Either of the generalized models meets both the local and the enterprise need to manage the information about an organization’s reporting structure and can easily change when the business reorganizes itself. The same can’t be said for the literal model.
Terry Moriarty, president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management. You can reach her via email at terry@inastrol.com.
