This paper identifies issues that, if resolved, will help define a realistic role for standards in defining the different necessary components of enterprise integration. The representation of the enterprise is, by definition, a model. One could view the enterprise-reference architecture as information and knowledge with which one could adequately represent the enterprise. One could then consider the enterprise-reference architecture to be a meta model of the enterprise representation. The actual enterprise-architecture is a component of this meta model.

Standards can help vendors create software products that enable the information transfers required by any organization of processes. Accomplishing these transfers will provide a path for enterprises to approach higher levels of integration. The standards will define guidelines and requirements for designing new enterprises that can operate in a more integrated mode, and for creating enterprise models. The domain of these standards can range from standardizing the enterprise to standard names for key concepts. This paper will attempt to point out which of these is relevant material for standardization.

Enterprise, integration, process interoperability, architecture, framework, enterprise model, virtual enterprise, infrastructure, process, life cycle, enterprise representation, international standard, terminology.

How much freedom should businesses have to design the enterprise of their choice, with freedom will there still be acceptable interoperability, and is the idea of a standard enterprise realistic?

Integration refers to a state of enterprise operation in which all necessary things, processes and infrastructure, are in place that enable the communication of correct information, at the correct time, every time. Information flow is at the heart of successful integration. Of course, many other things must happen both technically and culturally to allow satisfactory information flow.

Businesses typically consist of groups, divisions, departments, and sections. Somewhere in that hierarchy the organization becomes function oriented and the higher manager establishes incentives to lower 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 process and infrastructure improvements tend to sub-optimize and even conflict with similar investments in other departments. Subsequent reorganization will attempt to fix the problem and the enterprise engineers will be kept quite busy. This cultural problem will exist whether or not there are standards or policies that recommend otherwise.

For these reasons the standards organizations should recognize that they would waste resources to attempt to standardize enterprise design, or process design, or establish a hurdle level of integration required that would qualify the enterprise as an integrated one. Even if standards that define the entire enterprise existed, humans will always demand the freedom to improve enterprise operation through redesign.

What must happen to assure proper information flow?

Proper information has been flowing between processes for decades--or else manufacturing enterprises would have produced no products. What enterprise integrators are trying to do is to reduce overhead costs and effort by making the information flow repeatable, have higher accuracy, and be computer sensible. Knowing what is necessary to help information transfer depends upon whether:

• The information at the interface between applications is in an open format, or mapped to adequate neutral-format standards
• The semantics is in the one-name-one-meaning category
• The hardware is compatible
• The software interrelationships are well defined
• There is agreement about the communication protocols to be used
• There is understanding about how to transfer information among the information architectures that exist.
• The purpose of the communication is mutually understood.

Even with 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.

What material qualifies for consideration as a standard? The easy, but unrealistic, answer is everything. The appropriate answer involves some tradeoffs. One must consider the rate of technology change against the amount of time it takes to create and change standards. And, to employ standards, one must evaluate the flexibility the enterprise surrenders in the ability to migrate at a later time to a newer technology that will enable an enterprise to achieve a higher degree of integration.

A virtual enterprise is an enterprise. Technically the standards categories involved are the same: hardware, software, communications, information, and, perhaps, architecture. The notion of virtual enterprise brings in a time element such that the enterprise can form or dissolve very quickly. If virtual enterprises are to be the mode of enterprise operation for the near term, an enterprise will have to analyze new relationships, and form and dissolve these relationships in relatively short time. There will be processes available for hire, and enterprises shopping to append these processes to their enterprise. Enterprises will have to match process capability quickly to product requirements. This will emphasize the need to have executable or computer-sensible enterprise models. Some degree of standardizing the interfaces among processes is necessary to allow virtual enterprises to integrate their operations at the speed and flexibility that is necessary to be a competitive supplier of products or processes.

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 to 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.

There is much technology involved with enterprise operation. To improve the level of integration, certain improvements to technology are necessary. The categories of integration technology divide into infrastructure and process technologies. Infrastructure improvements benefit more than one process in the enterprise whereas a process improvement focuses on one process. If one considers all possible infrastructure and process improvements it is not likely that any enterprise will have invested to the maximum in all possible areas. However, the enterprise still operates and it ships products. The improvement areas are, therefore, not a set of specific and fixed hurdles. More accurately, the improvement areas are continua, and each enterprise is free to position itself at a particular spot on each continuum. Enterprises base this placement decision on the strategies of the enterprise, the amount of available capital-investment money, and any other criterion important to the enterprise. Also the technology level of each continuum is moving.

Each enterprise is unique with respect to determining how to improve it. The enterprise has a character and there is some implicit or explicit vision that drives it. Tools help an enterprise accomplish its outputs. Who buys these tools, selects them, determines if one is better than the other, and decides to invest the money or to wait? How do the tools communicate? How does the enterprise acquire, move, and ship its information and physical things? There is an executive function that decides these things. This is not necessarily a person at the executive level but the function. This function receives its inputs and constraints from a process that determines enterprise goals and strategies and allocates resources that implement the strategies, in an attempt to meet the goals. This process must operate even more smoothly in a virtual enterprise. The enterprise-executive function selects the level of investment that is appropriate for each process and infrastructure area.

As stated, these areas appear as continua of opportunity and capability rather than specific hurdles of capability. Each enterprise will have a self-determined priority for those projects that will receive investment and where on each continuum the enterprise will operate. Some enterprises will want to be on the leading edge and others may choose to follow the leaders; perhaps to enable them to invest in these technologies later at a lower cost. Neither strategy is incorrect, but they lead to unevenly equipped enterprises that are trying to do business in the global marketplace. With well-planned standards, these unevenly equipped enterprises still would be able to interoperate to the degree that their investments permit. A low level of integration capability will not have all of the functionality of the high level. This is sort of like buying stereo-system components, telephones, or cable-television capability--not everyone has the same functionality or capability with these technologies, although they do operate quite well in user-configured systems. Therefore, it would seem useless to specify exactly what must be in place to have enterprise integration.

Defining a specific set of capabilities that would qualify an enterprise as integrated would tend to codify the enterprise strategies and reduce product differentiation. The idea of a standard-capability set is contrary to the operation of a free-enterprise market and not feasible for current and foreseen world-commerce situations.

People or machines analyze, design, simulate, and operate enterprises with tools. To justify the investment of the tool builder and to make the tool cost reasonable, the tools must be compatible so that more than one enterprise can use them. The tools must be extensible, migratable, and interoperable so that one enterprise can evaluate virtual-enterprise opportunities, select the most favorable, and then hook up to the selected enterprise. The other enterprise will be operating at its own chosen points on the various continua. Which components of inter-enterprise transactions should standards constrain: model structure, model content, interfaces between models, and/or known hook-up points so that the software knows with what it dealing? Which standards in place will increase the market for tools, thereby justifying tool-development costs?

This issue is difficult because the resolution lies in a range between those opinions that say they need none or few standards and those who say they need to standardize and constrain everything. It is often the easiest and least-effective solution to a computer-compatibility problem to standardize everything. The loss of user delight, the loss of opportunity to use tools especially designed for the job, and the lost opportunity for technological improvement is enormous--and it would stay that way because standards always consume more time to develop than 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.

About 15 years ago the U.S. Air Force envisioned a design-engineering-tool environment that hinted at a solution that would probably work here. The theory was that there were and will be many tools available to do the many special jobs in product design. There are several options available to get the tools to interoperate better. They include standardizing the tools, using one tool developer, or finding a way to make different, non-standard tools interoperate through the software in the tools. If one wanted to import a spreadsheet table into a word-processing program, the tools themselves or the operating system would be able to tell from looking at the code what would be necessary to accomplish what the user wanted, and then do it. The only standards would be the basics, such as ASCII and a common nomenclature. At the time this was first discussed it seemed futuristic but now it seems feasible; indeed, it is being done for the commercial-office, software-application suites, and for the National Industrial Information Infrastructure Protocols Consortium Project, NIIIP.

The NIIIP-mediated architecture is probably the way of the future rather than standardizing everything. To help explain how NIIIP is intended to operate the program uses a music metaphor. Mediation would allow the software and the knowledge base combination to say: "Hum a few bars and I will catch on to what's happening." Otherwise we would have to standardize the notes, the rules, the arrangements, the key--everything. The standards will change much more slowly than the technology improves. This would stifle innovation. ISO TC184/SC5/WG1, the ISO group responsible for enterprise modeling and architecture standards, will analyze the real need for enterprise-integration standards by approaching the topic from a mediated-architecture viewpoint.

Enterprise applications should be able to operate effectively with only a minimum of standards limiting the functionality of tools. A new-work-item proposal for new standards should propose to define ways to allow the tools themselves to work with the software in the integrated enterprise and not rely upon standards. To force tool builders to add cost to their products and comply with a set of unnecessary standards may be too limiting, for technological, competitive, and flexibility reasons.

If, as presented above, standardized enterprises and processes are not feasible, then at what level is a standard appropriate? The domain consists of hardware, software, communications protocols, information, languages, frameworks, and architectures. There are things, the connections between the things, the information, the context, and the information formats.

Interfaces are a good start. Hardware and communication interface standards are rather mature. Information formats are becoming available with ISO 10303, STEP, or Standard for the Exchange of Product Model Data, and others; and the electronic-data-interchange standards, ANSI X12, and EDIFACT. Architectures and frameworks need to have known or common, but not necessarily standard, interfaces to the extent that when one interfaces with another the pieces of one are mappable to pieces of another. Software interfaces are receiving attention, such as with the CASE Data Interchange Format, CDIF.

One issue that most knowledgeable enterprise integrators agree upon is that terminology is a problem; that is, there needs to be some sort of unambiguous naming dictionary. Possible solutions are the ISO 11179, parts 1-6, Data Element Standard that is under development, the Basic-Semantics Register (X12 and EDIFACT), and the Universal Data Element Framework (UDEF). A good terminology facility will require formally modeled definitions to the concepts to preclude ambiguity.

The UDEF is a Dewey-Decimal-like naming system that is gathering support in the international CALS community. There would be a centrally registered naming facility that would serve to unite the semantics of different naming schemes. It is not necessary that everyone in the world name things the UDEF way, only that they map to its schema. Two different applications could use any name they want, map to the standard, and thereby link up their semantics.

The Basic-Semantics Register, BSR, being developed at the ISO Central Secretariat for electronic-data interchange is an approach that can apply to the enterprise-representation domain.

The concept is fine as long as the three, or however many there are, come together soon before there are three or more solutions requiring tons of work to map to each other. Of course STEP would have to participate and cooperate because many of its entities fall in the same tank as the entity names covered by this proposal.

Let us discuss a standards model that does not set specific limits to everything. Rather, such a standards set would 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 ones apply, together with the set of information they present on line 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 capability guidelines and that they conform to listed interface standards. The shopping enterprise could then advise its software to make any needed adjustments to its enterprise models (function, hardware, software, communication, and information), establish a relationship, and operate in an acceptable (to both parties) level of integration.

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 usable is to standardize the interfaces, the nomenclature (for example, model components), and the formats. Then encourage the enterprise-tool builders to use these standards to design software in such a way as to allow the processes to communicate.

The enterprise model will allow more consistent modularization so that enterprises can interchange pieces rather than entire model. The models will ameliorate the need to develop the entire system at one time. Simulation will be possible allowing evaluation of interoperation with interenterprise entities and evaluation of systems with differing granularity. Enterprises will be able to plan migration paths more effectively. Because information will be a separate asset, changing applications will be possible without re-entering information about the products and processes unnecessarily. Enterprises can define paths to make the product and process information tie logically into enterprise goals, strategies, capabilities, and business rules. The models should be scalable so that a high-level model is essentially the same as a lower-level model--that is, use the same modeling constructs for all levels. A good, interoperable, set of enterprise models will expand the effectiveness of the re-engineering process in much the same way as a good set of engineering drawings always has enhanced the ability to analyze and change traditional products and processes.

Issue summary

Cultural inertia will limit the effectiveness and use of standards to constrain enterprise design. Defining and representing the interfaces that exist 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. Deciding whether or not to standardize each enabler in the information-integration process requires that the enterprise evaluate if the standards will inhibit interoperability improvements. In addition, enterprises must determine 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 that constrains the technology.

The alternative to standardizing and constraining everything is to apply technology within the applications to determine how to best interoperate based on the capability and version of the application.

Enterprise management will insist upon retaining the freedom to tinker with the enterprise and process design. This will be a survival instinct to improve operation efficiency and to differentiate their products. Therefore attempts to standardize enterprises, processes, or reference architectures will probably be ignored.

A virtual enterprise is 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.

Considering the breadth of technology required to integrate enterprises, the speed at which the technology progresses, and the freedom to apply technology that suits, it seems fruitless to create a metric that evaluates whether an integrated enterprise exists or not. An enterprise will have to manage its limited investment resources wisely to be able to communicate in the global-commerce environment at the level that it chooses. Part of this investment will probably involve providing software applications with enough knowledge about the necessary interfaces to mediate the interface connections. Thereby, mediation will achieve satisfactory communication rather than relying on a full set of standards.

There are several areas to evaluate when analyzing enterprise operation. If subsets of the models that apply to the communication from one enterprise are to connect to subsets of models of another enterprise, both sets of models must have considered and formally modeled 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. Of these, enterprise-representation software 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 the 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. Enterprise models are a product of a technology-driven methodology. If standards constrain enterprise models properly they would reveal the necessary points from which one enterprise, and its chosen architecture, can mediate an information transfer with another enterprise, and another architecture.

Standards must define only what is necessary so that the software developer knows with what the software must work. Ideally, standards should enable interoperability and still protect innovation, efficiency of approach, and migration capability.

Ensuing enterprise representation standards should not mandate standard processes, or standard enterprises, or standard organizations, or standard-enterprise data. These standards should define the key ideas involved with enterprise frameworks or enterprise models so that the models produced are consistent. The standards should also guide vendors in developing tools that allow users to produce and operate frameworks and models with minimum investment risk and with maximum confidence that they will encounter known interfaces. Vendors also should have access to a language such that the information in instantiated models can be represented in a widely accepted form.