By Ed Johnson © 2008-2010

 (Business Process Trends, www.BPTrends.com, published a version of this perspective in July, 2008.)

The data model of an enterprise and any process model of the same enterprise will differ in purpose and form, yet the models must complement each other.  That's because, in reality, every enterprise embodies but two intrinsic and inseparable facets: structure and behavior.

By the enterprise data model, the enterprise is made up of things related through happenings that can occur, do occur, or did occur between the things.  Every thing relates to at least one other thing and there are no free-standing “islands” of things.  Moreover, the qualities of all individual happenings that relate things conspire more so than the things themselves to define for the enterprise a structural flexibility between, for example, brittle and sturdy in the face of change or disturbance.  Thus the data model of the enterprise amounts to a definition of fully integrated enterprise structure.

A particular thing may be soft or hard, tangible or intangible, cognitive or physical, social or technical.  Two things related will suggest a particular kind of happening.  For example, in “executive formulates strategy,” the action word “formulates” suggests a cognition-oriented happening in the enterprise strategic planning space.  In “company builds hotels,” the action word “builds” suggests a construction-oriented happening in the enterprise asset acquisitioning space.  And in “company lodges travelers,” the action word “lodges” suggests a service-oriented happening in the enterprise transacting space.  Thus enterprise structure comprises various kinds of things that are, in reality, fully integrated through happenings.

By an enterprise process model, the enterprise is made up of happenings related through things consumed, produced, used, and that govern happenings.  Every happening functions interdependently with at least one other happening, which together constitute a bigger, more complex happening.  Here, too, there are no free-standing “islands” of happenings.  Moreover, the qualities of individual things that relate happenings conspire more so than the happenings themselves to define for the enterprise a behavioral agility between, for example, awkward and nimble in the face of change or disturbance.  Thus the process model of the enterprise amounts to a definition of fully integrated enterprise behavior.

Every happening produces two general types of things with respect to particular aims or intentions: things wanted and things unwanted (i.e., waste).  Wanted and unwanted things produced are not always mutually exclusive and may, in fact, reflect a qualitative continuum (e.g., customer satisfaction).  Unwanted things produced by one happening generally become things wanted by another happening. 

Every thing that exists is a consequence of a happening, whether soft or hard, tangible or intangible, cognitive or physical, social or technical.  Moreover, enterprise behavior is governed by, responsive to, constrained by, and occurs interdependently with its environment.  Various things, including feedback, enter the enterprise from its environment, and the enterprise puts various things into its environment.  So, perceived from its environment—that is, the external world—the enterprise is one big happening, perhaps strongly associated with a brand identity.

Note that in order to make certain things knowable requires detection and measuring processes.  A few examples: a process that measures electrical resistance using an ohmmeter; a process that measures, widely, customer satisfaction using a survey; and, a process that measures process health (i.e., entropy or state of chaos) using statistical process control.

In a sense, the data model of the enterprise is like one side of a coin and a process model of the enterprise is like the other side of the coin.  Seen from either side, the coin is recognizable as the same coin—say, a quarter.  Similarly, an enterprise seen through the enterprise data model and through an enterprise process model must be recognizable as the same enterprise—say, K-12 public education.  Thus the enterprise data model and an enterprise process model have equal standing; neither stands inherently more important than the other.

Recognize here that since data are but one type of thing, "data model" is a misnomer, typically born of how IT organizations generally perceive the enterprise in terms of data requirements scoped for a particular IT solution.  The reality that many varied types of things make up the fully integrated enterprise structure often escapes the prevailing IT analysis paradigm.  Because it does, and because “enterprise things model” seems too rough a term, use of the terms "data model" and "data modeling" will continue in what follows for the sake of familiarity.

Although the IT organization within the enterprise typically performs data modeling and process modeling of the enterprise, there is no fundamental reason for this, except for the prevailing IT analysis paradigm that attracts proponents of certain popular and emerging algorithmic diagramming techniques implemented in computer software.  The usual deeply rooted cognitive consequence is the continual promotion of modeling the enterprise with reductionistic and mechanistic paradigms to the exclusion of doing so with synthetic and organic paradigms.  Alone, reductionistic and mechanistic paradigms facilitate the proliferation of disparate IT solutions that contribute to sub-optimizing enterprise capability to deliver quality business value to stakeholders.

The time-tested modeling methods today known as Integration Definition (IDEF, pronounced eye-def) have long shown being well-suited to facilitate modeling the enterprise with appropriate paradigms, so as to contribute to realizing optimized and sustainable enterprise capability to deliver quality business value to stakeholders.

While several IDEF methods have come on the scene, the earliest two remain essential to modeling the enterprise data-wise and process-wise.  For enterprise data modeling, there is Integration Definition for Information Modeling, Extended, commonly known simply as IDEF1X.  For process modeling, there is Integration Definition for Function Modeling, commonly known simply as IDEF0.

Both IDEF0 and IDEF1X were first published in the public domain during the early to mid 1980s and have remained nonproprietary.  Early IDEF practice made use of pencil-and-paper, as the personal computer equipped with a graphical user interface and a pointing device had yet to arrive.  Even after the personal computer so configured did arrive, pencil-and-paper has remained a viable means of IDEF practice because of its simple (not simplistic) yet powerfully expressive box-and-arrow graphical language—syntax and grammar—that invites sharper perceptions of reality and clearer and deeper holistic thinking.  Even today, the IDEF-savvy business executive can express his or her thinking as an IDEF model “on the back of the envelope" quite easily.

Just as enterprise happenings and things are complementary, so are IDEF0 and IDEF1X.  Each method provides a system of concepts, pragmatics, and a simple yet powerful, virtually self-evident graphical language born of well-defined rules of syntax and grammar for rigorously authoring well-defined models of the enterprise.  This modeling capability extends, in fact, to modeling any systems within the ranges from atomic to cosmological, from social to technical, from natural to man-made, and of course from manufacturing to service.

In contrast, eclectic, symbol-laden, feature-rich, algorithmic “flow diagram” techniques [1] force IT solution-oriented considerations and activities, right away.  These techniques also tend to quickly break down or to incite inventiveness in the face of highly dynamic processes to the extent of declaring such processes have no output.  IDEF0, however, helps one to know then to represent that every process produces something regardless of the kind of process.

In 1993, the U.S. Commerce Department, National Institute of Standards and Technology (NIST) made both IDEF0 and IDEF1X Federal Information Processing Standards.  Both are favored for their simple yet rigorous methods for modeling the two intrinsic and inseparable facets of the enterprise—again, structure and behavior—to facilitate optimizing enterprise capability to deliver quality business value to stakeholders.  Necessarily, the quality of enterprise structure and the quality of enterprise behavior interact to determine that capability.

Recognizing the modeler's role in enterprise modeling, the IDEF methods provide essentially the same iterative modeling process for both data modeling and process modeling that happen to be consistent with Plan-Do-Study-Act (PDSA) cycles of continual quality improvement: 

• Recognize some essential questions needing answers
• Establish model purpose and viewpoint
• Engage appropriate business experts and expertise
• Elicit, abstract, and model enterprise knowledge about things and happenings
• Validate model among experts, including those involved with related happenings
• Iterate prior steps with feedback until essential questions become answerable

The aim of a particular IDEF0 process modeling or IDEF1X data modeling effort of the enterprise is not to design the enterprise; the enterprise already exists.  Neither is the aim necessarily to gather and model design requirements for an IT solution.  The aim is to define and communicate the business of the enterprise, as is, should be, or to be, so as to facilitate enterprise improvement.  Adherence to the aim contributes to authoring enterprise models that communicate at all organizational levels.  Subsequently, stakeholders can become better able to align their individual mental models toward the enterprise purpose, vision, goals, and missions.

Then when particular IT requirements arise, solutions to meet the requirements become highly economically derivable with the usage of common IDEF models of the enterprise.  Thus the IDEF models of the enterprise must never be compromised for IT convenience.

The reason is simple, and important: the enterprise must continually know its definition versus implementations of its definition.  This is important because of the ever-present need to sustain optimal enterprise capability to deliver quality business value to stakeholders.  The IDEF methods are powerful enough, yet simple enough for modeling and communicating the definition of the enterprise as well as the implementations of the enterprise to all stakeholders.***

Ed Johnson consults as Quality Information Solutions, Inc., with a commitment to human social and cultural systems to receive quality information from information systems for the continual improvement of life, work, and play.  His commitment extends to advocating the transformation of K-12 public education systems to humanistic paradigms from prevailing mechanistic paradigms.  Ed also is former president of Atlanta Area Deming Study Group.

Copyright © 2008-2010 Quality Information Solutions, Inc.  All rights reserved.  This material may be copied in whole or in part, provided the source is cited.

[1] It is worthwhile to observe that UML, Unified Modeling Language, provides roughly twice as many "major" symbols as does the English language, which provides 26 alphabet symbols, A-Z.  The roughly 50 UML major symbols do not include the numerous variations of those symbols.  By comparison, the IDEF methods provide just two "box and arrow" symbols, a few variations of those symbols, and a well-defined, easily learned syntax and grammar for combining the symbols and text.  These qualities make the IDEF methods eminently more practical and cost-effective for enterprise-wide use.  Moreover, in spite of “having been around” since the early 1980s, the IDEF methods allow for incorporating all manner of displays, exhibits, and diagrams, including UML diagrams and even BPMN diagrams.