Information vs Data: Semantic Shifts

Discussion for EA874 Topic 3 > Data/Information Architecture Layer

Post # 1

I think the way to sort out enterprise architecture along the domains of information and data  is by going back and sorting out our semantics, i.e. what we mean by terms like information and data.  I admit that I am myself guilty of mix-ups, because there are many contexts that we can really get away with using one term for the other. However, by clearly defining what we mean by data, information and knowledge – and how they interact with one another – it should be much easier to develop our taxonomies to communicate our work in the EA discipline.

Information vs. Data vs. Knowledge

Neil Ingebrigtsen's blog at infogineering.net is an example of useful discussions on the differences between data, information and knowledge. Neil works backwards and starts with what knowledge is. Knowledge is not just what we know, but what we know based on our personal beliefs and expectations. This makes sense, and explains knowledge in the way we speak of the "giant network of ideas, memories, predictions, beliefs, etc." What are the sources of this knowledge? Data and Information.

Similar to many popular discussions, "data" are the basic facts of the world, physiologically perceived with the senses, and eventually processed by the brain. Thus, data are raw, unorganized facts that need to be processed. Data can be something simple and seemingly random and useless until it is organized, and combined with other data elements. When data is processed, organized, structured or presented in a given context so as to make it useful, it is called information. Simple example: We can have a notion of 6 feet, but it only remains as data until perhaps we associate it with say a person,  on which it becomes information about that person -- and so on.

So here's why I was drawn to Neil's discussion: "When people confuse data with information, they can make critical mistakes. Data is always correct (I can’t be 29 years old and 62 years old at the same time) but information can be wrong (there could be two files on me, one saying I was born in 1981, and one saying I was born in 1948). He keenly notes that information captures data at a single point in time, and that data changes over time. "The mistake people make is thinking that the information they are looking at is always an accurate reflection of the data." And I agree with him that by understanding the differences between these, we can better understand how to make better decisions based on the accuracy of [information].

In summary, we can thus find the following to be a useful working taxonomy.
Data: Raw factual descriptions of the World
Information: Captured Data and processed to provide useful context.
Knowledge: Our personal use of information to create a map/model of the World

Bellinger et al, in their articles at systems-thinking.org, elaborates on the following so-called DIKW extension that includes wisdom, and invokes the scholarship of folks like R. Ackoff and N. Sharma on the evolution of this model for information use.

 The DIKW framework is used by many organizations. The diagram below shows the adaptation of the DIKW pyramid by US Army Knowledge Managers.




Semantic Shifts.

Going deeper now into investigating the nuances of Information Architecture and Data Architecture, I found a truly fascinating compilation of historical notes from Resmini, et al, (2011) on how our semantics shifted for the way we communicate the notion of Ïnformation Architecture." Their article speaks of Wurman's original contribution and vision that many think stills holds today, and which places Information Architecture as follows:

a.) the organization of  the patterns inherent  in data, making the complex clear; b.) the creation of the structure or map of information which allows others to find their personal paths to knowledge; c.) the emerging 21st century occupation that addresses the needs of the age focused upon clarity, human understanding, and the science of the organization of information.

Resmini's article becomes truly insightful when it narrates how the Rosenfeld-Morville team shifted the notion Information Architecture later to emphasize the importance of structure of and organization in website design i.e. what they call "Pervasive IA". Quite interesting to note that this shows how the disconnect to Wurman's past scholarship allowed for this shift to happen. At any rate, I think although the emphasis has shifted, we can still see how scholarly intuition continues to place structure and organization -- in the conceptual and logical context of Wurman's classical IA, as the overarching notion associated with what we call Information Architecture.

What about Data Architecture?

Ultimately, I come back to this old NIST Enterprise Architecture reference diagram of the late-1980's, shown below  to serve as my own reminder that we can separate Information Architecture with what we call Data Architecture. The NIST Enterprise Architecture Model is a five-layered model with each layer are defined separately but are interrelated and interwoven. The model defined the interrelation as follows:

• Business Architecture drives the information architecture
• Information architecture prescribes the information systems architecture
• Information systems architecture identifies the data architecture
• Data Architecture suggests specific data delivery systems, and
• Data Delivery Systems (Software, Hardware, Communications) support the data architecture.

The hierarchy in the model is based on the notion that an organization operates a number of business functions, each of which requires information from a number of sources, and each of these sources may come from any one or more operational systems, which in turn stores organized data in any number of data systems.

Mapping out these nuances onto our conceptual-logical-physical modeling constructs, we can perhaps intuitively associate the conceptual, semantic, and logical relationships at the Information Architecure layer, the processing logic, approach, and data systems at the Data Architecture layer, and leave most of the suppporting technology components for database engines, storage,  and I/O infrastructure to the realm of Infrastructure Architecture.

Thus for what we usually call Information or Data Architecture, we may perhaps find this deconstruction useful.



References:

Neil Ingebrigtsen (n.d.). The Differences Between Data, Information and Knowledge. http://www.infogineering.net/data-information-knowledge.htm

Gene Bellinger, Durval Castro, Anthony Mills. Data, Information, Knowledge, and Wisdom. http://www.systems-thinking.org/dikw/dikw.htm

Andrea Resmini, Luca Rosati (2011). A Brief History of Information Architecture. Journal of Information Architecture.  http://journalofia.org/volume3/issue2/03-resmini/