Date: November 9, 2019
Author: Daniel O’Neil
Reading Time: 3 min 6 sec

Summary: An information architect is responsible for representing the structure of a digital space in a way that is meaningful and useful for its visitors.

One of the things you may wonder about information architecture is: Why can’t one of our team members, like the data architect or the systems architect, do this work? After all, wouldn’t an architect of data be the same as an architect of information? What is an information architect?

These are great questions, and they get to how all architects are similar—and how they are different.

The DNA of an Architect

First, all architects—building, urban, naval, or information—do essentially the same thing: Model a vision to keep intent coherent throughout a construction effort. All architects take a broad range of information and inputs and then use vocabulary, models, and blueprints to convey a vision of structure to the people building the product.

The most compelling video of architecture that I’ve ever seen is this one—How To Design Like An Architect—by Doug Patt at the Architects Academy, which describes the architectural process building architects use. Although he calls it how to “design” like an architect, he is really describing the process of creating an architectural vision based on information from the world.

What is notable about the video is that the same rigorous process is present in some form or another in all the architectural forms that I’ve studied. This includes:

• collecting information (Programming),

• organizing and categorizing the data (Analysis),

• creating a coherent integration of that vision in the forms of models (Synthesis), and

• providing formal blueprints (Specification).

Taking all this complex and fascinating information, then fusing it together into a consistent whole, is at the core of all architecture.

Of course, none of this is possible if there isn’t a masterful team of engineers and designers who help the architect realize the vision. But first, let’s talk about how architects differ from each other.

It’s All About the Space

So, if these are the criteria for what architects ARE, then how do architects differ? It comes down to the problem space they are trying to describe, who realizes their models, and whom the structure serves.

• The System Architect defines a structure to manage technology capabilities and constraints that contain a digital space. Developers build their models in the service of operational stakeholders.

• The Data Architect develops the storage and retrieval structures that provision a digital space. Database developers build their models in the service of anyone who needs to organize or use the data.

• The Information Architect builds structures for understanding how the digital space will be used. Interface developers build their models—and, if possible, the development team as a whole—in the service of the system’s users.

These distinctions are important. If a data architect tries to bring their unique perspective on data design to an information architecture effort, the outcomes will probably look a lot like a database.

We at TUG have seen numerous interfaces that were essentially recapitulations of the underlying database; in one sense they were very organized, but from the perspective of the users trying to make sense of them, they didn’t work well at all. Information architecture represents the structure of the digital space, not the technology delivering it, not the data provisioning it.

We’re All in This Together

The most notable thing about architectural DNA is how much it depends on a mature, competent team to succeed. There must be mutual trust between the architect and the makers of the space, mediated by blueprints, but executed by the engineering and design disciplines that actually implement the idea.

A key part of this trust is the assumption that the vision will be realized through transformational analysis, where masters of other disciplines use the architect’s blueprints to realize the vision—not through direct decomposition of each detail, but by grasping and executing the vision as a whole.

This is a very different concept than most requirements specifications, which are generally using decompositional analysis. But it’s not a radical idea at all to mature architectural disciplines, such as those that create building blueprints.

It’s a wild thing for people accustomed to detailed traceability matrices. For folks on Agile teams, the experience of transformational analysis will feel very, very familiar; it’s basically what they do in each sprint, albeit on a smaller scale. The deep promise of Information Architecture—of all architects, really—is that the structure can exist at the level of an entire project, and that together we can make a beautiful, delightful thing.

Want to Learn More?

We would be happy to talk more with you about how information architects can help save time and money in your design process.