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