Information and data – the words are seemingly interchangeable. Data can be information. Information, particularly with respect to business operations and processes, is data. In polite conversation this statement generally holds true. But when talking data strategy, information and data are entirely different beasts. Understanding their differences, and correctly handling the data strategy architectures of each, is vital if your organization is to get the most it can from its strategy.
Pioneering management consultant Peter Drucker once described information as “data endowed with relevance and purpose”. Examples of raw organizational data including sales revenue, operating costs, and customer retention rates, are essentially meaningless when analyzed as standalone totals; but once this data is set in some form of context, usually by combining it with other data, it transforms into information. The raw data of one month’s sales figures will give an organization absolutely zero insight into how they are performing, but give that data some historical context by showing it in relation to the sales figures of preceding months and you’ve now got tangible information on which to act. The more data combined, the greater the insights that can be garnered from it. Perhaps the sales figures are on an upward trend thanks to your organization entering a new market, or on the back of a new marketing initiative. In short, data can be thought of as the zeros and ones, whereas information is what those zeros and ones are trying to say.
As part of its data strategy an organization will require two ‘architectures’; one devoted to raw data, the other devoted to the information that builds on that data. An organization’s data architecture will define how data is to be collected and organized. Rules and practices must be created to govern the structures of databases and file systems, as well as the processes which connect the data to the areas of the organization that require it. It takes raw data and makes it digestible for the information architecture. Information architecture, on the other hand, aims to give structure to the process of converting the data into useful information. Once the data has been delivered with the help of the data architecture, the information architecture then takes over to convert that data into real insights.
As an example, a data architecture system might include extracting customer contact data from a CRM system alongside sales data from PaaS or local accounting system. Feeding that combination into an information architecture system, where it can be cleansed and modeled in meaningful ways, will unlock the data and release new insights into the relationship between customers and sales – by customer attributes, seasonal rhythms, sales channels, product lines, and more.
With data strategy now top-of-mind for any forward thinking organization, the subsequent focus on architectures is now stronger than ever. An organization’s approach to these architectures will inform its approach to its greater data strategy, perhaps more than many realize. The temptation when formulating architectural strategy is to aim for maximum control. A highly centralized, highly regulated approach to your data and information architectures may result from a data strategy that is inflexible and monodirectional.
As always, there is a happy middle ground, although this middle ground will shift depending on the needs and wants of your organization. But defining that middle ground will have to wait until our next article, when we tackle data truth.