Data is not information, neither is data architecture the same as information architecture, despite the two terms often being used interchangeably. The situation is not helped by TOGAF 9.1 which, while it defines data architecture, has practically nothing to say on the subject of information architecture.
Things are even further confused by the term ‘information architecture’ being used within the web development industry to exclusively refer to the way in which web content is structured.
In this post I’d like to go some way to sketching out what an information architecture is concerned with, its value, and how we might construct such an architecture.
Let’s start by defining information as: data + context. Data without context is meaningless. For example, take a column of floating point values in a database table – while a developer might be able to discern something about the meaning of the values by physically inspecting the database table and column names – the values are meaningless to the naive user until they are presented on a computer’s screen in a field labelled “Cholesterol level (mg/dL):”
This distinction between data and information is captured by the concept of the information asset.
Information assets (and not data assets or data objects) are the subject of information architecture. An information asset is defined as the combination of one or more data sources managed and communicated by a system. The system via its presentation layer is responsible to manage the context in which the data is presented to communicate the correct intended meaning. A ‘system’ may be implemented using paper-based, manually maintained or electronic technologies.
An information asset, like other assets has value and a life-cycle. The value of an information asset varies over its life-cycle and is dependent on the quality of the underlying data, as well as, characteristics of the system that manages it (e.g., system responsiveness, accessibility). The discipline of information management is typically how the information asset life-cycle is managed.
Information assets are categorised (non-exhaustively) at a conceptual level as:
These high level categories are used to further group information asset logical types needed within an enterprise in order to successfully conduct its business (e.g., budget reports, strategic plans, performance dashboards, financial statements, project reports, medical records, trade blotters, organisational charts, job schedules, calendars etc).
Each logical type has a life-cycle and can be implemented physically using current or future state data sources and systems. Moreover, different underlying technologies are more suited for different information asset categories (e.g., dimensional vs relational database design, OWL vs XML, or spreadsheet vs data visualisation tool), and so an information architecture begins to scope out the type of technologies and systems required.
Future state implementations aim to improve the value of an information asset by reducing overall implementation cost, or improving information accuracy, security, quality or timeliness of information presentation. For example, a future state information architecture might identify an information asset (e.g., a performance dashboard) that today is implemented using a manually maintained spreadsheet, to be implemented in future as a SharePoint based dashboard automatically populated with data from a data warehouse or a number of external data sources in near real time.
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. The physical structuring of data should be transparent to the information architecture as it is typically mediated by the application layer. For example, a single data warehouse is likely to store and manage the data that appear in multiple information assets.
Common benefits of developing an information architecture include consolidation of reports and improved reporting consistency. It is not uncommon for the same logical type of information asset (e.g., monthly project status report) to be implemented across an organisation using various configurations of systems and data. An information architecture highlights these opportunities for business improvement.
Information architecture is an often misunderstood, and overlooked architectural domain that logically sits between the business and application domains. It provides a crucial link between business process and, the applications and data used by an organisation.
By identifying the information assets necessary to conduct business, and how these are structured, information architecture scopes the requirements for current and future data technologies while abstracting away the complexities of application design and data management.
With the current popularity of Big Data, and increasing data storage and cost, the need to understand thevalue of information derived from this data is as important as ever.
The simple acquisition of more data, much like the acquisition of more technology no longer represents a competitive advantage in itself. Rather, it is the deliberate, intelligent and targeted use of data and technology that is likely to lead to disruptive information driven market opportunities.
Information architecture provides the view to identify the business value of information and the means to achieve a more targeted approach to the use and management of both data and technology within the enterprise.
Originally posted as 'Data is NOT Information' on the Enterprise Architects website.