Version 4 (modified by gordonrachar, 15 years ago)

--

A Peek at ISO 15926


Contents

  1. Abstract
  2. Common Data Definitions
    1. Benefits of a Common Dictionary
    2. Complications of a Common Dictionary
  3. Reuse
    1. Benefits of a Common Standard
    2. Complication - Mergers and Acquisitions
    3. Complication - Speed of Changes
  4. Public Extensible Dictionary
  5. RDS/WIP - The ISO 15926 Public Extensible Dictionary
  6. Next

Abstract

To make the process of mapping applications together easier and more reliable, an organization can make a common data dictionary for all applications to use. This can take considerable effort just to create, but pays off when connecting another application to the Confederation of Applications. A major complication is revealed when two organizations, each with its own common dictionary, have to communicate.

ISO 15926 makes this situation easier in three ways:

  • ISO 15926 is a public dictionary that all applications can map to.
  • ISO 15926 is extensible so that the public dictionary can adapt to new developments.
  • ISO 15926 is designed to be extensible quickly so new items can be used right away.

Common Data Definitions

Even if an organization accepts the cost of mapping all of its applications together one-to-one, it is usually impractical for a large organization to do so. Mapping two similar applications together might be straight-forward; mapping 250 applications together (even though all of them probably don't have to be mapped to all of them), is not.

Confederations of Applications (as we called them in the previous section) tend to become either fragile (when one application changes many links break), or ossified (when applications delay upgrades just so that links do not break.) Even if an organization uses commercial "Middleware" to make mapping as easy as possible, continual maintenance will be required as the individual applications go through their own lifecycles.

To make mapping between software applications more robust an organization can make a "Dictionary" of the meanings of all the columns in its databases.

Error: Macro Image(Peek01.JPG, 450px) failed
Attachment 'wiki:ISO15926Primer_PeekAt15926: Peek01.JPG' does not exist.

Figure 1 - Common Dictionary of Database Definitions

In this example, someone has created a dictionary containing the meaning of the attributes of the Line List. Perhaps there has been dictionary design meetings for interested parties throughout the organization, or perhaps someone simply made an "Executive Decision".

Using the dictionary, the developer of the Engineering Application has determined the appropriate definitions that apply to the columns in his database. Without having to change the Engineering Application in any way, he builds an export function that extracts the appropriate data values to some neutral medium. (It could be to a comma-seperated text file, XML, an Excel spreadsheet, or something else, as long as all business partners know the form.)

Engineering AppDictionary IDDescriptionUnits
tag_noszTagTag Number of a plant object
diadDiaNominal Diameter per ASME/ANSI B36.10
lendLenPressure Class per ASME/ANSI B16.10
tempdTempNormal Operating Temperature degF
pressdPressNormal Operating Pressurepsig
ifcdateIFCIssued for Construction Dateyyyymmdd

Similarly, the developer of the Construction Application would use the same dictionary and determine the appropriate definitions that apply to the columns in her database.

Construction AppDictionary IDDescriptionUnits
idszTagTag Number of a plant object
diadDiaNominal Diameter per ASME/ANSI B36.10
cldLenPressure Class per ASME/ANSI B16.10
tempdTempNormal Operating Temperature degF
pressdPressNormal Operating Pressurepsig
ifcdateIFCIssued for Construction Dateyyyymmdd

Again, without having to change the Construction Application in any way, she builds an import function that reads the appropriate data values from a neutral file. One important point here is that she no longer has to know anything at all about the Engineering Application.

Benefits of a Common Dictionary

  • Complexity is hidden. The developer of the Construction Application does not have to know anything at all about the Engineering Application.
  • Semantic Precision in terminology. All parties would know the exact meaning of all the terms. For instance, there would be no doubt in your mind what dTemperature was.
  • Easy reuse. (More on this later.)

Complications of a Common Dictionary

  • Someone has to heard the cats together to decide on the meaning of each term and what to call them.
  • If an outside organization is part of the common dictionary there may be questions about releasing proprietary information. It could take a long time to get approval.

In short, there's more initial work in making a common standard.

Reuse

The value of a common dictionary is demonstrated when you want to link in a third application, say, when a purchasing agent wants to import information from the Engineering Application to a Purchasing Application. Instead of having to examine the contents of the Engineering Application's database, all a software developer has to do is consult the dictionary and determine the values he wants to use.

Procurement AppDictionary IDDescriptionUnits
tagszTagTag Number of a plant object
diadDiaNominal Diameter per ASME/ANSI B36.10
lendLenPressure Class per ASME/ANSI B16.10
ifcdateIFCIssued for Construction Dateyyyymmdd

The fact that the Engineering Application is exposing other data attributes is not of interest. The Procurement Application will simply choose the four data items it needs and use them.

Error: Macro Image(Peek02.JPG, 450px) failed
Attachment 'wiki:ISO15926Primer_PeekAt15926: Peek02.JPG' does not exist.

Figure 2 - Reuse

So creating the common dictionary made the first mapping exercise more difficult since someone had to create the data dictionary, but the second mapping exercise is free (provided, of course, that you don't need to define any new terms.)

Benefits of a Common Standard

  • Easy re-use. When the developer of the Purchasing Application wanted to import Line List information from the Engineering Application, he simply used the appropriate definitions from the public dictionary. The developer of the Engineering Application didn't have to do anything at all.
  • Robust. If the keepers of the Dictionary decide to extend the standard, for instance, to add another type of Pressure, they will simply make a new term. New linking applications will use the new definition if appropriate, but none of the existing functions will break.

Complication - Mergers and Acquisitions

  • Regardless of the size of the organization that creates the dictionary, eventually its sphere of interest will intersect the sphere of interest of another organization. A common example is when one organization acquires another. If both have their own dictionary, which of them has to change?

Complication - Speed of Changes

  • A public standard can become a victim of its own success. It may get so large it cannot change fast enough to keep up with the industry. STEP, first proposed in the early 1980s, is a good example of this. It was initially intended to be a medium of exchange of plant information by providing a data dictionary that was available for anyone to use. When it was adopted as ISO 10303 in 1994 it attained the status of an industry standard and some organizations implemented it. But changes are a major barrier. It takes up to seven years to implement a change.

What we need is a publicly-available extensible dictionary that can be updated quickly, within the time-frame of a typical database mapping project.

Public Extensible Dictionary

Error: Macro Image(Peek03.JPG, 500px) failed
Attachment 'wiki:ISO15926Primer_PeekAt15926: Peek03.JPG' does not exist.

Figure 3 - Public Extensible Dictionary

Figure 3 shows the same two applications where the developers need to include a new attribute, "Widget Color", in the Line List. Widget Color may have been in the Engineering Application all along, or it could have been added to support a particular plant project where Widget Color is important.

The developers of the two applications are free to modify their software in any way, since the inner workings of proprietary software is not a concern of the public dictionary. But when the developers exchange information, the public dictionary is affected. The time frame to implement and test the new function could be as short as a few days. If the new term, Widget Color, can be added to the public dictionary and approved within this time, the developers can continue to use the public dictionary. And since the dictionary is public, the new term will be available for anyone else to use as well.

RDS/WIP - The ISO 15926 Public Extensible Dictionary

ISO 15926 provides an almost-publicly-available extensible dictionary that can be updated quickly, called the Reference Data System/Work In Progress, or "the WIP" for short. After a short training period, available to all for the cost of putting it on, anyone can add a new term to the WIP. Provided only that it meets some basic Quality standards, new terms will be publicly available within five minutes. Over a period of time, expected to be about a year, the new term will be vetted by known ISO 15926 practitioners and will be given status so other organizations will have an indication of quality. But an important point is that the new term will never be deleted. Organizations using the brand new term do not have to be afraid of their software breaking suddenly.

As you may have imagined, there is still much more to ISO 15926 than what has been described here, but this shows the direction it is going.

Next


Home
About PCA
Reference Data Services
Projects
Workgroups