Appendix A. Types of Models and Forms of Breakdown
No mention has been made thus far of types of models or forms of breakdown that a modeler may employ when analyzing a topic top-down. That is because an analyst can develop IDEFO models without being aware of this distinction. He can still use IDEFO effectively by keeping his purpose for developing the model clearly before him. But in this Appendix, we go deeper into using model types and breakdown forms to become even more effective in modeling the purpose and in communicating with the intended audience.
Modeling the Function versus the Process
In IDEFO, either the functions or the processes of an enterprise may be modeled. A function-oriented model defines the types of activities that are performed irrespective of time; a process-oriented model shows sequences of activities performed by the enterprise. For example, a function model contains a single activity box for each type of activity (design, manufacturing, management, and so forth), whereas a process model contains multiple activity boxes of the same type—one for each time a function is performed. Figure A-1 illustrates the concept with an example from a manufacturing enterprise.
The diagram in Figure A-1 is not intended to represent a single IDEFO diagram; it shows individual activity boxes from several diagrams to illustrate the differences.
On the left side of the figure, three separate processes are drawn for the design function based on when the function is used: a preliminary design, a detailed design, and a design change process. On the lower right side of the figure, a single box in a function model depicts the design function regardless of when it occurs—in other words, what it means to do design in general. From this example, we see that a process-type model is by nature much larger than a function model, since each activity box must be repeated each time it occurs during the enterprise’s daily operation.
Aside from being much larger than the function model, the process model scatters each function over a widespread location in the model structure, and this makes it more difficult for the viewer or analyst to envision commonalities to exploit when reengineering the enterprise. In an IDEFO function model, all of the design activities are modeled in one place, and all of the required functionality is analyzed cohesively. For example, an effect of the process model is to increase the likelihood of defining several computer packages to assist a designer—one for each process—whereas the function model would yield a single-computer support system for all uses of a function (a common design system, for example).
On the negative side, it is much harder for the staff of an enterprise to check the correctness and completeness of a function model than of a process model. This is because each staff member may envision himself performing his daily activities in the process model (“I do this, then I do this. . . .”), rather than imagining how others do similar tasks and synthesizing all usages into a single function.
An analyst may use this phenomenon to his advantage by creating a process model first, checking the facts with staff, and then developing a function model later, after identifying the common functions scattered around the process model and grouping them by commonality of function. Process improvements may then be designed to serve a wide variety of related processes, based upon the gathering of all uses of the function by the enterprise.
Forms of Activity Breakdown
Either form of model—function or process—may use one of several methods for modeling activities in finer detail. For purposes of this Appendix, we examine the four most common forms of breakdown: decomposition, sequential, organizational, and split-by-type (SBT), so that an analyst may choose which form best suits his purpose. In the following paragraphs, I define each form of breakdown and use a repeating example to illustrate the way each form of breakdown approaches the same subject.
The original form of breakdown used by SADT is decomposition, in which the parent activity decomposes into its sub-activities. Figure A-2 shows that the function “Report to Management” includes a status-gathering function, a documentation function, and a presentation function. These three functions are different in nature from one another; they require different skills and different detailed activities. A staff member who gathers prescribed data may not be good at writing. A staff member who writes well may not be as effective when making presentations to management.
Document production could be shown as a fourth box (printing, collating, binding, and so on), since it fulfills all of the criteria used to identify the other three boxes. However, the author chose to include this as a sub-function under the document status function. That is, the production of the physical document is a sub-part of the function of documenting the status. It is not worth highlighting at a diagram with node A43’s level but is more properly considered a detail of preparing the document as a whole.
The second form of breakdown is sequential, which breaks down the parent activity by a sequence of sub-activities. Sequence is popular in process modeling methods, and it is used to describe an event and the subsequent steps of a process to react to the event.
In the example shown in Figure A-3, the author thinks of the order of presenting reports to management, and he breaks down the reporting into three time periods—the initial kick-off meeting, the weekly reporting during project performance, and the final reporting. This author does not decompose the verb “report,” but rather, looks at the reporting process as it must be done at different points in time.
Compare this with the decomposition example in Figure A-2, which divides the reporting function into sub-functions of data gathering, report preparation, and presentation. All three documents (start-up documents, weekly documents, and final reporting) are included in the decomposition version, but in Figure A-3, the author presents a sequence of invoking the parent as a breakdown of the single parent function.
The third form of breakdown is organizational, in which the breakdown matches the enterprise’s organization chart. This form may be useful if one purpose of the modeling effort is to show the roles and responsibilities of the personnel in an AS-IS model. However, unless the organization is patterned after the functions to be performed, the breakdown will be cluttered with many arrows, showing organization-related interfaces.
A symptom that reveals to the reader that an organizational breakdown is being followed is that activity box titles typically contain department names instead of verb phrases. For example, you might see project management or technical publications as activity titles instead of verb phrases such as MANAGE THE PROJECT or PUBLISH THE DOCUMENT.
The danger of using the organizational breakdown form is that the author may be documenting the existing enterprise structure instead of really analyzing the enterprise. Another clue that an awkward structure exists is found in the complexity of the arrow structure. That is, if a tangle of arrows seems to be necessary to represent the breakdown, some of the activities should be clustered together and the organization should be restructured to reduce internal communication complexity.
In the organizational breakdown diagram of Figure A-4, we see that the TECHNICAL PUBLICATIONS organization is shown at the same level as the other activities, and all of them are depicted as structurally parallel. The data-flow traffic between the boxes is likely to be heavy and not easy to follow when attempting a walk-through. This is one of the most serious reader communication roadblocks—complex arrow structure.
The fourth form of breakdown is split-by-type (SBT). Figure A-5 shows the parent activity (REPORT TO MANAGEMENT) applied to different types of topics. The parent activity is not really broken down, but is explored in different situations. This kind of breakdown always results in a diagram with an uninformative arrow pattern, and is better replaced by a call arrow listing the topics or situations and pointing to a separate model for each call arrow reference (see the section treating levels of abstraction in Chapter 3).
The SBT breakdown in Figure A-5 demonstrates an uninformative arrow pattern in which all three activities are controlled by the reporting requirements, and all three activities use the project status as input. Three types of reports are produced, each of which are merged into the reports to management output.
An inherent danger in using the SBT form of breakdown became evident very early in the application of SADT to process modeling: In modeling a manufacturing process for a complex aerospace product, we found that the part fabrication activity broke down into 28 distinct fabrication processes (milling, sawing, lathe turning, bending, and so on). After considering many ways of grouping the processes into six or fewer activities, we realized that this was a case of SBT: not a decomposition of the verb “to fabricate,” but 28 types of fabrication (the parent activity). As a result of this realization, we built separate models for several of the fabrication disciplines and employed a call arrow to list the existing forms of process models.
The SADT example helps us understand the meaning of split-by-type. The breakdown of the verb “to fabricate.” applies to all forms of fabrication. Sub-activities using decomposition would result in activities such as START PROCESS, CHECK DURING FABRICATION, EVALUATE ACCURACY, STOP PROCESS, and SIGN ROUTING SLIP. These subprocesses apply to all types of products and processes; they decompose the verb “to process” as it applies to all types of products and part forming. However, to satisfy the purpose of the modeling effort, we should look at specific types of processes (hence the term “split-by-type”) rather than analyze the fabrication process in general.
Since this early experience, we have noticed many models that mix the decomposition form of breakdown with the SBT form. They are called a partial SBT and can be recognized by the arrow pattern shown in Figure A-5. That is, part of the detail diagram is an SBT and the remainder is a decomposition of the parent activity. If the split is into fewer than six parts, the occurrence of an SBT is often not realized by the author or the commenters. This oversight can be remedied by mounting the complete model on a wall, stepping back, and noting where SBT arrow patterns are evident.
Mixing forms of breakdown in a model is generally not a good idea, since it makes the reader switch his way of thinking without warning. The most common form of switching breakdown methods is to include an SBT within a decomposition and then to return to decomposition, as shown in Figure A-6. This typically occurs because the author becomes disinterested in the general level of abstraction and finds it more informative to drop down a level to model specific instances of applying the parent activity. This is clearly a situation in which the call arrow syntax should be applied. To avoid inadvertently switching to the SBT breakdown method, the author should follow the IDEFO diagramming steps carefully and not skip the initial data list step when beginning a new diagram.
The data listing step helps authors avoid the SBT problem because the mental process of identifying the data elements used or produced by the parent activity, and then of using this list to consider what sub-activities use or produce each data item on the list, naturally leads the author into a decomposition of the parent into its parts. Of course, a drop in level of abstraction may be more helpful to the purpose of the model, and the author must not continue when further decomposition at the present level of abstraction is not helpful.