Looking back at the first blog posts I think the themes touched are still valid.
The first post from June 2009 was about data architecture. 2000 years ago, the roman writer, architect and engineer Marcus Vitruvius Pollio wrote that a structure must exhibit the three qualities of firmitas, utilitas, venustas — that is, it must be strong or durable, useful, and beautiful. This is true today – both in architecture and data architecture – as told in the post Qualities in Data Architecture.
A recurring topic on this blog has been a discussion around the common definition of data quality as being that the data is fit for the intended purpose of use. The opening of this topic as made in the post Fit for what purpose?
Diversity in data quality has been another repeating topic. Several old tales including in the Genesis and the Qur’an have stories about a great tower built by mankind at a time with a single language of all people. Since then mankind was confused by having multiple languages. And indeed, we still are as pondered in the post The Tower of Babel.
Thanks to all who are reading this blog and not least to all who from time to time takes time to make a comment, like and share.
During my engagements in selecting and working with the major data management tools on the market, I have from time to time experienced that they often lack support for specialized data management needs in minor markets.
Two such areas I have been involved with as a Denmark based consultant are:
The authorities in Denmark offers a free of charge access to very up to data and granular accurate address data that besides the envelope form of an address also comes with a data management friendly key (usually referred to as KVHX) on the unit level for each residential and business address within the country. Besides the existence of the address you also have access to what activity that takes place on the address as for example if it is a single-family house, a nursing home, a campus and other useful information for verification, matching and other data management activities.
If you want to verify addresses with the major international data managements tools I have come around, much of these goodies are gone, as for example:
Address reference data are refreshed only once per quarter
The key and the access to more information is not available
A price tag for data has been introduced
In Denmark (and other Scandinavian countries) we have a national identification number (known as personnummer) used much more intensively than the national IDs known from most other countries as told in the post Citizen ID within seconds.
The data masking capabilities in major data management solutions comes with pre-build functions for national IDs – but only covering major markets as the United States Social Security Number, the United Kingdom NINO and the kind of national id in use in a few other large western countries.
So, GDPR compliance is just a little bit harder here even when using a major tool.
The upcoming application of the EU General Data Protection Regulation (GDPR) is an attempt to harmonize the data protection and privacy regulations across member states in the European Union.
However, there is room for deviance in ongoing national law enforcement. Probably article 87 concerning processing of the national identification number and article 88 dealing with processing in the context of employment is where we will see national peculiarities.
National identification numbers are today used in different ways across the member states. In The Nordics, the use of an all-purpose identification number that covers identification of citizens from cradle to grave in public (tax, health, social security, election and even transit) as well as private (financial, employment, telco …) registrations have been practiced for many years, where more or less unlinked single purpose (tax, social security, health, election …) identification numbers are the norm most places else.
How you treat the employment force and the derived ways of registering them is also a field of major differences within the Union, and we should therefore expect to be observant of national specialties when it comes to mastering the human resource part of the data domains affected by GDPR.
Do you see other fields where GDPR will become national within the Union?
This blog is in English. However, as a citizen in a country where English is not the first language, I have a problem with English. Which flavour or flavor of English should I use? US English? British English? Or any of the many other kinds of English?
It is, in that context, more a theoretical question than a practical one. Despite what Grammar Nazis might think, I guess everyone understands the meaning in my blend of English variants and occasional other spelling mistakes.
The variants of English, spiced up with other cultural and administrative differences, does however create real data quality issues as told in the post Cultured Freshwater Pearls of Wisdom.
When working with Product Data Lake, a service for sharing product information between trading partners, we also need to embrace languages. In doing that we cannot just pick English. We must make it possible to pick any combination of English and country where English is (one of) the official language(s). The same goes for Spanish, German, French, Portuguese, Russian and many other languages in the extend that products can be named and described with different spelling (in a given alphabet or script type).
You always must choose between standardization or standardisation.
Multi-lingual capabilities is one of the core capabilities in the product information sharing service Product Data Lake.
During our market introduction, we have had three milestones:
Product information can be exchanged in multiple languages – or rather cultures, being a combination of a language and a country. Product Data Lake was born with this core capability back in September 2016.
Product information can be defined in multiple languages. Our February 2017 release introduced metadata in multiple cultures.
Product information can be handled in multiple languages. Today we have released our multi-lingual user interface. The idea behind Product Data Lake is actually not, that you should spend much time in the user interface. You only need to set up the automation of product information exchange. Now, you have the possibility to do that in your preferred language.
However, this is not a fait accompli. Mañana, there will be more feinschmeckerei. Next multi-lingual feature will be access to classification and metadata in many languages from various general and industry standards for product information starting with the ETIM standard for technical products.
“The average financial impact of poor data quality on organizations is $9.7 million per year.” This is a quote from Gartner, the analyst firm, used by them to promote their services in building a business case for data quality.
While this quote rightfully emphasizes on that a lot of money is at stake, the quote itself holds a full load of data and information quality issues.
On the pedantic side, the use of the $ sign in international communication is problematic. The $ sign represents a lot of different currencies as CAD, AUD, HKD and of course also USD.
Then it is unclear on what basis this average is measured. Is it among the +200 million organizations in the Dun & Bradstreet Worldbase? Is it among organizations on a certain fortune list? In what year?
Even if you knew that this is an average in a given year for the likes of your organization, such an average would not help you justify allocation of resources for a data quality improvement quest in your organization.
I know the methodology provided by Gartner actually is designed to help you with specific return on investment for your organization. I also know from being involved in several business cases for data quality (as well as Master Data Management and data governance) that accurately stating how any one element of your data may affect your business is fiendishly difficult.
The below figure shows the cross border data flows on this planet. There are inter-regional data flows and there are flows between the worldwide regions:
Now, a small part of this data will be product data exchanged between trading partners participating in global business ecosystems. While I have no data on if product data are distributed by the same proportions as data in general, it will be a qualified guess, that the picture will look somewhat the same.
Exchanging product data across borders has some challenges:
Language is an issue. Product data will eventually have to be translated into the language of the end buyer, if this is not the language in which the product data originally are provided. The definitions (metadata) of product data will also be subject to translation. Even the language of the transmission tools would not be in English all over.
Regulations around product data are different from country to country.
The cultural content of the optimal data describing a product in structured data elements and related digital assets are different between countries and regions.
Our company Product Data Lake has relocated again. Our new address, in local language and format, is:
1058 København K
If our address were spelled and formatted as in England, where the business plan was drafted, the address would have looked like this:
The Old Seed Office
39 Harbour Street
Copenhagen, 1058 K
Across the pond, a sunny address could look like this:
39 Harbor Drive
Copenhagen, CR 1058
U.S. Virgin Islands
Now, the focal point of Product Data Lake is not the exciting world of address data quality, but product data quality.
However, the same issues of local and global linguistic and standardization – or should I say standardisation – issues are the same.
Our lovely city Copenhagen has many names. København in Danish. Köpenhamn in Swedish. Kopenhagen in German. Copenhague in French.
So have all the nice products in the world. Their classifications and related taxonomy are in many languages too. Their features can be spelled in many languages or be dependent of the country were to be sold. The documents that should follow a product by regulation are subject to diversity too.
Handling all this diversity stuff is a core capability for product data exchange between trading partners in Product Data Lake.
One of my current engagements is within jewelry – or is it jewellery? The use of these two respectively US English and British English words is a constant data quality issue, when we try to standardize – or is it standardise? – to a common set of reference data and a business glossary within an international organization – or is it organisation?
Looking for international standards often does not solve the case. For example, a shop that sells this kind of bijouterie, may be classified with a SIC code being “Jewelry store” or a NACE code being “Retail sale of watches and jewellery in specialised stores”.
A pearl is a popular gemstone. Natural pearls, meaning they have occurred spontaneously in the wild, are very rare. Instead, most are farmed in fresh water and therefore by regulation used in many countries must be referred to as cultured freshwater pearls.
My pearls of wisdom respectively cultured freshwater pearls of wisdom for building a business glossary and finding the common accepted wording for reference data to be used within your company will be:
Start looking at international standards and pick what makes sense for your organization. If you can live with only that, you are lucky.
If not, grow the rest of the content for your business glossary and reference data by imitating the international or national standards for your industry, and use your own better wording and additions that makes the most sense across your company.
And oh, I know that pearls of wisdom are often used to imply the opposite of wisdom 🙂