1.4 The Connection Between idef5 and Other Methods

As Mr. John Zachman in his seminal work on information systems architecture observed, “...

there is not an architecture, but a set of architectural representations. One is not right and another

wrong. The architectures are different. They are additive, complementary. There are reasons for

electing to expend the resources for developing each architectural representation. And, there are

risks associated with not developing any one of the architectural representations.” [Zachman 87]

Consistent, reliable creation of correct architectural representations, whether artificial approximations

of a system (models) or purely descriptive representations, requires the use of a guiding

method. These observations underscore the need for many “architectural representations,” and

correspondingly, many methods.

Typically, methods, and their associated architectural representations, focus on a limited set of

system characteristics and explicitly ignore those that are not directly pertinent to the task at

hand. Thus, IDEFØ provides a compact, yet surprisingly powerful, conceptual universe for

modeling business activities; for all its power, however, it would be highly inconvenient, if

possible at all, to use it to design a relational database; IDEF1X is the method that is optimized

for that task. Similarly, IDEFØ explicitly excludes temporal information, and limits what can be

represented about temporal relations that hold between business activities, as well as the objects

involved in the internal structure of those activities. These exclusions are what give IDEFØ its

power in modeling business activities. For in a method design as in a programming language

design, what distinguishes a well designed effective method is what is left out more so than what

is left in. IDEF3, on the other hand, includes explicit representations of processes, time intervals,

and temporal relations and, hence, is ideally suited for expressing information about timing and

sequencing; it also includes the capacity to express arbitrary information about the individuals

participating in those processes. It lacks, however, the specialized representations of IDEFØ and,

therefore, information that IDEFØ expresses with great ease and simplicity is, by comparison,

expressed only awkwardly in IDEF3.

The connection between these methods and IDEF5 is rather straightforward. Of the methods just

mentioned, the IDEF5 schematic language is perhaps closest to IDEF1 and IDEF1X. However,

the connection between IDEF1/1X and IDEF5 is analogous to that between IDEFØ and IDEF3.

The information in an IDEF1 or IDEF1X model could in principle be expressed in the IDEF5

elaboration language. However, because it does not contain the well-designed, specialized

11

representations of IDEF1/1X, it would be exceedingly cumbersome in IDEF5 to design a

relational database, for example. But the expressive power of IDEF1/1X soon reaches its limits

and, hence, could not possibly do all that is expected of a general ontology language. (For a

more detailed comparison of IDEF1/1X and IDEF5, see Subsection 2.4.)

In a sense, the designs of both IDEF3 and IDEF5 break the traditional mold according to which

methods are purposely designed with limited expressive power. The elaboration languages of

both methods are full first-order languages (and more besides) and, hence, are capable of

expressing most any information that might need to be recorded in a given domain. This break

with tradition not only reflects the need for greater expressive power, but also reflects the

development and increased utilization of more intelligent tools and automated, model-driven

systems in business and engineering. Intelligent tools and model-driven systems generally must

manipulate much richer forms of information than can be expressed in a traditional method. This

motivates the design of richer methods that have the capacity to represent and organize such

information, methods that are not restricted to pencil and paper form and, hence, which truly

augment the ability of human agents to create, manage, and reuse a richer store of knowledge.

For the reasons above, these newer methods will not make the older, more restricted methods

obsolete; the ability to filter and structure information relative to certain well-defined tasks will

still be very useful. At the same time, the greater demands of intelligent tools and model-driven

systems will require more.

The broader vision that guides these newer methods is one in which all system definition

information is stored in a global (albeit perhaps virtual) repository of information, with modeling

methodologies providing different views that filter the information in various useful ways

relative to the task at hand. When the task at hand is the general nature of the domain in which

the system operates, the ontology capture method will provide the appropriate perspective. The

next tier in the vision is for all organizations — within the bounds of their proprietary interests

— to have ontologies of their various component systems available for sharing and reuse.

IDEF5 is being developed in the belief that it can contribute in a vital way to the realization of

this vision of global knowledge sharing.

12