Introduction

This post is the second in a two-part series where I look at how and when the Modern UI should be adopted in SharePoint Online, including the benefits constraints, and design decisions that need to be weighed up as part of this process. In my first post I covered the first two steps below, in this post I cover parts three and four:

What compatibility problems (if any) are there for existing sites in SharePoint Online, and what do we need to do to address them?
What compatibility problems are there that may constrain or alter the approach for future design and development work, and how might we address these problems?
What requirements/use cases are there that mean moving to the Modern UI provides benefits to either the business or IT?
What options do we have for if/when we roll out the Modern UI, what are the pros/cons of each, and what is our recommendation?

Step 3 – Benefits of the Modern UI

So having spent the previous post unearthing a myriad of reasons not to adopt the Modern UI, it’s only fair that I go into a bit more detail on the benefits of adopting it. It’s undeniable that the UX is better in the Modern UI and offers a far more intuitive way of getting stuff done. Once you become familiar with the new layout, it makes things like menu options easier to find. I’ll go into a little bit more detail in this section.

User Experience – Lists/Libraries

Easier to Switch Views

Minor UI tweak, but the Modern Experience makes it easier to navigate between views of your library/list.

Easier to Customise Views

Users can change column widths, and sort, filter and group information to customise their view. They can then save the view to make it available to other users, without having to go into the hideous ‘Create a View’ interface we all know and love.

Pinning Documents

Important or frequently used documents can be ‘stickied’ to the top of document libraries, helping to highlight vital information to users. This can be really useful in big document libraries where only a few documents are truly useful.

Properties Pane

You can edit item metadata in-line in a nice new pane that appears on the right-hand side of a list/library. This pane also shows a preview of documents, and who they’re shared with. It’s a much easier way of accessing the stuff previously buried in the context menu or in pop-ups.

List Forms

The out of the box list forms have been revamped and generally provide a much more intuitive experience for end users.

Copy and Move Files Easily

These toolbar items provide a much easier, more intuitive way of moving/copying files to other areas of SharePoint.

Consistency

The Modern Libraries and Lists look like OneDrive, which provides users with some much-needed consistency across different services in Office 365.

User Experience – Sites/Pages

Permissions Management

Modern Sites expose the membership options on every page to site owners, and offers a far simpler way of managing membership than the overly-complex, cumbersome SharePoint model.

Page Editing

It’s much easier to edit pages now. You can add a web part far more simply, move them around far more intuitively (it’s nice not to have to threaten death to Bill Gates when web parts inevitably move into the wrong zone or in the wrong order), and the nasty old edit web part pane is massively improved.

Modern Web Parts

The best thing about Modern Pages are the Modern Web Parts themselves, which are all really useful and much easier to set-up than the old-school web parts. You can very quickly get pages looking really good and really useful.

Cross-Device Compatibility

The Modern UI moves SharePoint into the present in terms of mobile device compatibility. Forms, pages, libraries etc. will now display nicely on tablets and smartphones, without the need for custom CSS.

Integration

Office 365 Groups and Teams

Modern Sites are provisioned automatically alongside new Office 365 Groups, and are intrinsically linked to Groups and Teams. The Modern Site (also known as a Group Site) is the default storing place for files within the Group, and the out of the box ‘Files’ tab within Teams.

PowerApps and Flow

PowerApps and Flow can be easily integrated into Modern lists/libraries to create business applications/forms and basic workflows. I’ve not worked with any organisations yet that have widely adopted PowerApps or Flow, but I’m sure there are plenty out there who will see this deeper integration as a big win for the Modern UI.

Increased Storage Capacity

Site collections created as Modern Sites (as opposed to them being upgraded to the Modern UI later) can store a massive 25TB of content, up from the previous 1TB limit. The 1TB limit was already massive and serviced all but the most unusually large sites, but 25TB of storage is truly enormous. This gives even more flexibility to your IA (information architecture) planning, and all but removes site collection storage capacity as a constraint, allowing you to focus on other things like security boundaries and usability for your IA.

Step 4 – Options and Recommendations

Now that we’ve considered the impact to your existing estate; how you’ll be constrained for future work; and the benefits of upgrading to the Modern UI, we can compare different options of when/if to adopt the functionality.

Here are a few general things to consider when you’re looking at options.

Things to Consider Before You Come Up with Options

Consider Constraints Versus Benefits

Probably the best way to approach this decision point to weigh up the constraints of going Modern versus the benefits. Organisations are likely to weigh criteria differently depending on their exact context and business use cases, so it’s up to you what you consider the biggest areas of concern or benefit. In my current client’s case, the constraints around the provisioning, the fragmented user experience between classic and modern lists, and the (current) lack of support for a global navigation were big knocks against the Modern UI, but in other companies these may be more acceptable. Conversely, the business are crying out for a more intuitive page editing experience, whereas in your organisation this might not be seen as especially important.

Consider Whether to Upgrade Legacy Sites

The longer you leave it to upgrade to Modern, the more legacy sites you’ll have to deal with down the line. Sometimes you can ease this concern by coming up with blanket rules, such as “All existing project sites will remain in Classic” (as a project site has a finite lifespan), but most of the time you’ll need to consider sites on a case-by-case (or at least a template-by-template) basis.

My advice is to approach this like you would a migration: unless there is a good reason or a business case to justify putting in the remediation effort to change a site to Modern, don’t do it. Think about it in much the same way you would consider rebuilding a business application running on some old on-premises kit as a provider-hosted add-in in SharePoint Online: if it doesn’t provide some ROI, it’s just not worth the hassle, risk, and expense.

Consider the Fragmented User Experience Between Areas of SharePoint

I’m not talking about the fragmented experience of hopping between Classic and Modern lists here (which I’ve already covered), but the fragmented experience traversing Modern and Classic Sites. During your adoption of the Modern UI, it’s likely there will some sites that remain as Classic either indefinitely or for a period of time, and others that are either born Modern or upgraded quickly (due to them having no compatibility issues). And that’s not to mention the fact that your publishing intranet sites will be unable to adopt the Modern Sites experience for the foreseeable future!

Consider Fragmented Training

Your training delivery and material will likely need to cover both Modern and Classic configurations, as stuff has been moved about in the menus and generally looks quite different. This has impacts on the cost and resources required to train your staff.

Consider the Support Implications

Similar to training, you will need to support two types of experience. This has implications in terms of the knowledge required for support staff, and might make it harder for 1^st/2^nd line support to resolve issues. You could see an increased number of tickets flowing down to 2^nd/3^rd line when they might have previously been resolved further upstream.

Consider the Maintenance Implications

Another risk is that you could find yourself having to maintain two ‘copies’ of the same site type/template; one designed for the Classic UI and one for Modern. There’s a very real chance you’ll face a scenario where an urgent change needs to proliferate across all existing and future sites of that type, and guess what? You’re now going to double your test execution effort, and will probably need to spend more effort on design, development work, test scripting, automated regression testing set-up, and deployments to accommodate the two UIs.

Consider the Strategic Direction Microsoft Are Taking Things

The Modern UI is where things are all heading longer-term for SharePoint. At some point, you will have to get on the bandwagon, or you will miss out on useful new functionality and features being rolled out on Office 365.

You shouldn’t really look at “going Modern” as a question of if, more a question of when you do it.

Assessing the Options

As mentioned above, this should be a question of when, not if, you move to the Modern UI. For me, there are a few options worth looking at for when you choose to make the move, and these are:

Go Modern immediately;
Go Modern in c. 3 months (when things like embedding custom JS hit general availability);
Go Modern in c. 6 months (when – hopefully – other stuff like custom page layouts, new web parts etc. hits); and
Do nothing/stay Classic (included in the interest of fairness more than anything).

It’s going to depend on your organisation, your situation, and your stakeholders how you go about recommending what to do. But if you want to take the decision down to a very granular level, you can do something like I’ve done below.

In this table, I’ve got rows for every ‘consideration’, including the broad areas of constraint, benefits, how much remediating action would need to be conducted, and the extra stuff I outlined above. Against each criteria, I’ve given a weighting % for how important it is in the grand scheme of things. Obviously, this is likely to change in your organisation. Then, I’ve given a score out of 5 (with 0 being terrible and 5 being excellent) for how a particular option deals with a particular criterion. Again, this is highly subjective and you may vehemently disagree with my scores here!

Finally, a weighted score for each option can be derived, indicating which is the “best” option for you situation.

I’ve stuck the spreadsheet this table is derived from on my OneDrive here:

https://1drv.ms/x/s!AkfwQi26meWDgegN95w0IwNRaHJR-A

Final Recommendations

According to how I scored and weighted things above, it’s clear that moving to the Modern UI immediately would present too many challenges to overcome. Doing nothing is – despite it’s relatively high score – not a great idea either. For this reason, my final recommendations were as follows:

Adopt Modern (SPFx) Web Part development immediately to future-proof any customisations;
Trial workarounds for the provisioning issues (e.g. we can implement processes whereby an admin or power user adds an app to configure the homepage of a Modern Site how we want it to look, and implement a Proof of Concept for a UI-based execution to do this programmatically);
Build any new templates required in the next 3 months as Classic sites;
Leave all legacy sites in Classic mode for the time being;
Trial the Modern UI with business champions to see if there are specific use cases that will force us to go Modern;
Enable Modern on the tenant and ensure scripts for downgrading incompatible areas to Classic work; and
Reassess things in three months’ time, or whenever additional information is made available on the Public Roadmap.

Conclusion

So, there you have it. Hopefully this post helps some of you guide your organisations or clients as to if/when they should adopt the Modern UI. As I noted earlier, this is a bit of a moving feast as Microsoft are continually rolling out updates and making new information available to us about what’s coming down the pipeline, but – for the time being anyway – this post should serve as a useful reference or starting point for your own research.

My TL;DR (too long; didn’t read) summary of the Modern UI would be as follows: It’s great, but it’s not quite enterprise-ready yet.

The problems around provisioning and the limitations it puts on customisation currently means it is not feasible to roll it out in large organisations with a lot of legacy content or demand for new collaboration spaces. The only situation in which I would confidently endorse fully adopting the Modern UI in its current guise is for organisations with brand new, greenfield SharePoint Online implementations.

As it happens, I actually went into this process with the belief that my client should adopt the Modern UI immediately, in order to align themselves with Microsoft’s strategy. It was only after doing more research and testing around the constraints that I was forced to climb down from my original position and adopt a more conservative outlook. For most of us, the Modern UI just isn’t there yet. But I’m hoping my view will change once more updates are released!

Thanks for reading.

< Previous post in this series

How and When to Adopt the Modern UI in SharePoint – Part 1/2

July 23, 2017September 1, 2017 nathanwells20142 Comments

Next post in this series >

Introduction

I’ve spent some time over the last few weeks doing an impact assessment of moving to the new(ish) ‘Modern UI’ in SharePoint Online. I looked at it primarily from a technical angle so that my client can decide whether to adopt it now, based on the constraints of the current technology. The conclusion I reached was that it’s not quite ready yet.

This post isn’t an attempt to bash Microsoft or poke holes in this functionality. I actually think the Modern UI is great, and completely the right direction for Microsoft to take things. But for me, it’s not quite an ‘enterprise-ready’ product yet. Hopefully this post helps other customers out there facing a similar dilemma, or at the very least frames how you can do your own assessment of whether or not to ‘go Modern’.

The post ended up getting pretty big, so I’ve split it into two parts:

Part One: Introduction, assessing compatibility for existing sites, and assessing constraints for future work; and
Part Two: Benefits of the Modern UI, and options/recommendations for how and when to adopt it.

What is the Modern UI?

Microsoft have been introducing the ‘Modern UI’ for sites in SharePoint Online over the last year or so. This new functionality provides a better user experience, cross-device compatibility, better integration with other products in the Office 365 suite (namely, O365 Groups), and a 24 TB increase in total storage space per site.

It surfaces at three ‘levels’:

Modern Sites, in the form of Modern Team Sites (AKA Group Sites) and Modern Communication Sites;
Modern Lists and Libraries; and
Modern Pages.

Above: A Modern Page on a Modern Site

Above: A Modern Library within a Modern Site

However, Modern UI offer some drawbacks around the customisations that can be achieved. These constraints will directly affect how, where and when the Modern UI can be adopted within many organisations’ Office 365 environments.

Process for Assessing the Impact of the Modern UI in Your Environment

When I was looking at if/when the Modern UI should be adopted and rolled out in my organisation, I undertook four steps, which I will detail in this blog post. At a high-level, these steps were:

What compatibility problems (if any) are there for existing sites in SharePoint Online, and what do we need to do to address them?
What compatibility problems are there that may constrain or alter the approach for future design and development work, and how might we address these problems?
What requirements/use cases are there that mean moving to the Modern UI provides benefits to either the business or IT?
What options do we have for if/when we roll out the Modern UI, what are the pros/cons of each, and what is our recommendation?

As mentioned above, Steps 1 and 2 will be covered in this first post; Steps 3 and 4 will follow in a second post.

Step 1 – Assess Compatibility with Existing Sites

Before moving to the Modern UI, you are going to need to look at how it plays with any existing sites you have in your Office 365 tenant. There may be bits of customisation and configuration that preclude certain sites or lists from becoming Modern, and mean that you need to do some remediation work or plan for leaving some sites/areas behind in the Classic configuration.

To help with this assessment, the PnP (Patterns and Practices) team at Microsoft have provided a really excellent tool called the ‘SharePoint Modern UI Experience Scanner’. There are some solid instructions in the GitHub repository that even a plebeian like me could understand and follow, so you shouldn’t have too many difficulties getting this up and running in your environment – provided you have an admin account to set-up an app-only principle with tenant permissions.

The UI Scanner trawls through every site on your tenant and outputs a whole raft of CSV files at the end of it. These CSVs provide information on incompatible customisations and configurations at both the site level and the list level. I created a Power BI report to make the information a bit more human-readable, but you can achieve something similar in Excel (or draw your own conclusions straight from the CSV, if you don’t need to represent an impact assessment to a broader audience).

My tips to get meaningful information out of the reports are as follows:

Site-Level Customisations

IgnoredCustomisations.csv is the high-level report that tells you sites with custom Master Pages, custom CSS, or Custom Actions. These things are currently incompatible with the Modern UI.

My top tip for this report is to make sure you filter out any Publishing sites, i.e. stuff that is related to your publishing intranet rather than being a collaboration space. You might be able to do this via something as simple as which managed path a site resides under (/teams or /sites), but you may need some slightly more complicated logic to weed out the irrelevant stuff. The Modern UI cannot be used on Publishing sites anyway, so they’re kind of irrelevant for a compatibility report.

It’s also a good idea to find a way to call out any sites with no issues, so you have a clear way of knowing which sites you don’t need to refactor to get them working with the Modern UI.

My Power BI Report for Site-level customisations ended up looking like the below:

List-Level Customisations

The ModernListBlocked.csv file provides a whole heap of information about compatibility issues that might prevent you from switching on the Modern UI in certain lists/libraries. These issues fall into two broad buckets:

Out of the Box Issues: Areas where things outside of your control mean that the Modern UI is not available for this list/library. This includes stuff like the base list template being incompatible; the view type being incompatible; or an unsupported field type (such as geo-location fields).
Customisation Issues: These are areas where you, foolish developer, have caused a compatibility problem by customising something on a list or library. This includes stuff like custom list actions; JSLink; XSL; or multiple web parts added to a list view page.

I’ll discuss these limitations in much more detail in the next section, as they all need consideration, but for the purposes of assessing compatibility with your existing estate, my top tip for this report is to, again, find a way of filtering out the irrelevant publishing sites. A second tip is to find a way of categorising the type, or base template, of the list for each row. The report provides this in the format of a list base template identifier (e.g. 107, 108, 120 etc. etc.) from which you can infer the actual list type. For example, 104 is an Announcements list, 105 is Contacts, 106 is a Calendar, etc.

My Power BI Report for List-level customisations looked like the below:

How do I Upgrade?

Enabling Modern

Before you can think about when/where to upgrade, you need to enable the Modern UI on your tenant. This is simple to do, but has the potential to create a massive pain in the a**. Enabling the Modern UI is like an on/off switch. You can’t enable it at a more granular level, only across the tenant. This means you need to then script a downgrade for classic to any sites with compatibility issues, and for any sites you need to provision as Classic Sites. This is a massive pain in the neck. Once Modern is enabled (and you’ve disabled it wherever you need to disable), you can do the following:

Creating a Site as Modern Natively

Obviously, this isn’t an upgrade, but it’s worth noting here that new sites can be created as Modern natively. That said, read on to find out some of the constraints you have around provisioning Modern Sites, and other limitations you’ll experience once the site is up and running! This applies to sub-sites as well as new site collections.

Upgrading an Existing Classic Site

To upgrade an existing site in the classic configuration, you will need an admin to run a PowerShell script. This can be done against one or many sites.

Before doing this, you should – of course – have followed the guidance I outlined above around assessing the compatibility of your existing sites with the Modern UI. You might find that you need to do some remediation work before you can run any scripts.

Upgrading an Existing Classic List/Library

There are a few options as far as upgrading lists/libraries to the Modern UI goes:

Administrators can set the default list experience for the whole Office 365 tenant.
Site owners can switch lists and libraries to the Modern UI on a case-by-case basis.
Administrators can run a PowerShell script to programmatically change the default list experience, or upgrade individual lists across a site or many sites at once.

Again, keep in mind that fact that many list types are not compatible with the Modern UI.

Upgrading an Existing Classic Page

Unfortunately, it is not possible to upgrade a Classic web page on a SharePoint site to Modern. Pages will need to be recreated as Modern Pages.

Recommendations for Remediating Existing Sites

If you’re finding lots of team sites, project sites or other collaboration spaces with custom CSS or master pages, you should consider changing these to something more generic. The general guidance extolled by Microsoft and SharePoint experts for the last couple of years has been to avoid doing these types of customisations to collaboration sites. However, in the real world, organisations usually want – at the very least – a consistent global navigation experience with the rest of their intranet/SharePoint environment. Unless you’ve kept your SharePoint environment extremely vanilla, it’s likely you’ll have some quite extensive work to do here to get these sites ready to go Modern.

As for lists, it’s unlikely that there will be any sites that don’t have at least a couple of lists with compatibility issues. This is due to the lack of Modern UI support for some very common list view types and base templates. But for lists with customisation issues, you should look at how feasible it is to tweak these, keeping in mind that support for some of the things that cause issues with Modern Lists at the moment is coming down the pipeline.

Step 2 – Assess Constraints for Future Design and Development Work

The next step I recommend is to familiarise yourself with where and how the Modern UI constrains what you want to do in the future. To help with this, I’ve looked at a variety of things an organisation might want to do with a SharePoint site, and compared the capabilities in Modern to the existing capabilities in Classic. For anything that the Modern UI does not yet support, I’ve included a bit of detail I’ve gleaned from Microsoft’s Public Roadmap (or bits I’ve inferred from supporting information around the roadmap).

It should be noted here that this blog post is correct at the time of writing (July 2017), in terms of the items on the roadmap and where the gaps are, but it will likely become out of date. I’d also say it’s highly unlikely I’ll maintain the blog post going forwards, so I’d suggest doing some of your own research around the roadmap if you’ve come across this post more than a few months after its initial published date. But

The areas I consider are as follows:

Provisioning: How sites can be programmatically created to enforce consistency of structure, look and feel, information architecture etc.?
Branding: How can a site be configured to look and feel the way a business wants it to?
Custom Pages: What are some of the constraints around editing custom pages on a site?
Site Management: What needs to be kept in mind for the management of existing sites, in terms of settings, configuration, and adding new areas to the structure?
Site Discovery: How is the discovery/findability of sites impacted by the Modern UI?
List Views: What compatibility problems are there for specific types of list view in the Modern UI (building on what I alluded to in the compatibility with existing sites section)?
List Customisations: What customisations can you make at the list level?

In addition to the areas I’ve considered below, there are a few extra specifics in this article from Microsoft: https://support.office.com/en-us/article/Differences-between-classic-and-new-experiences-for-lists-and-document-libraries-30e1aab0-a5cc-4363-b7f2-09e2ae07d4dc?ui=en-US&rs=en-US&ad=US

Feature Gaps and Constraints

Provisioning

While Modern sites can be created programmatically as part of a provisioning process (including all the content types and metadata fields that are required), you have no way to make the homepage of the new site look how it needs to without human interaction. Currently, you must add a new app to a newly provisioned Modern site manually, unless you create some sort of hacky UI-based execution, which has significant risk attached to it if Microsoft make updates.

Branding

Options for branding Modern sites are extremely limited, though further options akin to Master Pages and custom CSS are being rolled out as I write, and should hit General Availability (GA) in the next few months. The key takeaway here is that Modern Sites/pages will not look like the rest of your SharePoint environment if you have customised it in any way, and it is currently impossible to make them fit in look and feel-wise.

Update Sep 2017: The SharePoint Framework Extensions (the things that give you the ability to add custom Global Nav and brand a Modern Site) are now out of preview and available on first release tenants.

Custom Pages

The types of Modern Page that can be created are relatively limited, though the pages themselves are much easier to use for both end users and editors. It is also worth noting that Modern Web Parts are Microsoft’s clear strategic direction, and should become the de facto way in which custom web parts are developed in your organisation. If you’re not adopting the SharePoint Framework (SPFx) wherever possible for custom web part development, you are creating a bigger and bigger backlog of legacy stuff that will eventually need to be refactored.

Update, Sept 2017: All Modern Pages (across both Group Sites/Team Sites and Communication Sites) can now change their layout to various choices. This is actually really nicely implemented, and a lot more flexible than the old page layouts and web part zones on classic pages.

Site Management

Modern Sites are currently only designed for collaboration (team/project site) scenarios, not web content management.

There are also issues with sub-sites created beneath Modern Sites, in that the homepage of the Sub-Site will be Classic, not Modern. This is a biggie for me, as it creates terrible inconsistency and is very confusing for site owners. Again, this is something that could possibly be addressed with a bit of a hack, but that’s not an ideal solution, or indeed a supported one.

Site Discovery

Modern Sites/pages can be rolled up and presented in much the same way as Classic sites/pages, though some tweaking of the current configuration of your Content by Search web parts may be required. Also worth noting here is that it is not possible to capture metadata for a site in the property bag of Modern Sites. Some custom applications will have previously utilised the site property bag (rather than tags on pages or hiding properties away in some sort of site configuration list) in order to classify a site for rollup/discovery purposes when surfacing it through search. This is no longer an option, and if you’ve done this, you might have some serious remediation work on your hands.

They can also be attached/created as part of a new Group/Team to provide a more seamless interface with these other services in the Office 365 suite.

List Views

Some core list functionality does not work in the Modern UI, including Gantt and Calendar views which are widely used on collaboration spaces (at least in my experience). This means there will be a fragmented user experience if the site is Modern, but the list remains in classic mode. Something you must accept in the Modern UI is that there will – for the time being at least – be a degree of jumping around between Classic and Modern layouts as you move between lists. This has knock-on effects for training guidance and collateral, which must be kept in mind when you’re assessing the impact of the Modern UI (more to come on this in the next post).

Additionally, there are several field types that don’t work in Modern lists, though these are unlikely to affect the majority of sites.

List Customisations

Lists with customisations generally do not work in the Modern Experience. However, Microsoft are rolling out the ability to add more customisations to the Modern Lists experience as we speak.

Microsoft’s Roadmap

Stuff That’s on the Roadmap

So this is a summary of the things that are on Microsoft’s current public roadmap, or at least alluded to as part of the collateral supporting related roadmap items.

Update, Sept 2017: As noted above, the ‘Injecting Content’ item is now out of preview and available to first release tenants.

Stuff That’s Missing from the Roadmap

This is a summary of constraints that aren’t on the roadmap to be addressed by Microsoft:

Wrapping it Up

So that’s it for Part One of this two-part series. It’s been slightly one-sided so far, but in the next post, I’ll cover off the benefits of the Modern UI, and options/recommendations for how and when to adopt it in your organisation.

Thanks for reading.

Next post in this series >

New Office 365 Feature: Per-Group Sharing Controls

June 12, 2017 nathanwells20141 Comment

When you’re thinking about enabling collaboration with external/third party users in your organisation’s Office 365 tenant, there are a lot of things you need to think through, agree, and design around. These include:

Which applications will you allow external sharing in (SharePoint Online, OneDrive for Business, Office 365 Groups)?
Will you enable member sharing, or require site owner approval when content is externally shared?
Will you enable or disable anonymous links?
How/where will you use domain restrictions?
Is there anywhere you’ll disable external sharing completely?
How will you encourage users not to share content with consumer identities?
What processes will you put in place to manage/maintain external user permissions and guest invites?
How will you tweak your IA (information architecture) to encourage good practices for external sharing/permissions management, e.g. sharing at the site/library level rather than per document?
Will you enforce MFA (multi-factor authentication) on guest users?
And lastly, but perhaps most importantly, will you use Azure AD B2B Collaboration or the traditional SharePoint Online external sharing model?

Now though, there’s one more thing you can add to that list: Per-Group Sharing Controls.

This new feature – which hits first release tenants in June 2017 – will give Office 365 administrators a little bit of extra control over who and how information can be shared with external/third party users in SharePoint Online and OneDrive for Business.

There are two new settings, the details of which I’ve lifted from Microsoft’s blog post on the subject:

Let only users in selected security groups share with authenticated external users – With this option, you can specify one or more Office 365 security groups which contain the users who you want to allow to share with authenticated external users. Users in these security groups will not be able to send anonymous links.
Let only users in selected security groups share with authenticated external users and using anonymous links – With this option, you can specify one or more Office 365 security groups which contain the users who you want to allow to share with authenticated external users and by using anonymous links. (This option doesn’t appear unless you have enabled anonymous access links for the tenant.)

The current set of options that the Per-Group Sharing Controls build upon are relatively coarse. The options available are: external sharing is disabled completely; external sharing with anonymous links is enabled; external sharing with only authenticated users is enabled; and sharing with users who already exist in your organisation’s directory (AKA the Azure B2B option). These options are available at both the tenant scope and site collection scope, though the site collection settings cannot be less restrictive than those defined at the tenant level (i.e. most restrictive setting wins).

The new functionality gives some extra granularity on top of these existing settings. You now have three separate audiences of users that can have different levels of external sharing ability:

Users who are unable to share content externally (by virtue of not belonging to a group specified for either option);
Users who can share authenticated links; and
Users who can share authenticated links and anonymous links.

But unfortunately, the feature can only be defined at the tenant scope, not per site collection. How it’s going to play with the existing set of options is also slightly unclear at the time of writing, but I’ve been informed that the site collection settings will take precedence. For example, if anonymous sharing is disabled at the site collection level, even users in the security group that can share anonymous links will not be able to do so in that site collection. This suggests that the best way to get set-up for these new controls is to allow anonymous sharing in each site collection in all but exceptional circumstances, and control who is actually allowed to undertake this action via the new Per-Group Sharing Controls.

Also worth noting here that this new feature only covers security groups (i.e. the thing that would once have been defined as a mail-enabled distribution list). It doesn’t cover Groups, as in, Office 365 groups. Confusing, but an important distinction.

It will be interesting to have a play with these new settings when they start rolling out, but for now, it’s one more thing to consider when you’re setting up your organisation for collaboration with third parties.

Planning for the Azure CDN Capabilities in Office 365

May 29, 2017 nathanwells20141 Comment

Introduction

At work the last couple of weeks, I’ve been looking at how an Azure Public CDN (Content Delivery Network) and the newly-released SharePoint Online CDN can improve performance for geographically dispersed users in Office 365. There are a few important factors to consider, but generally I think these are great options for organisations with users experiencing latency in Office 365 due to their location.

What is a CDN?

A CDN takes static web content used by web pages on SharePoint, web sites, and other custom web applications (such as images, fonts, JavaScript and Style Sheets) and stores it at strategically placed locations around the world. In an Office 365 set-up without a CDN, this content gets served to the client/user from the base location of the Office 365 tenant, be that North America, Western Europe, or wherever Office 365 was originally set-up. This results in terrible network latency for geographically dispersed users thanks to the large distances involved. But after a CDN is implemented, this content can be served to the user from their nearest data centre, as opposed to the primary tenant location. This provides much better performance and a much improved experience for users, regardless of their location.

What options are available?

Azure provides two ‘flavours’ of CDN: the Public CDN, and the Private CDN. The Private CDN (also known as the SharePoint Online CDN) can only cache assets stored in SharePoint libraries, and checks the user’s access to the original location of the asset before serving it to them from the CDN. The Public CDN allows broader access to assets cached in the CDN, meaning it can be used for all manner of web applications, and cache files hosted outside of SharePoint.

So in other words, the new SharePoint CDN can be used to serve assets from SharePoint Online to other SharePoint Online pages, while the Public CDN can be used for everything else and isn’t purely for SharePoint.

Further constraints around the types of files that can be cached by the SharePoint CDN drives how you should architect your CDN(s) for Office 365. The SharePoint CDN can only cache files of the type .gif, .ico, .jpeg, .jpg, .js, and .png, while the Public CDN can cache files of the type .css, .eot, .gif, .ico, .jpeg, .jpg, .js, .map, .png, .svg, .ttf, and .woff. The key gap for the SharePoint CDN is style sheets and fonts, which means it should be used primarily for ‘author’ content, such as images (e.g. News Article pictures in a publishing intranet scenario). The Public CDN should be used for design assets such as fonts and CSS, as well as assets originated from or served to non-SharePoint applications.

SharePoint CDN

At a high-level, the SharePoint CDN works as per the below diagram:

There are a few things worth explaining from this diagram:

Origin Libraries

These are the SharePoint Libraries set-up via PowerShell as the sources of files to serve via the SharePoint CDN. It is possible for the CDN to cache content from all libraries under a specified path by using a relative URL meaning that, for example, the Style Library within each site collection can be specified as a source, provided it exists under the same path in each site collection.

An important note about the SharePoint CDN is that it relies on a published major version of a file before that asset will be cached. Just something to keep in mind, depending on the type of version control applied to a library configured as an origin.

Referring Pages

In this context, referring pages are any pages on SharePoint Online that reference assets cached by the SharePoint CDN.

For the SharePoint CDN to work, the referring page must be a SharePoint Online page. This means that pages hosted outside of SharePoint Online (such as custom Azure Web Apps) cannot utilise the SharePoint CDN. However, provider hosted add-ins embedded on a SharePoint Online page will be able to make use of the SharePoint CDN.

URLs for SharePoint CDN content are dynamically generated and automatically rewritten so that the asset is retrieved from the nearest point of presence server location, rather than the main Office 365 tenant server location. URLs are automatically rewritten for the following elements in SharePoint Online:

Classic Publishing Pages will rewrite IMG and LINK URLs.
Content By Search web parts will rewrite display template JavaScript files and thumbnail images provided in query results.
Image Renditions.
Hyperlink fields on lists and libraries.
Picture Library slideshow web parts.
Image fields served back to the user via the SPList REST API.

So in theory, you shouldn’t have to rewrite much of your existing functionality if you opt to use the SharePoint CDN for your Office 365 environment, though of course, it would be a good idea to check.

One major gap at the time of writing is that SPFx client side web parts cannot utilise the SharePoint CDN. This is due to the way these web parts have to reference static URLs (and – as noted above – the URLs generated for cached SharePoint CDN content are not static). But this functionality is coming soon to SPFx.

Authentication/Authorisation

When a browser requests assets stored on the SharePoint CDN, user access to these assets is considered. In other words, the user must have at least Read access to the Origin Library the asset is stored in, or the image/script will not load on the page. Though, to be fair, this is the case regardless of whether the CDN is being used to serve content to the user, so not much should change here in terms of permissions you need to grant to origin libraries.

Public CDN

The diagram below summarises the components of the Public CDN and the relationship between them:

Origin Libraries

Any location can be set as the origin for a Public CDN, including external SaaS services, Azure Web Apps, and SharePoint Server on-premises libraries (and SharePoint Online libraries).

Referring Pages

Referring pages can use the Public CDN URLs to retrieve assets from the CDN location closest to the user. These pages can be from any application, including SharePoint and an Azure Web App.

Authentication/Authorisation

The Public CDN, by definition, allows anonymous access to cached assets and does not check a user’s authorisation against the origin library. Basically, any person out on the internet who can guess the URL of your content will see it if it is cached by the Public CDN. This has obvious security implications, though there are ways of mitigating this (see later in this blog post).

The Underlying CDN Technology

Microsoft haven’t really built a CDN themselves, and instead use third parties to deliver the capability that can be managed and configured under the Azure umbrella. Microsoft offers three alternatives for its CDN capability:

Akamai (Standard)
Verizon (Standard)
Verizon (Premium)

Feature Comparison

The table below compares the functionality provided by each CDN supplier. For brevity, the comparison table only includes items where the capabilities differ between suppliers. The full list of capabilities, including ones where all three provide comparable services, are available here and here.

Feature	Description	Standard Akamai	Standard Verizon	Premium Verizon
Points of Presence	Number of edge locations geographically dispersed around the world.	~2200	80+	80+
Custom domain HTTPS	Enables the delivery of secure content via SSL to improve the security of data in transit.		✓	✓
Asset pre-loading	Pre-loads assets so that there is no delay the first time they are requested by a user.		✓	✓
Core analytics	Shows usage patterns for the CDN, including bandwidth, hits, and data transferred.		✓	✓
Advanced HTTP reports	Generates detailed data about the CDN, including map-based geography reports on usage.			✓
Real-time stats	Provides data on bandwidth, connections, cache statuses etc. in real-time.			✓
Real-time alerts	Provides notifications about the performance of CDN end points in real-time.			✓
Rules engine	Customise how HTTP requests are handled, change the behaviour of the cache, set rules for mobile devices and implement URL redirects.			✓
Token authentication	Only requests with certain criteria in the URL will be served, e.g. only requests from certain hosts will be served.			✓
Origin Shield	Provides an extra caching layer between CDN edge servers and the origin to improve security.		✓	✓
Support	The support processes and models in place to handle incidents and queries.	Phone and Email support, Community Forum	24/7/365 Phone and Email support	24/7/365 Phone and Email support

Price Comparison

The costs for the CDNs are based on outbound data transfers in GB per month, and differ by region. There is also a sliding scale of cost whereby data becomes less expensive the more you use.

Akamai (Standard) and Verizon (Standard) are identically priced as below:

Outbound Data Transfers	NA + EMEA	Asia Pac	South America	Australia	India
First 10 TB/month	£0.0649 per GB	£0.1029 per GB	£0.1864 per GB	£0.1044 per GB	£0.1268 per GB
Next 40 TB (10-50 TB)/month	£0.0597 per GB	£0.0969 per GB	£0.1491 per GB	£0.1007 per GB	£0.0969 per GB
Next 100 TB (50-150 TB)/month	£0.0448 per GB	£0.0895 per GB	£0.1342 per GB	£0.0895 per GB	£0.082 per GB
Next 350 TB (150-500 TB)/month	£0.0299 per GB	£0.0746 per GB	£0.1193 per GB	£0.0746 per GB	£0.0746 per GB
Next 524 TB (500-1,024 TB)/month	£0.0224 per GB	£0.0597 per GB	£0.1044 per GB	£0.0709 per GB	Contact MSFT
Next 4,096 TB (1,024-5,120 TB)/month	£0.0187 per GB	£0.0522 per GB	£0.0969 per GB	£0.0671 per GB	Contact MSFT
Over 5,120 TB/month	Contact MSFT	Contact MSFT	Contact MSFT	Contact MSFT	Contact MSFT

While the Verizon (Premium) offering is a little under twice the price of the standard services:

Outbound Data Transfers	NA + EMEA	Asia Pac	South America	Australia	India
First 10 TB/month	£0.1268 per GB	£0.1864 per GB	£0.3727 per GB	£0.2087 per GB	£0.2535 per GB
Next 40 TB (10-50 TB)/month	£0.1118 per GB	£0.164 per GB	£0.3168 per GB	£0.1789 per GB	£0.2162 per GB
Next 100 TB (50-150 TB)/month	£0.0969 per GB	£0.1417 per GB	£0.2684 per GB	£0.1491 per GB	£0.1827 per GB
Next 350 TB (150-500 TB)/month	£0.082 per GB	£0.1193 per GB	£0.2236 per GB	£0.1268 per GB	£0.1566 per GB
Next 524 TB (500-1,024 TB)/month	£0.0746 per GB	£0.1044 per GB	£0.1938 per GB	£0.1081 per GB	Contact MSFT
Next 4,096 TB (1,024-5,120 TB)/month	£0.0671 per GB	£0.0895 per GB	£0.1677 per GB	£0.0932 per GB	Contact MSFT
Over 5,120 TB/month	Contact MSFT	Contact MSFT	Contact MSFT	Contact MSFT	Contact MSFT

If you work out the costs of this based on your current trends of data use, it soon becomes clear that the SharePoint CDN costs are negligible and almost a no-brainer to implement. Similar for the Public CDN, at least in the internal/enterprise space as opposed to publically accessible web sites.

Performance

Performance between the three options is very similar, though I would suggest you conduct your own performance tests to see how it would work in your environment.

Non-Functionals

Microsoft offers a SLA-backed 99.9% uptime guarantee for the CDN (both SharePoint and Public). There are diagnostic logs and analytics to help troubleshoot CDN issues and analyse traffic and bandwidth usage. The big thing to focus on here though are the security implications:

Data Privacy and Compliance

Microsoft pretty much washes its hands of any data you choose to cache in the CDN. When you’re setting up your CDN in PowerShell it will display disclaimers similar to the following:

Both the SharePoint CDN and Public CDN are Azure features built on 3^rd party applications with privacy and compliance standards that differ from the commitments outlined by Microsoft in the Office 365 Trust Centre. Data cached by the local servers for both the Public and SharePoint CDNs does not conform to Microsoft Data Processing Terms and is outside the Microsoft Office 365 Trust Centre compliance boundaries.

In other words, your data is no longer under Microsoft’s jurisdiction once it enters the CDN, as the underlying capability is provided by third parties. I haven’t managed to find any info on the web about what standards Verizon and Akamai do offer around data privacy and compliance, but will update this post if I find some.

Given the content cached in the CDN is likely just JavaScript, images, fonts, and style sheets, it is unlikely there is anything sensitive in there, but it’s still something to consider before switching on the CDN.

Anonymous Access to the Public CDN

As noted in the previous section, the Public CDN allows any referrer to access its cached content anonymously. Again, due to the nature of the content stored in the CDN, this is unlikely to be a problem (particularly given you can restrict who has access to upload assets to the origin library). However, if you need to provide an extra security wrapper around the Public CDN, you are only really left with one choice: the Verizon (Premium) offering, which supports Token Authentication.

Token Authentication can be used to check things like the referrer of specific requests (so you can, for example, limit it to just your SharePoint Online/on-prem estate), country, and a myriad of other things.

Constraints

Here are a few of the constraints associated with the Azure Public CDN and SharePoint CDN technology:

Files such as aspx pages or Master Pages cannot be delivered via the Azure CDN, only the static elements and client side code that is embedded on pages. This means Master Pages must still be deployed per site collection in SharePoint Online.

The SharePoint CDN can only cache files of the type .gif, .ico, .jpeg, .jpg, .js, and .png. This covers the most common image file formats and icon files, plus JavaScript files (which are called in order to run custom client side code on some SharePoint Online pages). The most crucial file type that the SharePoint CDN cannot cache is .css, which will be used on every single page of a publishing portal and in many collaboration scenarios in SharePoint online too.

The Public CDN can cache files of the type .css (Style Sheets used to change the look and feel of a site), .eot, .woff and .ttf (fonts), .map (image maps), and .svg (scalable images/vectors) in addition to the file types outlined for the SharePoint CDN.

All files of type GIF, ICO, JPEG, JPG, JS and PNG stored in origin locations will be cached by the SharePoint CDN. If a file of this type is placed in an origin library, it cannot be excluded from the SharePoint CDN at a granular level.

Using the SharePoint CDN means that the referring site must be a SharePoint Online site, and the user must have authorisation to view the location where the static files are stored.

The SharePoint CDN can only be used for SharePoint Online, not SharePoint Server on-premises, or the on-premises elements of a hybrid implementation of SharePoint.

URLs for content served via the SharePoint CDN are dynamically generated and can change on a regular basis. They therefore cannot be hardcoded into custom scripts, applications, or SharePoint Framework Client-side Web Parts (the newly recommended way of designing and building web part functionality in SharePoint).

My Recommendations

So that’s a whistle stop tour of the Azure Public CDN and the new SharePoint CDN capabilities. Here are my recommendations if you’re thinking about enabling either of these services in your organisation:

Make sure you (and your security team) are comfortable with the disclaimers Microsoft put around data privacy and compliance.
Plan around using the SharePoint CDN for ‘author content’ like images (plus JavaScript), and the Public CDN for everything else. You will likely need a blend of both CDNs to deliver a holistic solution.
Configure SharePoint CDN origin libraries with relative URLs so that any library located at the same place within a site collection (under a given path) can be cached. This has information architecture implications, as you do not want your asset libraries in different places within each site/site collection or you will have a massive admin overhead maintaining the CDN.
Use the Verizon (Premium) offering if you want to allow anything other than completely anonymous access to Public CDN content.
Keep in mind that SPFx web parts cannot – at the time of writing – utilise the SharePoint CDN.
Conduct some performance baselining before implementing the CDN so you can demonstrate how much improvement has been made post-implementation.
Ensure you put suitable cache expiration policies in place for CDN content.
Think about consolidating content to be cached by the Public CDN into a centralised library or Azure Web App. This will help you control who has access to update these assets, and ensure that multiple versions of the same content do not proliferate across the environment.

I would state that enabling the SharePoint CDN is a bit of a no-brainer for most organisations. It’s simple to do and offers massive performance benefits to any global company using Office 365. But I would also state that some form of planning/design is also required to ensure your company is comfortable with Microsoft’s disclaimers and whether or not you’re willing to allow anonymous access to your content in the Public CDN.

Thanks for reading.

Tinfoil Hat Predictions for SharePoint and Office365 in 2021

January 24, 2016January 24, 2016 nathanwells20146 Comments

So another year has slipped by, and the SharePoint blogosphere is alive with predictions about 2016 and what the future might hold. I thought I’d take this a step further: Time to don my trusty tinfoil hat, and make some predictions about what might be happening in the world of SharePoint in 5 years’ time! Now, it’s worth noting that most of these predictions are based on some basic research, reading, and my opinion about the way trends are heading in the broader tech landscape: I might prove to be right on some counts, I may very well be totally wrong. It will be interesting to revisit this post in 2021!

So without further ado, here are my Top 5 predictions for SharePoint in 2021:

1. SharePoint as a concept/brand will cease to exist

Microsoft barely refer to SharePoint in their marketing. This was particularly true during 2014 and the early part of 2015, when there were hardly any articles specifically about SharePoint on their Office Blogs site, one of the main channels through which Microsoft updates users about forthcoming features and changes within its enterprise technology stack. However, towards the end of last year, somebody sensible at Microsoft seemed to realise that the SharePoint brand still carries significant cachet, particularly with on-premises customers. There was more direct referral to SharePoint by Microsoft in late 2015, particularly with SharePoint Server 2016 coming out shortly.

With that said, I still think Microsoft’s preferred direction of travel is towards distinct, delineated experiences within a shared platform. SharePoint as a concept is just too big and hard to explain (as I wrote about in this article), so even though the brand name still carries some weight, I predict that Microsoft will distance themselves from it and focus on marketing ‘Groups’, ‘Delve’, ‘OneDrive’, and other individual apps within the broader platform.

2. Around 20% of content on SharePoint intranets will be created by automated writing tools

Automated composition engines are already capable of turning data and analytics into natural language writing. In my opinion, it’s a matter of when – not if – this technology makes its way onto corporate intranets and collaboration platforms. Things like market reports, shareholder reports, legal documents, and the latest quarterly financial results could all be written by machines, reviewed by a human, and then published on a SharePoint intranet as news articles.

3. Modern intranets will no longer have a homepage

This is something I’ve actually been longing to try on a project for the last couple of years, but have never found quite the right situation or client to do it with. Homepages take up a massively disproportionate amount of effort and cost on a project, usually somewhere between 10 and 20 per cent of an intranet project’s total development budget. Homepages also take up an exorbitant proportion of analysis/design time too, since stakeholders are always so wedded to the idea of having a nice-looking homepage that everybody wants to have their two pence and get it as ‘perfect’ as possible.

In my opinion, the homepage of an intranet should be nothing more than a jumping off point into distinct portals (or ‘experiences’ as Microsoft calls them) where users can get the content they need or perform the task they must do. You could already make the argument that the app launcher in O365 fulfils this purpose (particularly if it’s customised to include things like links to your News Centre, Project Sites Hub etc. etc.), so I’d be tempted to go full-Google and just have a search box and nothing more on the homepage. I still need to find a client I can sell on that concept :-).

So my bold prediction is that by 2021, modern intranets won’t really have homepages in the traditional sense, or at the very least, they will no longer be pouring disproportionate amounts of time, effort and money into one single page.

4. Team Sites will no longer exist

I’m a big fan of team sites, so this is a prediction I make with a slightly heavy heart. There are two main reasons I think this one is very likely to come into fruition: Firstly, Microsoft have created a minimum viable product in O365 called ‘Groups’ which is attempting to bridge the gap between shared mailboxes in Outlook, team sites in SharePoint, and discussion groups on Yammer. It’s a bit of a ‘worst of all worlds’ solution at the moment and I’m not aware of anywhere it’s been widely adopted, but it shows the route Microsoft are trying to go down on the collaboration side of things.

The second reason I think this prediction has a high probability of being right is that Microsoft wants to move away from power user customisation. In my experience, 90% of an organisation’s user base will only use their team sites for the basics: store some documents, maybe a team calendar, capture some contacts if you’re lucky. But the other 10% go to town, and create all sorts of power user customisations and small-scale business apps that help them get work done more efficiently and effectively. Microsoft has been burnt in the past by allowing heavy customisation of SharePoint platforms (hence the app/add-in model) since it makes things harder to support and upgrade. For SharePoint 2013, they took away the WYSIWYG visual interface from the SharePoint Designer tool to make it less non-dev friendly. And for SharePoint 2016, well… There is no more SharePoint Designer! This leaves a bit of a hole in my opinion, in terms of small-scale business applications (it remains to be seen if PowerApps can fill it effectively), but I think it’s another nail in the coffin of Team Sites in the traditional sense.

I think that by 2021, Groups will be the de facto collaboration area, and PowerApps will provide the ability for power users to customise SharePoint and create business applications.

5. ‘Intranet in a Box’ products will cease to exist

There’s been a massive trend in the last few years towards implementing pre-packaged intranet products. The market is saturated with products built on top of SharePoint Server/SharePoint Online, and there is relative parity in features and capabilities of all these platforms. I think that it’s only a matter of time before Microsoft builds something into O365/SharePoint that fills most of an organisation’s intranet requirements out of the box. Indeed, they’ve already started down this route with the forthcoming Microsites and Knowledge Management Portal features in O365. Companies that have their own intranet in a box products will have to react quickly to new functionality Microsoft provides, or they will go out of business.

Conclusion

So those are my predictions for the SharePoint/O365 landscape in 5 years’ time. Some slightly out there, some bold but based on solid evidence, some that it’s safe to say probably will happen at some point. It will be amusing to revisit these in a few years time and see if I’m some sort of Nostradamus, or a complete fool. Thanks for reading.

SharePoint Hybrid “Sync Gaps” and how to bridge them

September 2, 2015September 2, 2015 nathanwells2014Leave a comment

This post was originally published on the Contentandcode.com blog.

Introduction

More and more organisations are moving to a cloud-first strategy for their IT systems, but many need to retain some workloads on-premises due to compliance concerns, data residency, or technical limitations. This has given rise to an increasing number of ‘hybrid’ SharePoint implementations. Organisations store some information on-premises in SharePoint Server 2013, but still wish to utilise SharePoint Online in Office365 in order to reap the benefits of agility and cost-saving that the cloud brings.

However, SharePoint hybrid implementations result in a number of problems around data divergence and user experience consistency. These are what I call “sync gaps”. In my opinion, addressing these sync gaps is one of the biggest challenges (and opportunity spaces!) in SharePoint today.

There are a number of areas where an organisation implementing hybrid SharePoint might want to sync data between SharePoint Server on-premises and SharePoint Online in the cloud. Below, I address the more common ones that we have come across working with our clients at Content and Code.

Search

The biggest hybrid sync gap is one that Microsoft are already about to address: Search. Currently, it’s very difficult to provide a unified search experience across O365 and SharePoint 2013 because there is no way of creating a single search index. This means that you end up with search results from O365 being displayed in separate results blocks on SP2013, and vice versa. It’s basically the same experience as creating a federated content source for SharePoint search. There are ways to fudge it with some clever dev, but it’s generally a pretty poor experience.

Search is the biggest and most problematic sync gap, and luckily Microsoft have already taken steps to bridge it with the Cloud Search Service Application. My colleague Ben Athawes blogs about it here. The CSSA will be released as part of an update to SharePoint 2013 later in the year (2015) and baked into SharePoint Server 2016.

Cloud search service application — Picture taken from Microsoft Ignite slide pack

User Profiles

The second-most common hybrid sync gap is for User Profiles. Users should not be expected to re-key their profile information in both SharePoint 2013 and SharePoint Online. In addition, there are often compliance requirements around where certain pieces of profile metadata are mastered. The typical scenario sees profiles mastered (i.e. editable) in SharePoint 2013 on-prem, and pushed to the cloud. This is partly because it is much easier to connect to other sources of profile metadata (such as HR systems) from SharePoint Server, but also because Azure Active Directory sync (formerly DirSync) only allows a core set of AD attributes to be populated to O365 profiles direct from Active Directory. In other words, any organisation wanting to have more than bare-bones user profiles in O365 is going to have to build some custom mechanism of importing data regardless of whether they are in a hybrid scenario.

Content and Code have implemented this functionality for several clients now. My colleague Chris O’Brien blogs about it here in more detail.

Taxonomy/Term Sets

Another very common scenario we see is a requirement to synchronise term sets (or taxonomy) between SharePoint 2013 and SharePoint Online. Our clients tend to invest a lot of time and effort into creating a good, consistent Information Architecture (IA) that allows them to classify information with key terms. It’s important that these terms are unified across the cloud and on-prem so that information can be classified and retrieved in a consistent manner. Term sets are also often used to drive global navigation. Providing a consistent navigation experience in a hybrid deployment is very important, meaning this sync gap is a problem most implementations of this type face.

Luckily, this is also something C&C have done several times now – you can read about it in Chris’ blog.

Other sync gaps

Outside of the ‘big 3’ sync gaps (search, profiles, and taxonomy), we are seeing an increasing number of other scenarios where consistent data is required between SharePoint Online and on-prem. These include:

Branding: providing a consistent look and feel between the cloud and on-prem so that users have a joined up experience and do not necessarily realise they are traversing between two separate systems.
Content Types and Site Columns: an extension of the taxonomy sync gap. Having a consistent set of metadata and content types is important from an information classification and retrieval perspective.
Records Management: what happens if you classify an item as a Record in SharePoint Online? How will it get sent to your on-premises Records Centre?
Customisations: Keeping customisations consistent between on-prem and O365 is an important challenge to address in order to maintain a single user experience. It’s also worth noting that you should think carefully about any customisations you make on-prem, as it is often much harder (or even impossible) to achieve them in Office365. As for apps (add-ins), authentication will often need careful planning in a hybrid implementation.
eDiscovery: If your organisation is audited, can you perform a legal hold across both on-prem and the cloud?

Conclusion

Hybrid implementations of SharePoint Server and SharePoint Online are becoming increasingly common, and this is giving rise to all manner of new requirements around user experience consistency, integration, and data parity. If your organisation is looking to go down the hybrid route, careful planning is required to ensure you don’t end up with a poorly adopted system or a major information management headache. Addressing common “sync gaps” is a key step towards achieving a world class hybrid implementation of SharePoint.

This post was originally published on the Contentandcode.com blog.

Extranets – SharePoint vs. External Sharing vs. Yammer

August 21, 2015August 21, 2015 nathanwells2014Leave a comment

Introduction

Extranets are a pretty common requirement for organisations with a B2B sales model. They allow companies to collaborate more easily with clients, suppliers, and other third parties who are not part of their internal network. Over the last half-decade or so, SharePoint has become a widely-adopted means of delivering extranet capabilities. But is it actually the best solution available, even just within the Microsoft product stack?

This post will discuss the case for delivering extranet capabilities using Yammer, and the trade-offs compared to more traditional, SharePoint-based approaches. It also considers a third option, which is a subset of the SharePoint-based approach available within Office365 called External Sharing. It will assess the strengths and weaknesses of the three options, and suggest the criteria that would cause an organisation to choose one approach over the others.

What is an Extranet?

An extranet is basically an intranet that can also be accessed – at least partially – by authorised external users. It enables businesses to exchange information securely over the internet, and work more closely with one another.

So an extranet can – in theory – be used for anything an intranet is used for. But in my experience, the four most common use cases by far are:

Document management (creating, editing, reviewing, and sharing documents);
Discussions (informal, transient conversations);
‘Official’ communications (such as announcements); and
Business Process Management/automation.

SharePoint Extranet

SharePoint provides the ability to securely extend an organisation’s private network to provide a subset of the information and functionality available on the rest of the system. Extranet content tends to be hosted within the internal network, and made available through an edge network (or separate environment isolated within a perimeter network) to authenticated, authorised users. In layman’s terms, you can – in theory – do anything with a SharePoint Extranet that you can do with your normal SharePoint platform hosted on the internal network. However, you have the added headache of dealing with a lot of extra infrastructure, network configuration, and user management/authentication requirements. There is a lot of thinking to be done up front about exactly how you architect your information to ensure a suitable “Chinese wall” between different third parties, and how you manage user accounts for external companies.

SharePoint Online External Sharing

SharePoint Online (in Office365) allows you to build a SharePoint Extranet in much the same way as SharePoint Server (though without some of the infrastructure headaches associated with being on-premises or in a private cloud). However in SharePoint Online, you also have the additional option of enabling something called ‘External Sharing’. Activating this functionality allows you to invite external users to the system via a simple email notification. Users can share information at the site level, or at an individual item/document level. External people can authenticate to the SharePoint Online instance using either a work account (Office365 user ID stored in Azure AD, be it the third party’s Azure AD or the hosting organisation’s own Azure AD), or using a privately managed, personal Microsoft user ID (such as Hotmail.com or Outlook.com). Additionally, it’s also possible to share a temporary guest link to a piece of content. It’s a pretty convenient way of granting access information, but likely to give your InfoSec team a collective aneurism once they get into the detail about how difficult it is to manage and revoke access that has been granted.

Yammer

Another Microsoft product to add to the mix when it comes to delivering extranet capabilities is Yammer. Yammer is an Enterprise Social Network (ESN) platform that Microsoft acquired a few years ago, and is gradually becoming more and more tightly integrated with the rest of the Office365 product suite. It provides much better conversational functionality than SharePoint, but – being an ESN – does not provide anything like the same Web Content Management or Enterprise Content Management capability. It also falls way behind SharePoint in terms of personalisation and extensibility, but – in fairness – it’s not trying to compete with SharePoint: it’s a packaged product that you have very little control over, and does what it’s designed to do (i.e. social) very well. In terms of how it can be used to deliver an extranet, it is possible to create ‘external networks’ that act like sub-networks of an organisation’s main ESN. Third parties can then be invited by administrators or network members (depending on how you configure it) to join the external network via an email link.

Assessing the tools

There are a number of criteria by which you can compare and contrast the capabilities of the three options presented above. Each of the approaches has its pros and cons, strengths and weaknesses, in relation to the other two. Below, I’ve put together a list of the criteria by which I would judge an extranet tool, and given a Harvey Ball score against each. Naturally, you may have different criteria that are important to you and your organisation, and you may put a different weighting against certain criteria. Additionally, you’ll probably disagree with some of my ratings and comments, or want to include additional options that are a hybrid of the ones discussed above. But this assessment at least provides a starting point!

Conclusion

SharePoint provides richer functionality, greater flexibility and extensibility, and (arguably) better risk mitigation/compliance than Yammer. But Yammer is a good fit if your Extranet is mainly for conversations/discussions (perhaps with a little bit of document sharing thrown in), or if you need to get something live quickly and cheaply.

Personally, I have found Yammer to be an excellent tool for collaborating with clients; getting quick answers to questions and discussing important decisions, risks, issues, and plans. It is poor for document management, but if you are just publishing finished deliverables for the third party to see and discuss, it does the job. SharePoint is the only viable option if you have any desire to automate processes, or you need any form of web content management functionality. It is also a much better fit if you are creating and editing documents collaboratively with third parties.

External Sharing is a nice option to have on the table on top of a standard SharePoint Extranet, but I’m not a fan of the lack of manageability associated with this option. It’s tough to govern how/when users share files (really, they should share on a per site basis, not per file). It’s impossible to manage third party accounts that aren’t hosted in your own organisation’s Azure AD instance, and if a third party doesn’t have an Azure AD instance, they have to use personal Microsoft IDs. If you wish to keep tabs on sharing and ensure compliance, there is management overhead associated with maintaining and revoking shares and guest links. But that said, it is a quick, convenient, accessible way to extend SharePoint to third party organisations and allow them to access your information.

So really, the best option depends on what you want from your Extranet. My recommendation would be to investigate the benefits you are hoping to achieve from increasing collaboration with suppliers, clients, partners and other third parties, and to investigate exactly what your users desire from the tool.

Do you agree with my recommendations and assessment? Do you have a different option that you use to deliver Extranet functionality? Let me know in the comments!

Thanks for reading.

SharePoint Operating Model: Part 3 – Content

July 25, 2015July 25, 2015 nathanwells20142 Comments

Introduction

Now that you’ve set the strategy and direction for your SharePoint Operating Model, you can start to work through the 5 operational pillars. The first of these is Content. Content is the lifeblood of a Digital Workspace, be it transient working documents or carefully curated web content. Good content is a key driver for user adoption, and therefore something that warrants careful focus and attention when defining your Operating Model.

In this post, I will explore the key factors that influence the quality of your content, and what you can do operationally to ensure it is good. Things you need to think about in this part of the Operating Model include:

Your definition of what is and isn’t content. Where is the line drawn between content and enhancements/functionality?
How are you going to ensure content is always “good”? Does your definition of “good” content vary depending on the context/type of content?
How are you going to clearly define the boundaries between types of content, particularly at the site level?
A good Information Architecture (IA) provides the foundation for good content. How will you manage and build upon your IA post-implementation?
Are there any additional roles and responsibilities you need to put in place in order to deliver effective content on an ongoing basis?

I will consider each of these questions in turn as part of this post.

What is/isn’t content?

It’s important to define exactly where you draw the line in terms of what is or is not Content. Due to the fact that changing content is – in reality – still a change, there can sometimes be a bit of confusion between what comes under this pillar and what comes under the Enhancements pillar of the Operating Model. In SharePoint terms, I define Content as being information that can be added to the system, and the Information Architecture that underpins it. This is as opposed to functionality, which includes features and enhancements that need to be custom built and deployed. Another good way of splitting the Content and Enhancements pillars of a SharePoint Operating Model is to think of content as being anything that can be configured in the UI without needing to go through a formal development lifecycle. Anything outside of that is considered an Enhancement, and therefore subject to some of the controls you’ll put in place around change (see the forthcoming post in this series on Enhancements).

The diagram below shows some examples of what I classify as Content and what I classify as functionality (things that sit within the Enhancements part of this Operating Model):

What is “good” content?

In the Introduction to this post, I spoke about “good” content. To my mind, good content has four key characteristics:

Useful: the content must be serve a clear purpose within the context of where it is located. For every piece of content, authors should be asking themselves questions such as “Who is my intended audience for this content?”, “What tasks do people need to accomplish having read this content?” and “What related pieces of information might they need to accomplish these tasks?”
Trustworthy: the content must be the single source of the truth for that particular piece of subject matter or information. When users can find the same information in two different places, it compels them to make a decision about which one is the official source that they should use to accomplish their tasks. This is not a decision you want to force on your users.
Fresh: related to trustworthiness, your content must be kept up-to-date. When users find information they know to be outmoded, it degrades the trust they place in all other content on your system. Even if the content is still accurate, if it has not been checked or modified in a long time, users will often assume that a more up-to-date piece of information exists and will continue searching. Again, not something you want users to have to do.
Easy to find: closely linked to your Information Architecture (I’ll come to that later in this post) is how easily users can find or discover your content. Users can find your content via search, or they might be linked to it via navigation. It might even be content that’s dynamically surfaced on another location, but making the content easy to find is an important consideration.

As part of your Operating Model, you should think about your definition of “good” content, as it will frame some of the policies you later define as part of Governance. Later on, it is especially necessary to have some direction around what content should/should not be uploaded to SharePoint from a compliance/appropriateness point of view, and to provide some guidelines around writing for the web and keeping a consistent look and feel. This will really help the quality of your published information, in particular. But these are all details that can be ironed out later in the Operating Model: the important thing at this stage is to set the direction.

Some experienced SharePoint practitioners reading this post may already be thinking, “that’s all well and good, but achieving all of those 4 things with every piece of content is a tall ask”. And they would be right. The 4 aspects of “Good” content are less important to enforce with transient working information – the sort of stuff you’d expect to find tucked away in document libraries on a team site or a project site – compared to web content on your publishing intranet. Different approaches to ensuring ‘good’ content should be taken depending on the type and purpose of a site, which leads neatly on to the next section of this post…

Types of Site

Defining clear boundaries between the types of site that your digital workspace will support is an important step to complete as part of the Content section of your SharePoint Operating Model. As alluded to above, different types of site require different approaches to managing information. They will have different requirements around who and how they are managed, their lifecycle (and the lifecycle of their content), and how stringently content guidelines and policies should be enforced for the information they hold. It is necessary to be clear about the boundaries between types of content/site so that you can define effective Governance later in the Operating Model definition process.

I like to split sites into five broad categories. These are:

Publishing sites;
Collaboration sites;
Social sites (or Groups);
Custom sites; and
Personal sites (OneDrive or My Site).

Within these five categories, you will find several sub-types of site, which will often vary sector-to-sector, particularly within the Collaboration category. I’ll give some examples below, along with some other criteria for how you manage these different types of site.

Publishing Sites

Publishing sites fill the need for leadership, management and business areas to push information to employees in a streamlined manner. A small group of employees will use these sites to publish and disseminate officially curated information to the masses of the company. Publishing sites are the hub of official content within a Digital Workspace or Intranet.


Example types of content	News; Department/team “vanity” sites; Official policies and processes; Intranet homepages; Information sites about the organisation
Who can read this content?	The whole organisation.
Who can update this content?	Small, tightly controlled group of specialists.
What is the Ownership model for these sites?	Centralised.
What type of information is stored?	Primarily web content, some documents.
How do people primarily find this content?	Navigating
Importance of content Usefulness	High
Importance of content Trustworthiness	High
Importance of content Freshness	High
Importance of content being Easy to Find	High

Collaboration Sites

Collaboration sites provide a private ‘virtual office space’ for team members. People within the team can create, update and access the files and information they need on a day-to-day basis. They can get updates on important tasks, keep in touch with their team mates, and organise other information like contacts, calendars and useful hyperlinks to facilitate the smooth operation of the team. Collaboration sites can also help projects, bids and other teams formed for a finite period of time to organise their documents and information.


Example types of content	Team sites; Project sites; Bid sites; Extranet sites; Wikis
Who can read this content?	Generally, just the team it services.
Who can update this content?	The team the site services.
What is the Ownership model for these sites?	Devolved.
What type of information is stored?	Mainly documents, some list/tabular data, some web content, some discussion/social content.
How do people primarily find this content?	Search; opt-in (actively choosing to follow a site), some navigation.
Importance of content Usefulness	Low
Importance of content Trustworthiness	Medium
Importance of content Freshness	Medium
Importance of content being Easy to Find	High

Social Sites

Social sites (communities on SharePoint, Groups on Yammer) are designed for any and all employees to connect with people first, and information second. The social information an employee sees on an Intranet or Digital Workspace is based on their relationships, interests and subscriptions to content/groups. From the employee perspective, the social aspects of an Intranet or Digital Workspace are a real-time stream of opinions, ideas, conversations and free-form dialogue. Social sites allow employees to connect with other people in their team, department, function, profession, area of interest, or area of expertise.


Example types of content	Yammer groups; SharePoint community sites
Who can read this content?	Mainly open, some locked down.
Who can update this content?	Everyone.
What is the Ownership model for these sites?	Devolved.
What type of information is stored?	Discussion/social content.
How do people primarily find this content?	Opt-in (actively choosing to follow a site).
Importance of content Usefulness	Low
Importance of content Trustworthiness	Low
Importance of content Freshness	High
Importance of content being Easy to Find	Low

Custom Sites

SharePoint is a flexible platform that allows you to create all manner of custom applications that fulfil a specific purpose. Examples of Custom Sites include forms, workflow/process automation, knowledge management, management information/reporting, product catalogues, document management, and records management.


Example types of content	Custom workflow sites; Forms; Business Applications; Management Information/Reporting sites
Who can read this content?	Generally locked down.
Who can update this content?	Varies case-by-case.
What is the Ownership model for these sites?	Centralised (due to highly customised nature of site).
What type of information is stored?	Varies case-by-case, but
How do people primarily find this content?	Opt-in (actively choosing to follow a site).
Importance of content Usefulness	Low
Importance of content Trustworthiness	Low
Importance of content Freshness	Low
Importance of content being Easy to Find	Low

Personal Sites

A single page portal that contains the user’s personal sites, links, etc. OneDrive (AKA My Site) consists of the user’s profile, and personal documents (split between private and shared). Private documents are intended for viewing only by the individual user whilst Shared Documents are for personal files that the user wants to be viewed by a wider audience.


Example types of content	Personal documents; Profile; Personal blog
Who can read this content?	Generally, just the individual user.
Who can update this content?	The individual.
What is the Ownership model for these sites?	Devolved.
What type of information is stored?	Personal documents, web content (blogs).
How do people primarily find this content?	Navigation (for own personal site), direct linking/sharing (for content on other peoples’).
Importance of content Usefulness	Low
Importance of content Trustworthiness	Low
Importance of content Freshness	Low
Importance of content being Easy to Find	Low

Information Architecture

Information Architecture (IA) is how you structure and categorise the content within your SharePoint environment. Traditionally, it is thought to impact two aspects of information management: findability and “put-ability” (awful, awful word). But in my opinion it also impacts two more things which are crucial to an effective SharePoint Operating Model: scalability and manageability.

Findability: related to one of the four aspects of “good content”, findability is how easy it is for users to retrieve and discover content. This might be via search or via navigation. A good IA will provide an intuitive navigation experience, surface the most relevant information to users, and allow them to retrieve information effectively using search filtering and logical queries.
“Put-ability”: God I hate that word. But there isn’t really another way to represent ‘the ease with which a piece of content can be added to the system’. In older versions of SharePoint, there was a real dichotomy between put-ability and findability, in that the more metadata tags you have against a piece of content the easier it is to find, but the more friction there is for users in terms of adding it to the system. And vice versa. But with SharePoint 2013 and SharePoint Online, search technology has evolved to such an extent that findability is less reliant on a good IA. It is now much easier to find a sweet spot between findability and put-ability.
Scalability: another aspect of IA that has become much easier in recent times due to technology improvements is scalability. An important SharePoint ‘bucket’ that impacts scalability is the site collection, which used to be limited in size to just one Gb due to site collections being unable to span multiple content databases on the backend. Now though, the content database size limit (and therefore the site collection size limit) has increased into the terabytes for SharePoint Online. I remember in the MOSS2007 days, having to spend ages projecting content size growth and struggling to come up with intuitive ways to split information into different site collections so that the solution would be scalable. But nowadays, you only need to give this equal treatment with the other aspects of a good IA, rather than it being the thing that drives all thinking, requirements and solutions around site structure.
Manageability: a good IA makes your solution easier to manage, particularly in areas of the platform where ownership responsibility is devolved. A bad IA results in an ungovernable mess of sites and content. Consistent classification of information and clear lines of responsibility derived from a well thought-through permissions model makes a SharePoint solution much more manageable.

You should define your IA as part of the original implementation project, but it also needs careful management post-implementation. I’ll talk about how to manage the different aspects of a SharePoint IA below:

Taxonomy

Your SharePoint taxonomy is the formal classification system for words and labels that describe something related to your organisation. Because these classifications are likely to be used across large swathes of information on SharePoint, it is important to control who, how and when they are updated. Some taxonomy term sets can be left ‘open’, whereby users can contribute new terms while others can be ‘closed’, whereby only a small, centralised group can update them.

Something key to keep in mind when managing your taxonomy on an ongoing basis is that if your taxonomy drastically changes, it could impact how information is targeted at users. A common feature of intranet homepages is news articles targeted at the current user, based on attributes like their location, team, and job role from within their profile. To match specific content to a user, SharePoint needs to find a common attribute between their profile and the content. This attribute is often in the form a term within a taxonomy. If terms sets are torn down and rebuilt, you may discover that you have orphaned content (content with no users to be targeted at), or – perhaps even worse – orphaned users (users with no content that is targeted to them).

Content Types

Content Types are a uniquely identifiable way of grouping settings and metadata columns together. For example, a ‘Policy’ might be one content type, which has columns like Expiry Date, Related Department etc. etc. Another content type might be ‘News Article’, which has columns like Published Date, Author, Related Articles etc. They are a key building block of information architecture in SharePoint, as they provide consistency for how similar pieces of information get classified across libraries, sites, and site collections.

Choosing how you manage Content Types across SharePoint is an important decision to define in your Operating Model, since it can impact the findability of content. You can use the Content Type Hub (CTH), which is where a single site collection pushes changes to Content Types and columns at subscribed site collections, ensuring they are all consistent. Or, you can make it a dev task whereby a script is run to update all Content Types whenever a change is required. In my experience, the CTH works well in collaboration site scenarios, where there is a very consistent set of Content Types across a large number of site collections. For any custom development that uses Content Types, it is not such a good fit and I would advise scripting instead. One other issue to keep in mind is that thanks to the CTH running on a periodic timer job, Content Types and metadata may not be immediately available once a new site collection is created.

Permissions

It’s worth thinking carefully about who and how permissions will be managed on an ongoing basis. Keeping things tightly controlled for published areas is always a solid plan, but you can afford to be a bit more relaxed about transient, collaboration-related spaces that serve a much smaller audience. Effective permissions management is something broadly enforced as part of governance, mainly via training efforts to site owners. But keeping a handle on it is important in order to ensure users will have the right level of access to the right information once your SharePoint platform expands and grows over time. I’ll take a much more detailed look at permissions in the Governance parts of this Operating Model series.

Navigation

The areas of content that rely most heavily on navigation are the published areas. Often, this navigation will consist of a persistent global navigation structure or megamenu, controlled by a special term set. Ensuring only a small group of trained individuals have the ability to update this term set is vital, since changes to the global nav will impact all of your users and all of your published sites/pages.

For local or left-pane navigation, it is usually best left at the behest of the individual site owners. SharePoint provides a few options to generate a left nav based on the structure of the site within Publishing areas, but collaboration spaces tend to be much more open and less automated.

Search

Search is such an important aspect of IA to manage on an ongoing basis that I’ve dedicated a section of the ‘Operations’ pillar of the Operating Model to it – more on that in a future post. But broadly, your search needs to be monitored and optimised to ensure users can retrieve the most relevant content. I prefer to define and manage search schema (the mappings of properties to refiners, and the query rules that determine ranking logic and ‘best bets’) centrally from the search service application. This ensures a consistent search experience across the platform, rather than a (potentially) slightly different experience per site collection that becomes hard to manage.

Site Structure

The final part of IA that needs ongoing maintenance is your site structure. This needs to be thought through carefully from a manageability, consistency, and scalability perspective, and it can also impact how easy to navigate your sites are. For this reason, it’s usually a good idea to control how sites get created. This could be via a centralised team setting them up manually, or via an automated provisioning mechanism.

The other bonus of centralising the creation of sites is that you can nip any daft site ideas in the bud before anybody starts using them or creating content. For example, if your SharePoint platform is still quite nascent and only provides publishing/Intranet functionality on Day 1, you don’t want users to be able to create their own Team Sites until you have properly planned out the IA, web templates, provisioning mechanism, and (if you’re on-premises), scaled your infrastructure to accommodate the massive amounts of content that ends up living in collaboration spaces. Centrally controlling site creation is – in my experience across many SharePoint implementations – one of the most important things you should do to ensure your platform remains manageable post go-live. There are exceptions of course, but generally, applying this rule of thumb will make your SharePoint environment a much more effective platform.

New Roles and Responsibilities

In order to manage Content as part of your Operating Model, it is necessary to have some new roles and responsibilities for individuals or teams. The numbers of people you have fulfilling these roles will depend on the size of your organisation/user base, and the functionality you have deployed with your SharePoint implementation. For example, one of my clients – who have deployed SharePoint to almost 120,000 users – will have a ‘Business Support Team’ consisting of over 12 people fulfilling the Intranet Manager role, plus several more Community Managers. A smaller client I have worked with (<1000 users) has one full-time employee fulfilling both the Intranet Manager and Community Manager roles. It remains to be seen whether these are the right numbers of people as these are both new projects just going live, but this gives some idea of the scale of Content-related support required for larger deployments and the fact that you still need to do it even if you’re a small/medium-sized business.

Intranet Manager


Focus	> Usability and usefulness of content on SharePoint
Department	> Cross-functional between Business and Technology
Summary	> Takes responsibility for the findability of content and the structure of information on the intranet > Bridges the gap between Technology and the Business > Experienced SharePoint professional, with a particular focus on information architecture
Responsibilities	> Responsible for dealing with content-related service requests and tickets > Review search reports and make changes to synonyms and query rules to optimise search usability > Encourage optimal use of tagging for content on the intranet, particularly content with a broad reach (such as news articles) > Regularly review, ratify and – where appropriate – update the taxonomy to ensure it continues to provide maximum usefulness > Act as one of the gatekeepers for new site and site collection requests > Ensure permissions follow best practice > Ensure navigation is appropriate on all pages > Ensure different areas of the intranet are used for the appropriate purpose (e.g. no storing of personal documents in a Publishing site) > Reviewing analytics reports and advising/implementing necessary changes to ensure adoption, based on these metrics > Communicating best practices and etiquette on the intranet > Evangelising the intranet at every opportunity > Participating in training preparation and delivery > Creating and maintaining help content > Participating in Governance Committees

Community Manager


Focus	> Social community facilitation
Department	> Comms
Summary	> Manage day-to-day social activity on the intranet or Enterprise Social Network (ESN) > Well connected within the business > Experienced in communication, technology and social media
Time Commitment	> Full-time
Responsibilities	> Actively engaging with members of the intranet/ESN, responding to unanswered posts and generally being a ‘role model’ for how to use the social aspects of the intranet > Communicating best practices for etiquette on the intranet/ESN > Removing inappropriate content > Triaging reported posts > Evangelising the intranet and social at every opportunity > Participating in training preparation and delivery > Encouraging senior executives to regularly post/comment > Creating and maintaining help content > The Community Manager is NOT a policeman/woman or a monitor. Their focus should be the health and success of the intranet/ESN from a social point of view. > Participating in Governance Committees

Bringing It All Together

The Content pillar of your SharePoint Operating Model is incredibly important: Content is what users come to your system for in the first place. You need to put some lines in the sand around what is/isn’t content, and the exact purpose of different types of site. You need to make sure you have a plan for how you manage your Information Architecture on an ongoing basis, and ensure you create some clear roles and responsibilities to provide adequate support around Content creation and management.

There are further deliverables, processes and policies I would advise producing in addition to the suggestions in this post, and I will cover these in the forthcoming Governance part of this series. But for now, these broad decisions and definitions will help you ensure you have a solid first pillar of your SharePoint Operating Model. Even if you only do the stuff described in this post, you will be well on your way to delivering a great Digital Workspace and fostering user adoption and employee engagement through your high quality, well-organised content.

Thanks for reading.

—————————————————————

Part 1 – Introducing the SharePoint Operating Model

Part 2 – Strategy

Part 3 – Content

SharePoint Operating Model: Part 2 – Strategy

July 1, 2015July 25, 2015 nathanwells20142 Comments

Introduction

A SharePoint Operating Model brings standardisation and integration to the processes and people running SharePoint. You cannot deliver efficiency and predictability (standardisation) or link the efforts of all the different parties involved in operating the platform (integration) without some clear top-down decision-making. This is where the ‘Strategy’ part of the Operating Model comes in. The diagram below shows where ‘Strategy’ fits into the wider Operating Model I put forward in the previous post.

In its purest sense, a strategy contains three elements: a statement of the problem; a solution to that problem; and a list of cohesive actions to deliver that solution. As much as we’d like to tell ourselves otherwise, delivering SharePoint is only ever likely to be a cohesive action, one of many things that come together to fix a problem as part of a wider business or IT strategy. For this reason, I’m going to horrify purists and use the word ‘Strategy’ to mean “high-level stuff that someone important needs to decide”. It’s vital to get this clarity, or you are just operating the platform for the sake of it. Without these decisions, you won’t have a view as on how it impacts the rest of the organisation and its broader strategy. You need these things defined to provide direction and impetus for action, and to guide the broader Operating Model.

Below, I detail some of the key decisions that you must make in the Strategy part of your SharePoint Operating Model.

Roadmap

A good roadmap should give a clear sign of where the platform is heading. This is for both capabilities delivered, incumbent systems replaced, and major changes required in the organisation to support the new technology. It should also give an indication when you will deliver these things so that you can mobilise resources.

I like to define a roadmap at two levels: Firstly, it’s good to have a map that shows a macro-level view of where SharePoint sits within an organisation’s broader tech landscape. Secondly, I like to define a more SharePoint-centric roadmap which details the exact capabilities that will be delivered for the platform, and the phasing of this delivery.

High-Level Roadmap

The diagram below shows an example high-level roadmap:

This is quite a technology centred view of things, so you might want to include more on the business change side of it too. But whichever way you go about defining your high-level roadmap, it’s definitely a useful deliverable as part of a broader Operating Model.

Low-level Roadmap

For low level roadmaps, I focus on the phasing of SharePoint capabilities. I break the platform down into its core workloads, and also detail components that make up these workloads.

You should tailor these workloads and components for your particular organisation. But broadly they will include any/all of the following:

‘Foundational’ components – stuff that is needed across all other workloads such as your information architecture. This also includes the infrastructure and the SharePoint platform itself (if you’re on-premises, anyway).
Web Content Management – small groups of editors providing carefully curated web content to the masses. AKA, your typical publishing intranet scenario. This may also include extranet content, and even a publically accessible web site.
Search – you could consider this foundational, but it’s usually such an important capability that I call it out on its own. In particular, when you might go down the search integration, federation, custom connectors, or hybrid search route, it can get big and complicated.
Social – maybe Yammer, maybe SP social. This covers the community forums, microblogging, following, and commenting functionality all good SharePoint platforms should provide. The key distinction to make between the ‘Social’ and ‘Collaboration’ capabilities in a SharePoint context is that groups/communities should focus on people and relationships first, information second (and vice versa for Collaboration).
Personal – the ‘me’ stuff, such as my profile, personal document storage (OneDrive), and my sites. Plus Delve if you’re in O365.
Collaboration – Team sites and project sites. Plus, maybe some other components like wikis and bid sites. Collaboration sites act like a virtual office space and allow people to create, update and access the information they need on a day-to-day basis.
Enterprise Content Management – ECM covers things like Records Management, Document Management, and eDiscovery/Legal Hold. A more formal type of information management than the Collaboration workload.
‘Business Applications’ – the myriad of other stuff you can do with SharePoint to build applications that serve a distinct purpose. This might include BPM (Business Process Management), BI (Business Intelligence), plus all sorts of other weird and wonderful customisations. If your organisation is focusing heavily on one of these extra areas, you might want to call it out as its own workload.

It’s always a good idea to phase your rollout of SharePoint to get return on investment quicker. The most common phasing that I see is shown in the diagram above. A social publishing intranet first (with news, department sites, search, profiles, policies, processes, microblogging, commenting, groups/communities etc.); collaboration functionality next (team sites, project sites, bid sites, some sort of site provisioning mechanism etc.). But maybe your organisation brought in SharePoint as a Document Management System, or as a Records Management solution? Or maybe it was originally purchased with a view to automating business processes? Each implementation is unique, and you will need to phase your rollout accordingly to deliver the business benefits and investment objectives.

If you are in the cloud, you will also need to regularly review your roadmaps in light of the wider Microsoft O365 roadmap. Microsoft are continually releasing new features and enhancements for SharePoint Online and the broader O365 suite. You need to make sure you’re aligned with what they’re doing, or you might end up wasting money building stuff that becomes available for free in the near future. Believe me, I’ve seen it happen more than once.

Funding Model

The next high-level decision you should get agreement on as part of your Operating Model is how you will fund SharePoint beyond the end of the implementation project. A funding model is – at its core – who is going to pay for what parts of the system. Generally, you see organisations break this down one of three ways:

A basic ‘layered’ funding model;
A funding model based around the platform’s capabilities; and
A model based around the organisational structure of the business.

Each of the models has a divide between operating cost and capital expenditure on new functionality and enhancements. The operating costs are spent on ‘Business As Usual’ stuff like licensing, managed services (to provide support and ops capabilities) and – for on-premises environments at least – the underlying server infrastructure. The other operating expense is what one of my clients calls ‘KSOR’ (kay-sore), or ‘Keeping the show on the road’.

This is the expense needed to drive the platform forwards from an adoption perspective, as well as the expense of smaller projects that do not need to be charged back to the business.

You need CapEx to provide extra functionality and enhancements for the system. It’s useful to divide this between smaller, department-specific enhancements and larger, more strategic pieces of work. Smaller projects can be charged back to the requesting business, while bigger programmes that benefit the whole platform and its total user base can be funded from a centralised pot. Who pays for this centralised pot is often a point of contention, and the three funding models I’ve put forward here tackle it in different ways.

1. Layered Funding Model

This is the basic model, where OpEx costs get absorbed by IT. The requesting area of the business funds smaller, tactical projects, while IT’s CapEx budget funds larger pieces of work.

2. Capability-based Funding Model

In this model, some of the costs are split between different parts of the business depending on the SharePoint capability they are servicing. This model relies on clear definition of what parts of the organisation assume responsibility for which SharePoint workloads. I’ve seen one organisation implement this style of Funding Model, but I’m personally not a huge fan. In my opinion, there is too much overlap between SharePoint capabilities to assign the expense to just one area. For example, ‘collaboration’ is something that the whole company uses, so it doesn’t make sense that one part of the business assumes the cost for it. Plus, this model can create political strain between areas of the business when it comes to prioritising new work.

3. Organisation-based Funding Model

This model is my personal favourite. KSOR OpEx costs and strategic CapEx costs are divided proportionally between the different divisions within the business. The proportion is based on percentage of the total user base for a particular division. You can also extend this model so that BAU OpEx costs get divided too.

Ownership

In some situations it is necessary to assign overall ownership to some elements of the solution and the Operating Model. This is particularly true when there are multiple third party suppliers involved in the running of SharePoint.

Functional Ownership

Assigning ownership at the functional level can be done either simply or in a more complex manner. Firstly, you can assign ownership at the infrastructure, software/platform, and solution tiers. This is something you should most definitely do if you have a Managed Services agreement with a third party supplier. In this situation, the lines often get blurred between infrastructure, software, and solution incidents/requests. Even in a cloud scenario, it’s still worthwhile, even though Microsoft will be looking after much of the first two tiers.

Secondly, you can assign ownership by SharePoint workload or capability. As I touched on previously, assigning responsibility in this manner can sometimes get complicated and political. But occasionally, it is necessary. For example, the Comms and Marketing function might take ownership of the Intranet/publishing capabilities, while IT takes control of Collaboration. Maybe some sort of compliance function assumes ownership for Records Management, while a client-facing part of the business takes responsibility for the Extranet. Who knows? But defining this ownership is important to ensure the relevant people have a voice at the table. Every interested party needs a say in strategy, prioritisation, impact assessments, and governance boards/committees.

Operational Ownership

Similar to assigning ownership at the functional level, you might also want to assign it across the Operational Pillars outlined in the first post in this series. Different parts of the business are going to have different levels of input across the Operating Model. It is worth defining this as part of your Op Model strategy to help with buy-in. This becomes particularly important when doling out responsibilities for creating detailed documentation to support the Operating Model.

Objectives and Benefits

It’s important that you continue to focus on delivering benefits and objectives beyond the end of the initial implementation. I could write another massive series on how to capture and document objectives and benefits, but I will pay lip service to it here.

(By the way… If you’re delivering a project that does not have any stated benefits or objectives, then pull your finger out and define them! It’s imperative that a project has some link to the business strategy and has captured the reasons the money is being spent in the first place.)

Dependency Networks

The purpose of defining investment objectives and benefits is to answer the following questions:

Why is the investment being made?
What types of benefits is the organisation expecting to achieve?
How can a combination of business changes and technology (SharePoint) deliver these benefits?

The benefits are particularly important in that they also provide a mechanism to track against realisation targets. This allows the company to define success for the implementation. Plus, it gives an early indicator if the expected benefits are not being realised (allowing for corrective action to be taken).

My personal preference is to capture objectives and benefits in Dependency Networks (such as the below):

Benefits Profiles

A key element of the objectives and benefits work is to profile the benefits you are hoping to realise with SharePoint. This involves capturing things like the owner, target benefit, how you are going to measure the benefit, and measurement cadence. This ensures that the benefit will not be forgotten post-implementation.

Bringing It All Together

So there you have it, these are the high-level decisions you need to have in place in order for your Operating Model to be effective. To be honest, in an ideal world you would actually define some of these before the project even starts. Without these agreements, you will struggle to define the Operating Model originally, let alone actually enact it. Without strategy, there is no direction or impetus for action for your Operating Model. And without an Operating Model, you will be unable to realise the full potential of SharePoint within your organisation.

Thanks for reading.

—————————————————————

Part 1 – Introducing the SharePoint Operating Model

Part 2 – Strategy

Part 3 – Content

SharePoint Operating Model: Part 1 – Introduction

June 14, 2015July 25, 2015 nathanwells20142 Comments

Introduction

Most SharePoint projects focus on building the solution. This covers the information architecture, user experience, interface design, apps/add-ins, and system integrations that come together to form an effective SharePoint implementation. Fewer still define an effective strategy and business change approach for the project. But – in my experience at least – hardly any projects give much heed to how to run SharePoint once it goes live in the organisation. Having a well-defined Operating Model is crucial to ensuring the on-going success of the platform and can help to ease the difficult transition from project into service.

What is an “Operating Model”?

“An Operating Model is the organisational design that makes it possible to deliver the business strategy”. – Ashridge Business School

My interpretation of an Operating Model is that it’s a set of guidelines for how SharePoint aligns with people, processes and other technology to deliver the business strategy. The Operating Model defines the necessary level of process integration and standardisation to allow your SharePoint service to thrive and grow. It provides a general vision of how your organisation will enable the long-term business benefits of the platform. It drives the foundation for executing the SharePoint strategy.

I’ve also heard it described as “governance on steroids” in that it provides some definition to roles, responsibilities, processes and procedures. However, governance typically focuses on information management, application management, and IT ops. This is necessary work that all organisations looking to use SharePoint should be doing, yet SharePoint often requires something more holistic to get the most out of it long-term. This is where the Operating Model comes in.

There are two overriding dimensions that drive an operating model. These are:

Standardisation; and
Integration.

Standardisation is about defining how a process will be executed so that it runs smoothly no matter who is enacting it. This delivers efficiency and predictability around who is doing what, and helps align the platform across different divisions in the company, as well as third party suppliers.

Integration is about linking efforts through shared data, capability and knowledge. It ensures that new capabilities or initiatives delivered in SharePoint can be smoothly integrated with the pre-existing functionality.

A Sample Operating Model

The diagram below shows a sample high-level Operating Model:

The thinking behind this model is to divide SharePoint into five operational pillars: Content, Adoption, Enhancements, Support, and Operations. An overarching strategy supplements these pillars, and governance policies and processes underpin them.

	Strategy defines the direction for the platform. It ensures everyone involved in operating the system is singing from the same hymn sheet and pushing for the same outcomes. It provides direction and impetus for action and helps to guide future investments in the platform.
	Content encompasses all information stored on the platform. It covers the configuration possible without formal change control or lifecycle management.
	Adoption covers the on-going training, communications and business change aspects of running SharePoint. It ensures employees engage with and use the platform.
	Enhancements is how to deal with change in the system. This could range from adding small features to much bigger, strategic programmes of work.
	Support is all about how incidents, problems and service requests get raised against the system. It also covers who deals with them, and how to categorise and prioritise them.
	Operations covers on-going maintenance tasks. These activities ensure the smooth running and optimisation of the system over time. You will typically find that on-premises implementations will be much heavier from an ops perspective. This is because you have little control over much of the IT operational tasks in SharePoint Online, as Microsoft looks after these for you.
	Governance underpins the core operational pillars. It fleshes out the policies and procedures that must be followed to run SharePoint.

Together, these elements form a holistic Operating Model that can deliver standardisation and integration across the different pillars, and ensure that SharePoint can thrive within an organisation.

This series

I’m going to write a series of blog posts focusing on defining an operating model for SharePoint. I’ll do one post for each of the 5 operational pillars, plus one each for strategy and governance. I’ll also do an extra post on organisation design, and how to put together the right teams, roles and responsibilities to run SharePoint. I hope this blog series will provide some useful reference material for organisations who want to maximise their return on investment with SharePoint.

Thanks for reading.

—————————————————————

Part 1 – Introducing the SharePoint Operating Model

Part 2 – Strategy

Part 3 – Content

	Chad on How and When to Adopt the Mode…
	Mike Strubbe on How and When to Adopt the Mode…
	JSW on How and When to Adopt the Mode…
	Damien on Planning for the Azure CDN Cap…
	Antoine Troost (@apr… on New Office 365 Feature: Per-Gr…

Introduction

Step 3 – Benefits of the Modern UI

User Experience – Lists/Libraries

Easier to Switch Views

Easier to Customise Views

Pinning Documents

Properties Pane

List Forms

Copy and Move Files Easily

Consistency

User Experience – Sites/Pages

Permissions Management

Page Editing

Modern Web Parts

Cross-Device Compatibility

Integration

Office 365 Groups and Teams

PowerApps and Flow

Increased Storage Capacity

Step 4 – Options and Recommendations

Things to Consider Before You Come Up with Options

Consider Constraints Versus Benefits

Consider Whether to Upgrade Legacy Sites

Consider the Fragmented User Experience Between Areas of SharePoint

Consider Fragmented Training

Consider the Support Implications

Consider the Maintenance Implications

Consider the Strategic Direction Microsoft Are Taking Things

Assessing the Options

Final Recommendations

Conclusion

Related Reading

Introduction

What is the Modern UI?

Process for Assessing the Impact of the Modern UI in Your Environment

Step 1 – Assess Compatibility with Existing Sites

Site-Level Customisations

List-Level Customisations

How do I Upgrade?

Enabling Modern

Creating a Site as Modern Natively

Upgrading an Existing Classic Site

Upgrading an Existing Classic List/Library

Upgrading an Existing Classic Page

Recommendations for Remediating Existing Sites

Step 2 – Assess Constraints for Future Design and Development Work

Feature Gaps and Constraints

Provisioning

Branding

Custom Pages

Site Management

Site Discovery

List Views

List Customisations

Microsoft’s Roadmap

Stuff That’s on the Roadmap

Stuff That’s Missing from the Roadmap

Wrapping it Up

Introduction

What is a CDN?

What options are available?

SharePoint CDN

Origin Libraries

Referring Pages

Authentication/Authorisation

Public CDN

Origin Libraries

Referring Pages

Authentication/Authorisation

The Underlying CDN Technology

Feature Comparison

Price Comparison

Performance

Non-Functionals

Data Privacy and Compliance

Anonymous Access to the Public CDN

Constraints

My Recommendations

1. SharePoint as a concept/brand will cease to exist

2. Around 20% of content on SharePoint intranets will be created by automated writing tools