Author: redditech

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.

In my first post on this series, I gave the “why” behind thinking the goal to grok the “Tao of Microsoft Office 365 deployments” from Microsoft’s point of view is an important one for structuring the architectural thinking for a new Office 365 deployment. This time, let’s get started on the “how”. I’ll go deeper into the framework I structure my own architectural thinking for Office 365 deployments.

For this framework, consider that a Microsoft Office 365 driven Intranet environment, in my experience working with organisations, is best architected when thinking of it in smaller chunks. This is general Problem Solving Rule #1. So, starting with the highest level, one can say a Microsoft Office 365 deployment is broadly composed of mainly two entities: Users and Tools. Subsequently analysing and breaking down each of these entities into further child entities, where each entity must be given due consideration, is what follows. To do otherwise will, in effect, be designing an incomplete architecture for Office 365’s deployment.

Note: An Office 365 deployment, to be effectively implemented for present use cases, user stories and needs that initially drove the initiative to deploy Office 365 within a client organization, may choose to not be this rigorous initially to “get it live” in the shortest possible time. However the tradeoff with this approach is that it does not meet a desirable goal of a deployment to be configured in as close to zero-friction manner as possible for adapting/adjusting it later to meet future discovered needs of the organisation as their deployment’s adoption matures. In other words, even though it is not software code we are writing, with this approach we actually do better to keep the technical debt low when changes are needed.

I’ve seen from peer consultants in the past how users, their direct input and their feedback, is skipped over or avoided for as long as possible in most deployments. Maybe this is an inherited thinking from the “waterfall” model days in software delivery, or maybe it’s simply less friction to get a deployment rolled out without this input gathered prior.

Anecdotal evidence from my own past engagements shows though that if deliberately sought first, even if just thru a simple survey of a baseline of Office 365 tenant users, understanding your users and their immediate highest-priority problems that Office 365’s tooling can solve clearly with an initial deployment or minimal post-deployment configuration, can make a world of difference in sustaining universal adoption of Office 365 in a business environment.So with that to chew on, let’s get started with our first major entity, Users.

Users

Users are the folks like you and me, every member of the organisation from the CEO and his board of directors, to the guys in the mailroom, as well as possibly the vendors who provide other services to the organisation that are critical to their needs, e.g. raw material suppliers, maybe even the donut and coffee guys if you’re really going for inclusivity in your Intranet. Thinking of users in general can be a very broad use case, perhaps too broad to define meaningful scenarios, so how do I go about classifying users to begin with defining and prioritising their usage scenarios in my new Office 365 deployment? For the architecture of an initial Intranet deployment, I tend to think of users as being further divided into two types of users: internal users and external users

Internal Users

Internal users have an organisational account and can access the full range of Office 365 products, including Microsoft Office products under licence by the organisation like Word, Excel, Visio, Project, etc. The licensing tier of an internal user does not affect the “shared experience” within the organisation’s single Office 365 tenant, only what parts of the tenant and what software the user has access to. For example, an Office 365 ProPlus licensed user has access to desktop versions of Microsoft Office, but not online tooling such as Exchange, SharePoint or Microsoft Teams, but for an Office 365 E1 licensed user, the reverse is true. Both are listed as tenants within the Microsoft Office 365 administration portal though, and both types of users will have logon credentials for the Office 365 product site. More details on what each tier supports is comparatively listed on the Microsoft Office 365 product site, and may change as new products are released or enhanced, so it’s always good to take a look for any changes over time and never assume what was valid in the last deployment, is valid again with the next.

So this is where some work in architecture may need to be done that isn’t necessarily technical. Each organisation can get pretty unique here with their organisational structure. If an organisation doesn’t have an official organisational chart, this may be the time that one is collaboratively built that the client organisation is willing to go with initially. This organisational chart, officially accepted by stakeholders, would then fuel the discussion establishing guidelines for setting up the initial groupings of users who should be actively communicating or collaborating with each other. This grouping will be revealing as well when compared to the Office 365 licensing tiers, since it will then establish which is the appropriate Office 365 licensing tier for these each of these groupings. It can also help at a high level to establish shortcomings in licensing, and to start anticipating whether some customisation would be needed to help here thru a 3rd party component developed in house or provided by a vendor to onboard certain users. If an initially speedy “pilot” deployment is a goal, following this part of the framework for structuring architectural thinking in an Office 365 deployment will save you the time by not incorrectly adding pilot internal users to the initial deployment that would need additional time to on-board to Office 365 because of the need to plan and deploy these extra 3rd party components. If these users are priority users, it can help establish early on what expectations of “speedy pilot deployment” are reasonable given the inclusion of these pilot users.

External Users

External users do not have an organisational account in the Office 365 tenant, so don’t have a licensing tier, but do have a valid role since many organisations work with vendors, contingent staff or partner organisations intimately enough to share the corporate knowledge traditionally created, modified and stored in an Intranet environment. Usually an organisation will at least have an email address on record for each of these users. But there’s also the possibility for a special type of external user, the anonymous user, who may not have any recorded login credential for but who you may want to involve in Intranet processes such as accessing common documents, or gathering feedback from. Examples of external users may be your retail end-customers, sales leads, or even potential new employees or vendors applying for published vacancies within the organisation.

So it is a quite valid use case that external users, both with known email addresses and unknown ones, can have limited access to parts of the Intranet to enable the organisation to utilise the Intranet more effectively. This is exactly why I think Microsoft allows this limited usage experience in Office 365. The exact details of these limitations are already well documented  by both Microsoft official documentation at and some of its leading partners’ blogs like ShareGate and there’s a healthy discussion thread on configuring and enabling external users properly on TechCommunity forum as well, which I highly recommend to anyone to start participating in if you have questions here.

So now that we’ve dealt with structuring architectural thinking of an Office 365 deployment with consideration of the first main entity of Users, in the next post, we will use our insight into users as we consider our 2nd overarching entity, Tools.

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.

I love my Macbook Pro, but I’m a Windows developer by profession, so marrying the two worlds required I make use of tools like Parallels for Mac, which easily allows me to integrate Windows 10 into my Mac OSX experience thru Coherence mode. At a reasonable subscription cost, it’s the best option for independent developers like myself who don’t have an Enterprise budget.

However sometimes you want that full screen Windows experience to focus for a bit.

That’s when you realise Full screen mode Windows 10 using Parallels for Mac is an awesome feature. It almost makes me forget I’m on an Apple device. Until I’m ready to go back to OSX, and then I’m stuck. How do I exit this full screen mode if there’s no Apple window title button to click to exit?

The answer is simple, press Ctrl+Command+F to activate the shortcut key combination for both entering and exitting Full Screen mode with Parallels for Mac.

Thank Google and this reference article for the information 🙂

Reboot coming soon!