I am married to another man. This sometimes poses dilemmas for many businesses. I often receive mail addressed to “Mr. and Mrs. Tom Bilcze” or “You and your Wife”. Even worse, it’s a mishmash of both of our names.
It’s a classic case of poor data quality. Many databases assume a married couple is a male-female union. This is especially true of older legacy data. Many have no means to designate the sex of the parties or just have never made an effort to keep their applications and data current and accurate.
There is a cost to poor data quality in these missteps. Nothing turns me away from a charity, business or cause when they make this error. The data architect in me points directly to the database design. Isn’t this just a case of adding a sex code to the party and adding marriage type to the related party?
Data quality is one of the legs of data governance. Data quality relies on data cleansing, data transformations and consistency of data dolman of values. Although these are valid points to consider when assuring the quality of data, it starts much earlier in the data lifecycle.
The data architect plays an important role in providing the enterprise with quality data. If data is modeled incorrectly, there is a good chance that data of poor quality will be present despite the most thorough cleansing, impeccably mapped transformations and agreed upon domains.
The data architect bears great responsibility in getting the data quality ball rolling in the right direction. Here are five are in which data architects should focus on in their daily activities.
- Accurately implementing business requirements – The data architect must be very thorough in transforming requirements into entities and attributes. It requires us to have frequent and detailed conversations with our business users. A missing or wrongly interpreted business rule can wreak havoc in the implemented database.
- Knowing where data is and isn’t – Data is everywhere. The data architect often does not know every instance of a piece of data. The data architect needs to perform due diligence in finding existing data sources and tracing the lineage of data. It keeps us from introducing yet another data quality dilemma father down the data pipeline.
- It’s about the enterprise and not the project – Project managers want their project done quickly, on-time and under budget. The data architect’s enterprise view of data may collide with the project centric view. The data architect must speak of the quality of data as an enterprise asset based on the project-at-hand delivering data accessible and reusable by the enterprise.
- Metadata is not just an entry in a data dictionary – Metadata is more than crafting a good definition. Accurately documenting the characteristics of data pays off down the data stream. Data is becoming increasing exposed to larger audiences. The quality of their decisions and implementations is based on how well they understand the data. It all starts with metadata in the data model.
- Don’t forget to connect the dots – The data architect can create a logical model that is a masterpiece; fully attributed, well documented and spot on to the business needs. Our work does not stop there. It needs to map to the physical data model which must connect to the implemented database. Maintaining forward and reverse traceability can take some effort but is worth the cost in the end. This is a foundation on which quality data needs to be built.
Tom Bilcze