Portal Site Navigation Decisions - SharePoint 2013

Years ago I wrote a post titled "Portal Site Navigation Decisions" and the guidance there continues to be valid in today's world despite the fact that that blog entry was designed for SharePoint 2007. At the suggestion of an avid reader (Hi Mark!) I think it's time for an update. We've gone through 2 product versions since that original post (2010 and 2013) and many things have changed while some things continue to remain the same. Because I'm going to make references to that blog entry I strongly suggest reading it first. You can consider that entry to be more than appropriate for SharePoint 2007 and this article will be heavily focused on 2013. You're just now upgrading to SharePoint 2010 you say? Aside from the fact that you're rushing fast into the past, you can consider much of what I'm going to say to be appropriate for 2010 also. Much. Not all. ;)

First, lets start with what continues to be good guidance from that earlier blog entry:

• The intranet root should be a publishing site. This continues to be true, as does the recommendation to use abstractions rather than organization names and the recommendation to focus on topically related information that is understandable from a content and navigation perspective and not organization names structure. No one cared then about the fact that the Travel department was under Finance, and no one does today.
• The recommendation from "SharePointea SiteCollectionFearophobia" (aside from the fact that I now realize that including fear and phobia in the same name is redundant) also continues to be true. Beneath the intranet there should be at least 4 wildcard managed paths titled "teams", "projects", "communities", and "programs" or "services". In some cases there should be more... for example, a law firm may require "matters" because that's the primary focus of collaboration for them. Self-Service Site Creation should be enabled, and Site Use Confirmation and Deletion should also be enabled.
• There should still be only one central Enterprise Wiki. For better or worse there may be other wiki sites out there with highly specialized knowledge or information... but when it comes to that "one view of the truth" perspective, there should be one, it should be at the top, and it should follow the rules of wikis as described in "Do You Weally Want a Wiki?". Everyone can edit, everyone can see everything.

There have also been numerous changes from the 2007 product:

• The Site Directory has been deprecated in 2010 and no longer exists at all in 2013. While I personally consider this extremely unfortunate, I'm fairly certain that the SharePoint product group had metrics indicating that the directory wasn't be used or wasn't being used correctly. I agree with this perspective but I also think that the reasons why it wasn't being used were of greater concern and if we had fixed those issues (people didn't know how to use it, people didn't create site collections, etc.) it would have been a valuable feature and template to keep.
• Search is now fully Enterprise Class. It has gone through two major revisions and the direct integration/merging of many of the features of FAST for SharePoint. Aside from the fact that web analytics is now a Search feature, the Search service now has the ability to scale to a relatively insane degree and can truly index an entire company's worth of information. It is no longer about "SharePoint Search"... it is truly Enterprise Search.
• The "Collaboration Portal" no longer exists (it was removed in SharePoint 2010). Instead we have the Publishing Portal template which offers much of the same functionality and is the intended replacement.
• The 2007 My Sites have gone through extensive revision and although the fundamental architecture remains the same, the purpose of them has evolved. At minimum we have seen at least 1 name change from "My Site" to "SkyDrive Pro" and soon will be renamed to "OneDrive for Business". SharePoint also continues to refocus attention to the personal site, most visibly with the introduction of the social features of the platform.

Finally, the introduction of completely new features potentially changes the landscape for the platform:

• An emphasis on host-named site collections as the preferred method of creating new sites. This is most valuable when there is not already a well defined structure for SharePoint site collections.
• A completely new way to do branding.
• Metadata based navigation.
• Cross-site publishing.
• Increased functionality for mobile

I'm not going to go into the details of all of this... but suffice it to say a lot has changed since SharePoint 2007. However, the goal of the model I outlined in that blog entry so many years ago was for it to be resilient to change. You shouldn't have to re-architect with every product release and upgrade or whim of the business. The real questions are whether or not the model outlined continues to be of value, if it has served the purpose it was originally designed for, and what changes need to be integrated to continue to let it serve its primary purpose.

I am happy to report that the model still works and I still strongly recommend it to my customers. As I mentioned, so far I've received nothing but positive feedback on how it has impacted my customers. There are some slight enhancements/modifications I would like to make though...

• Do NOT align your site/web application naming strategy with our product names. We just change things too often to make that a good decision. If I never see https://mysite or https://my or https://sharepoint again it will still be too soon (and I know I'll see them again). Instead, come up with an ACTUAL name... something that represents the ideals of the business. For example, https://collaborate or https://share or https://us (as in, all of us... not united states) are fantastic demonstrations of what the solution is all about. Use those names... not our product names.
• DO enable Self-Service Site Creation (SSSC) AND Site Use Confirmation and Deletion. These two features are intended to work together. The first increases the number of sites that will be created. The second forces people to acknowledge that the site is still relevant and has value to them and should be retained. One creates content, the other cleans it up. Together they ensure that your SharePoint environment doesn't grow out of control. Yes, there will be a spike as sites are created... but over time they will be cleaned up if they're not used. This will also have the added benefit of cleaning up sites that are no longer used at all... even if they weren't created with self-service site creation. Many people would be concerned about the idea of "deleting sites"... but remember: We have recycle bins for this kind of thing, and you have backups if absolutely necessary. Deleting a site is not a permanent loss... it simply removes the site from availability to the end user so that they MUST tell you it is required for their business activity at which time you can identify them as the new owner. This is a good thing!
• DO use real business users for your site collection administrators... and in fact, demand both a primary and a secondary (this can be automatically enforced by SSSC). This is reinforced by SharePoint's implicit separation of the Farm Administrators from the Content Owners. It is the responsibility of the Site Collection Administrators to manage the content, not the Farm Admins. If they don't know how or you're concerned they may do the wrong things, that's a training issue, not a reason to violate a policy recommendation or put the content decisions on the support teams.
• DO use Quotas. They're there for a reason - to keep your end users from consuming an entire farm's worth of storage. Too many times I hear of customers say that they don't want to use quotas and in the same breath discuss how their users never clean up or archive content. Quotas are they way that we encourage people to clean up their content. We have to provide a choice: Clean up what you don't care about or request more storage... which brings us to...
• DO use Charge-Backs. Consumption of resources should imply a cost. This is where we get the customer to actually question whether that storage/quota increase is really worth it. Do I want to pay an extra $1K a month, or do I want to delete some old files? This is a valid question that every user should be able to ask themselves... and if they really need those files then that extra $1K might actually be worth it. As I realized recently: If there is no cost to excessive consumption, there is no reason to not consume excessively.
• Consider elevating search. SharePoint has offered "Enterprise Search" for quite some time now, but it has constantly been relegated to "SharePoint Search" because people don't realize just how powerful it is... plus, the SharePoint Admins seem to think that the search functionality should be exposed under some SharePoint-centric hostname. The fact that the Enterprise Search Center lives inside of SharePoint perpetuates this perspective that all search knows is how to search SharePoint. Instead, consider creating a search-specific web application... https://search for example... and let that be nothing but search. This elevates Search as a discrete service that can provide access to all types of content, not just SharePoint. Search is now a first-class citizen... elevate it.

These recommendations are intended to provide the most value from your SharePoint deployment possible, and try to help you avoid a lot of the difficulties that Premier Field Engineering finds a lot with customers who, in the process of trying to protect themselves from FUD or not understanding how to assemble the massive-box-of-legos-that-is-SharePoint into a high value service, manage to create for themselves. We want you to be successful, and avoiding pitfalls before they become sinkholes is the best way we know how.

If you have questions, ask them below. I'm happy to respond as soon as I can.