Structuring your Architectural Thinking for Office 365 deployments – Part 1

I write this new series to address a growingly common problem I’ve recognised over the years, where the deployment of Office 365, especially SharePoint Online, within an organisation is pretty mucky and inflexible because a previous implementor made some poor architectural choices. I hope with these articles, I can share some of the things I have learnt both as a past SharePoint Consultant for Microsoft Consulting Services, standing on the shoulders of giants in the SharePoint world who have shared their insights with me like Steve Peschka, Vesa Juvonen, Laura Rogers, or subsequently on the field in my years up to today as a SharePoint Architect and Consultant for several companies and organisations.

So my first piece of advice, which strangely, isn’t that obvious to many independent consultants or vendors I’ve met who consider themselves “SharePoint-saavy”. If you’re gonna play in the Microsoft “garden” of Office 365 when delivering services as a strategic advisor or consultant, it’s best that you grok (learn and appreciate the reasoning behind) Microsoft’s rules for “keeping their Office 365 garden green”. While I would not say to follow blindly and don’t do what makes sense, my humble advice is simply this:

Before trying to design a solution architecture from scratch, or with old habits from other platforms used before in mind, as much as is possible, follow Microsoft’s lead in architectural thinking of Office 365 solutions by understanding the Microsoft approach to the problems (use cases and scenarios) that each of the many Office 365 tools/products try to solve, the users they are seeking to engage with their different product tier offerings, and their preferred practices with deploying Office 365 to a customer.

To help in this journey, Microsoft Docs, and its predecessors Technet and MSDN should be the first place you start looking for official Microsoft documentation to help justify your proposed approach as a valid one, followed by the Microsoft blogs. More recently I’ve also found TechCommunity very useful in providing “specific context” answers thru connecting my posted questions with responses from other (much smarter) SharePoint experts. There is nothing weak in seeking advice and posing questions no matter how far along you are in the journey to master the “Tao of the Microsoft Office 365 deployment”. And it’s probably gonna be even sweeter a taste of victory when you might have the answer for someone else later on and are able to post this as a response.

You can, of course, choose to live on the edge and try something different than the Microsoft preferred approach, and unfortunately I see this approach being used more as the 1st choice rather than as an alternative given some mitigating circumstance for which existing Microsoft guidance doesn’t cover. The risk of living on the edge like this is falling over the edge by implementing things that break the mantra of the Office 365 ecosystem.

Consider as well that this type of “against the grain” approach comes with a side-effect for future supportability. Microsoft probably put lots more thought into how their recommendations will allow users to move smoothly to v.Next of Office 365, something you or I and our smaller teams may not have had the time, capacity or insight into future product roadmap to do with any alternative approach that may be considered. This is the tradeoff with any solution that is architected having a dependency on another platform. But it is a reasonable one given the further overheads going “greenfield” with a solution from zero code would present.

A risk of non-traditional approaches that don’t take an educated approach in understanding the Microsoft perspective on their product environment, is of becoming a ‘weed’ in the “botanical garden” of Office 365.

To follow thru on the analogy, a “weed” to me is a solution approach promoted by a consultant or organisation that is recognised by peer experts, other partnering or competing vendors, or in the extreme, Microsoft, as detrimental to the continued health and well being of the garden’s other flora. By using this solution, it serves not just the entire Office 365 ecosystem poorly, but also the customer it is delivered to, since they are at the end of the day, limited in some manner to utilising the full power of the product they’ve paid good money for.

A good architect should structure his/her architectural thinking of Office 365 deployments, any customizations done and their method of delivery, so that the aim instead should be to grok the ecosystem and the rules within so well that your approaches and add ons become the ‘exotic flower’ in the Office 365 botanical garden that adds to its overall beauty by your software’s or service’s very presence amongst the other “flowers” including Microsoft’s own homegrown ones.

Personally, two vendors I’ve used, ShareGate and LiveTiles are great example of this type of thinking. Another, SkyKick, is worth mentioning as well as I’ve seen how their product works, although not deployed it myself, and you can tell they have they definitely “grok the Tao of Office 365” in how they designed their product.

In part two of this series, I’ll start to go into my personal framework for structuring my architectural thinking for new Office 365 deployments, which is founded on two key entities: Users and Tools.