STRUCTURING YOUR ARCHITECTURAL THINKING FOR OFFICE 365 DEPLOYMENTS – PART 3

In the last article I focused on Users, the first entity in the framework for structuring your architectural thinking for Office 365 deployments. In this article, I will start, but probably not finish, focusing on the 2nd entity, Tools. For a recap of why I think this framework is useful to begin with, I’d recommend reading the first article in this series.

Tools

Office 365, if I remember correctly, started as a rebranding of BPOS, a Microsoft product offering where cloud-hosted versions of SharePoint, Exchange and Lync (now Skype for Business) servers were offered to customers as a packaged deployment, having initially been offered individually as SharePoint Online, Exchange Online and Lync Online. The noticeably reduced per-user licensing and the lack of a comparable infrastructure deployment effort and resources costs to their on-premises counterparts is something that to today drives the popularity in shift to a SaaS (Software as a Service) licensing model for most software vendors, not just Microsoft.

Office 365 has since evolved tremendously, both in terms of tiers of licensing, and the tools these tiers cover. This list is a bit exhaustive, but the graphic below gives a fair idea of what’s there.

Since we’re talking Intranet architecture, I’ll keep it high level and not go into each individual tool unless I’ve got some grokked insights into it I’d share that’s applicable for this framework and probably mention SharePoint a lot since that was my area of expertise in the on-premises deployment days.

One challenge more seasoned SharePoint, Exchange or other architects/consultants with more familiarity of the on-premises versions of only one server software will face is shifting the rules we’ve already established as second nature from our experiences in past deployments that may seem a bit frightening to leave behind in the cloud model.

However, with the change to Office 365 and cloud-hosted server software, also comes a necessary change in structuring the thinking of Office 365 deployments, that differ from the olden days of on-premises counterparts. Even “hybrid” deployments that combine on-premises and Office 365 hosted versions of tools such as SharePoint need to take stock of these changes.

For an Intranet project that was hosted on premises in the past, the core collaboration participation tool was probably SharePoint, and the child entity of focus was the SharePoint Intranet Team or Publishing site. Indeed, many experienced consultants still choose to stick with the SharePoint Intranet Team or Publishing site as the core area of focus during an initial deployment of Office 365. However, I believe that to keep this thinking leads to some significant technical debt when trying to include some of the newer tools like Delve, Planner and Teams that are becoming increasingly popular within Microsoft Office 365 later down the line. Intranets have evolved with Office 365, and it’s time for SharePoint architects and consultants to evolve their thinking as well on this.

I evolved my thinking in this space so that the core collaboration participation entity in Office 365 is now, well, Office 365, or more appropriately the Office 365 portal (as viewed in the screen above), and so now logically, my child entity of focus becomes the Office 365 Group, not the SharePoint Site when I start thinking of the Intranet experience, and to what Office 365 Groups a user should belong.

Office 365 Groups

This makes sense as creation of an Office 365 Group, whether thru a portal or thru Powershell, will also create the instances of, and associations with, Outlook Online, SharePoint, Onedrive for Business, Planner and Microsoft Teams, which means that I’m touching several of the tools in the Microsoft Office 365 suite, and not pigeon-holing my users to working in only one tool.

Credibility to this adjusted thinking can be seen today in the SharePoint Modern Team Sites, where it may seem like you are creating just a SharePoint Team Site when you use the SharePoint tab in the Office 365 Portal page, but you are in fact creating an Office 365 Group that has an associated SharePoint Team Site. This is a good thing, since you will want to use the right tool for the right job, and while SharePoint is good for some collaboration tasks, other task like a continuous running discussion may be more suited to a tool like Teams, while sharing files and documents may be better suited to. OneDrive for Business, and the overhead to get users in one tool configured for another should be minimal. This behavior where the entity we are creating is actually creating a parent Office 365 entity behind it happens as well with other tools, like Planner and Teams, where creating a new Plan or Team is in essence creating a new Office 365 Group with this tooling enabled.

Office 365 Groups has been excellently documented by Microsoft and partner blog posts alike, and I’d highly recommend reading and getting into the weeds of these articles to really clarify in your own mind how these are used best, so that in structuring your thinking on Office 365 deployments you ensure these take front and centre stage and are not forgotten like your 23rd birthday.

So this post started off as the discussion on Tools, and branched slightly to talk about Office 365 Groups, but hopefully with this foundation in mind, in the next post where we dive into actual tools such as SharePoint, the reasoning behind this deviation becomes a little more clear.