When To Use A New SharePoint Site Collection VS. A New Sub Site

Written By: John Tallon -- 11/10/2010 -- join -- contribute -- (1967) comments -- printer friendly version

Rating: Rate --

Categories: Configurations, Design, Document Management, Features, Infrastructure, MOSS 2007, Permission Management, SharePoint 2010, System Administration, WSS2, WSS3

< Prev - 1 | 2 | - Next > | Become a paid author

Building an Intranet Site Hierarchy

Let's take a walk-through of creating an Intranet for a medium sized company and see how we might decide on how the Information Architecture and the design of the site hierarchy may look.

OK, our CEO wants to use SharePoint as the single source of company information for the entire organization. We have limited hardware and the farm is going to be a SharePoint Server Farm with one SharePoint Server and one SQL database backend Server.

The agenda here is to create the organization's hierarchy using sites and lists in SharePoint so it is important to think about the way that the organization structures itself. So the first thing we might do is look at the organizational units within the company. From the Top to bottom:

  1. Board of Directors (Site)
  2. Departments (Site)
    1. Human Resources (Site)
    2. Finance (Site)
    3. Marketing(Site)
    4. Information Technology (Site)
    5. Sales (Site)
    6. Service and Support (Site)
    7. Logistics (Site)
    8. Research and Development (Site)
    9. Manufacturing (Site)
  3. Functions (Site)
    1. Company Secretary (News, Announcements)
    2. CEO (Blog)
    3. Human Resources Manager (Blog)
    4. CIO (Blog)
    5. CFO (Blog)
    6. Company News (Company Secretary)
    7. Jobs and Careers (HR)

Taking the above hierarchy we need to decide on what type of content to use (Site or Page) for the different departments and functions. In this case we choose to use sites (Sub Sites) as they offer more functionality and also allow us to build out the department's internal hierarchy. We create a new sub site called Divisions that will parent all the department sites. This will allow us to create a landing area/site for all departments and we can aggregate news and announcements from all the departmental sub sites into one section. On the department's site home page we would like to offer a series of useful links to content in the specific department site, such as HR Documents, IT Support, Sales Team Contacts, R&D news, etc.

We need to engage with developers/web admin (and creative designers) to build a Department Site Template that will offer a consistent look and feel and consistent placeholders for content that should be commonly shown for each department eg: Department Contacts List, Announcements, Latest News, etc. These site templates are saved in the site collection's Site Template Gallery and will be available to all sites and sub sites in that site collection. All sites from the top-level portal down to the landing page for each department should have the publishing features enabled so new content can be approved before it is published and made live for all employees to see.

We need to be consistent with the news articles that we communicate to employees. Our web administrators will create a new content type in the site collection called Company News which is based off the Article Content Type. We will need a new Layout page created from this Content Type that will be designed to convey the company brand and special fields for news articles. The news articles will be Pages in a SharePoint document library.

Announcements will be housed in the Announcements List that we can create out of the box. This will not be used for news articles. There should be a distinction between the two drawn up. Example, where we have a new employee in department X an announcement would be made, but if our sales team had just secured a deal worth 1 million with a new client, the company will make a big news article out of that.

There are company documents that need to be set as read-only which need to be available on the intranet for all employees to read. These include documents like past and current strategy documents, support documents, employee handbooks and other static documents produced by the company. As these documents are global and don't belong to any particular organizational unit the correct place for these to be located is in a document library underneath the main portal. Alternatively we could setup a document center type site and store all of these types of documents in libraries in this site. Most of the documents in circulation in the organization are not static, so the volume of documents that would be saved to this location would not warrant a dedicated site as this point.

Contacts are a very important when needing to collaborate on projects throughout the organization. There can be project contacts, site contacts, document contacts, department contacts, partner contacts, etc. We would allow most of our sites decide and manage their own contacts list, but there would be general contacts that each employee should be aware of. These would include HR contacts, IT contacts and other relevant contacts that we would house in the main portal.

So where would we need to use a Site Collection?

There are no rules governing when and where to use a site collection over a sub site. Most often the reasons become more technical rather than business centric. We know that the effort spent branding, creating company content types, workflows, List and Site Templates are all relevant to a site collection, so if we want to use a separate site collection we need to take into consideration that already existing customizations will not be available in the new site collection without some re-working by both our SharePoint Developers and Administrators.

Taking that into account what we want to do now is open up a new site collection that is going to be dedicated to a new product that the company is going to develop. We need to include most of the departments but only few employees and project stakeholders from each. Loss of branding is not going to be a huge draw back -- we can get our developers to package our branding into a SharePoint Solution and that would take care of that -- but we want this site to be more secure than normal as there is some very sensitive data that we need to control. The content created in this site is going to contain 10's of project sites, management dashboards, and research and development outputs and, ultimately, will grow rapidly in size and usage. We want a dedicated content database because our administrators have advised us that it would be the best direction due to the rapid recovery process in the event of data loss and we can have it disjointed from our main portal.

We do not want the content to be searchable from our main portal so this separation fits perfect in this case. Also, in the future we might need to allow external access for partners and other external users. By using a site collection this would allow us to restore the content on to a newly provisioned dedicated Web Application and extend it to allow non-active directory users in.

So in summary using a site collection to store this content made perfect sense. It allowed us to be fully integrated with the company while still allowing the flexibility to allow external users access without having to reconfigure our original portal or be concerned about sensitive data. It gave us a potentially speedier response and recovery time in the event of a disaster and made the site collection more portable if the need arise.

Next Steps

< Prev - 1 | 2 | - Next >

Learn more about SharePoint

Sponsor Information

Copyright (c) 2010-2017 Edgewood Solutions, LLC All rights reserved
privacy | disclaimer | copyright | advertise | contribute | feedback | about
Some names and products listed are the registered trademarks of their respective owners. |