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.

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.

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

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