Enterprise Information Architecture (EIA) refers to the process of making information easy to access throughout a discrete entity – in this case, an organization. According to Wikipedia, Information Architecture is, in part, defined simply as “the practice of structuring information (knowledge or data).” Note that this simplified definition makes no reference to the Web or information systems of any kind, a la Richard Saul Wurman.
This post attempts to rethink EIA and argues that information architecture need not be constrained to designing structures and managing content as it relates to the Web or for any electronic system for that matter. Instead, I argue that an enterprise information architect might also be called, as Thomas Davenport coins it, an “Information Ecologist.” In addition to the commonly defined responsibilities of the iA (little ‘i’), the EIA or IE adds the following skillsets/responsibilies to his or her repertoire:
The end result is that not all information finds its way into a web-based system. Some information may be best kept in other formats. However, an IE‘s responsibility is to structure information so that it is valued as a resource on par with human capital, physical capital, and the like. Although information systems are best suited for information management and information findability, the IE must map all information in order to have a comprehensive inventory.
I’ve been at my new job for close to three weeks now and during the first week I was inserted into a project. Without getting into specifics, K12 develops both digital (online) and “hardcopy” products for specific educational market segments. Their current CMS is the backbone of their production efforts.
I am enjoying taking this on as my first project, in part because it forces me to understand the business of K12 and its workflows. I’ve been able to interview different stakeholders and users, thereby forcing myself out of seclusion and getting to know my colleagues. In the process, however, I’ve been faced with the dilemma: What exactly is a CMS and what is the hand-off between system processes and people processes?
Unfortunately, I was unable to attend the Information Architecture (IA) Summit (As an aside, I hope to attend next year – although it’s hard to be participatory now that I’m a relatively new parent), and subsequently, two of the many sessions that interested me: in this case, the session on Enterprise Information Architecture, along with Dan Brown’s [slides], really got me thinking about the definition of who and what information architecture is.
Before I elaborate on EIA, let me make a bridge to the discussion by first remarking on the potential responsibility of an IA to participate in the process of gathering requirements, designing interfaces, and participating in the implementation of a CMS solution for a given organization. As Dan indicates in his slides, today’s organization is predominantly comprised of knowledge workers, yet CMS solutions tend to subscribe to the formula of “business as factory” with cookie-cutter workflows. Instead, businesses are living entities, defined by the fact that there are some skeletal business processes, but these processes are often dynamic and fluid in nature. That is, they change and are flexible – need to be flexible – as the makeup, growth, and focus of the business and its parts changes.
Many of the people I spoke with simply assumed that any new solution would replace the same business function of the current CMS – in this case, an asset repository, product staging area, and informal workflow system. However, as I spoke with different stakeholders, new needs readily emerged. We discussed needs for digital asset management (DAM), business process management (BPM) workflow, and document management. So, as I analyzed K12’s information assets, I learned that “content management” can mean many things to many people.
Which brings me back to the issue of rethinking EIA. Discussions abound which attempt to define where the boundaries of IA end and where [insert job function here] begins. For example, Louis Rosenfeld and Jess McMullin created the following diagram to make sense of the boundaries:
The problem I have with this diagram is that the end game is the design of a (web based) information system. I think an IA‘s vision must be greater than an information system, particularly if we take Dan’s metaphor and look at the organization as a dynamic living entity – in essense, the defining “information” system. It’s almost like distinguishing between the CIO of a company and the IA. Are the two so dissimilar? Should they be? Could this be where little iA ends and big IA begins?
The parallels between an enterprise information architect and an information ecologist are quite striking. According to Davenport & Prusak (1997, p. 29), the basic responsibilities of an information ecologist include:
Perhaps the progression of an IA‘s scope of responsibilities might look something like this:
So, where does this discussion leave us? Traditional information architecture concerns itself with the structure and design of information for a specific web entity or information system. Over the years, the work of an IA has moved from dealing with the information presentation (locate, find, use, etc.) of static structures (form) to interactive behaviors (function). Lou Rosenfeld fantasized about what it would take for IAs to move into more executive and strategic positions within an organization, and I hope this post reshapes our thinking. As we move into and think about EIA, let’s structure and design the information of the enterprise using the perspective of an information ecologist.
Tags: [Louis Rosenfeld, bloug, James Melzer, Brownorama, greenonions, information architecture, eia, enterprise information architecture, Thomas Davenport, Information Ecology, IA Summit, ia, ux, cio]
Fantastic Rob. As a law firm enterprise IA I have also come to realize how the job involves much more than just designing information access via the intranet or portal. There are many other information points in the enterprise, acting as both sources and places to be published to, including the accounting and work product systems, the firm directory, the library catalog, email contacts folders, etc. Even right down to dropdown lists that display in our travel arrangement software!
All these things and more must be incorporated into the plan if we aim to provide a seamless information experience to staff. And in order to get there in the most efficient and practical manner we also have to consider things like the technical expertise of staff creating the information, the marketing value of the information, and the culture of our unique offices and departments.
I also really liked your mention of “disposing of” information as part of the IA plan in your diagram. That critical task is so easy to leave out when you’re busy designing and building new IA.
Rob, I’d be interested to hear your thoughts on SOA projects like the one I just finished for my job, which seeks to make information from disparate systems available to all systems within the company via a Web Services architecture. This allows anyone to call even information that is NOT document-based, and display it on their website/application/report in whatever form makes most sense to their user based.
(SOA = Services Oriented Architecture)
I think that the SOA framework is promising in that it attempts to remove the “silo” effect by throwing a connecting layer on top of these silos. It promises easier information access, but it doesn’t necessarily remove redundancies. After all, you are only as good as your data.
It is a cost-effective short term solution, but when do you make the decision to consolidate systems? Should they remain separate?