SharePoint Information Architecture and the Information Architect

Who owns information architecture in a SharePoint deployment? Is it IT? Is it the business?

Well, who owns the Intranet. HR? Marketing? Corporate Communications?

Back up... What CXO should care about the Intranet? All of them should, but who owns it in your corporation? Who owns the platform and the browser or the desktop? I bet that's the CIO or CTO. Who owns the vision and strategy and likely purchased or is purchasing SharePoint Server for the enterprise search strategy, corporate Intranet Portal, Communications or HR publishing portal for corporate policies, news, and handbook.

Ok, that aside who has managed the Intranet topology, links, sites, data structures, etc...? I bet it's more than one department, and I bet it's either been a very concerted effort or a battle and silo-ed chaos.

Well, let's say that the corporation wanted to put together an all critical database structure with company products, news, information, with an ever expanding focus. I bet the business and their data structure designers, business analysts, would get together to map out data structures and models, integrity, with massive charts and sign off on designs. Even column names, data types, and naming standards would be in debate and driven to conclusion. Remember any projects like this? To move forward different departments or teams would be given certain pieces of ownership, guru's and SME's (subject matter experts) would float to the top. In larger organizations vendors and consultants would likely be brought in to coordinate the effort. In a project like this the ROI is very obvious, it is easy to recognize that this business or even mission critical data structure will be core to the business.

Now that I have you thinking, let's move back to the Intranet. Is there any difference? It's been a good 20 years since people looked at Portal ROI and the web has proven itself worthy. Search has vastly improved and employees now find it critical even spending 25% of their time searching for and analyzing information (taken from a recent article in IT Pro Magazine). This fixture in the business is the place where employees know to search, browse and if running the a business productivity platform like SharePoint Server, the experience could involve both structured and unstructured views of information critical to the day to day of the employee.

The rubber meets the road here... Here's what I'm saying. With SharePoint deployment it is no different. You need to take deployment seriously. It isn't something you want to just throw over the fence to the IT guy. Let me tell you why. Installing WSS 3.0 or MOSS (Microsoft Office SharePoint Server) isn't complicated. It's not even tough to create a web application and extend your first team collaboration, intranet or Internet site. What's tough then? Knowing what to set for quota. Knowing whether to create site collections or sites (more guidance below). Do you want all your sites in one database. Those may sound like IT questions, but without working with the business he may guess wrong. What about how many web applications? Sound like a technical question? Right? Wrong! The SharePoint Admin can create 1 or create dozens. It's an intranet philosophy question. I like to recommend consolidated namespaces and few web applications. This leads to an easier to support, easier to navigate environment. Although having a single web application prevents you from having two different types of information. If you have your adhoc information in one web app, you can setup default quotas that support smaller site collections and shorter lived sites with more aggressive life cycle policies (250 sites in a content database). On more structured group or departmental or functional portals where you can allow much larger qutoas and allow them to grow (25 site collections or less in a content database with quotas of 5GB by default with support up to 15GB before moving site collections into dedicated dbs). Another example would be the single portal, one site collection, no quota essentially, and managed site groups, global navigation, managed content types, forced checkout, structured workflows, etc... Using the adhoc for the real collaboration and building, and the structured for the official, even relevancy could be influenced by the namespace giving the portal the highest relevancy. Navigating the space of business intranet and technical designs requires an information architect. What is an Information Architect and what is information architecture? I found a pretty good definition on the Information Architecture Institute summit site. (I'm not familiar with the group, just found it on a search...)

The structural design of shared information environments.
The art and science of organizing and labeling web sites, intranets, online communities and software to support usability and findability.

This information architect could be the same group that designed your Active Directory OU structure. That was a taxonomy, has that worked out? Maybe the group that designed the public folder hierarchy... touchy subject? Even DFS (Distributed File System) has a namespace with DFS roots and targets which have limitations and choices with usability considerations. Did you go with Product lines, Functional, Organizational, Regional, or simple buckets?

DFS, Portal, My Site, and WSS Examples (don't click these):

There are SharePoint consultants that are busy helping customers figure this space out, but hopefully by bringing this up you won't just throw it over the fence and *hope* someone gets it right. They probably won't and a year or two down the road someone in IT will be researching how to split databases and move site collections to sites or visa versa. They may even carry the rough news of telling departments that they no longer have their own web app, but have been consolidated into a single portal and have their own site collection or site on the portal aka a tab in the navigation with the powerful inheritance model.

So I've brought up a few questions let me offer some guidance... You're probably saying as you read this... How come nobody told me about all this. How come this isn't on TechNet! Let me start with the TechNet references.

TechNet: Determine the information architecture of your site

What is information architecture?
General planning recommendations
Using information architecture to plan the structure of your site
Using information architecture to plan for people and personalization
Using information architecture to plan for business data
Using information architecture to plan for search

Recently they published an article and model on what they call logical architecture: Logical architecture model: Corporate deployment and Design Sample: Corporate Deployment Logical Architecture (I think Brenda Carter and team have done a great job on these. Provide feedback so they can improve.)

Other Great TechNet Planning Links related to Information Architecture

I did mention above a few topics better understood by understanding capacity planning and scale recommendations and hence this article helps... Plan for software boundaries (Office SharePoint Server) and a blog of the latest and greatest on Scale, Performance, and Capacity Planning. (Web Content Management specific content coming in April.)

Office Online has some great basic info on information architecture content as well for the information worker or the person creating the sites and workspaces.

Provisioning is a common location where companies make decisions not understanding ramifications. Sometimes the decisions are made without understanding that they even made a decision. I'm referring to the SSC tool. The Self Service Creation is a very powerful interface. A web app can be easily enabled from the central admin to allow users to create sites. First and foremost, do not jump straight in and turn this on to authenticated users. Think... Do you want to enable self service creation? If yes, then who should have this right? If you're going to enable this, is there a specific web application that should be enabled with this power? Have you already enabled quotas? Do users know what the SLAs (service level agreements) are on this web application? Do they know where they need to go for support? Have you created a service site to communicate change management practices and communicate these service levels?

I love the SSC. Thanks again Radu (creator of the add in) back in the day. In STS I saw this as the saving grace for IT. Imagine the power of self service in a world where there is one SharePoint IT guy and 70K+ employees (this takes me back a few years to 2000). In a world where SharePoint was growing in leaps and bounds and was even exponential in growth the first year. Having site creation go through IT added little value. We wanted to allow employees to create sites, and to create sites for projects, team sites, and later document and meeting workspaces. These types of sites are really adhoc in nature. Portals, knowledge management, document management structured sites on the other hand did require an approval process. The business needed to show it was committed. Is there a budget? Is there someone with time to devote to business development, design, and business process? No? Then think again. Yes, then let's talk about how IT can help you meet your business goals, then we'll put a portal in the queue. At Microsoft a software development company with nearly 100% information workers, it made sense to enable SSC on a namespace with a defined quota, and where we would capture ownership, secondary ownership, site descriptions, among other meta data during site creation. Search would later be driven by this list of sites and URLs.

TechNet references to provisioning:

So now thinking about Information Architecture, I hope you plan to succeed rather than not plan and fail or later come back to pick up the pieces and blame a product or blame the helpful IT guy who installed teh server and didn't know why he needed to care about quotas and templates. As a smart SharePoint guy once said. You wouldn't blame SQL for a bad database design. You also wouldn't blame the SQL administrator.

Let's work together to figure out this space. There is a lot of overlap with other hot topics... Governance and Management. Watch for an upcoming TechNet article in the TechEd edition and whitepapers covering this and related topics.

Joel