TLDR – Improved business resilience, improved security and alignment to Microsoft’s future direction for M365.
In the old days 🙂 many on-premises SharePoint systems were created with deep site hierarchies with site collection boundaries often being driven by content database size considerations as much as by good Information Architecture practises.
As we transitioned to SharePoint Online this approach persisted, especially as site collections now max out at around 25TB of storage. If you have a deep hierarchy in SharePoint Online, or one where you have many sites within a small number of site collections, I recommend you consider whether this still meets your current and future needs and look at whether you’d be better adopting a more modern approach.
The more modern approach I’m referring to is to adopt the single Site per Site Collection approach that Microsoft now recommends as the default. So, why do this? Well, while there are pros and cons to everything, here are what I think are 3 good reasons…
Improved Business Continuity/Resilience
When you place lots of Sites in Site Collection they might seem independent to your user community, but they are in fact sharing a number of key resources. The main ones of concern in my view are shared storage (yes, 25TB can be reached!), shared security (admins and security groups) and a shared database. If something goes wrong with any of these it can be catastrophic, especially storage and the single DB. With these two you have put all your eggs in one basket.
Now don’t get me wrong, Microsoft does a great job in managing their environment and backups but even if the failure is “small” it can still bring everybody down. For example, if you need to go to Microsoft to have some files, a library or a site restored after they have been auto-purged from recycling (or deliberately purged from recycling), everybody in that shared area will need the have their data rolled back by days, weeks or months to get the data back and then, of course, everything needs to be rolled forward again. Not pretty from a user downtime point of view.
So if you want to protect your business data, distribute it across individual site collections.
Improved Site Collection security
Microsoft’s security is top-notch and private and public sectors across the world rightly rely on it. But no security system is 100% guaranteed. Zero-day vulnerabilities, buggy releases, poorly implemented security policies and human nature are all points of attack that malicious parties try to use to break in and access our data.
While the details of securing an IT system is way beyond the scope of my 3 good reasons here, there is a fundamental advantage of the Site per Site Collection has over the many Sites to a Site Collection approach. That is, Site Collections are what I tend to refer to as a primarily security division. i.e. just because you have broken into 1 Site Collection in the tenancy, it does not necessarily follow that you can break into, or have access to, any of the others. So if there is only one Site in the Site Collection, you have only compromised that Site. That might be pretty bad for the organisation, but much better that you only got one Site hacked. Had all the organisations’ Site’s been in that Site Collection and Site Collection admin rights were compromised, the attacker would have access to everything.
So take advantage of the Site Collection security boundary and minimise the amount of data you have in each.
Embracing the future
Whether you like your hierarchies or not, Microsoft are moving away from them. For example, Microsoft is pushing MS Teams as the one-stop-shop for most users’ collaboration needs. One of the reasons this is working so well is that it is a portal as much as a product. What I mean by this is that you can add additional functionality from other systems by effectively presenting their “screens” via MS Teams. So a user may not even recognise that they are using a different app; it just seems to be MS Teams.
Why is this relevant to my 3 good reasons? Well, the same is true of the core features of MS Teams. Discussions are held in Exchange and critically from a SharePoint perspective, file storage is provided by the associated SharePoint site. This triad (sorry couldn’t resist 🙂 of Teams, Exchange and SharePoint is a common security configuration and for SharePoint it is based on a Site per Site Collection using shared group security. So when you create an MS Team, you also get a modern SharePoint Team Site in its own Site Collection. No other option is available and is unlikely to be supported either. So connecting a Team to somewhere deep in your site hierarchy is just not an option.
So, if you want to ensure long term alignment to maximise your investment in M365, moving away from old fashioned site hierarchies is a must.
Chris Blake, is a specialist in Delivery Management and Architecture, for Triad clients in the public and private sectors.
