RosettaNet, in its basic form, is just another trading community standard. However, its innovative approach to managing trading communities at both the information and process levels makes it particularly important to application integration and supply chain integration. The RosettaNet consortium was created to define standard processes and interfaces to manage supply chains within the high-technology industry. Building on the successes of RosettaNet, a movement is now under way to leverage the same or similar standards in other industries. The innovation within the RosettaNet community has been in defining how other trading community standards, typically structured around verticals, will operate. For all its strengths and innovations, RosettaNet is still in its early stages of development. A proof-of-concept prototype, running in early 2000, demonstrated that the concept will work. Indicators point to enough interest from the partners to make production systems inevitable. At this point, things bode well for RosettaNet. RosettaNet HistoryRosettaNet was officially formed in 1998 to standardize e-Business activities in the high-technology industry (e.g., computer manufacturing and reselling). It defined open interfaces between manufacturers, distributors, resellers, and other participants in the supply chain. Indeed, close to 300 vendor members are participating in the development of the RosettaNet standard. (More information about RosettaNet is available at www.rosettanet.org.) The high-technology industry provided a good testbed for the RosettaNet concept. The industry uses many of the same component suppliers (semiconductors, ICs, peripherals, etc.) and thus could quickly agree about information formats. Catalyzing RosettaNet's development was the perception that EDI had largely failed because of its expense, its proprietary nature, and its inability to adapt to changes in B2B processes. In addition, EDI was weak at real-time information exchange and was unable to keep up with high-volume information flows (although XML has not yet proved its viability here, either). What's RosettaNet?Despite the common belief that RosettaNet is all about XML, it is not. RosettaNet is a set of standard mechanisms processes, really that allow companies to agree upon the processing of standard business transactions. XML was added to take the place of EDI as a mere data interchange standard. Because RosettaNet is about processes rather than data, the most important aspect of RosettaNet is the development of common Partner Interface Processes (PIPs) and common dictionaries. RosettaNet provides a master dictionary to define properties for products, partners, and business transactions. This master dictionary, coupled with an established implementation framework, can be used to support the application integration dialog. PIPs provide alignment within the overall supply chain process, allowing businesses to interact at a number of levels to support the processes of common trading communities. For example, PIP2A2, Query Product Information, defines a common process between companies. Because each company adheres to this common process, or PIP, there is no confusion about what this particular process does. Common semantics and common mechanisms automatically carry out the process. The real value of RosettaNet is the common agreement on "which processes do what, and where." Although we long ago established processes for executing common business activities, there has been little agreement about common processes that exist between companies or a common set of application semantics (dictionaries). It should be apparent that, as we have suggested, RosettaNet is less about technology and all about creating PIPs, which are really contracts or agreements. Fundamentally, creating PIPs is a matter of understanding a process in detail, finding a way to make it more efficient, and defining it by using the standard PIP framework that RosettaNet offers. The process to create PIPs is depicted in Figure 14.2. Figure 14.2. RosettaNet development process.The stages to the process include
Those who want to leverage RosettaNet use business process modeling to identify and quantify the properties and behaviors of a particular business process. This is a laborious process of documenting what happens while selling a product, checking inventory, or shipping a product to a customer. Each stage is a process, and each stage may have hundreds of steps. Each step must be inventoried, defined in detail, and completely understood, with the goal of automating the process based on an agreement between companies. The output of this effort is a model that reflects every detail of a particular process using a common framework. Business Process AnalysisOnce the business process model is understood, we must realign the process in the form of a PIP target list. This step determines how much value this process will have when automated by RosettaNet. PIP DevelopmentEach PIP provides a common business/data model and documents that enable system developers to leverage RosettaNet interfaces. Each PIP includes
DictionariesDuring the development of RosettaNet, two data dictionaries were created to provide a common set of properties that exist within PIPs a technical properties dictionary and a business properties dictionary. The technical properties dictionary provides the technical specifications for all product categories. The business properties dictionary describes attributes used to define supply chain partner companies and business transaction properties. These dictionaries, when bound to the RosettaNet Implementation Framework (exchange protocol), become the basis for each PIP. It's the PIPThe real value of PIPs is the ability to allow manufacturers to seamlessly add new products to their partners' catalogs for example, adding a new part number using a common format and information interchange standard. A PIP specification (see Appendix A for an example) comprises three views of the e-Business PIP model. The Business Operational View (BOV) provides the semantics of the business data entities and their exchange flow between roles during normal operations. The content of the BOV section uses the PIP Blueprint document created for the RosettaNet business community. The Functional Service View (FSV) defines the network component services, agents, and functions required to execute PIPs. These include all transaction dialogs in a PIP protocol. The FSVs are semantically derived from the BOV and include two major components: the network component design and the network component interactions. The Implementation Framework View (IFV) defines the network protocol message formats and communication requirements between protocols supported by network components. These messages are exchanged when software programs execute a PIP. There are several categories, or clusters, of PIPs, such as the following (see the tidbit "RosettaNet PIP Clusters and Segments" for a complete listing):
As you might expect, there are several subcategories within each cluster (see the tidbit "RosettaNet PIP Clusters and Segments," and the tidbit "Published RosettaNet PIPs within Clusters and Segments"). Note that Clusters 1 through 3 are extensions, or a rehashing, of processes already specified in EDI during the past quarter century. Also, Cluster 4 PIPs are much like the VICS Collaborative Planning, Forecasting, and Replenishment standards administered by the Uniform Code Council.
The TechnologyRosettaNet's technology is nothing new or revolutionary. Its implementation is based on CommerceNet's OBI specification, XML, X12 EDI, and PKCS#7 digital signatures. The OBI specification was established to allow companies to use the Internet to purchase products that might not be part of their core business, such as coffee for the office coffee machine. OBI uses HTTP for communication between companies, Secure Socket Layer (SSL) for security services, PKCS#7 for digital signatures, and X12 for purchase orders. The RosettaNet communication model specifically defines the behavior that should occur within the OSI application and session layers, dividing the application layer into the action, transaction, process, service, agent, message handling, transfer, and security layers (see Figure 14.3). Figure 14.3. ISO/OSI and RosettaNet communication reference model.The action layer provides business actions that act upon or in conjunction with accompanying information. The transaction layer provides transaction monitoring for sequences of message exchanges that support a unit of work. Either every party commits to the transaction or the transaction is rolled back completely. The process layer encapsulates the conditional choreography of a transaction for executing a PIP. The service layer provides network resources that perform network and business-related functions. The agent layer provides a communication interface for other applications. The message handling layer provides asynchronous delivery of information. The transfer layer provides a mechanism for information transfer between uniquely named network resources. The security layer allows for a secure communication connection, which leverages digital signatures to implement authorization and authentication. RosettaNet uses OBI as a subset of its enabling technology, adding more functionality within the data formatting area. It leverages XML rather than EDI (OBI was created to use EDI) to move information from point to point. (Although many EDI-like semantics are maintained, XML was selected for its compact and simple nature, and its acceptance in the market.) PIP CommunicationAs we noted earlier in this chapter, the fundamental requirement of a PIP is to exchange business data between trading partners. RosettaNet-compliant networked applications receive data using a standard format that all systems and humans in the loop can understand. Those who created RosettaNet PIPs created RosettaNet messages by using the set of elements and codes defined in the RosettaNet business and technical dictionaries. The set exists as a baseline from which PIP teams create message-exchange specifications and precisely define the values and codes that are assignable to each of the data elements all of which are part of the PIP implementation guidelines. These guidelines are sent as a document from RosettaNet to trading partners and RosettaNet solution partners. The guidelines define the vocabulary, structure, and allowable data element values and value types for each message exchange. Moreover, PIP specifications enable the development of interoperable applications. Each message has three parts: the Preamble Header, the Service Header, and the Service Content. This information is typically packaged for exchanges as MIME messages. PIP Message StructureRosettaNet business messages consist of a message header and a message body, and both the header and body are a well-formed XML document. The header and body are encoded inside a multipart/related MIME message. The message preamble section of the MIME message contains elements that are global to the RosettaNet service, and those that are common to the Service Header and Service Content. This information is specified as a DTD that is common across all messages. The message header is also specified using a DTD that is also common across all messages. There is a separate DTD or XML schema for each message, and that DTD or XML schema is used to validate the body of the messages. The idea behind a common message header DTD that is separate from the message content DTD is to support the logical segmentation of validation steps, which include validation of grammar, sequence, schema, and content. Grammar and sequence validations are performed against the message header DTD, and validation of message content is deferred until the schema validation step. When this mechanism is used, the message header may be valid even when the content is not. RosettaNet has this structure in place so trading partners can send failure messages. The message content is specified in individual PIPs, and each PIP has one or more "actions" that are defined by the schemas or DTD contained in the message. RosettaNet Networked Application ProtocolsRosettaNet leverages most native Internet protocols, including HTTP and TCP/IP. The TCP/IP protocol provides the functionality defined for the transport layers. Sockets and SSL are OSI session layer protocols. RosettaNet and B2B Application IntegrationIt is a safe bet that RosettaNet will shape the way we view intercompany process integration as it supports the goal of supply chain integration. To date, it is the most sophisticated standard available. This sophistication is due to the fact that it takes both processes and data into account, defining common processes and points of integration within a vertical industry. Other trading community standards have yet to deliver both layers and won't, unless they can get everyone on the same page for both application semantics and technology. Sometimes we forget that even in the world of high technology we still have to deal with the psychology of people. The real strength of RosettaNet is not the technology, it is the fact that this organization got many people in a larger vertical industry (high technology) to define and agree upon a standard. What's more, it has succeeded at clearly defining the value of using such a standard as well as how new technology, including XML, fits into the framework. To its credit, RosettaNet built upon past success, reusing what worked with EDI. The future is clear in RosettaNet. As organizations seek to open automated trade, they have to agree upon processes and semantics, an agreement that has thus far been frustratingly elusive. |