Program S Characterization and Execution
1
6. THE USE OF THE AXIOMS OF ENGINEERING DESIGN AS A BASIS FOR DESCRIBING A GENERALIZED ENTERPRISE DEVELOPMENT
PROGRAM’S CHARACTERIZATION AND EXECUTION
The Development of the Concepts of Enterprise Reference Architectures for Program Development (Type Two) and Physical System Descriptive Architectures of Enterprises and their Components (Type One) is described in this chapter based on the axiomatic approach proposed by Professor Suh in order to establish a theoretical basis for the Purdue Enterprise Reference Architecture and the Purdue Methodology.
6.1 The Axioms of Design
Professor Nam P. Suh, Director of the Laboratory for Manufacturing and Productivity, Department of Mechanical Engineering, Massachusetts Institute of Technology has written the following textbook [84]:
The Principles of Design
Oxford University Press
New York, NY
1990
in which he established a scientific base for engineering design.
This work is based on a fifteen year research by Professor Suh and his associates to establish the Axioms of Engineering Design. Axioms are formal statements either of what people already know or of the knowledge imbedded in many things that people do routinely. They cannot be proven, and they can only be disproved through the discovery of counter-examples.
The basic assumption of an axiomatic approach to design is that there exists a fundamental set or principles that determines good design practice. The only way to refute this assumption is to uncover counter examples that prove these axioms to be invalid. The knowledge in a given field can be axiomatized when a set of self-consistent logic based on the axioms can yield correct solutions to all classes of problems. So far, no-one has come up with evidence that the design axioms are invalid.
Suh initially proposed twelve axioms of engineering design and over the years he and his associates have reduced these to two which are:
Axiom I: The Independence Axiom
All of the Functional Requirements for a Design Must be Made to be Independent of Each Other.
Axiom II: The Information Axiom
That Design is Best Which Requires the Minimum Information for its Execution.
Prof. Suh later pointed out [85]:
“Axiom I distinguishes between good and bad design, or acceptable and unacceptable design. Axiom II is the criterion for selection of the optimum design solutions from among those that satisfy Axiom I.”
Under Suh’s system, design is defined as the mapping process between the Functional Requirements (FRs) in the functional domain and the Design Parameters (DPs) in the physical domain. Their mapping relationships may be mathematically represented in a matrix form [A] as follows:
{FR} = [A] {DP}[6.1]
where
{FR} — the functional requirement vector;
[A] — the design matrix; and
{DP} — the design parameter vector.
The left-hand side of Equation [6.1] represents that “what we want in terms of design goals,” and the right-hand side “how we hope to satisfy the DRs.” [84, pp.54–55]
If the design matrix [A] is a diagonal one, any single element of {FR} can be changed independently by just changing one element of {DP}. A design that satisfies such a condition is defined as an uncoupled design.
The converse of an uncoupled design is the coupled design whose design matrix [A] has mostly non-zero elements. That is, if we change just one design parameter in {DP}, most probably every functional requirement will be changed at the same time. However, in this case, if we can arrange the [A] into a triangle matrix and solve the equitation starting from the line where there is just one non-zero element (see also Section 7.4.3 and Equation 7.1), then this system is called a decoupled design which offers a conditional independence between the functional requirements. [84, pp. 54–56]
Among the corollaries of the two Axioms, there are two which can be related to the study of this thesis. They are [84, pp. 52–54]
- Decoupling of Coupling Designs:
Decouple or separate parts or aspects of a solution if FRs are coupled or become interdependent in the designs proposed.
- Use of Standardization:
Use of standardized or interchangeable parts if the use of these parts is consistent with FRs and constraints.
Although Prof. Suh expressed his Axioms in the mathematical form, many of his application examples in his book [84] and other related articles[85–87] were discussed qualitatively with help of the mathematical symbology he defined.
A small example in his book is a design of a can and bottle opener (see Figure 6.1). This bottle/can opener satisfies two FRs: (1) opens cans, and (2) opens bottles. If the requirement is not to perform these two functions at the same time, this physically integrated device satisfies Suh’s first Axiom: they are independent FRs. [84, p. 51]
Prof. Suh especially stated [84, p. 51]:
“the identification of the ultimate optimal design having minimum information content cannot be guaranteed; also there is no method for generating all potential designs. We can only identify the best design on a relative basis among those proposed, using Axioms 1 and 2. However, the ability to eliminate unacceptable or unpromising ideas in their early stages enhances the creative part of design, and reduces the cost of development and the chance for failure.”
FIGURE 6.1 TWO FUNCTION REQUIREMENTS OF THE OPENER ARE INDEPENDENT
6.2 Applicability of Suh’s Axioms
Suh’s book and its theme, the Axioms, will apply to the Enterprise Reference Architecture work if the following are considered:
1. What is really being done in the Architecture Project is to Design a Methodology for Enterprise Integration.
2. The Architecture is a Model of the Process or Methodology for Achieving Enterprise Integration.
3. It is interesting that the method of development in the Industry-Purdue University Consortium was the reverse. First, the Architecture Structure was developed and then the Methodology was written as a text explanation of the Architecture Sketch. Coincidentally, CIMOSA and GRAI apparently did likewise in their projects as well. This says something about how engineers’ minds work.
4. Basically, the developers of PERA and the Purdue Methodology have summarized what they believe is a good engineering practice based upon general observation and put their summary into a framework and its guideline. The nature of this approach is developing a needed general theory to explain and to guide further development. The theoretical support needed to formalize this new theory must itself has a high generality and has a close connection with engineering practice.
The attached is an attempt at developing the Purdue Methodology for Enterprise Integration via the Axioms of Engineering Design. The system works as follows:
1. A minimum set of Functional Requirements is developed and the corresponding Design Parameters written for accomplishment of the Requirements.
2. Succeeding sets of Requirements and corresponding responses are then developed in a hierarchical fashion from the initial ones until the design description is finished as shown in the attached Figure 6.2.
3. The definitions accompanying Figure 6.2 present short titles for each Functional Requirement (FR) and its associated Design Parameter (DP).
The following notes are necessary for a fuller understanding of the axiomatic approach here:
11 There are four separate Functional Requirements which form the minimum set at the top level of the hierarchy as we see it. They relate as follows (see Figure 6.2 also):
11 A Complete Life Cycle is necessary (FR(1)).
21 The Methodology must be complete in that it must describe all systems components and their behavior (FR(2)).
31 The objectives in executing the methodology are (1) the development of a Master Plan for the overall enterprise integration project and (2) the properly developed Master Plan must include a set of independent projects (FR(3)).
41 These projects must be implementable as enterprise resources become available (FR(4)).
51 This minimum set of Functional Requirements at the top level are all independent of each other.
21 In order to complete the development of the Methodology associated with the Purdue Enterprise Reference Architecture, a continuing set of subsidiary Functional Requirements and associated Design Parameters (1 for 1) under each main Functional Requirement must be developed in a recursive decomposition [84, pp. 36–39] until the Methodology is complete. This gives the hierarchical structures of Figure 6.2 where each of the boxes contains the serial number and short title of the Functional Requirement (FR) or Design Parameter (DP).
31 The term Design Parameter is used to name the corresponding means of satisfying the given Functional Requirement in order to match the nomenclature of Professor Suh’s book. This is not a good term to use for this example application, but it is necessary to follow the textbook as much as possible.
41 It is noted that the Master Plan and its associated Project Program Proposal are the Products for which the Methodology is being developed. In nature, they are part of a Design Parameter (see FR(3) and DP(3) in Table 6.21).
51 A Short Analysis of the results of this investigation is presented as a set of Questions and Answers in Table 6.24.
6 Professor Suh proposes an Information Theory type analysis of the total information necessary for a design as the answer sought with AXIOM II. He also points out though that many design decisions can be made qualitatively based on his Axioms if and when the basic knowledge of the subject is understood [84, pp. 190, 244]. Based on the understanding of Suh’s Axioms and the Purdue Methodology, as noted in Question 4 in Table 6.24, the following is proposed to consider the information contents of the Purdue Methodology:
(a) Regardless of the Methodology used, the description of the Enterprise analyzed will require approximately the same overall amount of data.
(b) The important questions to be answered here are what are the critical questions asked in developing the Enterprise Models for further analysis. How many questions are asked? As noted in the Answer to Question 4, we believe only two are necessary in PERA. CIMOSA, for example, must ask several more to satisfy its required classifications.
6.3 Functional Requirements and Design Parameters of the Purdue Methodology
The contents of Functional Requirements and associated Design Parameters are presented in the following tables. Each pair of the Functional Requirement and Design Parameter is put together in a table which is named according to their symbols in Figure 6.2 and their short titles in Figure 6.2 are placed in parentheses after their long titles in the tables. The tables are arranged following the sequence of the boxes in Figure 6.2 similar to a depth-first pattern, which provide a suggested reading sequence to understand every aspect of the Purdue Methodology and its model PERA.
6.4 An Analysis: What is PERA and the Purdue Methodology?
By analyzing the work on PERA and the Purdue Methodology based on the Suh’s Design Axioms, the theoretical perspective and totality of the work can be validated and further summarized in a Q&A form in Table 6.24.
Table 6.1 FR-(1) and DP-(1)
METHODOLOGY FUNCTIONAL REQUIREMENT 1LIFE CYCLE OF THE ENTERPRISE DEVELOPMENT PROJECT AND
ENTERPRISE ENTITY INVOLVED (Life Cycle)
The Enterprise Development Program must cover the full Life Cycle of the subject Enterprise or part thereof under consideration.
METHODOLOGY DESIGN PARAMETER 1
LIFE CYCLE OF THE ENTERPRISE DEVELOPMENT PROJECT AND
ENTERPRISE ENTITY INVOLVED (Phases Named)
The life history of Life Cycle of any Project for Enterprise Development and/or the associated Enterprise Entity must include the following six Steps or Phases in order to be complete: (see Figure 3.1)
1. Concept
2. Functional Analysis or Functional Definition
3. Functional Design
4. Detailed Design
5. Construction and Installation, or Manifestation
6. Operation to Obsolescence
Note: This is the first pair of FR and DP at the top level of the hierarchy to define the general concept of a full life cycle of an enterprise. In order to establish such a life cycle, this pair has six following FRs defined (see Figure 6.2).
Table 6.2 FR-(1-1) and DP-(1-1)
METHODOLOGY FUNCTIONAL REQUIREMENT 1-1MODELING THE LIFE HISTORY OF ANY PROJECT FOR
ENTERPRISE DEVELOPMENT (Model Life Cycle)
The life history of any Project for Enterprise Development must be able to be modeled to show the interrelationship of the six Phases involved.
METHODOLOGY DESIGN PARAMETER 1-1
MODELING THE STRUCTURE OF THE ENTERPRISE DEVELOPMENT
PROGRAM (Model Proposed)
The six separate regions and phases of the Enterprise Development Program as described in Methodology Design Parameter 1 are commonly executed in series. In their totality they will describe the life history of that part of the Enterprise involved in the Enterprise Development Program. This whole discussion can thus be named the LIFE CYCLE of the Enterprise or of that part of the Enterprise involved in the Development Program.
A model of the structure (i.e. interactions and progression of the Phases of the Program) can be represented as shown in the attached sketch (Figure 3.1). The meaning of the several areas and locations involved will be described in succeeding Functional Requirement/Design Parameter Pairs. Since this model represents the structure of the Program described, it can be termed as the Architecture of the Program.
Note: This pair and its following pair (Table 6.3) explain detailed concepts of Phases and Activities of the Phases.
Table 6.3 FR-(1-1-1) and DP-(1-1-1)
METHODOLOGY FUNCTIONAL REQUIREMENT 1-1-1DETAILING OF THE PROGRAM MODEL WITH THE PROGRAM
ACTIVITIES (Model Detailed)
The model of the Life Cycle of the Enterprise Development Program must be detailed to show all activities occurring at each Phase of the Program.
METHODOLOGY DESIGN PARAMETER 1-1-1
DETAILING OF THE PROGRAM MODEL WITH THE PROGRAM
ACTIVITIES (Proposed Detail Presented)
Figure 3.18 is one example of the possible detailing of the activities which are involved at each Stage of Progression of the Implementation of an Enterprise Development Program.
The diagrams of Figures 3.1 and 3.18 illustrating the Life Cycle of an Enterprise Development Program become the generic representation of the corresponding Life Cycle for any such program for any enterprise in any industry or field of endeavor since there is nothing in this discussion to limit the type of activity discussed, the size or characteristics of the enterprise or part thereof involved, or the industry or field of endeavor under discussion.
These diagrams are also the corresponding STRUCTURE for such a development program and thus their form can be called an ARCHITECTURE. Because of its generality and wide applicability it should be called an ENTERPRISE REFERENCE ARCHITECTURE.
Table 6.4 FR-(1-2) and DP-(1-2)
METHODOLOGY FUNCTIONAL REQUIREMENT 1-2THE FUNDAMENTAL BASIS FOR ANY ENTERPRISE DEVELOPMENT
PROGRAM (Fundamental Basis for any Enterprise)
Any Enterprise Development Program must be driven by the requirements which its parent enterprise has for its own future existence and/or growth. These requirements are reflected in the goals and aspirations which Enterprise Management has concerning the expected outcome of the proposed endeavor. These latter must then form the basis for planning for the proposed Enterprise Development Program.
METHODOLOGY DESIGN PARAMETER 1-2
MANAGEMENT’S MISSION, VISION AND VALUES
(Mission, Vision and Values)
The first Action in establishing an Enterprise Development Program is to record Management’s Mission, Vision and Values for the program as expressed in their goals, objectives, mandates, critical success factors, etc., concerning that program. (See Section 3.1.1)
Note: This pair and its following pairs (Table 6.5–6.6) explain important concerns and actions related to the management involvement in the earlier stages of program development.
Table 6.5 FR-(1-2-1) and DP-(1-2-1)
METHODOLOGY FUNCTIONAL REQUIREMENT 1-2-1EXPANSION OF ENTERPRISE REQUIREMENT STATEMENTS
(Expansion of MVV)
The high level statements of goals, objectives, mandates, etc., for the proposed Enterprise Development Program as developed by Enterprise Management are by their very nature, abstract and general. They must be supplemented by appropriate material from external sources for use in later stages of the Program Development Process. Thus they must be expanded and further detailed to be readily useful by program development personnel in planning the proposed project.
METHODOLOGY DESIGN PARAMETER 1-2-1
EXPANSION OF ENTERPRISE REQUIREMENTS STATEMENTS
(Developing Policies, Requirements and Tasks)
Further stages of the detailing of management’s expectations for the proposed Enterprise Development Program should involve the conversion of the high level statements into a set of Policies concerning the means and expected results of the execution of the final implemented program. Preparation of the set of Policies is then followed by the preparation of a set of Enterprise Functional Requirements capable of satisfying the set of Policies. The Functional Requirements in turn must then be converted into a set of Tasks capable of satisfying these Functional Requirements. At each stage of this detailing process the higher level information available must be supplemented by external information sources to assume completeness of the next stage of development. The following diagram models the actions involved (see Figure 6.3 and Section 3.1.1).
FIGURE 6.3 DEVELOPMENT OF ENTERPRISE REQUIREMENTS
Table 6.6 FR-(1-2-2) and DP-(1-2-2)
METHODOLOGY FUNCTIONAL REQUIREMENT 1-2-2GROUPING OF MANAGEMENT RELATED ACTIVITIES
(Grouping of Management Functions)
The activities described under Management Mission, Vision and Values and the Policies Development part of the Program must be collectively grouped together and named as a distinct part or Phase of the Overall Enterprise Development Program. This is because of their specific relationship to management functions as contrasted with later parts of the Program.
METHODOLOGY DESIGN PARAMETER 1-2-2
GROUPING OF MANAGEMENT RELATED ACTIVITIES
(Naming of Concept Phase)
The work described under Mission, Vision and Values and Policies can be described as the Concept Phase of the Enterprise Development Program. As noted under Methodology Design Parameter 1, this Phase would be followed by a Definition or Functional Analysis Phase. The Concept Phase comprises the topics above the dashed line on Figure 6.3 and the so-indicated region on Figures 3.1 and 3.18.
Table 6.7 FR-(1-3) and DP-(1-3)
METHODOLOGY FUNCTIONAL REQUIREMENT 1-3THE CLASSIFICATION AND FUNCTIONAL MODELING OF ENTERPRISE POLICIES, FUNCTIONAL REQUIREMENTS, AND TASKS
(Classifications of Policies, etc.)
The Policies, Functional Requirements and Tasks as developed under the previous Methodology Functional Requirement and Design Parameter pair must be able to be classified into a relatively small number of closely related Classes or Groups by using an appropriate criterion for such choice.
METHODOLOGY DESIGN PARAMETER 1-3
THE CLASSIFICATION AND FUNCTIONAL MODELING OF ENTERPRISE POLICIES, FUNCTIONAL REQUIREMENTS AND TASKS
(Control and Customer Service)
All of the Policies, Functional Requirements, Tasks, etc., carried out by an enterprise in its operation can be readily classified into two groups or classes:
1. Those related to the furthering of the well-being of the Enterprise, i.e., CONTROL of the enterprise’s operations in the broadest sense. These can also be expressed as Mission Support Tasks or Functions.
2. Those related to the accomplishment or fulfillment of the enterprise’s mission as established by management, i.e., those related to SERVICE to the Enterprise’s customers in supplying the goods and services needed by those customers.
(continue)
Table 6.7 (CONT.) FR-(1-3) and DP-(1-3)