Changes between Version 5 and Version 6 of ISO15926Primer_PeekAt15926

Show
Ignore:
Timestamp:
11/16/11 04:55:23 (12 years ago)
Author:
gordonrachar (IP: 75.156.216.35)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ISO15926Primer_PeekAt15926

    v5 v6  
    22 
    33= A Peek at ISO 15926 = 
    4 ---- 
    5 [[PageOutline(2-4,Contents,inline)]] 
    64 
    7 == Abstract == 
     5The '''ISO 15926 Primer''' has been replaced with '''An Introduction to ISO 15926''', a free download from Fiatech. 
    86 
    9 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. 
     7This page is out of date and has been depricated. 
    108 
    11 ISO 15926 makes this situation easier in three ways: 
     9If you reached this page from a link in another web page please inform the webmaster. 
    1210 
    13   * ISO 15926 is a ''public'' dictionary that all applications can map to. 
    14   * ISO 15926 is ''extensible'' so that the public dictionary can adapt to new developments. 
    15   * ISO 15926 is designed to be extensible ''quickly'' so new items can be used right away. 
     11For a peek at the new book and instructions on how to download a copy please follow this link. 
    1612 
    17 ---- 
    18  
    19 == Common Data Definitions == 
    20  
    21 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. 
    22  
    23 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. 
    24  
    25 To make mapping between software applications more robust an organization can make a "Dictionary" of the meanings of all the columns in its databases. 
    26  
    27 [[Image(Peek01.JPG, 450px)]] 
    28  
    29 '''Figure 1 - Common Dictionary of Database Definitions''' 
    30  
    31 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". 
    32  
    33 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.) 
    34  
    35  
    36 ||'''Engineering App'''||'''Dictionary ID'''||'''Description'''||'''Units'''|| 
    37 ||tag_no||szTag||Tag Number of a plant object||   || 
    38 ||dia||dDia||Nominal Diameter per ASME/ANSI B36.10||  || 
    39 ||len||dLen||Pressure Class per ASME/ANSI B16.10||   || 
    40 ||temp||dTemp||Normal Operating Temperature|| degF|| 
    41 ||press||dPress||Normal Operating Pressure||psig|| 
    42 ||ifc||dateIFC||Issued for Construction Date||yyyymmdd|| 
    43  
    44  
    45 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. 
    46  
    47 ||'''Construction  App'''||'''Dictionary ID'''||'''Description'''||'''Units'''|| 
    48 ||id||szTag||Tag Number of a plant object||   || 
    49 ||dia||dDia||Nominal Diameter per ASME/ANSI B36.10||  || 
    50 ||cl||dLen||Pressure Class per ASME/ANSI B16.10||   || 
    51 ||temp||dTemp||Normal Operating Temperature|| degF|| 
    52 ||press||dPress||Normal Operating Pressure||psig|| 
    53 ||ifc||dateIFC||Issued for Construction Date||yyyymmdd|| 
    54  
    55 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. 
    56  
    57  
    58 === Benefits of a Common Dictionary === 
    59  
    60   * Complexity is hidden.  The developer of the Construction Application does not have to know anything at all about the Engineering Application. 
    61   * 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. 
    62   * Easy to reuse on the next project. 
    63  
    64 === Complications of a Common Dictionary === 
    65   * Someone has to heard the cats together to decide on the meaning of each term and what to call them. 
    66   * 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. 
    67  
    68 In short, there's more initial work in making a common standard, but you get to reuse it many times. 
    69  
    70 == Reuse == 
    71  
    72 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. 
    73  
    74 ||'''Procurement App'''||'''Dictionary ID'''||'''Description'''||'''Units'''|| 
    75 ||tag||szTag||Tag Number of a plant object||   || 
    76 ||dia||dDia||Nominal Diameter per ASME/ANSI B36.10||  || 
    77 ||len||dLen||Pressure Class per ASME/ANSI B16.10||   || 
    78 ||ifc||dateIFC||Issued for Construction Date||yyyymmdd|| 
    79  
    80  
    81 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. 
    82  
    83 [[Image(Peek02.JPG, 450px)]] 
    84  
    85 '''Figure 2 - Reuse''' 
    86  
    87 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. 
    88  
    89 === Benefits of a Common Standard === 
    90  
    91  * 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. 
    92  
    93  * 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. 
    94  
    95 === Complication - Mergers and Acquisitions === 
    96   * 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? 
    97  
    98 === Complication - Speed of Changes === 
    99  
    100   * 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. 
    101  
    102 What we need is a publicly-available extensible dictionary that can be updated quickly, within the time-frame of a typical database mapping project. 
    103  
    104 == Public Extensible Dictionary == 
    105  
    106 [[Image(Peek03.JPG, 500px)]] 
    107  
    108 '''Figure 3 - Public Extensible Dictionary''' 
    109  
    110 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. 
    111  
    112 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. 
    113  
    114 == RDS/WIP - The ISO 15926 Public Extensible Dictionary == 
    115  
    116 ISO 15926 provides an almost-publicly-available, extensible dictionary that can be updated quickly.  It is 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. 
    117  
    118 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. 
    119  
    120 == Next == 
    121  
    122   * [wiki:ISO15926Primer_BusinessProcesses Primer: Focus on Business Processes] 
    123  
    124 ---- 
     13  * [wiki:ISO15926Primer An Introduction to ISO 15926] 
Home
About PCA
Reference Data Services
Projects
Workgroups