Sharepoint: Organizing an Intranet site hierarchy

Question

Not totally sure this should be here or in Stackoverflow, but I look at it not from a developers point of view but from an admins.

In the past we had a pretty anemic intranet - now with SharePoint 2013 this will get a lot more use. We mostly delayed investing for the last half year ;)

My problem is - how do I organize the sites so that they go best with SharePoint long term, from an admin point of view, while possibly sites get added or removed.

In the past we had ONE site collection (Intranet) with sub-sites in it (not in the /sites folder) for all major parts of the small company (finance, organization, it services etc.). I am not sure this is "good enough" flexibility wise for a multi year thing. I also am a little concerned with everything being in one site collection...

I am just setting up the new intranet (having moved the old one to a new app intraned-old). So, here we go with some questions.

• What is the best template to use for the root? TeamSite? I do not lneed at the oment things like publishing - the homepages / root portal will be mostly static, lists.
• How would you structure sub-sites? It seems I can not make separate site collections outside the /sites folder. So, the alternative is to make this (use /sites), go to sepaarate applications (finance.intranet/) or go on making subsites in the root site, same site collection.

I definitely want t ogo into search, as we plan to move more and more documents etc. into sharepoint - we are small (7 people) but da full separation of the departments is needed, with for example developers not able to see our financial records. We also need - in 2-3 departments - to set up BI integration, make sub-portals for the people to see data from databases (some sort of "get an overview how we are standing).

A little lost how to set that up so that the setup does not come back to bite me some months down the road.

Answer 1

Ok, I am giving one answer so far - let's see if someone else finds something better.

• I am going with Team Templates everywhere for the start. As indicated there is no Need for serious Publishing. Due to the nature of the Setup (further down) the home area can be replaced easily (it contains Little more than a Portal page).
• It seems tha using "child sites" is not good. Creating new Site COllections is tricky, too, because the only place to put them is the /sites Folder in root, which limits, UNLESS... one reads the Manual where it is clear one can add more managed paths. I have created one managed path for every department (/finance) then can set up a separate site collection there.
• Thanks to 2013 there is a way to Combine all the Navigation - which is nice.

That seems to be it for the Moment - the good Thing with site colelctions like that is that theoretically they cna bem oved to different Content databases should they outgrow the one Content database we have now. THat is relevant as it is otherwise an administrative nightmare. Site COllections also have totally self-sufficient Setup in security and Features, which means that Projects to update a particular site can go relatively isolated. Again, this is an adminsitrative consideration - not a specific programmer wise, but it is nice to know I can have finance or another area separately developped without too many cross references. Always good to think of isolating Areas like that so development Projects dont go overboard in scope.

Answer 2

TomTom,

It's hard for anyone to give a direct answer to your question as you are asking about information architecture and topology--things are often based on business circumstances and requirements. With a seven person company it's not clear if that's total employees or your IT staff? Are you running on-premise SharePoint 2013 or hosted? How many sites or site collections do you really see adding and deleting in the course of a year? And, then for that matter, are you are separating sites or site collection to segregate access (such as finance from HR, etc.)? What kind of info are you segregating--files? In a seven person company I'd bet you could do everything you need in a single site collection and use a couple document libraries to segregate information access. How much overhead in navigation and site overhead do you need?

Now, if I misunderstood your company size, and let's say you support a company with a couple thousand employees, I might offer these suggestions for you. 1. Think of SharePoint in functional areas: Intranet for resource consumption (static content) and Collaboration for project working and interaction with others. 2. You can roll out a publishing site for the Intranet landing site collection and take advantage of its ability to build navigation to other resources and sites. 3. Many companies have cross-departmental project participation. Rather than creating an HR project under the /hr path and an it project under an /IT path, what is wrong with a generic path such as /sites/project 1, sites/project2, etc...? That way if your company ever re-orgs, your projects are still just projects regardless of the sponsoring department. 4. Sites versus sub sites. As a PM, I always insist that I run my project as a top-level site collection. I can have full access (and responsibility) and don't have to worry about another project sub site users consuming my limited storage. Also, I can set policies as to user access requests and retention. Traditionally there was a belief that sub sites removed IT burden imposed by user requests, but I've never seen or heard of this ever being an issue. Plus, the upsides gained with respect to quota, security, backup scripting, and recovery all favor site collections, or in other words, a site collection with only the default/intrinsic site.

Again, your questions are a bit general so hard to give you a perfect answer. If you are new to SharePoint, there are consultants like me and online resources available to help.

Chuck LaForte

Forte Design