In past articles, we have discussed the differences between Information Architecture (IA) and Data Architecture (DA). But what is Information Architecture, really? It’s a term with many different definitions, among (and within) different areas of Information Technology.
This article will discuss some of those definitions. A future article will discuss specific definitions, and applications, of IA for database professionals.
A paper published by the University of Arizona described its internal IA program as a drive to “bring the University’s information inventory under control.” This paper defines “an Information Architecture” as:
“…A comprehensive view of the business activities of the enterprise and the data required for its operation. An IA is comprised of logical data models based on the activities which have been confirmed as a complete, correct, and stable statement of the business as it currently operates and is likely to operate in the foreseeable future. The IA is developed independent of organizational structure and technology trends.”
But other branches of IT have their own definitions of IA. However you define IA, the phrase does seem to have a clear origin.
According to R.E. Wyllys of the University of Texas:
“The phrase ‘information architecture’ appears to have been coined, or at least brought to wide attention, by Richard Saul Wurman, a man trained as an architect but who has also become a skilled graphic designer and the author, editor, and/or publisher of numerous books that employ fine graphics in the presentation of information in a variety of fields.”
Wurman also created the ACCESS travel guidebooks and cofounded the TED (Technology, Entertainment, and Design) conferences.
Wurman first promoted the name in 1976, at a convention of the American Institute of Architects. He sought to apply the principles and inter-related disciplines of physical building design to the more abstract worlds of information, both in what is now known as “library and information science” and in what is now known as “information technology” (then “computer science,” still mostly mainframe-bound at the time).
However, Andrea Resmini and Luca Rosati, writing in the Journal of Information Architecture, trace the association of the words “architecture” and “information” 12 years further back, to a 1964 IBM research paper entitled “Architecture of the IBM System/360.” That article described “architecture,” in a mainframe-era computing context, as “the conceptual structure and functional behavior, distinguishing the organization of data flows and controls, logical design, and physical implementation.”
Wurman continued to advocate for the term, including writing the 1997 book Information Architects. A year before that, he explained IA as:
“The creating of systemic, structural, and orderly principles to make something work—the thoughtful making of either artifact, or idea, or policy that informs because it is clear. I use the word ‘information’ in its truest sense. Most of the word ‘information’ contains the word ‘inform,’ so I call things information only if they inform me, not if they are just collections of data, of stuff.”
But just as different types of buildings require different architectural concepts and disciplines, so do different types, and structures, of information. This helps to explain the different concepts of IA.
In the making of websites (and anything else with an on-screen user interface), IA is often invoked in reference to the organization of information and interactions on a screen.
In this iteration, IA is directly interrelated with page design and other User Experience (UX) disciplines.
The Information Architecture Institute (iainstitute.org), a trade organization devoted to this type of IA, defines IA as “the art and science of organizing and labeling web sites, intranets, online communities, and software to support usability and findability.”
This definition of IA emphasizes the “front end” disciplines of screen designs and user interfaces. Hence, it might seem relatively unimportant to DB engineers devoted to maintaining and improving the “back end” functions of an enterprise’s IT operations.
But, as hypertext pioneer Ted Nelson once said, “everything is deeply intertwingled.”1 The “back” and “front” ends of any computing environment are connected in more ways than mere input and output. A coherent, easily comprehensible front end screen design, even for in-house use, can result in more accurate input and more understanding of data results, and why they’re important for the business’ goals.
The more demands we make from our data, the more complex, demands we make from the humans who generate, enter, retrieve, and analyze that data.
Many of these people are your co-workers in the non-IT departments of your organization. These intelligent and able people could use simple, quickly understandable on-screen directions in what names and numbers to enter into which areas of a DB front-end screen. It doesn’t have to look fancy or “cool;” indeed, that just needlessly complicates what you’re trying to simplify.
That’s just one elementary aspect of User Experience Design (UX), a full discipline with principles of efficiency and accuracy as well as aesthetics.
As Jared R. Spool writes in “Four Tricks to Quick Intranet UX Improvements,”
“…A resource-limited user experience team often focuses on the customer-facing systems, leaving the internal designs to evolve organically, often without care or thought.
“Over time, this creates costs for the organization. The systems become clumsy and difficult to use, which slows down or prevents the employee from doing critical functions. For those who work in customer service, this makes it difficult to resolve customer issues, which lowers customer satisfaction. An inefficient organization can’t jump on new opportunities, thus opening up entry points for competition to step in and take business away.
“The good news, it’s easy to find improvements to make. This helps us show the value of great user experience. We can reduce costs, increase customer satisfaction, and improve revenues, often through simple enhancements to employees’ existing work experiences.”
One task common to the various forms of IA is to see a project (an in-house intranet, a website, etc.) from multiple points of view (users, developers, corporate management, etc.), and then to break down what the project needs to accomplish and how that can best be done.
Thomas Myer, writing for IBM’s DeveloperWorks site, explains what information architects do by comparing them to the heroes of police-procedural mysteries such as CSI:
“During the course of their work, they employ lots of different tools, methodologies, and techniques. Sometimes they look through a microscope or compare fingerprints in a database, or use high-tech lasers and gases to identify a piece of trace evidence. Other times they talk to people, walk the area surrounding a crime scene, or observe patterns in movement.
“Although it isn’t quite the same with information architects (you wouldn’t want them at a crime scene), one thing is true: They have an overarching goal of making an information space usable; and, like the forensic investigators, they have many different ways of figuring out how to go about doing that. I think of these techniques as fitting one of four main areas of inquiry, which I’ve labeled ask, observe, learn, and iterate.”
To learn a little more about UX improvements within in-house computing environments, look up “Intranet User Experience Design” by John Brunswick and “UX Behind the Firewall: Designing Engaging Experiences for Staff” by James Robertson.
1 Ted Nelson, Computer Lib/Dream Machines: Second Edition, Tempus/Microsoft Press, 1988.