One of the things you may wonder about information architecture is: Why can’t this be done by one of your team members, like the data architect or the systems architect? 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
The first thing to understand is that 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 a structural vocabulary, models, and blueprints to convey a vision of structure to the people who are going to build 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 used by building architects. 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 rigorous process of collecting information (Programming), organizing and categorizing the data (Analysis), creating a coherent integration of that vision in the forms of models (Synthesis) and then providing formal blueprints (Specification) exists, in some form or another, in all the architectural forms that I’ve studied. The application of the human mind as a mysterious difference engine 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 with whom the architect works to realize the vision; we’ll talk about them and the relationship between them and the architect a little bit. 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? Ultimately 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. Their models are realized by developers in the service of operational stakeholders.
- The Data Architect develops the storage and retrieval structures that provision a digital space. Their models are realized by database developers 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. Their models are realized by interface developers—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 essential, 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 the blueprints of the architect are used by masters of other disciplines 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 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.