The view of the information architect’s challenge as a tsunami of data fails to capture the full impact of the rapidly rising flood of information. Recognizing stages of growth and maturity in information domains, information architects can plan for and accommodate differences in size and complexity by using one of three strategies. A single domain strategy serves knowledge environments that are discreet and disconnected, operating independently of others, like sand bags against a rising tide. A multi-domain strategy is a short-term solution, like the temporary protection of boots. It supports connections between different constructs in a subject domain by using a single taxonomy or underlying model. The best long-term solution is a cross-domain strategy that, like a boat, links the disparate frameworks of unique domains, creating a single, integrated construct. With the cross-domain model, domains are self sufficient, but they share an information organization approach and support conceptual relationships between domains. A strategic approach to information architecture serves domains at each stage of maturity and sets the stage for future evolution.

information architecture
strategic planning
domain analysis
taxonomies
information explosion

Bulletin, August/September 2011


From Tsunami to Rising Tide: How to Plan for a Successful Information Architecture Strategy

by Nathaniel Davis

In 1997, on the jacket cover of his book Information Architects [1], Richard Saul Wurman warned that a tsunami of data was upon us. By then we had mass adoption of email in the hundreds of millions and the swell of millions of websites and applications coming online each year. He explained:

As it washes up on our beach, we see people in suits and ties skipping along the shoreline, men and women in fine shirts and blouses dressed for business. We see graphic designers and government officials, all getting their shoes wet and slowly submerging in the dense trough of stuff. Their trousers and slacks soaked, they walk stupidly into the water, smiling – a false smile of confidence and control. 

In light of what we know today, I’ve got good and bad news. The good news is that the tsunami of data that Wurman predicted never hit the shores of civilization. Graphic design, exhibition design, illustration and photography, viewed by Wurman as the champions of making the complex clear – which were the “breakwater in the ocean” and “the dunes on the beach” that would protect civilization from the tsunami of data – are no longer burdened with the responsibility of protecting society from the immediate dangers of information abundance and mediocrity. The reason (by no means a reflection of marginalization): These and all other visual communication disciplines were of limited consequence to the information architecture (IA) challenge that lay ahead. 

Now the bad news! The shoreline is under water, along with the boardwalk and Main Street. Not from the violent rush of tsunami tidal waves of data, but because of a steady and unrelenting rise in the tide – clearly above the breakwater and beyond the dunes. 

Wurman’s world is experiencing something on the order of a Twilight Zone episode. The abundance of water is not coming from the orbiting moon, melting ice glaciers or excessive rain. Oddly, water that was once a static natural resource – that materialized from the typical cycles of precipitation – is now dynamic and has evolved into a life force of its own that can interrelate in ways that create more water. It’s like the “Blob”!

While Wurman helped to sound the alarm about the amount of information that was coming our way, his metaphor fell short of nailing how the deluge of information would impact all of society. 

Think about it. A tsunami only impacts the shore and bordering towns. If you evacuate soon enough or make it to high ground in time, you’re fairly safe. Eventually the waters return back to the ocean. While a path of destruction is left behind and lives are surely changed forever, the bulk of civilization is spared. 

The fact is that in addition to the can of worms that has opened up due to the commercial adoption of Internet and information technology, we now live with socially disruptive platforms like blogging, social networking and sharing. Furthermore, with the broadening of the web experience into mobile devices that let you access and transmit information and execute applications from the palm of your hand to the sole of your shoe, information and information technology impact everyone and everything – from professionals in fine shirts and blouses to the pizza delivery person in shorts; from weather-sensing clocks to a traffic sensing road; from new world to third world.

In short, with our updated aquatic metaphor, the enormous flood of information that is before us will extend beyond the ocean towns sprawled along the coastline of information dependency in such a way that no land will be left dry to provide escape (Figure 1). At some point, every mountain peak will be turned into an island and then disappear.

Figure 1
Figure 1. “From Tsunami to Rising Tide.” The magnitude of information is less like a tsunami and more like an unrelenting rise in the tide caused by an exponential self-propagation of water. Every mountain peak will be turned into an island and then disappear. © 2011 Ventura Behlers, DSIA Research Initiative <http://www.methodbrain.com/dsia/about/contributor/?Ventura-Behlers>

Planning for the Flood 
Now that we’ve cranked up the intensity of Wurman’s prediction for what’s to come for everyone, what exactly does our new metaphor mean for the field of information architecture and its practitioners? 

First, we’ll need to recognize that while a tsunami will come and go a flood can persist for an extended period of time. The flood of information that many of us are starting to experience – especially in corporate domains – is not an exception, but the rule. 

For example, transactions for products and services that were once grounded by established trust – through face-to-face human relationships – are steadily becoming augmented by online experiences that are given credibility by influential social networks where one-to-one sales conversations are now one (seller) to many (purchaser and their associates, friends and followers). 

Remember the classic phrase, “It’s just business, nothing personal”? Well, not anymore. For many domains, business is inextricably joined to the personal. These relationships need to be maintained, and their maintenance creates even more information that needs to be managed. 

The use of the Internet and all that comes with it is no longer an add-on to some brilliant marketing campaign. It’s no longer a tool to enable efficiency or fulfill a leisure pastime. Personal and business are now mission critical to businesses and is here to stay.

If our personal and business-related information assets can only be expected to rise for the foreseeable future, what approaches can we consider that help in planning for the growth and complexity of the information domains we must design for and manage over time? 

A Domain Maturity Model for Information Architecture Strategy
If you’re lucky, the creek, as my father says, will rise slow enough for you to see it coming. If you can see it, you can plan. By referring to a domain-based maturity model, I’d like to show you a way to frame your strategic IA thinking as you address the rising tide of information activity now or in the future. 

In my work as a practitioner, I’ve come to identify three basic domain types of information for which an information architecture strategy can be applied. Each domain has what I refer to as a natural and complex state (see sidebar). 

Natural and Complex States of a Domain of Information
__________________________________________________

 
The natural state of a domain relates to a set of information that is [information] architected for a single mode of information interaction and consumption – such as a target screen resolution of a device. The natural state was the only case for a number of years as the desktop web browser was the only mode for delivering Internet content.

The complex state of an information domain is realized when an interactive sequence and its dependent nodes for a directed path, called a physical construct (popularly known as navigation), has an alternate physical construct that accommodates the constraints of an alternate mode of information interaction.

For example, an application in a desktop web browser mode can lead a user to a targeted feature in two clicks. However, where the mode is a mobile phone, accessing the same feature will require four clicks. Since the information architecture uses two physical constructs to accommodate the same use case, the domain for which the information architecture is being designed can be said to embody a complex state.

For this article I will briefly describe three basic types of IA strategies as they relate to the natural state of a domain of information. To imagine the complex state of any of these strategies, simply imagine having to model the physical constructs of an information architecture for multiple modes.

Single-Domain IA Strategy
Sand Bags Sand Bags: A great first line of defense. Unfortunately you can’t build a sand barrier as tall as the one you’re going to need!

Single domain architectures are typically self-serving. They can be so self serving that they don’t even warrant a formal search engine optimization (SEO) strategy. By simply organizing the content, pages and metadata based on best practices, search engines (both internal and external) will naturally find their way through a site or application.

A better way to view single-domain architectures is “nothing in, nothing out. Single-domain environments are closed from relating with other domains of information. Take for example a finance department within a large organization. The finance department is partly sub-divided into accounts payable and payroll. The payroll department has created a web-based interface to allow employees to view and manage the delivery of their paychecks and tax withholding information. On the other side of the office, the accounts-payable group has commissioned a separate project to let its accountants manage vendor reimbursement. 

As part of a domain model, finance can be viewed as a subject domain. Accounts payable and payroll would be considered two unique sub-domains under finance (Figure 2). As child domains, if the information architectures of the two sites don’t share a common abstract construct, like a taxonomy or domain model, they operate independently of each other and can be viewed as having single-domain information architectures.

Figure 2
Figure 2. The single domain IA strategy. Finance as a subject domain within a business organization with accounts payable and payroll as sub-domains.

It’s safe to say that a majority of the work that is being done in practice is largely single-domain strategies. However, if you find yourself part of an organization with a growing demand for your products and services, expect to become more sophisticated. So begin positioning your clients for at least a multi-domain IA strategy.

Multi-Domain IA Strategy
Boots Boots: Boots keep you active by allowing you to put your feet in the water without getting wet. However, as the water rises, boots eventually take a lot of effort to get around, and they’re not as tall as the wall you just built. At this point you’re just buying time.

Many business organizations – large ones in particular – that are organized into smaller groups tend to build out their websites and applications by how they view themselves – as separate. Multi-domain architectures join disparate abstract constructs of a related subject domain to create a single abstract construct. In this case the accounts payable group and the payroll group will share a single taxonomy and/or domain model that describes their information (Figure 3).

Figure 3
Figure 3. The multi-domain IA strategy. The sub-domains share an abstract construct.

Does a multi-domain concept work if you’re not working inside a large business or enterprise? Yes. It’s all the same. Let’s say you’re a consultant who has been asked to take the women’s shoes collection (the subject domain) of a shoe manufacturer and create a site with an information architecture that supports their athletic, casual and evening brands. Since the manufacturer also has a men’s shoe collection, you would be implementing multi-domain information architecture for that client. 

Multi-domain strategy has its benefits, but falls short of preparing organizations for more challenging information needs. When it comes to organizing, relating and navigating [2] information at its best, you’ll have to embrace a strategy that connects across any subject domain. That means subject domains you own as well as those managed by others.

Cross-Domain IA Strategy
Boats Boats: Boats are flexible and are made to thrive on water. A well-designed boat can take just about everything the high seas can bring – except for a rogue wave of course.

Any large business organization will have more than a finance group to keep the business running. Let’s say our company has a facilities management department that knows where all of the buildings are and controls access to meeting and conference rooms and parking. 

Finance and facilities are clearly two unique subject domains that can easily evolve over time under separate multi-domain IA strategies. However, the company has decided to create a single destination on its intranet that its employees can use to reserve rooms, request building access, arrange parking accommodation and manage payroll information.

One exhaustive and costly approach would be to put both business groups on a single systems platform. However, we know how that meeting went!

Cross-domain architectures join disparate abstract constructs of unique subject domains to create a single abstract construct. This means that finance and facilities management utilize a shared method for organizing and relating information (Figure 4). 

Figure 4
Figure 4. The cross-domain IA strategy. Multiple domains share an abstract construct.

This approach would allow both groups to keep their systems in place as they are bridged by the new IA and systems strategy. The strategy also becomes the foundation for adding and creating new subject domains as the company expands its intranet offering into areas such as human resources.

The actual methods used to make information relatable and navigable across unique subject domains can be challenging. But this is the reality for a growing number of information architecture practitioners who are hired to design and then maintain information architectures that must eventually relate to a broader enterprise information architecture strategy. 

In some cases you’ll have to determine how you must architect your information for the rest of world to consume as well – such as search engines, clients, vendors, business partners and other third parties.

If you’re responsible for information architecture and are attempting to relate information across disparate subject domains within a single company, multiple companies or across the entire Internet, cross-domain information architecture is perspective that will lead you in the right direction. 

Be Prepared to Make a Boat!
This introduction for communicating a domain maturity model for information architecture strategy has broader implications that go beyond the scope of this article. However, I’d like to provide a few takeaways: 

  1. Most domains of information won’t immediately require sophisticated information architecture strategy. However, if around long enough, maturing domains of information will need a boat-like strategy to get around. When you’ve exhausted sand bag and boot strategies for creating site information architectures, you’ll want to be in a position of having planned well enough to have more than a rowboat strategy to wade through the complex domain of information that’s coming your way. 
     
  2. If you wish to think more strategically about information architecture, make sure you are thinking of ways to position your clients and/or your organization for a cruise ship, a cross-domain strategy that will give them the comforts of the once dry land that will be left below an ocean of information. 
     
  3. Planning cross-domain information architecture, for a project or for a canonical information architecture, takes time and intention. If your clients and own organization are not there yet, use single-domain information architecture strategy as preparation for a consistent multi-domain strategy. As you engage in multi-domain efforts, research how your multi-domain strategies will migrate to cross-domain information architecture, because at some point it will be necessary. Either your users or the market will require it – or the evolving architecture of the Internet will demand it. 
     
  4. When you find yourself contracted or employed by a mature business organization, it will most likely have a range of approaches to information architecture – meaning you’ll see everything from single- to cross-domain strategies being implemented under the same roof. Tactically, this mix is perfectly normal. At some point someone will need to assert a sense of wisdom by asking, “How can we do this better?” Let that person be you. 

Going Deep in Information Architecture 
To understand the depth of the challenges that face information architecture you must realize that the domains of information you create today have the potential to evolve into massive bodies of knowledge, understanding and informational relationships that support a wide range of communications and modes of information interaction.

The field of information architecture needs individuals who are interested in going deeper – from creating information architectures for sites, to planning and managing information architectures for the critical services and utilities that many information domains will become in the future. 

As you approach strategic thinking around your practice of information architecture, consider a domain maturity perspective for identifying your rising tide of information. 

Having such a perspective will not only improve how we discuss information architecture; it will enable practitioners of information architecture to talk more strategically to businesses about the lifecycle of maturing information domains and the value this thinking brings to successful business and IA planning. 

Resources Mentioned in the Article
[1] Wurman, R.S. (1997). Information architects. New York: Graphis. 

[ [2] DSIA Research Initiative. (2011, July). The practice of information architecture. Retrieved July 9, 2011, from http://www.methodbrain.com/dsia/the-basics-of-ia/what-is-ia/ia-as-practice.cfm.

© 2011 By Nathaniel Davis


Nathaniel Davis is a theorist on IA subject matter and manager of information architecture for a Fortune 100 company based in the United States. In April 2010 he launched the DSIA Research Initiative and DSIA Portal of Information Architecture in an effort to begin defining and communicating a distinct discipline of information architecture that is centered on theory, research and practice. He can be reached at natedavis.ia<at>methodbrain.com.