Comments on Succeeding at IA in the enterprise

Patrick C. Walsh — Tue, 24 Apr 2007 14:17:47 GMT

Good article. Its nice to hear someone talking about EIA. I came to IA not from IT or web design but from being a Quality manager in the automotive sector for many years and came to IA through producing online quality manuals.
I find a lot in common between EIA and the Quality function. The skills/knowledge gained in document control, change management, negotiation etc from Quality I have found invaluable in my new career as an EIA.
EIA’s must also recognise that many organisations have now adopted various standards (ISO 9000, 14001, TS 16949 etc) that are important to their business. These standards must be subsumed and maintained as part of the enterprise’s information system. I think that information systems built around their internal policies and procedures may work better for some organisations but the traditional scope of the ‘Quality Manual’ must be expanded to include all areas/functions of the organisation. The scope of the information system must also reflect the organisation’s environment and ensure that all relevant external information is available and subsumed into the overall system.
Great to be having a debate on this!

Luke Kowalski — Fri, 26 Jan 2007 14:53:08 GMT

Very insightful, refreshing, and honest take on what it takes to get good IA through (without loss of fidelity) in a complex ecosystem. If I may add a few points that deal with “attitudes, motivations, and approaches” taken by interactions designers and architects, both good and bad, perhaps adding more tools to our arsenal to be used in enterprise design exercises:
http://blogs.oracle.com/lukekowalski/2006/07/31#a28
The linked-in CHI prez (“Design is the Easy Part”) also talks about the same challenges, where focus on stakeholders and organizational dynamics is often more imortant than the raw data/design ideas…

laurie kalmanson — Tue, 24 Apr 2007 14:15:43 GMT

Hear, hear. What you said. One addition:

—For better or worse, we have so grown as a trade, craft, guild that we are now deep inside large organizations, and many of our issues are purely turfological: who owns what, who can sign off on what, and how early can we get to the table so that we can guide and facilitate the decision making in the right direction from the beginning

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

James,
Another issue I have seen in communicating widely within organizations about the vision and goals is that people really do not care much for this stuff. People are so involved in their routine work that another initiative or communication is seen a “yet another blah blah blah from mgmt”. In this process even extremely important initiatives suffer.
The question here is how do we communicate effectively. Do we foster involvement at a lager scale? BTW, am enjoying your article a lot and can relate to a lot of issues that you have mentioned here:-)
And a lot of these issues you have mentioned are fodder for new stories. Can we expect some more on the same?

Martine Booth — Fri, 26 Jan 2007 14:53:01 GMT

One of the first articles I’ve seen that discusses enterprise information architecture (EIA) as opposed to information architecture (IA) which most of us know as web IA. So thanks!

In the last 12 months I’ve taken on a role as an enterprise information architect in a university that has identified the need for and value of Enterprise Architecture. We still don’t have a clear idea of what EIA is, what it means for us, how we resource it or what we actually produce.

James suggests EIA should be part of a broader team in an ideal world. In our environment this is the case, however its not plain sailing. EIA is one of three viewpoints within enterprise architure in our organisation. However our lack of maturity in enterprise architecture means EIA is often overlooked as the more clearly defined and understood areas of application and infrastructure architecture become the focus of the discussion.

The comments about business strategy, lack of clarity around needs and goals, the need for in-depth understanding of staff needs and issues, organisational change issues, and the soft skills required are right on the money. At least based on my limited experience in the area!

I’d like to see more discussion about EIA: what it is, how its done and who’s doing it.

Scott Abel — Fri, 26 Jan 2007 14:53:01 GMT

As always, James, excellent content. I agree with the often overlooked oganizational issues you mention. It’s about time we acknowledge these factors and be aware of them so they don’t prevent us from accomplishing our goals.

Now, back to those books on leadership and change I go. :)

James Robertson — Fri, 26 Jan 2007 14:53:01 GMT

Yup, organisational politics is a major factor. This is why I’m spending most of my time reading books on leadership and organisational change… :-)

Michael Beavers — Tue, 24 Apr 2007 13:59:59 GMT

True, especially in the stakeholder interview stage. We’ve found that some clients like to be in the room so that the strategy team is not in a position where we have to say no to stakeholder requests that we already know users will find cluttersome and irrelevant.

We’ve softened that message by saying, “good sites are a balance between business metrics and user needs—and we strive to hit that as perfectly as we can—with as much deference to our users as possible.”

“Hmmm…perhaps it is worth exploring. Depending on the prototyping budget and overall research timeframe, we can test that concept with a refined user population and see if they accept it as part of their content and functional goals.”

Masood Nasser — Fri, 26 Jan 2007 14:52:56 GMT

Another important factor IMHO in Enterprise IA is to manage internal organizational politics. The amount of internal manouvering that goes on does seem to have an impact on IA strategy. Business units & Groups competing and justifying spends can make an impact and threaten to derail your goals.

James Robertson — Fri, 26 Jan 2007 14:52:55 GMT

Hi Rob,

“As part of this team, we must understand organisational issues, but are not responsible for resolving them.”

Actually, I agree with you on this. :-)

My take is that really, we should be responsible for resolving some (if not all) of the fundamental organisational issues. I just wanted to soften the message, so as not to scare off too many IA’s. ;-)

Cheers, James

Masood Nasser — Fri, 26 Jan 2007 14:52:54 GMT

Nice article James. Gives a broad overview of the problems/scenarios in Enterprise IA.

“Enterprise IA projects are only successful when delivered solutions are actually used by staff.”

IA’s should be the first to cut any activity/ function/content that would add to the information pollution. A fancy application built in-house would be no good if there is a publicly available tool and your enterprise users prefer the same to what you have so painstakingly crafted.

“Instead, the aim is to build an in-depth understanding of how staff work, and the environment in which they operate”.

Analytics tools are a great way to understand how users how their system. I have seen examples where logs show us navigational paths from task based activity to the static content browsing. Such kind of research helps in crafting a solid IA that reduces time spent by employees on finding information rather than doing tasks.

Rob Fay — Tue, 24 Apr 2007 13:56:14 GMT

James, very thought-provoking article. When I think about enterprise IA, I think about how we need to think beyond any given project and start thinking more holistically. How does the project I am working on fit into the bigger picture? Am I thinking about knocking down silos and setting up opportunities for seamless data/information/knowledge transfer?

I think you bring up good points about how we need to connect with others in the organization who are more strategically minded, but I disagree with your phrase, “As part of this team, we must understand organisational issues, but are not responsible for resolving them.” It may not be part of our job description, but I believe as enterprise IAs, we are in the unique position to be agents of change. I find that in the process of requirements gathering, I often have the chance to speak with many different folks throughout the organization. In addition, my role often takes on that of the intermediary between the tech folks and the end users. This role therefore affords me the opportunity to influence the decision-makers.

I can be a change agent, but I must be aware of the culture in the organization. So many projects fail, by way of cost, time, or quality of the product. However, if we can be change agents, both aware of the “bigger picture” and aware of the culture in a given organization, then I think we’ll be better prepared to use our people skills to get buy-in on the projects we work on.