Third-Generation Information Architecture

The struggle for commercial supremacy through information is being fought on two fronts: information structures and enabling technologies. Business managers can turn to today’s third-generation information architecture to help their organizations distinguish information as a corporate resource from mere tactical IT.

IT gives organizations the capacity to process and analyze information, though its deeper value involves information itself, not the technology manipulating it. However, the typical corporate budget for technology is still much greater than the budget for information structure and design. Third-generation information architecture inherently addresses this imbalance, redirecting information strategy toward managing information as a corporate resource.

For the past 20 years, IT has produced various architectures, including those for the enterprise, applications, business, and data. We use the word architecture whenever we want to define a high-level overview of interrelated components and when the relationships among them are complex and difficult to understand. It can mean, for example, a skeletal framework representing the overall view of a detailed technical specification, emphasizing the parallels between IT and the art and science of building construction. The common theme is that architecture is used to organize information about a topic in order to manage it in a structured way; for example, network architecture includes information about nodes and devices that help manage the network itself.

No single term universally describes an encompassing framework for managing information as a resource. In this context, information architecture combines the background theory, design principles, structures, and diagrams representing the practical means of managing and gaining insight from information.

Back to Top

Changing Needs

The architectural approach to managing information originated in the 1980s, as the increasing complexity and size of individual information systems prompted development of architecture programs considered broader “in scope, in organizational impact, and in process” [3] than the earlier project-based development of standalone applications. Information architecture was a mechanism “for defining and controlling the interfaces and integration of all of the components of the system” [4].

The basic idea of information architecture reflected a fundamental need to impose better management structures on system development. Today, with more extensive links between systems and the increasing volume of information in corporate intranets and the public Internet, the concept is even more relevant. Current thinking by practicing architects shows three ways the early ideas have been adapted to meet contemporary needs. Most important is the focus on information, followed by technology, emphasizing the use and value of information content as a competitive resource distinct from the systems supporting its use.

Focusing on technology alone is like preparing a meal by equipping the kitchen with cooking utensils, then ignoring the quality of the ingredients. The first priority is therefore a thorough understanding of the principles and dimensions underlying the use of information; the word “dimension” denotes the key factors that should be included in an information architecture.

Users and architects alike have a greater understanding of the use of information through the capture of information about information, or metadata. This understanding goes much deeper than simple definitions of information items and their structure to include business theories and patterns; they help make sense of information, tips, and guidelines needed to use and interpret information, alternative representations, and user examples and scenarios. Better understanding and knowledge of information use helps control huge volumes of data while providing an opportunity for the innovative uses of information.

Finally, users and architects use measurements to demonstrate the value of and return from information (RFI), while feedback and learning ensure the architecture, management tools, and content stay current and relevant.

Back to Top

Three Generations

To help understand the evolution of information architectures, it is useful to look at the features of the early ones to highlight the specific ways they are being advanced today. The following review is based on the historical use of information architectures, notably the Zachman framework, Westpac Banking Corp.’s CS90 project, IBM’s industry architectures of the late 1980s, and the Information FrameWork, a collaborative project involving more than 150 financial institutions, along with ideas from today’s research and projects.

Information architecture has evolved through three distinct generations (see the table). First-generation architectures were published and described in the 1980s for developing standalone applications. The second generation applied these ideas at an enterprise level across more than one application. The current, or third generation, focuses on information rather than technology.

First- and second-generation information architectures (late 1970s to mid-1990s) used a single diagram to show everything; for example, the Information FrameWork [1], developed for IBM by the author Roger Evernden in 1990–1991, used a two-dimensional diagram to provide a quick memorable overview of the architecture that was easy to grasp and helped popularize a complex and difficult subject. However, it is impossible to describe all the outputs from any process, including information architecture, in a single diagram; many projects never achieve their goals by limiting themselves in this respect.

A single diagram can be compelling, as well as too simplistic, by overlooking important factors and confusing the user by trying to communicate too much information at once. For clarity, several diagrams are required. Third-generation information architectures solve this problem by reflecting this complexity and describing the key aspects of the architecture as distinct dimensions. Relating aspects to dimensions, anyone can illustrate two or three dimensions with a few pen strokes in, say, a matrix or a set of diagrams to illustrate each relevant feature of the architecture.

Another characteristic is the parallel drawn between information architecture and the design of physical buildings [4]. Architecture is most readily associated with buildings, making the comparison easy for anyone to grasp, but the emphasis on information is different; for example, the spatial dimension is important in buildings, whereas the epistemological dimension (whether knowledge is explicit or implicit) is a key aspect of information architecture. It is important for architects to know the limitations of any analogy; parallels are useful only when they identify information principles. Comparisons with other disciplines or professions (such as graphic designers and librarians) and further analogies (such as with musical orchestration and harmony) improve our understanding of information architecture.

The first and second generations emphasized technology solutions rather than an organization’s use of information. Following the emergence of knowledge management during the 1990s as a key business function and the availability of a broad range of information via the Internet, the discussion became more about information content and content management. Today, the third generation reflects the need for separate technology and information architectures. Applying this distinction makes it easier for information architects to understand user requirements while ensuring that information architecture is not ignored and the RFI investment is improved.

Early architectures were based on developing standalone applications through a traditional waterfall approach. Architecture described the products or outputs from the requirements, to design, to construction, and finally to delivery of an application. The emphasis was on deliverables in the development of a unique system. Building construction consumes resources that are then no longer available, so the building analogy worked well for developing standalone systems that didn’t have to account for reuse.

However, the reuse of components is key to the development of contemporary systems; as a result, three overlapping processes—develop components, build applications from components, and manage reuse—have replaced the waterfall approach. Information, as an intellectual resource, is readily replicated and reused. Every type of information, business pattern, and mental model is potentially reused in many different processes and contexts; for example, if someone gave you a penny, you would have the penny and the other person wouldn’t; but if that person gave you information, both of you would have it.

Just as a building’s design must be placed in the context of planning regulations, the availability of components and materials, and conformance with the principles of architecture, engineering, and design, so too information architecture requires a wider context. Complementing changes to the sequential development process, today’s information architectures account for the reuse of components and the integration of elements into the overall system.

Underlying principles are difficult to discern because early attempts at defining information architecture glossed over or simplified the background and rationale behind their frameworks. Architecture based on inappropriate design principles can be difficult or impossible to implement, while hidden or conflicting principles result in inconsistency or confusion.

An example of inconsistency is when items appear together as a set but cannot be compared because each is actually different from the others. Another complication arises when combinations of architectural dimensions are inappropriate. In a building’s architecture, the height, width, and length of a room are separate dimensions; it would be misleading and counterproductive to try to show the shape of a room by somehow merging width and height together. In information architecture, responsibility (such as for information ownership, accuracy, and creation) is distinct from representation (see the figure); for example, combining representation and responsibility in the same dimension suggests only one responsibility for each representation (such as ownership of an entity relationship diagram or creation of a data design). It does not explain who creates the entity relationship diagram or who owns the data design; this can be confusing or misleading even on a small scale.

Separating the two dimensions in a matrix of representations (entity relationship diagrams and data designs) against responsibilities (creation and ownership) highlights the four options. Making principles and dimensions explicit is the starting point for third-generation information architectures in order to identify and correct these problems.

The process for developing an information architecture is similar to many other decision-making activities. Here, we lay out a simplified overview of the most important steps.

Deciding information management requirements. The consequences of choosing the wrong information architecture can be catastrophic; failing to support the needs of the organization, the effort will ultimately be abandoned. Information is complex; any architecture described in a single chart or diagram is likely to be insufficient for such needs. A single diagram suggests the architecture is at best two-dimensional, whereas most organizations need to consider at least four or five dimensions. The best technique for covering relevant issues is to present architectural options in the form of checklists, rather than as a predefined framework. Reviewing the options makes it easier to make relevant selections and produce an architecture tailored to the organization’s specific business needs.

The starting point is to be absolutely clear about the business need to improve the use of information and the results the organization most wants to achieve. Information requirements must come before technology considerations. The output from this step includes principles, information design guidelines, standards, and naming conventions. It also decides which dimensions are in fact part of the architecture. The most important, required by all architectures, identifies the types of information needed. When key dimensions are overlooked, the resulting architecture is difficult or impossible to implement because the underlying logic is problematical. Making the principles and rationale explicit is important for communicating the thoughts and ideas behind the design. The more clearly defined, the easier they are to use.

Creating a management toolkit. Requirements determine which architectural dimensions are relevant and in turn govern which tools are needed. A toolkit includes checklists, charts, and diagrams derived from using the dimensions, either on their own or in combination. Dimensions transform a complicated problem into a simpler one by subdividing it into segments allowing people from different fields of expertise to collaborate—the intellectual equivalent of the division of labor. At the same time, they provide a cohesive structure or blueprint for a long-term information strategy, permitting the gradual development of the information resource. The number of dimensions and the range of possibilities mean that tools can be tailored to the conditions and context of use, ensuring the right tools are available to implement the architecture.

A common tool is a simple table or grid structure comparing one architectural dimension against another. First- and second-generation architectures (such as the Zachman framework [4] and the Information FrameWork [1]) were often based on a single table of this type and are referred to as frameworks. More sophisticated architectures, based on third-generation design principles, are multidimensional, using a set of interrelated charts showing the architecture from different viewpoints.

Defining an information map. An information map charts relevant information items, as well as the links and groupings among them. It contains information about information (beyond metadata), including explanations about how it is or could be used, who uses it, how it is structured, and why it is structured in a particular way. The better the quality of this material, the more useful it is. Because a map of the information landscape is complex, and in many respects unique to a particular organization, it is difficult for competitors to replicate.

Traditionally, this mapmaking is where the IT department would have created data and process models (or OO models) of the business and its supporting systems, but such models are often too technical in terms of both content and structure to meet the full potential of an information map. Industry models, also known as content or reference models, are also used to develop information maps. Like data and process models, they usually trace their origins to IT, having been developed by technology vendors for a variety of industrial categories (such as insurance and retail).

Third-generation information models, based on multidimensional architectures, provide a detailed formal representation of generic business and organizational knowledge. Ideally, the related descriptions, definitions, and examples should be in the language of business management rather than the jargon of technology. Technology models are supplemented with theory and practice from business and management books, extended to cover information processed manually, and enhanced with comments based on knowledge and experience. Information about how information is used has great potential for improving the effectiveness of information as it might be used and for creating innovative new ways to generate revenue.

Using the information resource. Finally, third-generation architectures are not static; they evolve through experience and use. Key processes measure RFI while capturing learning and feedback. When there is a serious commitment to information as a resource, this effort is rewarded in terms of business agility, productivity, effective use of information, and profitability [2]. Comments from employees, customers, and suppliers—from anyone using the information—help adapt the architecture to meet the overall needs of the organization. A well-established information resource becomes the key tool enabling an organization to both sense business opportunity and respond to it profitably.

Back to Top

Conclusion

Information architecture has changed dramatically over the past 20 years, becoming a sophisticated, multidimensional tool for managing information as a corporate resource distinct from technology architectures and frameworks no longer the exclusive province of the MIS department. Contemporary organizations need an information architecture and complementary technology working together to deliver commercial supremacy through communication and use of information—productively and profitably.

Back to Top

Back to Top

Back to Top

Back to top