louisrosenfeld.com logotype

Home > Bloug Archive

Aug 20, 2002: Information Architects in the Sticks

The last Bloug entry generated some great reader discussion on whether or not to separate IA from general IT consulting. And, like everything else these days, the discussion brought me back to the enterprise information architecture (EIA) axe that I've been grinding of late.

To refresh, you'd care about EIA if you are trying to develop a unified, logical information architecture for the entire organization and its users (e.g., a large corporate intranet portal).

My ideal EIA model includes a centralized IA team that takes an entrepreneurial approach in providing highly specific and digestible IA services to autonomous business units who pay for those services. The model can be extended beyond IA to just about anything related to user experience.

Part of the process of modeling an organization's EIA needs is to determine both what IA staffing resources you already have and analyze what the enterprise's current and future demand for IA services might be. Doing so exposes expertise gaps that can be filled by IA specialists and other consultants. In other words, you can develop a more rational and planned approach to bringing in outside expertise, avoiding a frenzied and costly process of plugging holes at the last-minute.

It seems like the same analysis should also be used to identify IA or IA-related staff who work for those distributed business units. I hadn't given this much thought before: while I grasp how the EIA team and outside experts should work together, I'm not entirely sure how the other in-house IA staff should fit. Here's a quick stab; would love your input!

  • Internal Centralized In-House EIA Team: Addresses over-arching IA challenges, such as developing a taxonomy for the intranet portal or evaluating search technology for use by the entire organization.
  • External IA Expertise: Addresses areas of IA specialization that are infrequently needed or expensive for permanent staff, such as providing an expert evaluation of an IA, or manually tagging a large volume of documents as part of a content management system installation.
  • Internal IAs Within Distributed Business Units: Address specialized needs of individual business units, their audiences, or their unique content, such as designing and maintaining a subsite of white papers and technical reports for use by researchers. These IA often have subject matter expertise or can navigate the politics of a specific business unit; perhaps these skills are more important here than a heavy duty knowledge of IA.

OK, I'm out of time and need to run, so back to you: so what is the role of the information architect who lives out in the corporate "sticks"?

email this entry

Comment: Debora Seys (Aug 20, 2002)

I'll give you a 'fahinstance' as my uncle would say...

The Internal Centralized In-House EIA Team would:
- establish company-wide metadata standards with required and recommended tags
- establish company-wide controlled vocabularies for some of these tags (these vocabularies may actually be owned by other groups in the company - e.g., the Real Estate organization has the list of valid company sites, the Central IA team acts as a syndicator to the rest of the company)
- design and deploy company-wide web page templates with required and recommended look/feel/navigation, etc.
- implement, configure and maintain company wide technology such as a search engine or portal platform

The Internal Business/Function Unit IA Team would do what you suggest but would also work as the local content, business and subject experts to:
- implement the web page templates (which involve some local design decisions) with their specific content
- implement the required metadata tags and decide which of the recommended tags they want to implement
- suggest additional terms for existing vocabularies or request that tags, vocabularies get established
- implement, configure and maintain local technology such as a content management system

In other words, the local team takes what the central team establishes and actually makes it happen. For company wide standards to work, they have to be adaptable or to have required, recommended and optional levels. The local team makes the local decisions that work for the business or function and their particular content and process.

Comment: jess (Aug 20, 2002)

what about all the inhouse folks who aren't IAs, but who do IA? I think this is more important to the field, and to the enterprise, than specialized business unit IAs...

Comment: Lou (Aug 20, 2002)

Jess, for purposes of this discussion, I'd lump them in with the people in the provinces who *are* labeled IAs.

Comment: vanderwal (Aug 20, 2002)

I am now working on my third Enterprise IA influenced project in five years (could be 8 projects in 12 years depending how IA is defined - yes IA can extend to pre-Web). These experiences greatly shaded how I look at IA. I tend to see the world of IA as: "Micro IA" (Web sites and Web related architectures); "Enterprise IA" (identifying, defining, normalizing, and making information reusable throughout an organization including an Intranet, Extranet, or Internet, which I was happy to find is nearly Thomas Davenport's definition of information architecture from his 1997 book Information Ecology ( http://www.amazon.com/exec/obidos/tg/detail/-/0195111680 )); and Macro IA (building common vocabularies and structures to share information across enterprise/organization boundaries, think XML for an industry as an example).

Enterprise IA not only shows up in Intranet projects, but Internet sites that incorporate data from various entities from within an single large organization that have traditionally had incongruent taxonomies. Much of the work in building central taxonomies and crosswalks tables in for Internet applications are often repurposed in the building of central data repositories that can be used throughout the organization for feeding information to various applications. Often Enterprise IAs work with knowledge management professionals or wear that hat themselves.

What is entertaining, well maybe only to myself, is Google searches on enterprise and information architecture will surface documents from the early 1990s that predate the Internet. These Enterprise Internet Architecture documents essentially encompass not only the machines (technologies that store data and information), but also who is responsible for the information. These were the days where mainframes and desktop applications (spreadsheets and MS Access ruled) ruled information storage and this information was largely not easily exchangeable. Knowing what machine and who maintained the information were the keys that unlocked the goldmines of data, information, and stored knowledge. Today the machines and who maintains the information has become Enterprise Architecture, but hardware and software are of importance along with the types of role this combination plays. Understanding the information in these systems and the information's structure are where information architects play their role in the enterprise. Most often data analysts play a role defining the data and modeling the structures through normalizing the data and building crosswalks so the data can be cross-purposed.

I have not seen an Enterprise IA team or heard of one, but many of the roles or skill sets that reoccur are dependant on the type of project being worked upon. Much of the skills needed for Enterprise work are dependent on the task, but internal IAs have variations on the Micro IA tools focuses. The Micro IA plays a very strong role in helping build a taxonomy and usable information structure for an Internet site. A person working on an Intranet also concerns them self with the user and their vocabulary, but the Intranet is often a tool used for enculturation to hopefully seamlessly teach the vocabulary and "information mores". I have worked on applications for organizations that encourage the adoption of the centrally controlled vocabularies. To me it was an odd concept at the time, but talking to people that had worked in the organization for more than a year or two found an incredibly solid communication foundation in the common vocabulary as there was very little misunderstanding in the headquarters or any of their offices around the globe, this was vary efficient for internal business purposes.

The internal centralized IA would not only need to be sensitive to the internal taxonomies, but the taxonomy crosswalks to autonomous or semi-autonomous groups in an organization. This team also tends to work with the outward facing IAs on crosswalks between internal vocabularies and the translations to their user/customer's vocabularies. There is much desired to be performed in large organizations that have established autonomous product divisions or product teams that capture relatively fungible information, but in drastically different formats and vocabularies on converse hardware and software setups. This is common in organizations that acquire a lot of other organizations, but in organizations that encourage competition internally between similar teams and divisions. Often training and distribution channels in these organization structures are shared to some degree, but there are gross information inefficiencies. Enterprise IAs often find themselves in the middle building crosswalks. These information crosswalks enable leveraging development work on applications, customer service, research and development, cross division analytics, and sales channel efficiencies to name a few.

The key to Enterprise IA is finding those people that understand the information and vocabularies. The data/information/knowledge experts need to embrace the Enterprise IA team and the team embrace these individuals.

One large project I was on found in the databases we were trying to use from disparate largely autonomous entities within a huge organization that had similar categories in their data stores, but the variables in the categories were vastly different. Trying to marry information from one repository to another found that the weather conditions captured had variations of 4 to 27 depending on the source. One provides options of: Clear, cloudy, raining, and snowing. While another would have: Clear, misting, showers, raining, heavy rain, etc. The only variables we could narrow it down to initially were clear and not clear. Through finding, embracing, and using information experts the variables expanded to 5 or 6, which was not optimal, but usable. The weather condition is very important in this organization as it helps identify trends and helps set policies that could not only provide efficiencies, but also save lives. Also from the limitations in the limitations of this work some of the higher-level individuals of the organization started working on providing standards for future data collection. We also found some of the information experts had vocabulary crosswalks they had been maintaining for their own purposes, which saved a great amount of time.

The external IA perspective is an excellent asset. Fresh perspectives are continually needed as those that are permanent insiders become accultured to the vocabulary and systems it is tough to see where improvements can be made, or worse that pat answers for why something can not happen have become engrained. The external IA offers a view of experience elsewhere and can highlight practices that will be helpful from their own lessons learned. External folks are often have developed a set of best practices that will ease moving forward quickly. Where the internal folks are often exposed to rather broad skill sets the external folks go deep in a few areas that can improve the overall product by helping avoid the proverbial missing manhole covers and guide the internal folks to efficient practices.

I hope this helps. Everything comes from my own experiences, which I often find are common experiences to what others have found.

Add a Comment:

Name

Email

URL (optional, but must include http://)

Required: Name, email, and comment.
Want to mention a linked URL? Include http:// before the address.
Want to include bold or italics? Sorry; just use *asterisks* instead.

DAYENU ); } else { // so comments are closed on this entry... print(<<< I_SAID_DAYENU
Comments are now closed for this entry.

Comment spam has forced me to close comment functionality for older entries. However, if you have something vital to add concerning this entry (or its associated comments), please email your sage insights to me (lou [at] louisrosenfeld dot com). I'll make sure your comments are added to the conversation. Sorry for the inconvenience.

I_SAID_DAYENU ); } ?>