James G. Nell
National Institute of Standards and Technology; Bldg. 220, Rm. A127, Gaithersburg MD, USA 20899
+1 301 975 5748 (V), +1 301 258 9749 (F), nell@nist.gov
Abstract
This paper presents an analysis of what it means
for an enterprise to be integrated, what enterprises are really
trying to achieve by integrating their processes, what is really
going on among their processes, and how integration may, or may
not, change that. Some approaches to analyzing enterprise operation
are discussed.
With an idea about how an enterprise really operates,
the paper proposes a standards-making philosophy that will improve
enterprise operations. The purpose is to create a standardization
strategy for integration that matches the operating enterprise.
If that is not done, the effort to produce the standards largely
will be wasted. This is because an ill-conceived standards strategy
will not alter the way enterprises actually operate at the activity
level. Finally, there is a suggestion that, perhaps, enterprise-integration-related
standards are in a category different from the usual standards
for hardware, software, and protocols. Because these standards
affect the entire enterprise, and even interacting enterprises,
they are more in the category of horizontal standards such as
quality and environmental standards.
Key words: Enterprise integration, information technology,
standards, strategic-standardization management, horizontal standards.
1 Operating Enterprises
Enterprise integration is an improvement concept,
as are total quality and error-free performance. These concepts
have proven to be very difficult to implement successfully because
the desired degree of improvement is difficult to achieve. One
part of the difficulty lies in the sheer complexity of changing
almost every sector of the business to achieve whatever goal is
set. Another part of the difficulty is in assigning metrics to
measure progress. Still another part is due to the fact that these
concepts do not refer to singularities. Any evaluation of progress
is only a glimpse or a snapshot in a continuous stream of mini-improvements
that happens over a period of many years. Management has been
trying for better quality, higher reliability, and better communication
ever since there has been business for profit. There is always
room for improvement when considering quality, reliability, and
communication among engineering, manufacturing, suppliers, and
customers.
Enterprise integration has similar characteristics.
Success is conditional in that it involves technological improvement,
revising some principles, and the presence of a compatible infrastructure.
Enterprise integration also requires a compatible infrastructure
in other organizations, so that the objective of the investment
is fully utilized. However, two businesses probably would not
invest in synchronism, for many reasons. If compatible infrastructure
does not exist, the investments in the improvements in one enterprise
are difficult to justify. Also, management finds that it is very
difficult to translate these investments into some incremental
improvement in specific business-improvement strategies, such
as lower product cost, lower cycle time, and higher quality.
On the other hand, some businesses have invested
to overcome integration barriers, and have achieved their integration,
cost, and quality goals and there was enormous improvement. The
products were produced correctly, the first time, on time, but
at such a low cost that the facilities and people that were required
in the old system were no longer cost effective and justifiable.
Their reaction to having underutilized resources was not positive.
The solution was to undo the improvement, lose a facility, and
terminate people, rather than change old attitudes and management
metrics! In these situations, applying technology and meeting
cost and quality goals are necessary but not sufficient for success
because the enterprise could not overcome the old corporate culture.
These cultural attitudes must be kept in mind when analyzing how
enterprises really operate.
Even with the barriers there exists in industry
an eagerness to achieve the benefits implied by the words enterprise
integration, but with a hesitancy to invest in it. A lot of
money has been invested in the past with little perceived results.
But, since enterprise integration is a continuum, rather than
a specific, singular goal, and since the task is so large and
so enterprise wide, the incremental improvements that have been
made are largely unappreciated.
In a typical scenario, enterprises evaluate their
needs, establish their character, and set goals to achieve market
aspirations at an executive-level function often called strategic
planning. The enterprise is a set of processes and infrastructure
consisting of systems that employ certain technologies. If new
needs and goals require new or upgraded systems or processes,
and if there is a limited amount of financial means to acquire
new capability, then a trade-off analysis will assign priorities,
and investments will be made accordingly. There are hundreds of
choices that could be made. If we multiply this one scenario by
all of the enterprises that are making the same kind of decision
there is a very low probability that any two enterprises will
have invested the same amounts of money on the same improvements
at the same time. Their infrastructure improvements and process
improvements will evolve at different rates. Therefore, what results
are many enterprises with sets of processes and infrastructure
that are not interchangeable, not interoperable, or at the same
level of process granularity.
This is also true of organizational functions
within a single enterprise [NELL96]. Businesses typically consist
of groups, divisions, departments, and sections. Somewhere in
that hierarchy the organization becomes function oriented and
the executive establishes incentives to subordinate managers to
reduce the costs of their function. When that happens there is
no advantage to doing things for the benefit of the enterprise
because the resulting process and infrastructure improvements
tend to suboptimize and even conflict with similar investments
in other departments. This is a cultural problem that will exist
whether or not there are standards recommending otherwise. Enterprises
are therefore not able to migrate toward one another. The fact
that enterprises or processes do not share information well is
not surprising.
Enterprises say that they wish to be integrated.
What does this mean really? It may mean to an enterprise that
has tried to integrate, that management is disenchanted with the
integration process and has a greater reluctance to invest in
integration technologies. Often, managers fail to see in the above
scenario that integration is neither a one-time activity, nor
a singular achievement, nor a final state. There are hundreds
of areas to change that will achieve an improved degree of integration,
and there is not enough money to do it all. Even if the money
were there and the investment made, there would be a better solution
shortly after the investment because technology will not stop
advancing. As commerce becomes more global, and there is need
to interact with offshore partners as well as domestic partners,
the problem compounds because decisions made within one enterprise
often do not coincide with the decisions made in other enterprises.
To produce an output, an enterprise or a process
usually needs to work with another enterprise or process. To
work with can mean several things. Materials and tools need
to get there. Parts and components need to get there. Physical
things need to exit. Timing is important. In addition, triggering,
instructions, controls, intended and actual output, verification,
and many other things require that a significant amount of information
flows into, and out of, the process. Here is where the going becomes
difficult. Judgement enters the process and the possibility of
misunderstanding, or miscommunicating, is possible. In fact, miscommunication
is probable and to establish a smoothly running system of processes,
methods to resolve the miscommunications must be planned into
enterprise operation.
The plan to resolve the miscommunications can
take several tracks, but two or three seem to predominate. The
first has to do with changing the world by prescribing that all
of the hardware and software shall be from the same manufacturer
to prevent miscommunications. This approach rarely works because
the communications come from people in the enterprise, not from
the hardware and software. A related approach is to force all
of the possible interactions into a predetermined set of instructions,
queries, and responses. It is very difficult to, a priori, prescribe
all the possible instructions, queries, and responses. As a result
the software engineers are continuously busy adding code to the
process software until the system is too ponderous to be reasonably
productive. Often in this model the solutions are legislated,
in effect, by developing top-down, enterprise-specific standards
that must be uniformly adapted by all processes, planned and existing,
that contribute to enterprise output. Everyone must be on the
same version of the same standard, or provide some kind of conversion
or translators; that is, insuring forward and backward compatibility.
This may work better for some areas of the information-technology
domain than in other areas.
Another way to approach this problem of communication
is to analyze how communications have been handled in the past,
before computers, and realize that humans negotiated understanding
through repeated questions and clarifications. One of the problems
in the enterprise-integration domain is that humans and computers
must interact and that their "brains" think differently.
So far, the solution has been to make humans interact with computer
systems on the computer's terms rather that making computers interact
on human terms. People really need smarter computers not faster
ones. On a computer's terms all communication must be in precise
language and entered through the human machine interface without
a single error. Well, humans just do not work that way. Humans
tend to create, tinker, modify, and innovate--an iterative process
toward some goal.
So, using the humans-only model, what must happen
to assure proper information flow? Proper information has been
flowing between processes for hundreds of years--or else manufacturing
enterprises would have produced no products. Factory communications
among humans will involve a minimum of words and a lot of common-sense
information that is taken for granted in human discourse. When
an engineer hands a drawing of a part to someone in operations
to have the part built, the drawing contains symbols referring
to the part, but the amount of information on the drawing is very
small compared to the amount of information that is transferred
(implied and inferred). Most of the information transferred is
implicit in the everyday knowledge that humans bring to bear.
This is in addition to the expertise that is shared among humans.
The expertise, acquired from formal education and experience,
enables the human element within the two processes to imply and
infer what they need from the information that is contained in
the symbols on the drawing, as well as the from information that
is not there.
However, in the human-driven processes, there
is always an opportunity for additional transfer of information
that completes the information exchange. This is the information
in the oral question-and-answer negotiation that precedes complete
understanding during the inter-process transfer. When a receiving
process, such as an operations person, completely understands
the concept intended by a sending person, such as a design engineer,
a kind of process integration has occurred. This integration will
recur, one process at a time, through the product-life history.
Enterprise integrators are trying to use information-technology
tools to improve interprocess interactions; that is, make the
information interchange repeatable, faster, more accurate, and
computer sensible. Perhaps there is a software model that will
achieve necessary integration, improve on the human interactions,
but not require a top-down or up-front, complete, and error-free
definition in computer terms.
It is possible to achieve lights-out factories
and totally automatic processes. However these phenomena are usually
an extension of a human-driven enterprise someplace and are a
very small part of the life history of a product. Until major
parts of a product-life history can be automated, enterprises
and a majority of the processes will act largely as if humans
were communicating. If this were the case it would not be productive
to assume the enterprise runs as if it were totally automated.
Negotiation of some aspect of inter-process communications will
be the rule rather than the exception. With the enterprise viewed
this way it may be more useful to create a strategy for a more
automated enterprise to accommodate this reality, rather than
to assume that another standards model is better because it reflects
the way analysts wish the enterprise were. The necessary interprocess
transactions will require the hardware to be physically compatible,
the software to interact predictably, the communications protocols
to be usable jointly, and the information to be mutually understandable.
Achieving this will require a delicate balance of human planning,
technology, and a properly designed standards strategy. There
also will have to be a mechanism to allow an enterprise to have
an internally designed architecture that allows the processes
to negotiate the best way to interoperate, among themselves, in
a standard way, using standard infrastructure elements.
2 Standardization
Having determined how enterprises will operate and
produce an output, one can analyze how to design a system of realistic
standards to boost process interoperability without stifling technology
development and technology insertion. This standards view will
involve a standards system that will allow enterprises to operate,
change, and grow; and it will improve operations rather than hinder
them.
To determine the standards that are necessary
depends on existing technology and the standards that are in use
[NELL96]. The analysis will be aided by first developing a set
of enterprise models. The models should show:
Even with all of that defined, the business rules
must be compatible, government regulations for commerce must be
agreeable, and the people of the enterprise must truly want integration.
This does not mean to suggest that the idea of a standard enterprise
is realistic. Businesses must be free to design the enterprise
of their choice, and with this freedom acceptable integration
still must be achievable.
The issue of what things should be standardized
and what should be good software design is difficult because the
resolution lies in a range between having a few low-level standards
and constraining everything with standards. Often the easiest
and least-effective solution to a computer-compatibility problem
is to standardize everything; the models, the modeling, the tools,
and the processes. The loss of user delight, the loss of opportunity
to use tools especially designed for the job, and the lost opportunity
for technological improvement are enormous. It would stay that
way because standards always seem to consume more time to develop
than does the technology that standards are attempting to constrain.
Shortening the time it takes to make standards is not necessarily
a good idea. Imagine a world with many easily and hastily constructed
standards that are ill-conceived in their development.
Properly modeling the enterprise will allow more
consistent modularization so that enterprises can effectively
plug-and-play their processes. The models will ameliorate
the need to develop the entire system at one time. Simulation
will be possible allowing one to evaluate interoperation among
interenterprise entities and to evaluate systems with differing
granularity. Enterprises will be able to plan migration paths
more effectively. Information should be a separate asset, so that
changing applications will be possible without re-entering information
about the products and processes unnecessarily. Enterprises can
define paths using standards and enterprise models to make the
product and process information tie logically into enterprise
goals, strategies, capabilities, and business rules. The models
and standards should be scalable so that a high-level model is
essentially the same as a lower-level model; that is, they should
use the same or compatible modeling constructs for all levels.
Rather than setting specific limits to everything,
such a standards set should be designed to force enterprises to
analyze and document, perhaps electronically on-line, what they
do; and then operate their enterprise accordingly. Lower-level
standards would still define interfaces and the supplying process
would indicate which standards apply for that particular communication.
They would also share, on-line, the set of information they need
to know about their processes. This way, an enterprise shopping
for a process would be able to evaluate, on-line, that a process
meets both quality and integration guidelines and that they conform
to listed interface standards. The process in the shopping enterprise
could then make any needed adjustments to itself and to the appropriate
enterprise model (function, hardware, software, communication,
and information), establish a relationship, and operate in an
acceptable (to both parties) level of integration.
Are there special standards required to enable
virtual enterprises? A virtual enterprise, or an extended enterprise,
is an enterprise--not really different from a traditional enterprise
other than the fact that it can append and shed processes quickly.
There are more legal and regulatory issues than technical issues
when removing barriers to virtual-enterprise operations. Technically
the standards categories involved are the same: hardware, software,
communications, information, and architecture. The notion of virtual
enterprise brings in a time element such that the enterprise can
form or dissolve very quickly. To accomplish this, standards other
than just technical ones must be in place. A virtual-enterprise
candidate may have to negotiate such contracts as a basic-ordering
agreement in advance of considering such an alliance. Collaborating
enterprises must resolve other things in a generic sense long
before true virtual-enterprise commerce can succeed. Eventual
parties comprising the enterprise will probably pre-define the
following, currently often locally unique: financial standards,
environmental-impact standards, markup language, safety requirements,
statutes, product liability, quality, and organizational requirements.
Standardizing the enterprises, parts of the enterprise,
the products, the information transferred, and the processes,
is probably not going to be a productive use of standard-making
resources. What seems more useful is to standardize the interfaces,
the nomenclature, and the formats and allow the enterprise-tool
builders to use these standards to design software in such a way
as to allow the processes to communicate.
3 Strategic Standardization
What is the best way to employ standards in an enterprise?
Many executives feel that funding standards development is a non-value-added
activity, and that paying extra money to have standards incorporated
in the tools they buy is an increase in process cost. They feel
that both are a cost of doing business and this cost should be
minimized [HOW96]. This could be a valid course of action for
enterprises that plan to maintain control of all processes that
produce their product, sell their product locally, and face limited
competition. Enterprises that plan to produce and market their
product globally may take a different view.
For the global enterprise a better approach to
planning for standards may be to include standardization as a
component of their strategy [BET95]. These enterprises would be
planning to operate on a more global basis, planning to compete
more effectively in a new market, seeking to expand their market
or their competitive position, and seeking ways to protect significant
investment in rapidly changing technology. These investments could
be in their manufacturing facilities, quality assurance and environmental
impact policies and procedures, and process-interoperability plans.
The goal of strategic standardization is to see how certain standards
would help the enterprise better fulfil its mission. One or more
of these strategies could be invalid or prohibitively difficult
and expensive if, at the same time, the company did not investigate
ways to mitigate barriers that could impede success because sufficient
attention was not paid to standards. Analyzing these strategies
properly can indicate marketing opportunities or probable cost
saving. Cost saving could come from leverage achieved through
working with others to achieve a shared advantage in some area
of commerce; either to improve infrastructure, process interoperability,
or the operation of virtual (or extended) enterprises. The marketing
opportunities would arise from government or trading-bloc requirements
to require quality, environmental, and/or recycling standards
as a hurdle-of-entry into that market.
In applying strategic-standardization management,
the standards-investment decision becomes a strategic one for
the enterprise rather than a tactical one for the process. Planners
must evaluate what they are trying to accomplish, which standards
would make the job easier, and the best way to get those standards
implemented. This would involve standards development as well
as lobbying to gain acceptance. Strategic-standardization management
is not about standards. Rather, it is about leveraging all aspects
of the standardizing process to optimize competitiveness. This
should be a horizontal discipline, that is, enterprise wide rather
than applicable to a single product or process. Example horizontal
strategies include quality, environmental, electronic-data interchange,
and safety. Parallel with this horizontal-enterprise strategy,
a new category of standard has emerged--often referred to as horizontal
standards. Rather than affecting one process or tool these standards
affect everything that an enterprise does within the subject area
of the standard. All of the enterprise processes and the infrastructure
that supports them would be affected. Therefore to position the
enterprise to best deal with the standard requires executive-level
decision making during the strategy-making process and not disjointed
point solutions. The philosophy of some of these horizontal standards
is slightly different from the usual standards.
These standards tend to ask what one does
rather than to tell everyone what to do. ISO 9000 series
requires that for compliance, one must reveal all enterprise-quality-related
activities and procedures, document them, implement them as documented,
then certify that it is done. Perhaps improving enterprise-process
interoperability will require a similar philosophy. Rather than
forcing every process that wishes to communicate to have the same
everything, maybe the processes involved in the transaction, the
querying process and a responding process, could operate by asking
rather than telling. To do this, the process initiating
the discourse could ask another process, in a standard way, what
that process speaks, what its capability is, and whatever else
is required. The answering process would respond in a standard
way. These interactions could be on a resource such as the Internet.
The processes then could determine between themselves the best
way to communicate.
Standards at the correct level and constraining
the correct things act to preserve innovation incentive. They
allow users to form alliances more easily and with fewer barriers,
and they allow more effective product and process differentiation;
that is, they enable commerce to be effective and competitive.
With more deregulation, companies are viewing standardization
more globally, and at a strategic perspective rather than at a
tactical perspective. Without the strategic viewpoint, standards
can be a barrier to global operations because different markets
have legally enforceable entry requirements that must be addressed
at the corporate or government level.
4 Conclusions
Cultural inertia, direction and rate of enterprise
change, and human ingenuity will limit the effectiveness and use
of standards to constrain enterprise design. Defining and representing
the interfaces that exist in a manner similar to the ISO 9000
series of standards may enable enterprises to communicate without
standardizing an enterprise or process structure. The process
of evaluating how best to communicate electronically will involve
some tradeoffs. Enterprise designers must evaluate whether the
technology used to achieve acceptable functionality has a life
that is shorter than the time it takes to develop and/or modify
a standard to constrain the technology. The alternative to standards
is to use the technology to circumvent the problem.
There are several areas to evaluate when analyzing
enterprise operation. If sets of models from one enterprise are
to connect to models of another enterprise, both sets of models
must have considered the same areas or the models probably will
not interoperate. To ascertain whether modelers can manage these
areas consistently, informally from a checklist or formally by
standards, needs further implementation experience and discussion
to decide. The issue needs satisfactory resolution because the
areas in question are precisely the interfaces that one enterprise
will mediate with another to communicate.
Areas of integration technology needing standards-like
attention are hardware, software, communications protocols, information,
and architectures. Enterprise-representation technology, coordinated
terminology, and enterprise-representation architectures are not
yet adequately addressed. There are a few areas that appear to
be good candidates for standards. One is terminology and another
is enterprise models. The solution to the terminology problem
appears to lie in some registry to which an individual enterprise
can map its terminology. Properly constraining enterprise models
and the way they communicate among themselves, would reveal, in
a standard way, the necessary points from which one enterprise
architecture can mediate an information transfer with another
enterprise architecture.
Ensuing enterprise representation standards should
not mandate standard processes, standard enterprises, standard
organizations, standard methodologies, or standard-enterprise
data. Enterprise-representation standards should define the key
ideas involved with enterprise frameworks or enterprise models
so that the models produced are consistent. Then, vendors can
develop tools that produce and operate frameworks and models with
minimum investment risk and with the maximum confidence that they
will encounter known interfaces. Ideally, standards should enable
interoperability and still protect innovation, efficiency of approach,
and migration capability.
Interprocess communication may not be 100%. Well,
it rarely ever was, is not now, and maybe never will be the case
that everyone will be invested to the same level and version to
enable 100% communication on the first try. Let us recognize that
fact and find a way to communicate to the best of our ability.
It may require a change in standardization philosophy to move
toward ask rather than tell standards.
Governments around the world use standards in
a strategic sense; for example, as a barrier to product entry.
A corresponding strategic view will help companies to operate
better in global environments. Businesses must pay closer attention
to standards matters to insure that they will be able to compete
on a playing field that is more level. Many standards issues are
becoming more company or industry wide, such as quality, environmental,
services, and electronic-data interchange. Continued participation
in standards activities and strategic treatment are needed to
avoid standards that add cost but do not add value, and to avoid
standards that are being developed deliberately for the purpose
of restraining trade.
5 References
[BET95] Betancourt, Diego, and Walsh, Robert, "The Evolution of Strategic Standardization Management", StandardView, Vol. 3, No. 3, 1995-September.
[HOW96] Howie, Robert L., Jr., "Competition 2000", Special Advertising Section, Business Week, 1996-October-21.
[NELL96] Nell, James G., "Enterprise Representation:
An Analysis of Standards Issues", Modeling and Methodologies
for Enterprise Integration, Edited by Bernus and Nemes, Chapman
and Hall, 1996
The author acknowledges contributions to this
paper from Shirley Hurwitz, Neil Christopher, Howard Bloom, and
Kurt Kosanke. NIST, through its SIMA (Systems Integration for
Manufacturing Program) sponsored this paper and the NIST participation
in the ICEIMT'97 activities. Since the U.S. part of the ICEIMT'97
activities is funded by the United States government, this paper
is not subject to copyright.
Jim Nell is Convenor of ISO TC184/SC5/WG1, Automation
Systems and Integration, Modeling and Architecture. He is a member
of the US delegation to SC5, and a member of the US technical-advisory
groups to TC184 and SC5. At NIST, he is the principal investigator
of the Manufacturing Enterprise Integration Project to evaluate
the use of architectures, frameworks, and enterprise models for
use by business entities. He is co-convenerof the ICEIMT'97 workshops
and conference.
Formerly, he was convener of the ISO/IEC JTC-1 Joint
Workshop on Standards for the Use of Models that Define the Data
and Processes for Information Systems. He was active in the TC
184 SC4 work to develop product- and process-data representation
serving as the US expert to the SC4 Strategic Planning Advisory
Group. For the IGES/PDES Organization, he was Chairman of the
Steering Committee. He was the original chair of the Evolving
Standards Focus Group of the Agile Manufacturing Enterprise Forum
at the Iacocca Institute, and a founding participant of the ANSI
Organization for Harmonization of Product Data Standards. As a
member of the National Initiative for Product Data Exchange staff,
he was the architect of the NIPDE Electronic Library on the World-Wide
Web.
Jim Nell was formerly Manager of Information Technology
Programs at the Manufacturing Systems and Technology Center of
Westinghouse Electric Corporation in Columbia, Maryland USA. During
the 32 years prior to his retirement from Westinghouse, he had
various assignments in systems engineering, international marketing,
program management, and strategic planning. From 1984-1993, he
concentrated on product-information representation, enterprise
integration, and standards that apply to information representation
and enterprise integration.
He received his BSEE from Drexel University and his
MBA from Bowling Green State University.