Eliminating "Ontario" confusion with a strong MDM/RDM program
Updated: Jun 13, 2018
Every year the MDM & Data Governance Summit brings master data and data governance practitioners and experts to New York for several days of peer-to-peer education, information sharing, and networking. One thing that sets the Summit apart is its emphasis on the voice of the practitioner. At the summit, the majority of the case studies are delivered by program teams. A wide range of topics are covered—everything from building business cases through change management. This year several of our customers participated, notably, Greg Gibson from Sabre. Greg, who is responsible for Sabre's MDM program and data architecture, provided pragmatic examples in the pre-conference tutorial on Reference Data Management and insights in the panel on Reference Data best practices. In the sessions and on the panel, Greg's concrete examples helped bring some of the more esoteric concepts to life. Here are a couple of highlights.
The semantics in reference data is critical
Greg illustrated the importance of semantics by demonstrating how Ontario is not Ontario. He gave the example of an unaccompanied minor that ended up in Ontario California instead of Ontario Canada.
From the technical perspective, Greg pointed out that what often appears as simple two-column code lists (airport codes) are complex hierarchies in disguise (airports by countries by regions). Then taking a step back, Greg focused on the risks created by poor reference data. He explained how social media has upped the stakes for everyone, especially for customer-facing (or B2C) organizations. "Back when this happened I'm sure it made the local affiliate's weird news segment." said Greg, "But today with Facebook and Twitter imagine the explosion of bad PR and outrage that would emerge when an irate parent posts how their minor child was sent to the wrong country."
How reference/master data and their relationships fit into transactions
A comment Greg made again and again was that it's not just the data values that matter, but how the data relates.
To bring this concept to life, Greg enumerated how a few of the domains (and their connections) are used in booking an airplane trip. We see how master and reference data domains:
Supplier/Airline with its references/connections to pricing, fare code, and schedules, and
Airports with its references/connection to countries, time zones, lat/long, and cities
are transformed into a PNR through the booking process. Greg emphasized that having consistency between airports (such as ONT) and their country (USA) helps preserve semantics eliminating confusion about where people are actually traveling.