Section 20.2. What are semantic standards, and how do they help build IT solutions?

20.2. What are semantic standards, and how do they help build IT solutions?

Semantic standardssometimes referred to as business standardsare an attempt to preserve meaning and lower the risk of misinterpretation as data is moved from one IT system to another. Without semantic standards to govern the structuring and tagging (with XML, for example) of individual chunks of data, what System A may perceive as valuable and vital information, System B may reject as gibberish.

Thus, semantic standards are absolutely key to today's IT activities, in which users are trying to weave together enterprise services, enable IT systems to collaborate, and link to their business partners and customers as closely as possible. While it's possible for a set of business partners to work out their own, closed set of semantic standards, it's much more practical and economical to employ the growing number of standards that industry associations are hammering out. The vast majority of the cost of building connections between systems derives from the work involved in understanding the semantics and business logic involved. Clearly, if the semantics are standardized, integration costs can be reduced significantly.

20.2.1. Are semantic standards simply sets of XML tags?

Semantic standards encompass more than the vocabularies of XML tags that many vertical industry groups have hammered out for their own purposes. Those vocabulariesthe high-tech industry's RosettaNet is a typical examplefocus on the format or content of electronic documents that two business partners are to exchange. And there is no question that those formats are critical to the successful use of enterprise services.

But document formats alone are not sufficient to define what's needed in a complex, cross-industry interaction. Of equal importance is the sequencealso called choreographyin which documents or data are to be exchanged. Because each industry's formats and choreographies are different, ESA has introduced a common understanding of those variances. Over time, ESA will encompass the standard enterprise services that businesses will need in order to interact at this level. As things stand today, there is too much variation in how each industry and company defines the way it does business. Some of this is necessary; for example, the aerospace industry and the steel industry have different business requirements, which can also vary by locale. The value-added tax, for example, is relevant in Europe but not in the U.S. Much of what businesses do is the same, however; sending and paying invoices is pretty much universal across industries, companies, and locales.

What is needed is a series of service interfaces, standard service definitions, or enterprise services that are defined in a way that can help partners operating in quite different industries to conduct their basic business processes efficiently, yet allow for controlled variation where needed. Ideally, this standardization would cover all aspects of enterprise services, from their naming"order management"to the network addresses where those services are accessibleintegration.companyX.comto the precise sequence of steps that a service automates.

SAP is helping to improve all of these types of semantic standards. The company is working closely with the UN/CEFACT, for instance, which has developed and continues to maintain the definitive international EDI standard, called UN/EDIFACT. SAP also chairs UN/CEFACT's Technologies and Methodologies Group (TMG), which is developing next-generation business information and collaborative process standards.

Semantic standards being supported by ESA include the following:

Data definitions

Define the format, structure, and semantics of the data exchanged between businesses (for example, on orders and invoices) as well as information exchanged between and stored by applications.

Collaborative process definitions

Sometimes called choreography standards or process orchestration, these standards define how two or more businesses collaborate by defining the sequence in which documents are exchanged. For example, an order sent to a supplier usually results in the return of an order response.

Core Components Technical Specification (CCTS)

Provides precise semantic definitions for business documents and processes.

Naming and Design Rules (NDR)

Specify how the core components developed by CCTS (such as address, full name, and line item) can be mapped to XML in a consistent way.

20.2.2. What are core components and how do they relate to SAP's concept of semantic standards?

Core components are reusable semantic building blocks that can be combined in various ways to create shared libraries of well-defined and widely interoperable business documents and processes. Many vertical industry groups have expressed strong interest in building business documents based on core components. Defining the guidelines for the development of core components is the task of SAP's Technique and Methodologies Group. Core components also serve as the basis of the enterprise services that SAP is creating. This ensures that business apps built on SAP NetWeaver will be able to map easily to the semantic standards that industry groups are developing.

Core components are chunks of data that are frequently used in most or perhaps all industries and that therefore lend themselves to being assigned standardized definitions and formats that don't vary from industry to industry. This frees standards-setting bodies in each industry from having to come up with their own definitions, encourages reuse of the components within higher-level and more complex documents, and reduces risk for all involved.

Examples? Typical core components are items such as amount, line item, and address. Every industry deals in such information, so there's no practical reason for each industry to define those entities uniquely. Indeed, adopting these core components reduces the cost of mapping between different formats and XML vocabularies used in different industries.

The need for core components is strongest in industries, such as chemicals, where producers do most of their business with customers operating in entirely different industries. Chemical makers, for instance, sell to the automotive, pharmaceutical, retail, aerospace, and even high-tech industries. Were the standards groups in each industry to adopt their own, unique definitions of "order" and "price," a chemical maker would face a dilemma when trying to integrate IT systems for the sake of closer collaboration and e-commerce. Should it insist that the other industries do things its way, or should it try to adopt each of the other's standards?

In contrast to electronic data interchange (EDI) standards, the core components approach does not attempt to define every possible type of data and every possible field that a data record might contain to serve every possible industry. Instead, it aims for the much more reasonable and practical goal of defining a minimum, or core, set of data items. Thus, each industry is free to build on this basic set and create the precise electronic documents it needs.