Managing corporate data in a way that lets knowledge drive business success has always been a challenge. Managing it in a cloud environment has compounded that overall task enormously. Heightened awareness is critical.

Even before we had computers, we had the need to track business data in ways that enabled enterprises to understand such basic information as inventory, cash outlays, and income; to make better decisions on what products and services to add in the future; and to support predictions of market evolution more effectively than "seat-of-the-pants educated guesswork." Big Data in a cloud environment has created knowledge possibilities that were simply on wish lists a decade ago and promises to continue to provide substantial rewards to organizations that can make fullest use of analyzing everything there is to know about their customers and markets.

But therein lies the rub. The sheer amount of data potentially available for analysis has grown exponentially as cloud storage technology and advances in gathering and parsing available data have improved. It's reaching the point that if your organization is a megacorporation with lots of financial and staff resources, you can access what you need to stay competitive. If not, well, your business venture may not survive competition against those who do have such access. This is the rather stark reality that's starting to come into focus as businesses compete for a pool of such talent as data analysts, data architects, and data scientists—which isn't growing fast enough to meet demand.

Traditional vs. Cloud Data Management

To illustrate, let's start with the monumental changes inherent in the evolution from using traditional on-premises data management to managing data that is stored in the cloud. Traditional data management practices developed in environments that were exclusively local or on-premises. Databases stored on in-house equipment used software stored on local area networks attached to central servers to give organization analysts and managers answers to basic questions about who the customers were and how the organization was serving them. Analysis tools, network connections, data integration algorithms, programming assistance, and hardware maintenance workers were under the full control of each company's own executives, who could make fixing problems and formulating new ways of looking at data a top priority for their own employees.

These aspects of data have always been important, but now that the cloud has become such a dominant medium in business data analysis processes, the ability to draw better information from larger amounts of data faster and more accurately than the competition has caused a turning point. The opportunities of scale are evolving in favor of those with access to a larger pool of better data. This crisis makes data quality more important than ever, even as data quantity itself has become a kind of quality. In short, cloud computing has morphed into an "information habitat" in which data has become analogous to food. Whoever gets the most access to the best of it is most likely to survive. Those left behind are increasingly likely to remain behind until they are themselves consumed by larger and more efficient competitors. It may even be reaching the point where public-cloud users are gaining an advantage over private cloud users because the private-cloud users are living in a data universe that's inherently limited by the enterprise's own ability to gather and store relevant data. Add to that the advantages of using a large service provider that can offer better APIs, data-integration tools, reporting apps, and data-checking algorithms than a smaller enterprise may be able to deploy, and the playing field starts to look even more sloped.

This situation puts an unprecedented new emphasis on Data Quality Management (DQM), particularly in cloud environments. DQM can be defined as the art of bringing together a combination of the best technology, processes, and people skills to ensure the accuracy and utility of data to meet an organization's goals. Making the best use of the best-quality data is looking like the best way smaller enterprises can overcome the scale advantages of competitors with access to more data, more places to store it, and more ways to slice and dice it.

Data Quality Pitfalls

What's the most important factor in maintaining DQM? Sadly, this is a great critical question to which there is no clear answer despite scads of recommendations that vary significantly depending on the authors’ point of view (e.g., marketing or technical) or the types of career-saving tools for data managers that their companies happen to be offering. Too many suggestions are horribly vague: "promote good data governance," "collaborate with data providers," "validate and cleanse your data," and "make sure your data is secure."

Well…duh! Maybe what's needed is to take a step back and take a broader view, even if that simply highlights many common pitfalls to achieving real data quality.

Data accuracy seems like a good place to start. Back in the ’70s, when all programming was being done with chisels on stone tablets, "garbage in, garbage out" was a favored explanation for how coding mistakes led to useless results. The joke was old 40 years ago, but the adage still holds true for data in the age of cloud. Today, data can't just be accurate; it must be in a consistent format, it must be refreshed frequently, and it must be "complete," whatever that may mean in your business context.

And quality issues don't stop there. If any of the data happens to have been fat-fingered in by a human using a keyboard, you'll need some kind of algorithm to watch for typos, mismatches between fields that expect to get a five- or nine-digit ZIP code into which six digits are actually entered, fields whose entries are skipped altogether, and duplicate records whose contents are off by a single character and therefore don't show up as actual duplicates. (Just to name a few common instances.)

Then there's the matter of how, in some contexts, the data coming in (even from an automated source) isn't as intrinsically important as raising a flag if there's some kind of change to the data coming in. There's also the problem of hidden data, which occurs because the tried-and-true data tool an accounts manager has always used ignores a field that today might show an opportunity, but that data point remains locked in a silo with no one the wiser.

Data sources can present challenges. We'll assume your enterprise is correctly tracking its own customer transactions and has some workaround for data inconsistencies from those sources, but what other useful information is out there that might be germane? Market conditions? Data on competitors? News on supply chain problems for your providers? Changing consumer trends? Is there even someone in charge of looking for this additional information at your enterprise, or is it just vaguely left up to some executive committee meeting quarterly?

How does your enterprise (or cloud provider) handle your data? Could there be any data volume or distribution issues that could hamper accurate data analysis? Have there been any schema changes that might affect your company's results? Do some data sources report later than others so that some data isn't included in a particular analysis? Has a problem at some server farm dictated a failover? Do your enterprise's needs still match what's specifically in your service contract?

Are Your Data Tools Up to Date?

Another potential weak spot is how well your data analysis algorithms are working. Unless you've upgraded them in the past year, they're probably not as up to date as they could be. If you're reliant on in-house or provider-sourced tools, you could be missing out on something useful. There are many companies (too numerous to mention here) that are constantly coming out with new tools for slicing and dicing data, making consistency checks of existing data, and looking for fields left blank (null values) or other errors.

Faulty data models can be a source of problems. Two of them are referential integrity and relationship cardinality. The former refers to information that's stored or displayed in different places but is missing correlation. For example, a hospital patient might have been recorded as having received a procedure with a numeric code, but that code doesn't match the name of a corresponding procedure. The latter happens sometimes when two data objects have more than one relationship in a certain context. For example, a patient may live at a certain address, but the same address may be valid for another patient who, let's say, lives in the same apartment building. Other data-model problems can include missing validation constraints, which check that values stored in certain database fields are standardized and properly formatted or are using an incorrect formula for producing values calculated from existing other fields in a database.

Remedies for Data Nutrition

Hopefully it's clear that fixing DQM problems involves designating a person or department to check for these problems and asking some of the above questions constantly. It's important that this be a primary responsibility for those assigned to keep an eye on it, not let it be delegated to some IT programmer with a dozen other priorities and projects on her plate. It's also important to create a culture in which data accuracy and quality are identified as of paramount importance. Are employees being sufficiently trained to watch out for errors? Do they understand how data is structured and how to properly query information that is important to the enterprise mission?

Organizations should have a person or department that's specifically empowered to address all the issues raised so far, as well as many others there hasn't been room here to discuss, such as data governance rules, staying up to date on specific government laws and regulations that affect data, and riding herd on a cloud service provider, should you have one. Ideally, it will be a data architecture team with enough imagination to think about all these contingencies and enough clout to identify data challenges and bring them to the attention of those who can do something about them without simply having to accept the explanation that "we can't afford it right now."

Take DQM Seriously

DQM has become too important to let its stewardship slide. If your organization doesn't have someone—or better, a group of people—paying attention to DQM concerns, your enterprise may no longer be running fast enough to avoid becoming prey on the data savannah. Waiting to worry about it after the buyout will be too late.

John Ghrist has been a journalist, programmer, and systems manager in the computer industry since 1982. He has covered the market for IBM i servers and their predecessor platforms for more than a quarter century and has attended more than 25 COMMON conferences. A former editor-in-chief with Defense Computing and a senior editor with SystemiNEWS, John has written and edited hundreds of articles and blogs for more than a dozen print and electronic publications. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

Primary storage vs. secondary storage: What’s the difference?

Planning for Multicloud Environment Management

Cloud Accelerators: A Chameleon of Many Colors