Enterprise Integration

Enterprise Integration

Because e-business systems are a core part of any business enterprise that interacts with suppliers and trading partners, they cannot exist outside of and be disconnected from enterprise back-end systems. As a result, e-business systems need to be tied to various back-end systems, including the following:

   Customer Relationship Management (CRM) systems

   Enterprise Resource Planning (ERP) systems

   Asset- and inventory-tracking systems

   Point-of-sale systems

   Warehousing, shipping, and logistics systems

   Financial and accounting systems

   Marketing, sales, and customer service systems

Enterprise integration provides connection hooks into these various systems by means of APIs, Enterprise Application Integration (EAI), file transfer, or other shared messaging techniques. Integration is a two-way street, meaning that e-business systems can extract data from these various knowledge repositories as well as enter data into them. In the process of this bidirectional interchange, these systems apply business logic processing and translation among different formats. Enterprise integration therefore provides a gate-way to the back-end systems from which results are communicated to other processes in the chain.

Fundamental Network and Platform Layers

In order for much of these e-business processes to happen, various technology, network, and protocol layers need to exist. These various layers cover the following fundamentals for e-business exchange:

   Partner connection and document transport

   Security

   Development platform and tools

First, it is necessary for e-business messages to be transported between points and for business partners to physically get “connected” to a network. In the EDI model, the VAN handles these issues, plus many others covered by other segments of e-business technol-ogy. In this case, e-business messages are generally transported over well-known and popular Internet transport protocols, including the Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), and File Transfer Protocol (FTP). Each of these protocols provides different messages for asynchronous publishing of data, subscription to supply chains, message queuing, and synchronous request/response messaging mod-els. Due to widespread adoption, a plethora of tools and techniques exist for proper and low-cost use of these transport mechanisms. Therefore, this component of e-business functionality provides a means for messages to “get on the wire.”

Additional security layers are applied to these fundamental transport protocols to provide security of different levels, including these:

   Encryption

   Authentication

   Authorization and permissions

   Privacy

Encryption is commonly handled by the use of Secure Sockets Layer (SSL) over HTTP or SMTP, and authentication can be handled by means of digital certificates. Authorization and privacy layers are more proprietary in nature and are just not being solved in a standard, open manner. In general, e-business transactions need these security technologies and protocols in order for the relationships to be trusted.

This set of foundation components also provides some management capability of e-busi-ness systems to help discover the availability, existence, and condition of e-business sys-tems. These components manage the quality of services for the overall system to ensure a consistent delivery of supply chain interactions.

Finally, the fundamental network components of e-business systems are the development tools and platforms for the construction of e-business systems, such as those powered by Web Services. Microsoft, Sun, HP, Oracle, and IBM all offer a number of e-business-enabling systems that can be built on to offer the rich functionality required. This portion of e-business functionality defines APIs that serve to connect e-business transaction sys-tems with the back-end systems.

Messaging (Transport, Routing, and Packaging)

Just having a transport protocol is not enough to provide business-level, robust, and reli-able communications between trading partners. EDI VANs have historically provided a number of other major features that have enabled partners to reliably conduct business with each other. As a result, the messaging layer, consisting of transport, routing, and packaging components, is the core to e-business systems.

Messaging systems provide a standardized message and envelope structure that serves to identify endpoints (and optionally intermediaries) in a given e-business transaction, spec-ify how long messages are to be resent before timeout, and provide transaction controls and nonrepudiation (which helps to guarantee that messages are received by the end user). These components provide a certain level of session management and transaction coordination in a loosely coupled environment.

Messaging components also record sessions and other parameters that control reliable and secured messaging, among other features. As a result, messaging components serve as a basis for all e-business communications between parties.

Registry and Repository

E-Business services and capabilities are stored within repositories and registries—two terms whose meaning is often interchanged. Similar to the service offered by Universal Description, Discovery, and Integration (UDDI), registries and repositories serve as a central location where e-business services can be stored and later retrieved to dynami-cally discover business partners and their various capabilities, services, and business terms and conditions.

Data Dictionaries

Many portions of B2B information exchange require common knowledge of the vocabu-lary and acceptable items to be used within that vocabulary. These definitions of accept-able vocabulary usage can be found within a structure known as a data dictionary. These entities contain data structures, data types, constraints, and code lists of all the items nec-essary to compose valid business documents. In general, dictionaries specify the structure and semantics for particular business process documents.

Process and Workflow

Much of what differentiates e-business from simple e-commerce and individual transac-tional information is its ability to string multiple transactions into an overall business process to be executed. Many business process components, such as the “purchase order,” are in fact composed of multiple individual transactions that must be executed in a particular order and with a given accepted workflow. In many e-business systems, these larger processes and workflows can be specified and exchanged in advance. Business processes can also be modeled with various technologies and those models shared to help craft the actual execution of e-business transactions.

Some business processes are applicable to a broad range of businesses, regardless of the vertical industry or locale, and despite specific characteristics of the business. These processes include many common business activities, such as invoicing, request for quote (RFQ), collaborative product development, purchasing, supply chain execution, and man-ufacturing. These general-purpose processes are defined so that they may be reused by other industries and businesses to achieve manageability and economies of scale. Other business processes are more specific to individual industries or organizations. These, too, may be defined as modifications to the generalized business processes or as new compos-ites or sequences of established processes and workflow. Such examples include specific purchase order methodology, taxes, and production requirements.

Trading Partner Agreements

In the paper world, in order to execute any supply chain interaction, a contract must exist. This contract stipulates the terms and conditions of sale and the production of goods. In order to maintain a sense of legality and accountability, a similar process must exist in the electronic world. In e-business, this electronic form is known as a Trading Partner Agreement (TPA). The TPA includes a profile of a business partner’s contractual agreement for transaction as well as its e-business system infrastructure and usage of protocols.

However, TPAs can be time consuming to negotiate and sign because they inevitably require businesses to use lawyers in the business process. They can sometimes raise thorny, intractable issues, and so some organizations may decide to forego TPAs because their costs appear to outweigh the benefits. Some TPAs and e-business systems, however, allow their users to prepare partial TPAs that, for example, send a declaratory letter to a trading partner asserting the company’s position and policy on the issues that would oth-erwise be in the TPA.

Business Vocabulary

Much of the heavy lifting in an e-business system is actually accomplished in the actual document that describes a specific transaction. Of course, such transactions vary in dis-tinct ways among different businesses, industries, geographies, and markets. As a result, business vocabularies have been defined by standards bodies of all sorts covering various business needs. These vocabularies are then used to construct the actual business content of a message. This message can contain product, finance, employee, or other business information. The actual terms to be used in the vocabulary are described by the data dic-tionary defined earlier in this section. Examples of business vocabularies include Health Level Seven (HL7) for the healthcare industry, ACORD for the insurance industry, the Open Travel Alliance (OTA) for the travel industry, and the Extensible Business Reporting Language (XBRL) for a variety of financial exchange needs.

Vocabularies are where the “rubber meets the road” in e-business transactions and include industry or supply chain–specific technical terms, properties, values, and taxo-nomic structures that are used to conduct commerce. In essence, it is the actual payload of a business transaction.