Last week, 1,033 folks joined us for the "SharePoint: From Chaos to Control" online event, at which I presented two sessions—one about security and one about governance. I've been talking about governance to thousands of IT pros ever since I helped write some white papers on the topic for Microsoft in 2007, but this time something dawned on me and it was like a light bulb turning on. For anyone trying to design a governable SharePoint implementation, there is a huge disconnect between two key concepts: information architecture and information architecture. What do I mean?
Organizations that plan to have SharePoint (or any other technology) provide content, search, and portal functionality often invest time in defining what is traditionally called "information architecture." Information architecture examines the relationship between categories and sources of content. Out of an information architecture effort you would typically obtain a site plan that includes a hierarchical navigation chart that shows how users can browse through your organization's content, the taxonomy, keywords, and definitions of content types and metadata. All of these deliverables will help your organization put information into, find, and get information out of your content management system.
That's information architecture, right?
But wait! In 2007, when we were introducing governance white papers about SharePoint, we talked about information architecture as well. This flavor of information architecture is all about how to architect a SharePoint implementation that can govern content through its lifecycle. This "information architecture" results in the design of farms, web applications, site collections, content databases, shared service providers, and other technical components of SharePoint based on how you must manage information based on your corporate policies, processes, and constituents.
Unfortunately, these two types of architecture often do not align. (I would even argue that they almost never align.) The way users think about information—about finding it through navigation in particular—very rarely aligns with the way that information might be managed behind the scenes. As a typical (and I apologize if overused) example, information architecture of the first kind might suggest a single intranet web application with single site collection that contains sites for each department. The departments collaborate internally and communicate publicly with other departments. That would be an easily navigable information architecture for many organizations, to be sure, but it would not be a manageable or governable one. There's a huge disconnect! To make matters worse, SharePoint out of the box leads you to just this kind of implementation. Even Microsoft Office SharePoint Server's (MOSS's) out-of-the-box default web application is set up this way, and it's not a design that's going to support governance for most organizations.
When I say "information architecture," when you say "information architecture," and when someone else says "information architecture," the odds are high that at least one of us is not on the same page. An attendee at last week's event asked a great question in this vein. The question was, to paraphrase, "Should an organization retain an information architect or build the skills internally?" The answer is a question: "What information architect do you mean?"
The taxonomy building, content-type deriving, keyword generating, navigation charting information architect plays a crucial role, but for most organizations, these information architecture skills are needed once (or rarely) as part of designing SharePoint content management. I think that this type of information architect should be hired as a consultant.
The logical-design building, governance deriving, information managing, security enforcing, performance enhancing information architect brings a different set of skills—skills that are likely to be needed often because this type of information architecture is closely aligned with the technology, which changes regularly and which supports an evolving organization. I think it's important to build these skills internally, but I recommend bringing in a consultant to jumpstart the process. That way, you aren't reinventing the wheel and you can leverage the best practices and learning curves of those enterprises that have gone before you. But those two information architects will rarely be the same person because they require very different skill sets. One is more about knowledge management, whereas the other is more about managing the technology that supports content management.
Because your navigation/taxonomy information architecture is unlikely to align with your governance/management information architecture, you're likely to need some good solutions—solutions beyond what SharePoint provides out-of-box—to present your managed information architecture to users in a way that reflects their cognitive information architecture. If you've tackled this problem, what third-party solutions from CodePlex or vendors are you using to bridge the gap between navigation and management? I'd love to know what you have found effective. Shoot me a line at [email protected].
It's a fine-line distinction, and that fine line has tripped up a lot of enterprises. When you talk with people about information architecture, make sure that you're talking about both kinds of information architecture and that everyone is talking the same language!
You can read more about both kinds of information architecture and about governance at the Governance Resource Center for SharePoint Server 2007.