USE OF THE PURDUE ENTERPRISE REFERENCE ARCHITECTURE AND METHODOLOGY IN
INDUSTRY
(THE FLUOR DANIEL EXAMPLE)
by
Gary A. Rathwell
Fluor Daniel, Inc.
Chicago, Illinois, USA
and
Theodore J. Williams
Purdue University
West Lafayette, Indiana, USA
ABSTRACT
The Fluor Daniel Company, a major engineering consulting and
construction firm, is applying the Purdue Enterprise Reference Architecture and
Methodology (PERA) to their project work.
They have established these methods across a range of industrial areas
which the company serves. They have
used PERA to present a framework around which much of their current work
practices can be organized. These will
be discussed in this paper.
In addition, application of this new technology upon their
existing practices and company culture has engendered the necessity of altering
the way in which PERA is presented to company and client personnel and
organizations who were not previously familiar with PERA. These changes are also discussed here.
KEYWORDS
Enterprise,
Enterprise Integration, Integration Methodologies, Architecture.
INTRODUCTION
Enterprise integration has
been a much promoted and debated technology in the United States and most other
advanced industrial countries over the last two decades. Originally proposed as computer integrated
manufacturing (CIM), it has recently been generally described as computer
integrated enterprises (CIE), or more commonly, simply as enterprise
integration.
The intuitively obvious, and therefore readily expected,
economic and productivity benefits of the process-wide, plant-wide, or
corporation-wide coordination of all operating variables have often proven to
be a will-of-the-wisp. This is a
consequence of the vast amount of detail and the extremely large number of
operational variables and plant operating factors which have to be considered
in such a project.
What is needed is a management and engineering technology which
can have the effect of “minimizing the apparent complexity”[1] of these
systems. It must also present an
intuitively correct and easy-to-follow methodology for unit, plant and company
engineering and operational design and planning. Only then can it accomplish the above tasks and attain the hoped
for goals of the endeavor. Many
attempts by various groups have been made to define this technology but so far
success still seems to elude the practitioners.
PERA [2] has recently been proposed as such a methodology and
one which appears to have major expectations for success where others have
failed. The Fluor Daniel Company has
been the major industrial partner to apply this technology to date. They have had considerable success, well
beyond that of earlier studies with other methodologies, and expect further
benefits as the technology pervades all aspects of their mission.
In selling the use of this technology internally, Fluor Daniel
has combined it with their previous common methods. In addition, they have modified the details of presentation of
PERA and thus its appearance, but not its content. This has greatly improved the degree and rate of acceptance of
this technology by their staff. This
paper will treat in detail the resulting combined methodology and the changes
made to improve its acceptability.
The new technology has been labeled the Fluor Daniel-PERA
methodology by the company.
BACKGROUND
Fluor Daniel, Inc., is a major engineering, procurement, and
construction company which serves clients in all types of industries, including
process and discrete manufacturing.
They also serve government telecommunications, highways, and other
“infrastructure” clients. Fluor
Daniel, Inc., is a member company of the Users Group on Architectures for
Enterprise Integration at Purdue University and thus is a participant in
the ongoing development of the Purdue Enterprise Reference Architecture and
Methodology. Purdue University’s
cooperation in the Users Group was carried out through the Purdue Laboratory
for Applied Industrial Control (PLAIC), an engineering unit engaged in
postgraduate research in the industrial control field, particularly
computer-based process and enterprise-wide control systems. Mr. Rathwell was the principal Fluor Daniel
representative to the Users Group.
Professor Williams served as Director of PLAIC.
The earliest work in PERA had been carried out by the
Industry-Purdue University Consortium for Computer Integrated Manufacturing
[1], a group of ten major process industry, control and computer companies
chartered to work together during the period 1989-92. The Users Group succeeded the Consortium with many of the same
members.
SELLING METHODS
Why Use the Fluor
Daniel-PERA Methodology?
Fluor Daniel personnel who were familiar with the Purdue
Enterprise Reference Architecture and the Purdue Methodology (PERA) believed it
to be important for their company for the following reasons:
1. It provided a full “life
cycle” for the facilities being developed in the company’s projects with its
clients.
2. It provides a means for
handling human and organizational factors inherent in these projects and in
Fluor Daniel’s approach to these projects.
3. It presents a “phased”
approach to reduce rework in carrying out projects.
4. It provides an understanding
of the dynamic interfaces between the many disciplines of engineering and
management working on a particular project.
5. It provides informational
models of each phase to improve understanding and to monitor the work in
progress.
6. Perhaps best of all, the PERA
diagram looks intuitively correct and presents the life history in a way which
follows the conception which most engineers and industry management have of
their plants and companies.
Each of these capabilities were more successful than the
corresponding ones available from previous methods or were entirely missing
from those earlier methodologies.
Some Subtle Changes Made in
the Presentation to Improve Acceptance
Figures 1 and 2 present the PERA Life Cycle as initially
developed by the Industry-Purdue University Consortium for CIM which originated
the PERA Methodology [1,2,3]. Figure 3
shows the Life Cycle Diagram divided into numbered blocks and nodes. This figure was accompanied in the PERA
documentation by an extensive table detailing the tasks required at each
numbered location, the models and tools available or needed for carrying out
each task and the deliverables to be produced as a result. This listing greatly expanded the brief
notations on Figure 2 and particularly those on the second page of Figure 2,
very valuable presentation but requiring considerable detail to present its
message. The above listing is not
included here for reasons of space requirements in this paper. It is included in the References [1,2,3].
Figure 4 shows the single sheet presentation of all of the above
material as eventually used by Fluor Daniel personnel in explaining the
architecture and its potential usefulness to their compatriots (both internal
company groups and external customers.
This was thus a major increase in convenience of reference for the user
over the previous Purdue documentation.
It should be remembered at this point that the Fluor Daniel
personnel making the presentations as well as the representative members of the
Industry-Purdue University Consortium and the Purdue University personnel who
developed the Purdue Methodology were all personnel with control and
information systems engineering backgrounds.
At first the Fluor Daniel presentations of PERA were met with a
“ho-hum” attitude from the listeners, most of whom were from other disciplines
than control and information systems.
(The lecturers were using modified versions of the Purdue prepared
materials (Figures 1, 2 and 3).) They
noticed this inattention and resolved to determine why such an important set of
materials (in their eyes) was so poorly received.
They correctly surmised (fortunately) that the problem was that
the listeners received this material as just another scheme to build up the
importance of the control area and not something that could be of very major
importance to every discipline in Fluor Daniel or their customers.
The answer to this problem, once identified, was simple. Just flip-flop the model (or framework) of
PERA so that the mission-fulfilling tasks (the customer product and services
functions) were on the viewer’s left and the information functions (data,
control and communications) were on the viewer’s right. Then PERA and the Purdue Methodology were
readily accepted as something of relevance to all! Compare Figure 4 with Figures 2 and 2 (continued).
This also meant that the
“left-to-right” order followed the sequence of the design steps. For example, during the Preliminary
Engineering Phase, one might design a tank and a pump (Item 10 of Figure 4)
which would be represented on the Piping & Instrumentation Diagram
(P&ID). The decision would then
follow that the operator would not manually run this pump since it needed to
start and stop every 5 minutes (Item 11).
And then the instrumentation to sense tank level and start the pump
would then be added to the P&ID (Item 12).
Thus two ways of “ordering” the PERA steps should be
considered. One is of priority of
importance or rank, and the other is of precedence in time. By reordering PERA it now fits the perceived
order of placement in both priority & precedence.
This perception is a result of the long-standing custom in
Western countries that the place of priority or precedence is up and/or to the
viewer’s left, and that the sequence will be from the top to bottom and left to
the right.
Think of a few examples!
1. National flags when displayed
in a group,
2. The medals on a soldier’s
uniform,
3. The guest of honor in a
receiving line,
4. The arrangement of the
elements in a Matrix.
Thus the non-control system
practitioners were, probably subconsciously, viewing the original PERA
presentation as somehow downplaying the importance of their own disciplines and
correspondingly glorifying the importance of the control field. This is especially significant when one
considers that information and control comprises only about 15% of the budget
of an industrial plant construction project, the rest being devoted directly to
mission fulfillment equipment and related items. Hence the reversal of perception when this small difficulty was
corrected.
Please note that the reversal of position of mission and
information tasks also entails a reshuffling of the assignment of the box
number description of tasks (see Figures 3 and 4 and related discussion) in the
separate phases. Information and
control tasks will now have the higher number of each group of three in each
phase rather than the lower as before.
The reasoning is the same as before in terms of acceptance.
The Purdue group had not noticed this before since their
audiences had almost always been those interested specifically in enterprise
integration or control systems.
INTEGRATION OF HUMAN AND ORGANIZATIONAL FACTORS
A singularly important contribution of the PERA Enterprise
Integration Reference Architecture has been its presentation of a very simple
yet again intuitively correct method for accounting for the place of the human
worker in any automated system. The
system works as listed in Table 1 and in the following discussion.
In order to show the true place of the human in the
implementation of the enterprise functions, we need to assign the appropriate
ones of these functions to the human element of the system. This can be done by considering the
functional tasks as grouped in three boxes in the preliminary engineering or
specification phase. These are
separated by defining and placing sets of three lines in the graphical
architecture representation. This
action will separate the two functional analysis streams into three as shown in
Figure 5 and thus assign the tasks or functions involved to the appropriate
boxes. The resulting boxes then define
the automated information tasks which become the Information Systems
Architecture functions and the automated manufacturing tasks which become the
Manufacturing Equipment Architecture functions. The remainder (non-automated) become the functions carried out by
humans as the Human and Organizational Architecture,
There is the line called the Automatability Line which shows the
absolute extent of pure technologies in their capability to actually automate
the tasks and functions of the Enterprise Integration system of the Enterprise
Integration Business Entity. It is
limited by the fact that many tasks and functions require human innovation,
etc., and cannot be automated with presently available technology.
There is another line which can be called the Humanizability
Line (see Figure 5) which shows the maximum extent to which humans can be used
to actually implement the tasks and functions of the Enterprise Integration
system of the Enterprise Integration Business Entity. It is limited by human abilities in speed of response, breadth of
comprehension, range of vision, physical strength, etc.
Still a third line is presented which can be called the Extent
of Automation Line (see Figure 5) which shows the actual degree of automation
carried out or planned in the subject Enterprise Integration system. Therefore, it is the one which actually
defines in Figure 5 the boundary between the Human and Organizational
Architecture and the Information Systems Architecture on the one hand, and the
boundary between the Human and Organization Architecture and the Manufacturing
Equipment Architecture on the other side.
The location of the Extent of Automation Line has
• Economic
• Political
• Social
-- Customs
-- Laws & Directives
-- Union Rules
as well as Technological
factors in its determination of the ultimate split of functions between humans
and machines. This is the line actually
implemented in the Implementation Region of the Purdue Architecture.
The Automatability Line showing the limits of technology in
achieving automation will always be outside of the Extent of Automation Line
with respect to the automation actually installed (see Figure 5). That is, not all of the technological
capacity for automation is ever utilized in any installation for various
reasons. Thus, the Human and
Organizational Architecture is larger (i.e., more tasks or functions) and the
Information System and Manufacturing Equipment Architecture are smaller (less
functions) than technological capability alone would allow or require.
Note that for a completely automated plant as an extreme case,
both the Automatability Line and the Extent of Automation Line would coalesce
together and move to the left edge of the Information Architecture block and
correspondingly to the right edge of the Manufacturing Architecture block. Therefore, the Human and Organizational
Architecture would disappear and the Information Systems Architecture and the
Manufacturing Equipment Architecture would coincide with the unmanned
Information Architecture and the unmanned Manufacturing Architecture,
respectively. Note that Figure 5 uses
the Fluor Daniel form of the PERA diagram, i.e., Enterprise Mission aspects are
placed in the left (Figure 4), as well as succeeding figures.
Fluor Daniel used the above discussion to emphasize several
rules of project developed procedure as shown in Figure 6.
The Fluor Daniel training sessions also emphasized the state of
knowledge of Human and Organizational factors and that this resulting lack
requires that special attention be given to this area by project management to
assure success. Figure 7 shows this.
THE IMPORTANCE OF A PHASED APPROACH
Figure 8 and the following discussion of the Purdue phased
approach and its academic justification allowed Fluor Daniel to emphasize a
similar approach to the organization of their project work. Purdue had used the Axioms of Engineering
Design developed by Professor Nam Suh [4,5] to show the correctness of PERA as
an engineering design. Fluor Daniel
applied the same axioms to their project management. These are shown in Figure 9.
Suh’s work also carried several corollaries to the axioms. These readily show the impact of late
modifications to scope or equipment specifications of the project and the need
for early and firm project decisions.
This is dramatically illustrated by Figures 10 and 11. Figure 12 also shows how project work can
become “unstable” if too many changes are made too quickly and late in the
project.
INTERFACES
Purdue had also done considerable work to define and analyze the
interfaces that occur in an enterprise engineering project not only between the
individual task modules involved but also within and between the phases of the
engineering project as shown by the PERA architecture.
Again, the Fluor Daniel staff took advantage of this information
to teach the behavior of their project performance factors and propose
methodologies which would avoid the resulting problems. They also took advantage of opportunities
uncovered by this information. Some of
this is already shown in Figures 8-10.
Figures 11-14 emphasize the importance of considering each and all of
these interfaces and their effects on the project and on the resulting plant
and its performance. Figures 16 and 17
summarize the requirements for the good project practices developed from this.
THE FLUOR DANIEL WORKBENCH
As noted, the lengthy table which accompanied Figure 3 in the
Purdue documentation of PERA (not reproduced here) presented an extensive list
of the assignments of tasks, models of the tasks and their interconnections,
tools to carry out these tasks, and the interfaces between tasks and phases
throughout the enterprise development and operational life history.
Fluor Daniel already had a large stable of engineering
procedures and tools to carry out most of this work, much of it computerized
and interconnected with a massive company-wide database of tools,
specifications, procedures, report formats, etc. The PERA outline gave them an excellent new mechanism for
organizing, categorizing, and teaching the technology to their company and
client personnel. Figures 18 and 19
present two aspects of what is a massive teaching and operational capability
now being set up and used in Fluor Daniel known as the Fluor Daniel Engineering
Workbench. As can be seen, the PERA
Diagram and the associated Methodology have been of major help in this effort.
LESSONS FOR MANAGEMENT
The PERA technology has not only been of use to Fluor Daniel’s
engineering and construction groups but it can also be used to help management
in their future planning and decision making.
Figure 20 illustrates this point.
Fluor Daniel’s management had prided themselves on the company’s
excellence in and concentration on the area of the Detailed Design of plants
and their equipment. This is Block 13
on Figure 20. However, Figure 20 points
out that the downsizing which is occurring in many of their customer companies
has created an opportunity to branch out into the other areas of project
management, even into the operations phase.
In addition, there are also major opportunities in the other areas and
phases not now completely exploited by Fluor Daniel which could also be
important in their future planning.
SUMMARY
This paper has presented a review of some of the ways in which
Fluor Daniel, Inc., has used the Purdue Enterprise Reference Architecture and
Purdue Methodology (PERA) to form the basis for organizing their own project
execution and project management tools and system to be one integrated whole.
The ways which they used to slightly modify the presentation of
PERA to greatly increase its rate of acceptance by those of their employees in
engineering disciplines other than automatic control are most noteworthy. Similar methods might be used by many other
groups.
Most other major developments associated with PERA such as the
Axioms of Engineering Design, the study of Interfaces, etc., have also been
incorporated into the Fluor Daniel system with major benefits as a result.
It should be appreciated that all of the changes described here
have been cosmetic, i.e., changes in wording, arrangement of figures, etc., to
satisfy discipline and cultural preferences of the prospective users. There have been no changes in the technology
expressed by PERA or the concepts involved.
Nevertheless, it must also be appreciated that these
modifications, cosmetic as they may be, can have a profound effect on the
degree and rate of acceptance by others of these technologies.
REFERENCES
1. Industry-University Consortium, Purdue
Laboratory for Applied Industrial Control, An Implementation Procedures
Manual for Developing Master Plans for Computer Integrated Manufacturing,
Report Number 155, Purdue Laboratory for Applied Industrial Control, Purdue
University, West Lafayette, Indiana (June 1992).
2. Williams, T.J., and the Members of the
Industry-Purdue University Consortium for CIM, The Purdue Enterprise
Reference Architecture, Technical Report 154, Purdue Laboratory for Applied
Industrial Control, Purdue University, West Lafayette, Indiana (December
1991). Also published as: Williams, T.J., The Purdue Enterprise
Reference Architecture, Instrument Society of America, Research Triangle
Park, North Carolina (1992).
3. Li, Hong, A Formalization and Extension of
the Purdue Enterprise Reference Architecture and the Purdue Methodology,
Ph.D. Thesis, Purdue University, West Lafayette, Indiana (December 1994). Also published as: Li, Hong, and Williams, T.J., A Formalization and Extension of
the Purdue Enterprise Reference Architecture and the Purdue Methodology,
Technical Report 158, Purdue Laboratory for Applied Industrial Control, Purdue
University, West Lafayette, Indiana (December 1994).
4. Suh, N.P., The Principles of Design,
Oxford University Press (1990).
5. Suh, N.P., and Sekimoto, Shinya, “Design of
Thinking Design Machine,” Annuals of the CIRP, Vol. 39, pp. 145-170
(1990).