Change Architecture: Bringing IA to the Business Domain

Posted by

“Information architects hold the potential to become master Bead Game players who help companies play the right music to succeed. But gaining a seat at the business table requires that we change aspects of our usual perspective.”

In Herman Hesse’s Nobel-prize winning novel, The Glass Bead Game, skilled players tap into a symbolic language that encodes all of human knowledge into a kind of music to be played and shared: [1]

These rules, the sign language and grammar of the Game, constitute a kind of highly developed secret language drawing upon several sciences and arts, but especially mathematics and music (and/ or musicology), and capable of expressing and establishing interrelationships between the content and conclusions of nearly all scholarly disciplines. … on all this immense body of intellectual values the Glass Bead Game player plays like the organist on an organ. [2]

Today, as the world of knowledge increasingly resides encoded in digital form, stored in databases, and accessed through the web, information architects hold the potential to become master Bead Game players who help companies play the right music to succeed. But gaining a seat at the business table requires that we change aspects of our usual perspective.

As IAs, we are not just architecting information; we are using information to architect change. In “traditional” information architecture, the target of work is usually a website or a web-based application. Change architecture steps outside of these bounds. The domain is not limited to a web team; it expands to include today’s dynamic business environment and the way people, processes, and tools interact and interoperate. The target is no longer limited to web browsers; rather, it is the minds of those people charged with understanding the broader business landscape and contributing to better business decisions.

When seen from a change architecture perspective, the IA’s existing toolkit—normally used to discover and capture information, re-categorize content for easier consumption, and visualize ideas for shared understanding and action—naturally supports this expanded business domain. IAs can help companies reap the benefits of positive change by reducing fear of change, creating hope for the future, enhancing adaptivity to change, and architecting applications and processes that enable business success.

Thinking about change architecture raises new questions:

  • How can we clearly communicate with clients about the ways information architecture paves the way for positive change?
  • What role do digital (or even physical) assets—including site maps, work flows, and visual explanations—play in helping a team and a company share a vision for change?
  • How do we help our clients, and their employees or customers, adapt to and embrace change?
  • How can we change the perception that IA is just a step in a website production process?

Not just for websites anymore

In fact, a number of information architects are already applying IA methods to business problems beyond the web. A few recent cases in point:

  • At Vanguard, the mutual fund firm, information architects Richard Dalton and Rob Weening stepped into the company’s strategic planning process to synthesize and visualize findings from extensive client interviews and make recommendations to internal business decision-makers about solving key pain points. Dalton and Weening faced initial skepticism about the ability of IA to overcome what they call the “web design” stereotype in the strategic planning arena. [3]
  • At Dynamic Diagrams, a Rhode Island-based information architecture firm, the company’s “visual explanation” services are often employed by companies with complex business processes or products to help put an internal team on the same page. The Dynamic Diagrams team advocates the use of “isometric” illustrations that bring perspective—in both the literal and figurative sense—to large-scale information and process issues. [4] “When applied correctly,” note several members of the firm in the Interaction Design Journal, “the introduction of depth makes the information easier to grasp by appealing to our intuitive understanding of space.”
  • At EZgov, which helps bring government services online, information architect Peter Boersma and other internal team members convinced decision makers to incorporate user-centered practices into the company’s software development process. Their persuasion tools include workflows and process maps overlaid by visual design. [5]

Commenting on his experience, Boersma notes that visuals, when converted into life-size objects such as posters, can help convert an abstract realm into something tangible that the team can talk about: “Visual explanations, when designed well, are the proverbial pictures that are worth more than 1000 words; they make lengthy explanations unnecessary. But, more importantly, they allow for discussion by pointing at things and indicating relationships by drawing lines in the air, when the visual is projected or hung on the wall.” [6]

The physical form, scale, and transmission of visual explanations can become extremely important as the medium for “spreading the news.” Dalton and Weening created one large-scale information map, and then hundreds of smaller “placemat” versions that were distributed to business units. [7] Depending on a particular IA’s skill set, these visual assets may be developed directly by him or her, or they may be developed in close collaboration with a visual designer.

Anecdotal evidence points to an evolution of IA as a unique approach to business consulting that combines analysis with tangible digital assets and actions. While business consulting comes in many flavors, information architects bring a particular set of top-down and bottom-up tools and capabilities to the table. IA practitioners may not necessarily think of themselves as change architects or persons engaged in change architecture, but there is a common thread of working to make changes in the process and/or perceptions of a collaborative team.

Learning more about change

As IAs, we know a lot about working with information. However, we need to learn more about attitudes toward change. Areas of knowledge that could be incorporated into change architecture include business strategy, business process intelligence, and cultural psychology. Change architecture could also benefit from the lessons of change management, a business consulting approach with roots that pre-date the emergence of the web.

One of the key models in change management comes from Kurt Lewin, one of the founders of modern social psychology. Lewin suggested a three-phase approach of change, which has been distilled into the following framework: Unfreeze, Transition, and Refreeze. Here’s a quick look at each phase:

Unfreeze: People tend to create a comfort zone where habits, patterns, and processes repeat in a somewhat static, fixed way. This gives them a sense of familiarity, control, and purpose. As Charles Handy writes in an essay, Unimagined Future: “Most of us prefer to walk backward into the future, a posture which may be uncomfortable but which at least allows us to keep on looking at familiar things as long as we can.” [8] There is an instinctive and understandable resistance to change. Old patterns have a powerful ability to propagate across a culture, achieving a kind of cultural lock-in and monopolizing the way people think about possibilities. Before someone becomes change-ready, they often need to be “unfrozen” from their static environment.

Transition: Transitioning marks the journey across the chasm of change. People and organizations reconfigure themselves from an old formation to a new one (“re-form”), through many different and often difficult realignment steps and stages. The first step is often the hardest, and leaders need tools to help people to avoid “change shock”, feel hopeful about change, and acclimate to the new possibilities.

The writings of creativity expert Edward de Bono are an excellent source of transitioning tools. He draws the following analogy in his book, Parallel Thinking: “Your existing cooking-pots may allow you to cook all the meals you have always cooked, but if one day you want to cook dim sum, then you may need to get a proper steamer system.” [9]

The practice of IA provides transitioning tools that can help people limber up their thinking and explore new structures, new terminology, and new approaches. For example, card-sorting sessions, interactive prototypes, and visual explanations safely simulate change in advance and let people “try it on for size” before the full change arrives.

Refreeze: Aims to bring a renewed sense of confidence and comfort to the person or organization’s changed environment. Refreezing also helps bolster the changes, so the organization avoids falling back into the earlier frozen patterns. (Alas, refreezing is perhaps not the best word choice. In today’s constantly changing environment, one shouldn’t strive to achieve another frozen state, but rather an integration of stability and dynamism.)

Big change, small change, and loose change

Lewin’s change model brings to mind major top-down changes. But what about the smaller-scale everyday decisions that drive the tempo and tenor of business? In their article, “Who Has The D? How Clear Decision Roles Enhance Organizational Performance” in the January 2006 issue of the Harvard Business Review, Bain & Company consultants Paul Rogers and Marda Blenko offer a compelling framework for clearing decision bottlenecks. [10]

They call it “RAPID,” for the sake of a catchy acronym (even though the terms are ordered differently), and define five key roles in the decision-making process: those who recommend a course of action based on discovery and analysis, those who offer input on the recommendation, those who review and agree to the recommendation, those who ultimately decide on the recommendation, and those who perform the decided action.

Although the Rogers and Blenko article focuses on role-definition, not information architecture, it has a number of implications for our field. For one, information architects are often asked to perform a recommendation role. The often-hazy path leading from recommendation to decision and action has historically been a source of great professional frustration to many IAs, who may chalk up shortcomings in that terrain to “politics.” From a change architecture perspective, the conflict inherent in this decision-making process may be seen instead as an opportunity. While people often disagree over the possible outcomes and pace of change, we need to understand that conflict is an attribute—not a side effect—of the decision-making process. In addition, business decisions increasingly play out across a distributed team that never actually converges face-to-face. Decisions hang in the ether and, in the words of Rogers and Blenko, “get stuck inside the organization like loose change.”

If we IAs become attuned to this situation, we’ll come to understand that the assets we create for fostering understanding are well-suited to helping clear these decision-making bottlenecks and improving the decision “throughput” across the company. Teams that are divided by office, country, continent, and culture can be placed on the same page. IAs are in a position to not only inform the situation, but also proactively propose a workflow to define the path leading from a recommendation to “performing” that recommendation. With these approaches, an information architect can become a kind of Black Belt in architecting and navigating big, small, and even loose change within an organization.

Is change architecture worth changing for?

Using the paradigm of change architecture, IAs can become more aware of the idea that when we step onto the business stage of a project, we will first need to unfreeze aspects of the situation and the environment, and ultimately make the path from recommendation to action visible to the participants.

Change architecture could even be applied to the trade of information architecture itself. When I began as an information architect 10 years ago, such matters were outside my field of vision; I thought of my role only in terms of providing information and documentation. Today, I recognize that practicing information architecture in an organization—either as an employee or as a consultant—requires intervention, persuasion, and leadership.

For many IAs, even the idea that the first phase of a new project engagement requires unfreezing to create a change-ready state would itself represent a major change. But information architecture may be a domain that is ready for a sea change. The signs are there: the internal soul-searching that has taken place on IA mailing lists and conferences, the seeming confusion about the overlap or gap between IA and design, and the struggle to find a shared language. Could it be we are unfreezing, heading toward transition?

Learn More

Podcast with Bob Goodman on Change Architecture “Bob also shares his thoughts about Web 2.0 and the value add this new approach to the web will bring to organizations. As well, we discuss different approaches to IA and Usability including card sorting and Bob’s experiences with Listening Labs.”

Footnotes:

[1] The connection of the “Glass Bead Game” and its players to the domain of “information visualization” was recently noted by Alan Marcus, “Visualizing the Future of Information Visualization”, Interactions, (March/April 2006): 42-43.

[2] Herman Hess, The Glass Bead Game, (New York: Picador, 2002), 15.

[3] Robert Dalton and Rob Weening, “A Foray Across Boundaries: Applying IA to Business Strategy and Planning”, (Power Point presentation.)

[4] Paul Kahn, Piotr Kaczmarek, Krzysztof Lenk, “Applications of Isometric Projection for Visualizing Web Sites”, Information Design Journal, (Volume 10, No. 3, 2000): 221-229.

[5] Peter, Boersma, “Integrating IA Deliverables in a Web application methodology”, paper adapted from ASIS&T Bulletin publication, February/March 2005.

[6] Peter Boersma, e-mail exchange, March 2006.

[7] Dalton and Weening, “A Foray Across Boundaries.”

[8] Charles Handy, “Unimagined Future,” in The Drucker Foundation : The Organization of the Future, ed. Marshall Goldsmith (San Fransico: Jossey-Bass, 1996): 377.

[9] Edward, Debono, “Parallel Thinking,” (London: Viking, 1995),

[10] Paul Rogers and Marda Blenko, “Who Has The D?,” Harvard Business Review (January 2006): 53-61.

10 comments

  1. In reading this article and as a member of an enterprise architecture (EA) team, I began thinking about the role of IAs versus the role of enterprise IT architecture. It seems that the organization’s EA team, which is typically chartered with aligning the organization’s enterprise information system design with the business (architecture) and processes, might be a great resource for IA’s to work with to influence change. Of course, this partnership would reside primarily at the corporate, divisional, or regional layer of a large organization, given the strategic role of most EA teams. Nevertheless, it is one potential resource to consider. In fact, many large organizations are required to document the current and future state information architecture as well as a transition plan for their information systems within this design layer. Given the limited resources of many of these EA teams, some might welcome a partnership with IAs that are willing and able to step up to the plate.

  2. Right on. I can’t tell you how times I felt like I was really making business recommendations than organizing content. Often, large companies create barriers across operational units that are completely functional and logical to them – but are impenetrable to users needing to perform a task that spans across these units. It got to the point where I had to go back to school and get an MBA so that I could talk the talk and walk the walk – and to tare down the “what do you know, you are just a web designer” stigma. In one recent experience, we helped Hopkins Nursing discover and address some significant issues with their international recruiting techniques and processes. Yes, IAs can (and should) be catalysts for change.

  3. Wonderful connections! Change management has so many implications for UX in general. The IA skill of being able to take inputs from multiple people, understand their needs and motivations, visualize a model, design it well and communicate it clearly absolutely applies to situations beyond web design. I do disagree that the signs you mention are indicative of a recent transition in the field of IA – I think it’s part of our nature as professionals that lead us to a constant state of soul-searching and a yearning for shared languages 🙂 – but I think we are ripe for an extension of IA skills into the realm of strategic business communication and decision-making.

    Change issues also touch the UX field strongly when it comes to user adoption. Very often, “usability” is stated as the reason why a user group does not adopt an application. But there are many other things that impact adoption that often are underestimated – such as the degree of executive buy-in, the number of peers and managers who are actually using it and recommending it, and corporate communications, conflicting goals between user groups, etc. All of them can make the “unfreeze” step you mention more difficult. By understanding these factors and the variations in users’ approach to change (as outlined in “Diffusion of Innovations,” for example) we can better diagnose the problems and help our organizations approach change more effectively.

    Thank you for the inspiring article.
    cc

  4. But institutional change doesn’t work the way a Web site does! The two are completely different domains, and after several years of beating my former-IA head against intractable issues that were in fact grounded in the way a given client chose to do business, I’m less than ever convinced that they have meaningful things in common.

    I mean, oh my goodness, anyone who knows me knows that I’ve long upheld the idea of using *insights* gleaned from the practice of information architecture in other problem domains. But to literally map the practice itself onto managing the process of institutional change? That, I’m afraid, is a no-go.

    Why? Andres correctly points out that IAs often wind up “really making business recommendations [rather] than organizing content.” But most of the time IAs are forced to make such recommendations to the wrong people, an echelon or two at least beneath the appropriate level for such interventions.

    If reengineering business is what you dig, by all means, rebrand yourself a strategic consultant and take those insights and rock them at the appropriate level. You’ll certainly be able to bill more, and you may even face a less frustrating time in winning buy-in.

    But don’t saddle the common-or-garden variety IA – who’s been brought in, remember, to fix a Web site or an application – with the futile challenge of wrangling a re-org, almost invariably without the internal constituency, championship, or critical mass of consensus necessary to such an ambition. It’s just not fair to sandbag someone in the IA position with the additional responsibility of fixing everything that’s institutionally dysfunctional in the client.

    And especially don’t call it “change architecture.” ; . )

  5. I have to go with Adam on this one. I may sound negative but there are a few points I’d like to bring up:

    1. It has been my unfortunate experience that when you do get access to the right people, half of the time they don’t pay attention to the details of what is being presented. It’s a case of “Just get it done, spare me the details, but don’t make any decisions until you go through me.” Makes me wonder what the initial proposal to bring in Usability Experts was like? Did someone say “Oh that sounds cool, let’s get a couple of them in here and check it out.” If so, what are they saying now? “Wireframes, functionality, user experience testing? Sheesh! I thought they were just going to tell us where to put the buttons?”

    2. That’s QA’s job. That’s the Developer’s job. That’s the Designer’s job. That’s the Janitor’s job…politics, politics, politics. When your mom is Creative Services and your dad is Technology…there’s a lot of sibling rivalry to deal with. It’s almost like being the kid who is trying to convince the other kids to clean their rooms before they go outside.

    3. Documentation. Research. They should warn people in these new Usability certification programs; those are two words Techs and Execs don’t like. I wonder if they have a course in “Usability Presentations using Hand Puppets”?

  6. I agee that this is, right now, a fantastically overblown article. However, I wonder about the long-term career progression of young IAs coming into the practice. In thirty years time, when their roles are well-defined and their methods accepted – will this article seem as ridiculous then as it does now? I hope not. Thanks, Bob, for some good futurology.

  7. Just read this article now..

    I compeltely agree with Adam Greenfield

    “If reengineering business is what you dig, by all means, rebrand yourself a strategic consultant and take those insights and rock them at the appropriate level”

    Too many IA’s have aspirational notions of affecting business, and are often barking up the wrong tree. A Re-branding as strategy consultants would be the first step of sorts…

    Bob,

    Thinking like this always increases value and enhances perception of what we do..

    Cheers
    Masood

  8. I agree. This is a great article. Most clients I have worked with start off wanting a new Web site or other Web application and figure, “Hey, we need an IA to help us organize what we sell/make/etc.” I come into a meeting and one of the first orders at hand is to define what their brand values and business processes are. While doing this exercise, we often dig up some of the business issues we need to resolve and various gaps in general. I personally don’t solve them, but just make them present and provide recommendations when they impact IA and usability. I feel like I’m a professional problem identifier sometimes. It’s true – IAs turn into the group that finds and raises issues. But what makes it so wonderful is that it brings design in general to the business table and forms that bridge that needs to happen between business and design (and brand).

    Thanks for writing this article, Bob. It is definitely something that is happening in the IA world today.

  9. I completely agree with Adam et. al. that this isn’t Kansas (“Information Architecture”) anymore, it’s “Strategic Consulting” or “Business Strategy” or whatever. However, find and replace “Information Architects” in the article with “Information Architecture tools and techniques”, i.e. lets stop focusing on IA as our identity and instead just use it as a name for a collection of things we do. The full title of the presentation Rob and I gave in Montreal should really have been “A Foray Across Boundaries: Applying IA Tools and Techniques to Business Strategy and Planning”.

  10. The idea of using information architecture to affect change at business level is extremely interesting. I’ve worked on several very large government projects, where using the tail (websites, applications, processes) to wag the dog (facilitate and create change within an organisation) is very often the only approach available, considering many of us don’t have access to government ministers, and that organisations such as these are just so political (no pun intended). Building strategic relationships with ‘mid level’ representatives by continually delivering great products does provide the opportunity to implement a kind of ‘gaijin’ approach to change, but it’s an environment that is notoriously difficult to predict. I’ve seen it work more than once, but its a long process. Great article though, and an interesting set of comments.

Comments are closed.