Posted by 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.
Redditech 'Ground Zero' Blog 