2000-March

This paper identifies issues that, if resolved, will help define a realistic role for standards in defining the different necessary components of enterprise integration. Standards can help vendors create software products that enable automated information transfers among any organization of processes. The standards will define guidelines and requirements for designing new enterprises and software-system components that can operate in a more integrated mode, and for creating enterprise models.

Environments that allow systems to self-integrate can encourage vendors to create software products that can accomplish the information transfers required by any organization of processes. These transfers will provide a path for enterprises to approach higher levels of integration. The environment will comprise standards and tools. Self-integrating systems will operate in a standard way to find a way for processes to communicate to the maximum of the installed capability of the process.

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

Integration
Integration refers to an 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. Integration is not a specific capability or an end state, but a continuum of improvement. Therefore, integration is a continuing process. 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.

Self integration
Self-integration refers to an enterprise environment in which the things in a process that must share information can configure themselves to do so to the degree that the process capability allows. This may or may not require constraints by some kind of standard. Self-integrating systems may be thought of as software that adapts to its environment with no human assistance. Within that simple definition, two implementation viewpoints exist:

• Self-integrating systems in a well-defined environment: An environment in which all interfaces are governed by standards or otherwise known in some way. There may be multiple standards that overlap and even conflict.
• Self-integrating systems in an unknown environment: An environment in which not all interfaces are known. Presumably, the interfaces can be discovered; such as, by learning, querying, and guessing.

The capability presented here will enable an enterprise to operate in the second-viewpoint mode.

Self-integrating software systems for manufacturing
The self-integrating-software entities are to be deployable in an open environment (Examples: Internet and a CORBA framework). The systems should operate for intra-enterprise transactions and inter-enterprise transactions on a global scale. To define this environment, WG1 envisions a set of standards that enables an enterprise that is shopping for a process to be able to evaluate, on line, what it does, what it means, the information it needs, and the data it provides. If a process meets both quality and capability guidelines, and if it conforms to acceptable interface standards, the systems involved would be able to adjust, adapt, and select their parameters to establish a relationship and operate at a level of integration that is acceptable to both parties.

Integration Odyssey
Industrial testimonials indicate multi-million-dollar-cost allocations assigned to unsuccessful software-systems-integration efforts. Those seeking integration have progressed from making clusters of computers share information, through islands or stovepipe integration. Any true integration ended at the process or activity boundary. Information was shared with other processes by defining a very restrictive system of translators. Often the only way to accomplish information transfer was by proprietary-system design. The systems lacked such desirable features as interoperability, interchangeability, common information format, information accessibility, granularity resolution, and migratability. Effective integration of systems in manufacturing and related industries will impact positively current revolutionary developments in business-to-business, Internet-based, technology developments, and the evolution of the predicted multi-trillion-dollar market.

Information flow
Proper information has been flowing between processes for decades--or else manufacturing enterprises would have produced no products. When this information transfers successfully and a product gets made, an instance of integration has happened. 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 to share information--not always a given.

Considering globally distributed enterprises
A group of distributed processes, perhaps a virtual enterprise, is still an enterprise. Technically the inter-process communication categories involved are the same: hardware, software, communications, information format, 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 in 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, things other than just technology 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. Other issues that need to be resolved are security and the nature of the information to be shared. (including proprietary information)

An integrated enterprise
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 successful 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 and compliant self-integrating systems, 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 every buyer or seller has the same functionality or capability with these technologies, although they do operate quite well in user-configured systems.

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. So, how do we get to where we achieve significantly better process interoperability?

Contrasting the role of standards and good software design
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, using the same tool, more than one enterprise can evaluate virtual-enterprise opportunities, select the most favorable, and then hook up to the selected enterprise. Each enterprise will be operating at its own chosen points on the various continua.

What kinds of standards are needed to increase the market for the correct tools, thereby justifying tool-development costs? 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.

These issues are 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 but 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. Perhaps the answer lies in the type of thing the standards constrain.

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 analyzing 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 the ISO Open-systems-interconnection standards, ASCII, and a common nomenclature. At the time this was first discussed it seemed futuristic, but now it seems feasible; indeed, models of this type of software behavior appear in commercial-office-application suites, and in the National Industrial Information Infrastructure Protocols Consortium Project, NIIIP.

Rather than organizational policy or standards that constrain the functionality of tools, a more open policy in conjunction with new standards should define ways to improve tool functionality such that the software tools can work autonomously with other enterprise applications to set up integration improvements. To force tool builders to add cost to their products to comply with restrictive policy and a set of unnecessary standards may be too limiting, for technological, competitive, and flexibility reasons.

If, as presented in the previous section, 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.

Some interfaces are a good start; for example, those systems that connect process applications to the manufacturing-execution system and to the enterprise-resource-planning system. Hardware and communication interface standards are rather mature. Neutral-information formats are becoming available with ISO 10303, STEP, or Standard for the Exchange of Product Model Data, and others; HTML and XML; and the electronic-data-interchange standards, ANSI X12, and CEFACT (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 can be related to pieces of another. Software interfaces are receiving attention, such as with the CASE Data Interchange Format, CDIF. Making use of universally available infrastructure technology is wise, such as the Internet.

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 ISO Basic-Semantics Register (X12 and EDIFACT), and the Universal Data Element Framework. A good terminology facility will require formally modeled definitions to the concepts to preclude ambiguity. Other terminology projects that show promise are the NIST Process Specification Language and the new project of the IFAC/IFIP Task Force, the Universal Enterprise Modeling Language. However, fully pre-planned semantic representation in some form of ontology may never become possible as long as human minds are involved with least one end of the semantic representation because of the human tendency to be flexible when they name actions and things.

A paradigm that will further process interoperability--use cases and scenarios
Let us discuss a model that does not set specific limits to everything. Rather, consider a combination of standards and tools that would force enterprises to analyze and document, perhaps electronically on line, what they do; and then operate their enterprise accordingly. Lower-level standards, such as the Open-systems interconnection, would still define infrastructure interfaces. Either the querying or the supplying process could indicate which protocols or standards apply. The processes also would present information about the process capability. Standards would define the choreography of this introduction process. Thus, an enterprise shopping for a process would be able to evaluate, on line, that a candidate process meets both quality and capability guidelines and that they conform to listed interface standards. Either enterprise could then advise its software to make any needed adjustments to its enterprise, establish a relationship, and operate in an acceptable (to both parties) level of integration. This will not always be the most perfect information transfer imaginable, but the best considering the technology encountered.

The strategy is to create a family of software tools and standards that apply to interoperating enterprise processes. ISO TC184 SC5 WG1 generated several process-information-exchange use cases to help envision what would be the nature of the communications necessary, where the processes would interface, and the standards involved in such exchanges. The use cases are:

1. Publishing a capability (an interface) to unknown clients.
   Raises issues of semantics, taxonomy, representation, costs, and service qualities. Also, this case involves a looser coupling than in 2 below.
2. Negotiating and establishing an interworking mechanism, possibly with help from intermediaries.
   Implies contracts, modalities such as inventory replacement, and two-sided purpose. This case has a tighter coupling than in 1 above.
3. Establishing a low-overhead version of 2, once trust has been established. Implies presence of tokens, encryption, and authorization.
4. a. Executing the interworking mechanism (e.g. state-machine characterization). Implies time horizons, volumes, and description of behavior
   or
   b. Executing the interworking mechanism but adding interaction modalities such as ODP handoff; for example, motion control.
5. Monitoring the interworking, within an agreed (envelop of) quality of service(s)--perhaps with third party involvement. Implies contracts monitoring, exceptions, and performance.

• Use cases 1 and 2 are concerned with the what; use case 3 with the how, and use cases 4 and 5 with the do part of process communication.
• A possible 6th use case might emerge as a result of 5. That is the evolution and encapsulation of business processes into a new business process with newly exposed service interfaces.
• A further use case topic is to define how an organization would make use of the standard(s) that will come out of this work. This theme will be incorporated into each use case.

Actors and Resources:
Marketing function, business processes (inputs and outputs), external view of process model, language, World-Wide Web, database, and server.

What happens:
Extract or select a needed capability.

1. Represent the capability. Implies language(s), customer vocabulary, codifying, key words, arrangement (in the sense of organization of parts), registration, and notification.
2. Map 1 to 2 above
3. Publish. Implies implementation
4. "How to use us" and/or "How we do business". This implies modalities and qualities of service such as costs accuracy, and delivery. Note that publication could be for human review and/or machine review.

The other use cases should be expanded to expose the scope of technology, standards and capability required for self integration.

Scenarios
While the main focus of the self-integrating project envisioned is discrete-parts manufacturing, other scenarios might suggest something that would be useful to add to the manufacturing model. In general, a scenario sets up as follows. Software system A is deployed on the Internet intending to interoperate with system B. Focusing on semantic interoperability, component A sends an initial query message to B identifying the preferred communication and content languages, as well as the adopted semantic definition for the languages. The languages and semantic definition are accessible in the environment of each system. Systems A and B interact to negotiate appropriate languages and neutral semantic definitions. During the negotiations, the two systems adjust, adapt, and/or select appropriate parameters or components to establish semantic interoperability.

Cultural inertia will limit the effectiveness and use of standards to constrain enterprises. Enterprise management will insist upon retaining the freedom to tinker with the enterprise and process design. This will be a survival maneuver to improve operations efficiency and to differentiate products. Therefore attempts to standardize enterprises, processes, or reference architectures will probably be ignored.

The new enterprise environment should not set specific limits to everything. Rather, there could be a combination of standards and tools that would require complying enterprises to analyze and document, perhaps electronically on line, what they do; and then operate their enterprises accordingly. Lower-level standards, such as the Open-systems interconnection, would still define infrastructure interfaces. The strategy is to create a family of software tools and standards that apply to inter-operating enterprise processes in a way that allows the software systems to determine, in a standard way, the best way to integrate those processes. These are called self-integrating systems and they may be thought of as software that adapts to its environment with no human assistance. Assume an environment in which not all interfaces are known. Using the new standards, the nature of the interfaces can be discovered; such as, by learning, querying, and guessing. The new environment should operate for intra-enterprise transactions and inter-enterprise transactions on a global scale.

Either the querying or the supplying process could indicate which protocols or standards apply. The processes also would present information about the process capability. Standards would define how this introduction process would operate. Using this, an enterprise shopping for a process would be able to evaluate, on line, that a candidate process meets both quality and capability guidelines and that it conforms to certain interface standards. The standards would define the entire mediation or negotiation choreography that would include such topics as the information format, the script for the query and response process, the ontology system, the language to use during the process, the capability assessment methodology, and error resolution. Either enterprise could then advise its software to make any needed adjustments to its enterprise application, establish a relationship, and operate in an acceptable (to both parties) level of integration. In addition, if standards constrained enterprise models properly they would reveal the necessary points from which one enterprise, and its chosen architecture, can mediate an information transfer with another software system.

The systems would initiate their problem-solving behavior by identifying the shared goals and proceed with identifying individual tasks, dividing the tasks, and planning for final synthesis according to the agreed-upon protocols of interaction and coordination. The respective inference engines in each system would make decisions, become pro-active, engage in planning, and meet the specified performance within the super-system.

This will not always be the most perfect information transfer imaginable, but the best considering the technology encountered.

The self-integrating systems adapt over time to meet changing integration specifications and to accumulate experience for enhanced integration of the similar-system type. Self-integrating systems should play a decisive role in achieving optimal performance in the system-life cycle including integration, problem solving, maintenance, and function updating. Solutions need to assure extensibility and migratability of limited-scope-demonstration prototypes.

The specific requirements need be very carefully specified so as not to preclude continuing integration improvements.

More responsibility for process interoperation should be transferred from standards groups to software developers and to system integrators so that enterprise-application software is made intelligent enough to enable the software to self-integrate process information.

Standards must define only what is necessary so that the software developer knows with what, and how, the software must work to self-integrate process applications. 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 applications together with 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 should have access to a language such that the information in instantiated models can be represented in a widely accepted and easily understood form.

WG1 should design the standards appropriately so as to encourage the enterprise-tool builders to use these standards to design software systems in such a way as to allow the processes to integrate themselves to a level of successful communication.

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 enterprise-definition standards. The mediation process must be defined in a new type of standard.

[Cyberdesk] http://www.gvu.gatech.edu/gvu/reports/1997/

Engwall, Richard, et al, Industrial Modernization Incentives Program (IMIP), Phase I Enterprise Analysis, Final Report by Westinghouse for US Air Force Electronic Systems Center, Hanscom AFB, MA, F19628-92-C-0021, CDRL#4, 1993-January-31

Fulton, JA, Boeing Airplane Company, Semantic Plug and Play, Prepared for the Joint Workshop on Standards for the Use of Models that Define the Data and Processes of Information Systems, 1996-September, Seattle, Washington.

Ivezic, Nenad, NIST, A Concept Paper: Self-Integrating Software Systems for Manufacturing, 2000-January, unpublished

Ivezic, Nenad; Libes, Don; Nell, JG, NIST. A vision for self-integrating systems: Improving process interoperability, 2000-January, unpublished.

Kosanke, K, CIMOSA Association, and Nell, JG, NIST, Standardization in ISO for enterprise engineering and integration, Computers in Industry 40 (1999) pp311-319, Elsevier Science B.V., Amsterdam 1999

Libes, Don, NIST, Self-Integrating Systems--A Computer Scientist's View, 2000-January, unpublished

Nell, JG, NIST, Enterprise Representation: A different paradigm for designing process-interoperability standards, a TC184 SC5 WG1 working paper, 1999-March, unpublished

Nell, JG, NIST, A Standardization Strategy that Matches Enterprise Operation, in Enterprise Engineering and Integration, Proceedings of the ICEIMT97, edited by K Kosanke and JG Nell, Springer, ISBN 3-540-63402-9, 1997-October