What is the difference between Information Architecture and Data Architecture?
Christine Thomson, Architecture Lead, Instructor, Mentor & Consultant
No doubt, for many of you, this question has come up. Perhaps your organization has Information Architecture but no Data Architecture. Or maybe, you are in the reverse. If this is the case, it can be easy to
think that they are the same, just different names. I had the experience once of observing an innocent data architect expressing this understanding to an Information architect. I will never forget the rather harsh “correction” the data architect received.
It would seem, as new architecture disciplines emerge, which they have, and continue to do, one needs to be aware that there will be a period of confusion and negotiation to establish them. The case of Information Architecture versus Data Architecture is such a situation.
Let us look at how each is defined. Then, we can decide if both are actually needed.
Information, according to DAMA, is:
“data in context. Without context, data is meaningless; we create meaningful information by interpreting the context around data… The resulting information then guides our decisions.”
Another definition provided by the State Department of Public Works in Queensland, Australia, asserts:
“Information is any collection of data that is processed, analyzed, interpreted, organized, classified or communicated in order to serve a useful purpose, present facts or represent knowledge in any medium or form.”
They go on to say that:
“Information architecture is the means of providing a structured description of an enterprise’s information, the relationship of this information to business requirements and processes, applications and technology, and the processes and rules which govern it.”
From this, we can see that the key factor when looking at Information Architecture is that it deals with the relationships of knowledge, information, and, yes, data, from any source that is relevant and useful to the business.
In information architecture, ontologies are created and utilized extensively. This is done as a means to determine how information relates, so that technologies can be identified or created to support working with the information in a powerful and meaningful way. Examples of technologies supporting information architecture are search engines and semantic web, e.g.
Resource Description Framework (RDF).
Looking back to DAMA, we get the following as the definition of data:
“[Data] is the representation of facts as text, numbers, graphics, images, sound or video.”
We can then understand that data architecture is:
“composed of models, policies, rules or standards that govern which data is collected, and how it is stored, arranged, integrated, and put to use in data systems and in organizations.” (Business Dictionary)
The focus for data architecture is on gathering and storing the data. Knowing the source and its use, the data architect is tasked with choosing the best technologies to move and store the data to ensure its
availability and integrity for business use.
Information and Data in an EA practice:
Having provided these descriptions, we can see that the two do have a connection, but are indeed distinct. The question is, do we need to have these as two separate architecture disciplines or are they merely
a specialization of one or the other? While academically, the answer is that they are in fact distinct, in an EA practice it may actually work better to have one as an area of specialization within the other.
Organizations are challenged to determine if separating the the two into their own domain discipline will enhance the architecture practice. By seeing that they are different, requiring different skills and resources, the EA program can ensure that each discipline is fully supported.
However, there is overlap between the two. Treating them as unique domains does come at a cost. By keeping them together, resources can be pooled which could be more advantageous. But this raises the question of, which way should it be done? Since information architecture has a broader scope in terms of its view of sources and data architecture requires some basic context for the data it supports, one could easily argue that data architecture should be under information architecture. Nevertheless, it could also be argued that data architecture is foundational for information architecture to happen. Information architecture might be seen as a specialization of data architecture and would benefit from a mature data architect’s practice which has at the ready governance, principles and policies to leverage.
There is no one right answer. It requires an understanding of the business, maturity in the EA practice, and readiness and availability of the needed skills.
I have seen organizations that address information architecture as part of their data architecture program. I have also seen data architecture as a sub-domain of information architecture. And in some organizations, I have seen information architecture happening, but without the label. What I have not seen is the absence of either.
Both exist. Both are being done. It is on the EA practice to determine the most effective way to fulfill the mandate of each.