Introduction

This document focuses on the need for interoperability at the business process level and the benefits for companies of being able to mix and match different vendor solutions to address their requirements. When companies want to purchase business applications from multiple vendors, they have the difficult task of getting the business applications to work together without the benefit of controlling the integration of those business applications. Additionally, customers are struggling with the larger task of integrating all of their systems into a coherent information technology infrastructure to support their business.

By defining integration standards as an enterprise canonical model, application integration can be optimized for all, instead of having different costly point-to-point solutions between each business applications, businesses and software vendors benefit.

The definition of the enterprise canonical model is a “single source of truth” for a semantic language all enterprise applications can speak, for commerce worldwide, for enterprise applications such as enterprise resource planning (ERP), purchasing, order management, finance, customer management, quality data, and more. The long-term scope is to enable all current and future enterprise application integration in a syntax-neutral manner to keep pace with rapidly changing technology landscape and resource skillsets. Other applications of canonical model include business intelligence and reporting, to normalize and aggregate business data across applications to provide a consistent vocabulary to generate business insights (see Annex B).

The enterprise canonical model reflects many thousands of person hours contributed by the Open Applications Group1 (OAGi) member companies.

The contributors represent the people who are building, testing, and implementing their business applications in thousands of companies worldwide.

It is anticipated that future parts of this standard will:

— Provide specification of a physical data model that underlies the model-based approach to data exchange specification. The data model is an adoption of the ISO 15000‑5 standard conceptual model, as is implemented in open-source application named Score.
— Discuss the content, including the actual nouns and messages (business object documents - BOD), of the standard. The document contains a discussion of the notion of business context, including its definition and use to specify precisely profiles (i.e. subsets of) nouns. A list of integration scenarios is provided, which are the basis for determining detailed business processes that are essential for the definition of business context. Each scenario is provided with links to specific BODs appearing in the scenarios. Additionally, list of all nouns, which make up the standard, is provided. Finally, differing delivery approaches for (including canonical, standalone, and database) and alternative formats (JSON Schema,^[¹^] XSD, etc.) are described.
— Describe the platform aspect of the standard whereby the user can create his or her own noun or message (BOD). The purpose of the platform package is for its content to be reused by other organizations. The submission describes the library of core component and fields that may be used to create new messages.
— Describe the serialization of ‘profiles’ into XML schema^[²^][³^] definition. Also, the submission describes mappings from the BIE profiles to XML schema.
— Describe the serialization of semantic ‘profiles’ into Javascript Serialized Object Notation (JSON) schema Draft 4, and Open API Specification 3.0 schema object representation. JSON syntax has been increasingly popular with business application and API developers ever since the introduction of mobile and cloud-based technologies due to its more compact payload size for specific instances. Combined with the Representational State Transfer (REST) architectural style, JSON syntax is currently what development resources expect to use for modern application integration and what students are learning in college and vocational schools.

Much of OAGi member research has suggested a hybrid approach for REST JSON, taking the ‘best of’ various existing and historical efforts to standardize metadata definitions for REST include OData,^[⁴^] JSON Schema and Open API Specification. The OAGi RESTful Web API Specification describes this hybrid of OData’s URI Conventions,^[²⁰^]JSON Schema Draft 4 (as published by the Internet Engineering Task Force - IETF) which influenced ‘Swagger 2.0’, vendor specific approaches such as OpenAPI,^[⁵^] and ultimately, the Open API Specification 3.0.

Mappings from the BIE profiles to JSON schema are provided, as well as best practices to incorporate in request/response (HTTP GET)^[⁶^][⁷^] and synchronous one-way (HTTP POST, PUT, PATCH, DELETE) methods.

BS ISO 5054-1:2023

Specification for an enterprise canonical model - Architecture

Current

Published:

31 Mar 2023