Comments on Change Architecture: Bringing IA to the Business Domain

Matthew Wright — Sat, 28 Jul 2007 01:24:21 GMT

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.

Richard Dalton — Thu, 19 Apr 2007 02:05:31 GMT

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”.

Mary Brodie — Sun, 22 Apr 2007 17:00:17 GMT

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.

Masood Nasser — Fri, 26 Jan 2007 14:53:08 GMT

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

Jonathan Baker-Bates — Fri, 26 Jan 2007 14:53:07 GMT

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.

Mickey Moran — Fri, 26 Jan 2007 14:52:47 GMT

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”?

Adam Greenfield — Fri, 26 Jan 2007 14:52:41 GMT

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.” ; . )

carolyn chandler — Sun, 22 Apr 2007 16:59:05 GMT

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

Jay Cross — Fri, 26 Jan 2007 14:52:39 GMT

I agree with all your points and applaud your desire to make a real difference, but why is this IA? Shouldn’t everyone be a catalyst for change?

In other words, wouldn’t we want OD specialists, chief learning officers, intrapreneurs, and anyone else with moxie to work this way?

Just curious, not antagonistic. Good, thought-provoking piece.

jay

Andres Zapata — Fri, 26 Jan 2007 14:52:39 GMT

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.

Steven Thornton — Fri, 26 Jan 2007 14:52:39 GMT

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.