William Leggett

SharePoint development relies on “12-hive” folder and each who writes code for SharePoint uses that folder intensively. SharePoint uses that folder to store features, log, content types are other stuff.

12 hive folder structure is not private and you can find full description all folders in google, the core folders you should know about are the following:

• \ADMISAPI - The directory contain the web service used used by the SharePoint Central Administration and appears as a virtual directory.
• \BIN  - The directory contains all the core binary files, utilities that are used by Windows SharePoint Services. Your command line tools such as STSADM.EXE reside in this folder
• \BIN\LCIDD - A directory will be created for each language will be created that contains language specific binary files.
• \CONFIG - This directory contains a set of configuration, binary and resource files used by SharePoint. Some files are the default values which will be copied to web site instances.
• \DATA - SharePoint uses this directory structure for the indexing services where content will be indexed.
• \HCCab\LCID - This directory has a set of cab files containing manifest and content information used by the SharePoint help sytem
• \HELP - The folder contains a compiled html help file (.chm) used by the configuration wizard.
• \ISAPI - This directory contains all the standard Web Services for SharePoint and some additional DLL’s, resources and configuration files that the web services use. Every web application provisioned in SharePoint will have a virtual directory strong>/_vti/_bin that points to this directory, thus giving each web application it’s own set of web services.
• \ISAPI\HELP - This directory contains all the help files used by SharePoint. The folder also contains LCID sub directories for each language installed thus globalising the help system.
• \LOGS - This is the directory that you will visiting frequently whilst doing development and administration as it contains the log files of what SharePoint did and what errors occurred.
• \RESOURCES - This directory contains the core.resx file used for creating language packs for SharePoint. If you are going to be localising your SharePoint sites with different languages and cultures, this is the folder to do it in.
• \TEMPLATE - This directory structure contains the core web site functionality in SharePoint, that is the features, templates, configurations, resources of a web site. What is important to note about this directory structure is that the Virtual Path Provider hides and masks this directory structure, thus it appears under each web site, list in a completely different structure.

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.

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

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, Organisational, Regional, or simple buckets? 

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

• \\mystorage\users\%username%
• \\storage\hr\dfslink
• \\storage\marketing\dfslink
• \\company\root\link
• http://portal/inclusion/sitecollection
• http://msw/
• http://webapp/inclusion/sitecollection
• http://team/sites/myteam
• http://my/sites/joelo 

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

• Determine sites and subsites
• Plan site navigation (Office SharePoint Server)
• Plan Web pages
• Plan content deployment
• Plan for collaboration sites
• Plan variations
• Plan content approval and scheduling
• Plan for multilingual sites
• White paper: Plan for building multilingual solutions

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.

• Plan the structure of site collections and sites
• Site templates
• Introduction to site navigation
• Introduction to customizing sites and pages
• Introduction to sites, workspaces, and pages (what are sites and workspaces?)
• Manage permission levels
• Share customizations by saving them as templates
• Introduction to Windows SharePoint Services in international environments

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?

TechNet references to provisioning:

• Chapter overview: Plan for site creation and maintenance (Office SharePoint Server)
• Plan process for creating sites (Office SharePoint Server)
• Plan for site maintenance and management (Office SharePoint Server)

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 the server and didn't know why he needed to care about quotas and templates. You wouldn't blame SQL for a bad database design.  You also wouldn't blame the SQL administrator.