So, What Is Enterprise IA Again?
by Chiara FoxI’ve been doing a lot of research into “advanced” topics in information architecture in preparation for my day in the UX Intensive. It seemed to me that I couldn’t talk about advanced IA topics without talking about Enterprise IA. But the more I’ve dug into the topic, the more I’m realizing that there really isn’t that much there there.
Most of what I’ve read about EIA is really core, basic principles of IA. They focus on understanding the business context, what the users need and a deep understanding of the content. The emphasis may shift a bit being a little less about content analysis and modeling and more on the business context and facilitation skills, but really, that seems a subtle shift to me. You have to understand the social and political factors that your IA is going into if you have any hope of it succeeding. To me that subtle shift isn’t enough to warrant the new label of EIA.
I do, however, believe that something called EIA exists. Though, I’m starting to wonder if like the unicorn it only exists in our imaginations and mythologies. To me, Enterprise Information Architecture is something that happens in large organizations, when different business units come together and start playing nice with their information structures. I’m talking stuff like the holy grail of a single product vocabulary used by all departments (something that at PeopleSoft we were never able to achieve despite my best efforts). Or better yet, crosswalks, switching vocabularies, or meta-thesauri that map like terms between business units and their databases. This means that the marketing department and the support department and the developers can all use their own terminology, but the end user has a seamless experience as they move through the content of the site, as they search various databases, and most importantly, they don’t have to worry that they aren’t finding all the relevant stuff.
I’m not sure that I buy Lou Rosenfeld’s vision of a board of directors that oversees information architecture within an organization. Perhaps we’ll get there one day. And we certainly need visionaries like Lou campaigning for such things if they are ever to exist. But I hate for IAs to think that unless they have an IA department they aren’t really doing EIA. Sure it’s easier with a team. But I think even one person, with the backing of their department, can make a lot of change in the right direction.
At some point, you’ll need more than one IA. I certainly found this at PeopleSoft. We needed one IA to keep the websites running smoothly. But we also needed someone who started to work at this more strategic, inter-departmental level. Someone who understands the basic, core principles of IA and sees them implemented throughout the organization, even if they have to do a lot of the implementing themselves.
So, I guess what I’m saying is, I don’t see EIA as this big, different, evolutionary progression from “regular” IA. EIA is regular IA, just with a slight tweak in focus.
This entry was posted
on Tuesday, April 3rd, 2007 at 11:42 am and is filed under Information Architecture.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
This post is licensed under a Creative Commons Attribution 3.0 Unported License.
April 3rd, 2007 at 9:34 pm
Great points Chiara; I’m glad you’re bringing them up.
When you’re delving into EIA, I think it’s important to recognize that, while the basic goal is straightforward (i.e., bridging departmental silos), there’s no single best approach. My entrepreneurial approach–with a board of directors but much more as well (such as a services-oriented team), is just one way. It works in certain settings, not in others. But that shouldn’t distract you from the overall goal.
I also don’t necessarily recommend calling it an IA team. UX, Knowledge Management, whatever fills the bill and carries the least baggage is what will work best. I do advocate for the team to standalone, because being part of another department, such as marketing, IT, or corporate communications, creates major headaches for a group that purportedly advocates on behalf of the enterprise (and its users) as a whole, not one department. See why the group’s autonomy is so important? Even semi-autonomy is better than being part and parcel of a department that is perceived as having negative baggage, and which itself doesn’t understand the value of IA.
I could talk more, but I think you’re evaluating my position on a few snippets. You should come to my seminar instead; I think you’d get a better picture of EIA that way.
Let me know if you’re interested and I’ll comp you in.
cheers
April 4th, 2007 at 6:48 am
Chiara,
I invested last 5 years with a large organization taking care of Internal UX operations focusing on the same problem of bridging gaps between Organization Silos. It included over 2000 sites offering completely disconnected experiences, and the end objective was to build a single Intranet.
I think whether we call is EIA or not, there are differences in how IA is designed in an Enterprises. following are my thoughts:
In an EIA (lemme call it so for ease of communication) the control (referring to control in a good way) is very dispersed. When we deal with smaller chunks the control of a central IA team is to a much more granular level - it’s easier to absorb business context and it’s a much more manageable set of information, but in Large Enterprises that has to be dispersed. So we get into issues of how to we define a single IA framework/language that can be and is adopted by current and future units in an organization.
We could do it through Meta Data Structures, CV etc.. but it’s just not possible to absorb all different business contexts - We had complete business process taxaonomy, but it just did work for everyone. Hence the focus is to create a foundation which has the right mix of rules and principles. Rules being specific and principles providing flexibility within some constraints.
And then next level work, which we could not spend as much time on, was really to analyze this decentralized activity over a period of time and see if the fundamental mdoel itself needs to change , which I would expect it would have to evolve. This is where the meta data based approach started to beocme restrictive as the cost of a change in the model was discouraging. So a differnet solution is required, not sure what the perfect answer would be here. Towards the end I was exploring tagging on some parts..
We did work with different units to bring a user centric design perspective instead of Org structure based, but we did not do that with every unit, only some selected one based on criticality (for e.g. HR) and interest from the units themselves whethere pushed from top or otherwise.
Regards
Alok Jain
April 4th, 2007 at 2:18 pm
I work in an Enterprise Architecture group and one of our architect’s sole responsibility is IA. So yes, the EIA unicorn does exist but it may not necessarily have the title of EIA. It’s like you said, taking IA and casting a broader view across various departments and silos. And getting people to want to talk to each other is the hard part, as depending on how large the org is (mine’s big) people don’t want to (time, budget, priorities) talk to each other until they have to or need to in order to accomplish what they need.
However, I will say, when we show our IA in the context of various system models plotted to paper, eyes light up and all this abstract information makes sense.
April 5th, 2007 at 12:06 pm
I’m so glad to hear that the unicorn does exist and that folks are working in EIA groups! So much of the consulting that I do with large organizations (and back from the time I worked in one), well, they just aren’t ready for that type of thing. So, yay! I’m glad you guys are out there fighting the good fight.
April 7th, 2007 at 7:17 pm
When I first started teaching my seminars in 2002 and would suggest stand-alone IA groups, I thought I’d get pelted with tomatoes. Nowadays, it’s not uncommon–maybe not the majority of attendees, but certainly 30-40% are in at least semi-autonomous IA groups.
April 12th, 2007 at 7:59 am
hi Chiara. This is exactly what I’ve been thinking about EIA lately, so interesting to hear you say it and equally interesting to hear the responses. Although… I don’t think they really contradict anything you originally stated. (Except, perhaps, that the unicorn exists!)
April 17th, 2007 at 11:47 am
Understanding the content is somewhat meaningless without first understanding the contexts: the context in which the content is generated, the context for what the content is intended, and the contexts that actually parametrize and to an extent dictate the various uses of the content. Context isn’t some vague word but rather one that ostends to a set of complexities that are identifiable given careful analysis and a sensible vocabulary of both words and tools to describe those complexities. I am skeptical of “knowledge management” for a number of reasons but I do believe one can at least turn data into information. Information is, what exactly? Information is contextualized data.
Simply put, context needs to be understood before knowledge is even aped at. And context can be understood through modeling work. Flow models, sequence models, cultural models, use cases, decision trees, activity diagrams, artifact models, site diagrams, physical diagrams, and so forth can all be drawn up, drawn together, and drawn upon before data can ever hope to become information. And, wow, what if you combine work models not only with data models but also with market analysis models? And if you caqn do advanced content analysis using clustering and semantics for topic identification? Or if you can automate such analyses and dynamically generate user-friendly metadata? And integrate that data with site search keyword vectors and even off-site keyword tagging data?
This list at least partially comprises the role of the EIA. But it’s not a role that business clients understand. I spent three months at a very big BI software company working in this very role, inventing the capacity as I went (with ideas from Morville and Rosenfeld usually open at the shelf). I needed to spend most of my time making the business case for such work rather than implementing analysis tools, databases, or executing advanced user analyses.
Optimality of user experience and content delivery ceases to be the question. The big question is whether the full-time EIA can produce ROI. The competent EIA is going to have a deep and wide set of skills and such people are expensive. And that EIA is ever going to need to remain the salesman as well as the programmer analyst. With an absence of business cases to justify the expenditure on the EIA, creating the EIA role is, ahem, an exciting and wide-open challenge. It was always a struggle, even in a business driven almost entirely by advanced analytics.
As one person said earlier, the diagrams make people’s eyes open. I found that simple text analytics (e.g., search term distributions and correlations) opened eyes more than anything. And when you present those stats nicely, crisply, people really eat it up.