Information and Data Architecture

Are these the same things, are they maybe similar, or are they truly different?  If they are different, then what is the difference and how should they be treated from an architecture practice point of view?

Within your company do you have data architecture or information architecture? Should you have one,  both, or maybe neither?

Like me, I am sure that for many of you these question have come up over and over again.  Let’s take a look at each and see how they are defined and what the difference is.  Then you will be better placed to decide what they mean to you and your organisation.

There are a number of quite useful definitions on the Internet.  The first port of call for me was DAMA,  and for those not familiar with DAMA it is an International non-profit, vendor-independent, global association of technical and business professionals dedicated to advancing the concepts and practices of information and data management.  DAMA’s first chapter was founded in 1980 in Los Angeles – sadly, we don’t have any New Zealand chapters as yet so if you are interested please give me a shout!   There are other great sources that I have also referenced and used in the discussion below, all well worth reading.

Information Architecture

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.”

A white paper by the State Department of Public Works in Queensland, Australia on Information Architecture, 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.  This includes presentation in electronic (digital), print, audio, video, image, graphical, cartographic, physical sample, textual, or numerical 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.”

This tells us that when looking at Information Architecture it is concerned with the relationships of knowledge, information, and, yes, data, from any source that is relevant and useful to the business.

As an architectural domain I think that perhaps information architecture is an often misunderstood domain, it is something that sits logically between the business and application domains and provides that oh so  important connection between business processes, applications and the data that is used by an organisation.  One of the key problems with this misunderstanding is the fact that the term “information architecture” was adopted by the web development industry to refer to the way in which web content is designed and structured.   Information Architecture is not just about sitemaps and  wireframes, and although ontologies and taxonomies are created and used extensively this is done as a way  to determine the meaning of information  and how information relates, so that technologies can be identified or created to support working with the information in a meaningful way.

Data Architecture

The DAMA definition of data is as follows::

“[Data] is the representation of facts as text, numbers, graphics, images, sound or video.”

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)

Data architecture is concerned with gathering and storing the data. Knowing the source and its use, the data architect is focussed on selecting the best technologies to move and store the data to ensure its availability and integrity for business use.

A 2011 Sybase white paper “What’s In YOUR Architecture?,” depicts a five-level pyramid of “domains of enterprise architecture.”

The figure starts at the top with Business and descends through Information, Applications, Data, and Technology. This paper defines Information Architecture as “a holistic view on the flow of information in an enterprise, including the effects of the processes that act upon the data.”

Data Architecture is defined as describing the way data will be processed and stored; how the data flows,  the data models (conceptual, logical, physical, and dimensional).and is predominantly used by solutions teams,  “Data Architecture (DA) is a component of Information Architecture, and is concerned with the design and use of data in structured formats such as databases and file systems. A data architect models the data in stages (conceptual, logical and physical) and must relate the data to each process that consumes (uses) that data.”

David Loshin and Charles Roe “The Utilization of Information Architecture at the Enterprise Level 2013”; assert that “Information is data put into action. Where a specific data element may exist on a server somewhere in one format or another, it has lesser business value until it is integrated with other data elements into an information package. Information is data with context. So where Data Architecture is necessary to contain and organize the manifold data resources into a manageable system, Information Architecture is necessary to combine those resources into a structure that allows the dissemination of that information to be captured, shared, analysed, utilised, and governed throughout an enterprise, across all lines of business, within all departments, with confidence and reliability.”

Chris Aitkin (from EA) summarises very well in stating that  “Information architecture provides the means to view and categorise the information required to support and enable business processes. By understanding its alignment with process we can begin to identify the value of the information and how critical it is to a business. In this way information architecture provides a means to scope and prioritise activities like master data management, application portfolio management, and data warehousing. “ How data are physically structured and managed is the business of data architecture and the discipline of data management.”

From these definitions it seems obvious  that  information architecture is something much broader in scope than data architecture, and  that Information Architecture is a set of tasks and procedures that are more strategic in their nature than Data Architecture:

Information and Data in the EA Practice

How then should we manage these two separate but related architecture domains? As two distinct architecture domains or as a specialisation of one or the other? The descriptions show us that the two do have a connection, but they are recognisably different in nature and each one addresses a specific set of concerns for a particular stakeholder community. Information architecture today covers a broad spectrum of interrelated disciplines such as master data management, data warehousing, business intelligence, enterprise information integration and many more whereas data architecture is more focused towards an application (e.g. CRM, ERP) and concerned with structured data and the more technical aspects of applications and database design.  Each domain provides a perspective on making information more usable and valuable and they leverage approaches and principles of the other.

From an EA practice perspective it may work better to keep them together, and to have data architecture as an area of specialisation within information architecture (management). This will enable the information “master plan” to establish the longer term blueprints that will allow for the development of an integrated and useable information ecosystem. The creation of the information ecosystem needs architects that can attend to all aspects of data and information. If treated as completely separate domains then we run the risk of things being considered in a vacuum without regard to the wider information ecosystem, or the needs of the organisation.

Whatever route you choose however, will be dependant on having a clear understanding of your organisation and the environment in which it operates, the maturity of the EA practice, and the availability and capability of required resources and skillsets. From a skillset and perspective it would be worth exploring a “day in the life of” information and data architects alike to help determine the focus areas for your given organisation. Ultimately, It is the responsibility of the EA practice to determine the most effective way to fulfil the mandate of each.

Amanda Parkes, Senior Consultant Architect at Cyma Limited

Email: amanda.parkes@cyma.co.nz  Twitter: @cymaltd

LinkedIn: https://www.linkedin.com/in/amanda-parkes-26a82a9

Creative Commons License
This work is licensed under a Creative Commons Attribution 4.0 International License.