Summary: Software developers often raise common objections about Information Architecture—but they aren't really problems at all.

Information Architects often must explain how their approach would work with a company’s development team. There are a lot of aspects of information architecture (IA) that “feel funny” to developers, probably because some of the language feels like an attempt to get on top of software projects from a management perspective. Those kinds of top-down initiatives often result in bad requirements and bad software. So, developers are naturally initially skeptical of IA!

As a former software developer and requirements analyst, I totally appreciate this perspective. But based on what I’ve seen TUG do, I am passionate about benefits that Information Architects bring to a project.

To that end, I want to address the 4 major objections development teams raise about IA, and how they aren’t really problems with IA at all. In fact, if we do our jobs right, developers produce not just awesome code, but awesome, relevant code that makes stakeholders deliriously happy.

Let’s dive in!

This is just a waterfall process.

It’s really not, we promise. Waterfall is a project management methodology that tries to ensure the outcomes of software don’t veer too far from the original intent. The biggest issue with waterfalls is what spawned the Agile Software revolution: it relies on functional decomposition to describe and manage software development.

Software developed by functional decomposition, no matter how rigorous, does not create true understanding. The binders of carefully executed, traceable requirements end with misunderstandings, confusion, and inaccurate scoping. And that’s if we’re lucky! Often management used the waterfall process to send broad directives about an outcome with little or no discussion of WHAT the thing is.

The most important, most critical part of understanding IA is that it does not operate via functional decomposition. An Information Architect acts more like a cartographer mapping an area where the goal is supposed to happen—not providing broad, detailed directives about specific parts of what will be built.

“Young George Washington” by National Park Service, U.S. Dept. of the Interior, not credited. – National Park Service Historical Handbook Series No. 26, frontispiece.. Licensed under Public Domain via Commons

In getting the lay of the land, Information Architects ask many of the same questions that come up in the waterfall context. So developers look at activities outlined in TUG‘s process, and it FEELS like another waterfall. But the goal couldn’t be more different. The Information Architect is not interested in requirements. Their task is to discover the true intent of a project. Then they model its structure, which is a sharable vision, a map of what to make.

If done properly, the vision keeps the intent coherent throughout a project.

You can’t understand anything until you try to build it.

One result of all those bad waterfall processes was that projects failed so completely, and so often, that people in software decided understanding could only happen as the result of making a smaller component of a larger, poorly understood thing. Management, in the meantime, tried to keep track of things by demanding traceability between broad directives and testable outcomes.

As a result, the maturity of software over the last 20 years has been in the management of *making* the things, not in the *understanding* of them.

Regardless of your organization’s philosophy, this is probably how things are done. Everyone agrees to some level of understanding to move forward. Then they chunk the work into parts that are discreet enough to be developed and tested, with the hope that more clarity will emerge. In Agile, the top-level planning is informal and largely based on utilization planning; in systems like RUP, it is more formal and iterative, requiring more documentation. But in either case by the time the developer starts working, there is a great deal that they do not know.

In that unknown space, that lack of understanding, comes almost all of the disappointments felt by stakeholders at the end of a software project. The desire to create sustained understanding that can maintain the structure of a project throughout its lifecycle is at the core of information architecture.

We’re just going to have to start requirements over again.

We promise you won’t. And we also promise that you won’t have to formally decompose what we create. Information Architects do not create requirements; we create blueprints of digital spaces that are used to confirm that detailed design and development efforts map to the overall project’s intent.

We already have an architect.

You probably mean a system architect or an enterprise architect. Which is great! Because all architects use models to create an understandable structure for a project. What is notable about each type of architect is the structure they build.

• The System Architect builds structures for understanding technology’s capabilities and constraints.

• The Enterprise Architect develops a structure for managing requirements and process.

• The Information Architect builds structures for understanding the digital place.

Developers who work with Enterprise Architects and System Architects value their contributions, for the same reasons that an Information Architect is valuable: they contextualize and frame a specific, enduring vision that will matter throughout the entire project.

Understanding, not Making

Above all, these objections speak to the primary tension in software development with projects: Making is not the same as understanding. Organizations and processes have failed software developers for decades by not making the effort to make the complex clear. They do not provide the level of understanding necessary to truly create context and structure for a digital place. But you can do it! Companies that engage with TUG have more success developing software and websites than any organization I have ever seen. It comes from the structure of understanding that supports the making.

If you want to have a more detailed discussion about how IA can help your organization and development, drop us a note!