When talking master data management we usually divide the discipline into domains, where the two most prominent domains are:
- Customer, or rather party, master data management
- Product, sometimes also named “things”, master data management
One the most frequent mentioned additional domains are locations.
But despite that locations are all around we seldom see a business initiative aimed at enterprise wide location data management under a slogan of having a 360 degree view of locations. Most often locations are seen as a subset of either the party master data or in some cases the product master data.
Industry diversity
The need for having locations as focus area varies between industries.
In some industries like public transit, where I have been working a lot, locations are implicit in the delivered services. Travel and hospitality is another example of a tight connection between the product and a location. Also some insurance products have a location element. And do I have to mention real estate: Location, Location, Location.
In other industries the location has a more moderate relation to the product domain. There may be some considerations around plant and warehouse locations, but that’s usually not high volume and complex stuff.
Locations as a main factor in exploiting demographic stereotypes are important in retailing and other business-to-consumer (B2C) activities. When doing B2C you often want to see your customer as the household where the location is a main, but treacherous, factor in doing so. We had a discussion on the house-holding dilemma in the LinkedIn Data Matching group recently.
Whenever you, or a partner of yours, are delivering physical goods or a physical letter of any kind to a customer, it’s crucial to have high quality location master data. The impact of not having that is of course dependent on the volume of deliveries.
Globalization
If you ask me about London, I will instinctively think about the London in England. But there is a pretty big London in Canada too, that would be top of mind to other people. And there are other smaller Londons around the world.
Master data with location attributes does increasingly come in populations covering more than one country. It’s not that ambiguous place names don’t exist in single country sets. Ambiguous place names were the main driver behind that many countries have a postal code system. However the British, and the Canadians, invented a system including letters opposite to most other systems only having numbers typically with an embedded geographic hierarchy.
Apart from the different standards used around the possibilities for exploiting external reference data is very different concerning data quality dimensions as timeliness, consistency, completeness, conformity – and price.
Handling location data from many countries at the same time ruins many best practices of handling location data that have worked for handling location for a single country.
Geocoding
Instead of identifying locations in a textual way by having country codes, state/province abbreviations, postal codes and/or city names, street names and types or blocks and house numbers and names it has become increasingly popular to use geocoding as supplement or even alternative.
There are different types of geocodes out there suitable for different purposes. Examples are:
- Latitude and longitude picturing a round world,
- UTM X,Y coordinates picturing peels of the world
- WGS84 X, Y coordinates picturing a world as flat as your computer screen.
While geocoding has a lot to offer in identifying and global standardization we of course has a gap between geocodes and everyday language. If you want to learn more then come and visit me at N55’’38’47, E12’’32’58.
Liliendahl on Data Quality 
Good points.
We have, for example, a city called Washington (at least one) in every state in the USA.
We have a state called Washington.
And we have a special administrative district commonly called Washington. The full name of this administrative district is Washington DC, where DC means “District of Columbia.” There is no Columbia, of course. And while Washington DC is not a state in many ways (no voting elected representatives in the Federal Government) it has many state like aspects, including taxation, police forces, etc. So it’s included on drop-down lists as a state.
Somehow we find this not very confusing.
-XC
Thanks for commenting Cliff. Good example of place name confusion within a country. I think the fact that Washington is both the capital placed on the East Coast and a state placed on the West Coast is confusing to many foreigners as well. Somehow I’m pleased that it is confusing to you too 🙂
Excellent read with many points applicable to business intelligence, particularly in terms of localized marketing efforts.
By the by, to help with the confusion between District of Columbia versus Washington State, news stations here in Seattle often refer to DC as “the other Washington.” 🙂
Thanks for a good read.
Thanks a lot Marie. I think you are right that exploiting the location attributes of master data within business intelligence is a main driver for getting location data right, unambiguous and standardized.
Good post Henrik,
Matter of fact, there is a London in Ohio too.
You are right. The key characteristic of location master is that it is often closely linked to other master data. Mainly customer or product. This off course like in the case of customer and product master, requires enterprise-wide distribution and is one of the most rapidly evolving data.
Coming to globalization aspect, It’s hard to come up with one standard notion with current format of address. Tirthankar Ghosh recently wrote an article about addresses in India where he explains different patterns used for addresses there. I can only imagine how difficult the standardization rule sets can get with so many formats and variants.
If I were to sort different domain according to their complexity, I will probably put it on the top. (At worst, right after product domain).
And thanks for mentioning again about geocodes. If only this technology evolves well, I see some light at the end of the tunnel.
Prashanta, thanks for adding in. I think your right, that location master data is an evolving area, which may be a bit strange, since a lot of activity is happening in the cloud these days.
Great post, thanks for raising a good point plus Geocoding as a possible way out of the dilemma, it’s probably just not readable enough for humans – Maybe.
How are you proposing we should model the Location entity/domain in a MDM repository and how should that entity be connected to other domains?
Thanks,
Andy
Thanks for joining Andy.
Indeed, geocoding is an exciting aspect of location data management. We also had a discussion on that a few days ago on Prashanta C’s blog post called Geocoding: Accurate Location Master Data.
The question about how to model the location domain and how the location domain relates to the customer and product domain is very close to me, as I have recently worked with one of the MDM technology vendors on features for multi-domain MDM including customer (and supplier), product and related location data.
My take, with an offset in the customer domain, is exemplified in the blog post A Place in Time . I feel perhaps a whole series of blog posts coming up on this subject. Thanks for asking.
Hi Henrik,
Some interesting additional considerations for you In the telecommunications industry location is very important for two special reasons: (1) in the retail landline space, you need to know where the physical connection is, and (2) in the wholesale/physical networks domain you need to know very accurately where your physical equipment si located – where are your exchanges, where are your cabinets, and where is your copper/fibre in the ground. For both of these purposes postal addresses are of no help! Often initial connections may have no postal address (for instance new subdivisions), and much of your network doesn’t live at a postal address at all. When we need to overlay this with our customers (e.g. we want to lay a physical cable to a customer’s address) we are faced with the intersting problem of matching a postal address to a physical location – introducing even more issues.
Doug
Very good example of industry related requirements Doug.
I also remember one job I did a few years ago for a telco, which was about matching postal addresses for a marketing campaign with equipment positions. Here I converted the two data sets to UTM positions and then, using good old Pythagoras, calculated which addresses was within a suitable distance to be able to use the offered service.
We are increasingly using GIS data to accurately identify locations. A lot of time we have cross-street addresses which are business valid but Postal invalid. With increasing reliance on GIS and harnessing it in different channel we have significantly reduced anomalies.
I commented the same on Linked in…
In your article are you more like hinting at keeping good standardized/geo-coded addresses. We have seen value proposition in it a lot of our implementation. Ask any business user the $ amount lost for returned mails and they will tell a ton of horror stories of lost revenues. I remember to have asked a similar Q in my current initiative and when I explained the significance the User was pretty dumb struck.
When I looked at the article title I was thinking of something else…
At our MDM implementation we were actually toying with the idea of location master for last several months. The model brings significance when you think of certain companies who serve a particular location which rarely changes even though the one occupying the spot changes. Think of a utility company like the Gas/electricity provider. Except for certain market areas your choice of these utilities is one and they are going to serve the same location no matter whether it is occupied by Micky D or King B. For them a 360 on that location is very important – knowing who has occupied the particular location over say last 5 years and how the revenue has changed with the nature of business might be of good importance. They will also obviously need Customer Master to identify the big $ customers.
Thanks for adding in Sudip. I also remember a data matching assignment with a domestic customer base from a large Danish brewery (guess which one). Here the weight was more on the address (and the line of business) than usual, as bars, cafés, canteens change legal entity all the time, but, as you say, is on the same spot.
All the discussions so far have focused on the “physical” aspect of the location, whether using zity, state, zip kind of coding progressing to geocoding which is becoming more commonplace. However, I beleive there is a need to abstract that notion atleast from master data perspective. A location in my mind is a higher level entity as opposed to the “address” that the physical aspect manifests itself (as being discussed).
A physical address can play multiple roles in any given situation — for a small business it could manifest as the corporate/headquarters location as well as possibly shipping and billing locations (among others). In the case of a multi tenant building, it could be associated with multiple customers or multiple customers and one of company’s locations.
It may just be a case of semantics address, location but an important one nevertheless. Master data should account for that distinction and as appropriate for an organization maintain the information in a granular manner. We also have to keep in mind that the association of the physical address to its role/use within an organization is temporal in nature.
I follow you completely Rangarajan.
We have the same model in the customer domain, where we have to look at the customer as a party in the real world probably belonging to some kind of hierarchy (household, company family tree) and then the customer as a role that may be different to various departments in the enterprise.
The relation between an entity in the customer domain and an entity in the location is a time dependent relation for sure, and may vary by the customer role.
All very intersting.
I have see stores referred to as locations. Stores have numbers. That number becomes the accounting “location,” and server which is in the store has the same number as an ID as the store. This makes some systems issues easier until a small store shares the server of the large store. Accouting gets messy during store relocation.
All of this comes about because we conflate multiple concepts: geographic location, inventory location, political jurisdiction, accounting responsibility, deliverabiltiy, findability. In somes context, a Go-To-Meeting ID might be the location of the meeting.
Creating an maintaining separate physical constructs for all of them will certainly find resistance. But, to keep it straight, we do need to separate the issues.
Thanks John, good wrap up on the semantic challenge related to location.