Best practice SharePoint site architecture

SharePoint has been around for a while now (approximately 2001). If you do not already know, it is part of the Microsoft suite of products when you purchase a business plan. A business of any size can subscribe to a Microsoft 365 business plan and SharePoint comes with the plan.  Microsoft originally sold it as a document management and storage platform, but it has evolved into so much more since then. It is not tricky to use but it is a sensible move to get someone who knows how to configure document libraries, permissions, and column metadata. SharePoint can, with careful planning, and governance, become a growth tool for a business that offers a raft of content options, encourages collaboration, and comes with oodles of storage.

 

Hub site or subsite?

Today’s article explores flat architecture SharePoint hub sites versus subsites. Hub sites are the new normal but what is the difference between the two? What is a real-world example of subsite complexities and why are businesses moving to hub sites?

 

Subsites – what are they?

Subsites (regular sites) are sites that hang off the top-level parent site URL. They were popular because businesses could configure a parent site with navigation and security and it would propagate to their subsites. Site columns and content types were also reusable on subsites.

Keywords – nested, inherited, or inside.

 

Hub sites – what are they?

As the definition of the word hub suggests, the hub is the central part of a wheel from which the spokes radiate. The concept is no different for SharePoint only that you associate your site collections with its central hub. The figure below shows a live example where Night Owl has already registered my Company Intranet as my Hub site and associated the two separate site collections below it with my hub site Company Intranet.

Keywords: separate sites, flat structure.

SharePoint_hub site configuration

Real-world example

Let’s say your business has a top-level site collection called “ABC Widgets Homepage”. Underneath their top-level site collection, they have a bunch of nested subsites called HR, Marketing, and IT/Projects. (Remembering the top-level site called “ABC Widgets Homepage” cannot be considered a subsite because it is not sitting underneath anything).

In those respective subsites, the business has everything from employment contracts, project plans, staff policies, and campaigns spread across the subsites. They have permissions applied at the top level and use a couple of third-party tools and workflows to help with various work processes. The business finds it is working well because all the subsites inherit all the settings including their homepage URL construct. It has saved a lot of manual hours of setup because it is all filtered through.

All is well until there is a restructure. They ask to move the subsite that is currently IT/Projects out and give it its site collection calling it IS. Unfortunately, the business now realises it is a complete rebuild of the two separate sites IS and Projects. They also realise they will need a migration tool to move the 5,428 existing files manually to IS. And to add to the pain, they will need to replicate all the old elements they had structure-wise in IT/Projects so it’s an exact match. And because the URL will change, all the previous links in emails, local bookmarks will be broken. Their workflows will not be preserved either and will have to be reconfigured. Phew! a lot of work ahead.

 

Why Microsoft recommends hub sites?

Hierarchy – it’s that simple. Microsoft recommends every site should sit in its own site collection and every site should be its own piece of work. This means bye-bye to nested subsites with an inheritance from the parent URL. Where subsites share top-level navigation and permissions, the hub-associated sites have a link of their own. This means you can set your security permissions with comfort as there is no hierarchical inheritance as the hub site collection model is flat and standalone. If you stuff up permissions on one site, it does not affect the other sites.

One thing that is inherited however is the branding. If you set the theme branding to theme whatever on your hub, the associated sites will reflect the same branding. That is kind of cool compared with subsites where you had to turn on the publishing feature in the settings. Another handy feature of hub sites is sharing on the landing page. If the Marketing department makes an announcement on their Marketing site collection, you can set up a web part so that news appears on the main landing hub page with their news.

 

Final word

Subsites are not evil but do become a hindrance to move if your business changes. Microsoft offers tools to move subsites, but the reality is you will need to learn SharePoint configuration in your precious business time. I think the flat architecture model is slightly more maintenance but worth it in the long term. Most of all, I prefer the hub model for security. Sharing confidential information is too easy to do with subsite inherited permissions.

For assistance with your SharePoint business project, contact Night Owl Digital.