My work recently shifted from the comfortably concrete world of Web sites and portals to the cloudy conceptual world of enterprise information architecture. The folks I’m working with are in records management, enterprise architecture, Web, IT, and management. There are even some librarians in the mix. The various groups each speak their own lingo and have trouble understanding one another’s motivations, processes, and deliverables.
I created this graphic to give everyone a starting point, a point of common understanding. The graphic depicts how enterprise information architecture (EIA) relates to enterprise content management (ECM). I originally envisioned the two things as being part of the same overall process, but I came to a realization that they are better understood as two separate activities.
As I see it, ECM is a permanent ongoing process to control a never-ending stream of content – to file it, organize it, and deliver it to the people who need it. EIA is the intelligence behind content management. It translates user needs, business goals, policies, and standards into a coherent plan for content management.
On the left side of the document are the inputs that inform and drive EIA. Even in organizations where there is no formal EIA, these kinds of inputs exist and are actively sculpting the content landscape. My diagram is pretty specific to the federal government landscape in the US, but you can extrapolate the kinds of inputs that are relevant in your organization.
In the center of the diagram are the products of EIA, five kinds of structures. These structures are the key to everything. In fact, that part makes me a bit nervous, because they are very hard to define in such a small space. For examples of search and navigation structures, see Lou Rosenfeld’s EIA Roadmap diagram.
On the right side of the diagram, we see how these structures help people create and catalog content, organize and publish collections, and filter and deliver content to audiences. They are the translation of an entire organization’s rules and knowledge into a set of rules that help people find and use content they need to get work done. That’s pretty powerful stuff.
Download it: Enterprise Information Architecture in Context (PDF). This diagram is a work in progress. I would like to thank Dan Brown and Lou Rosenfeld for their invaluable comments. It is twice the diagram it was before I showed it to them. I would love to hear what people think. Is it helpful? Love it, hate it: please comment.
I modified the title of this entry on 5/18
revised: You may download Version 2.0 of the diagram on this post. I’ve taken down all the old versions of the diagram.
James:
What a great way to get everyone “on the same page.” I am a visual learner, so seeing how IA and CM fits together what helpful to me.
On the “managing content” section, I am a bit confused with the “documents / records / content” section along with the “records management / document management / portal/intranet / web” sections. The terms just don’t seem as logical to me as they could be.
For the former, I might vote for delineating something like “data / information / knowledge / wisdom” or “tacit / explicit content.” There just doesn’t appear to be enough differentiation between the terms you’ve used.
For the latter, it appears as though you mix tasks (ORGANIZE – records/document management) with vehicles for delivering content (PUBLISH – portal/web). My vote would be to further differentiate between the tasks by possibly color coding and labeling the “organize” components and “publish” components.
By the way, what tool did you use to create this diagram?
Actually, this was done with Visio.
Kudos! Great job with it. Now the real question: How has this diagram impacted the communication among the diverse people on your team?
Thanks for the comments Rob.
There is some reasoning behind the three ‘kinds’ of content I used (content/document/record). First, there is a statutory definition for record, so that one stands out clearly from other kinds of information. Second, I wanted to use known and established kinds: there are whole communities of practice and enterprise systems designed around the idea of managing content, documents, and records separately. This may not have been wise, in hindsight, but that’s the world we live in. Lastly, the scope I wanted for the diagram was content management, however broadly defined. Some of the entities you suggest (e.g. wisdom) are not content at all. Here I am defining content as narrative, visual, or audio information recorded to serve a business purpose.
I now see the need for another layer of labels. The things in the RM/DM/Portal/Web set were hard to label – I called them publications/collections but that connection is not as clear as it might be. These tend to become systems, although I am not representing the systems. So, for example, a Web site might be considered a publication. An organization might have three Web sites all driven out of the same system. They might have an intranet and a Web site run out of the same system. They might do records management and document management out of the same system. But the business purpose and audience for these publications are different, so the structures to organize them are different. The organizations Web site and intranet are rarely organized the same way (if they are any good).
To answer your last question: The communication is still a work in progess, I’ll report when I have more perspective.
Enterprise information architecture in context
James Melzer has cerated a very interesting poster outlining enterprise information architecture in context. To quote: I created this graphic to give everyone a starting point, a point of common understanding. The graphic depicts how enterprise informa…
Very Nice – Unless I missed it, the concept of creating Metrics to seek business process improvement, user satisfaction, and show Return on Investment… closes the loop
This is fantastic James! You and Lou are helping me explain this concept to my colleagues hugely – many thanks!
They’re beginning to understand the concept; the “how we achieve it” however is much more difficult to explain and get commitment for (ie. the individual components of your diagram).
One step at a time as they say…
Enterprise IA in context
Getting My Bearings: Enterprise Information Architecture in Context My work recently shifted from the comfortably concrete world of Web sites and portals to the cloudy conceptual world of enterprise information architecture. The folks I’m working with …