次の方法で共有

SharePoint Online Information Architecture Considerations

  • [アーティクル]

The geek in me would love to have a developer cure-all to ensure a successful SharePoint deployment (ok…provisioning comes really close). In reality, success is based largely on great Organizational Change Management (OCM) and solid Information Architecture (IA). Even the most mature SharePoint organizations struggle with these activities. This is especially true as they move SharePoint workloads to the multi-tenant cloud of Office 365. In this post, I’ll discuss Information Architecture considerations specific to SharePoint Online. In many ways, the cloud demands re-imagined patterns for Information Architecture in SharePoint. I’ll break down the discussion into four areas…URL Limitations, Capacity Considerations, Templates/Provisioning, and Managed Metadata/Content Types.

NOTE: Information Architecture is a departure from my normal development themed posts, but you will find that Office 365 development patterns can help deliver a stronger IA implementation in SharePoint Online. I will make many references to Office 365 Development Patterns and Practices on GitHub that includes samples to automate and add governance to an IA strategy.

 

What is a Tenant

Before getting started, it would help to define the word “tenant” that is often mentioned in Office 365 and/or SharePoint Online discussions. After frequent confused looks by customers, I no longer assume understanding of this term in context. Office 365 and SharePoint Online are considered a multi-tenant software as a service (MT SaaS). To simplify, you can consider SharePoint a large apartment building Microsoft owns in the cloud. Our customers are the “tenants” in that apartment building. Tenants share the apartment building (SharePoint), but Microsoft does everything possible to avoid tenants from disrupting other tenants. Microsoft has also offered customers dedicated SharePoint hosting. Dedicated hosting gives a customer their own apartment building, but isn’t nearly as economical as multi-tenant. Multi-tenant SharePoint Online is where most innovation investments are being made and where Microsoft hosts its own internal SharePoint workloads (we wouldn’t put you in an apartment we wouldn’t live in ourselves).

URL Limitations

The use of “vanity URLs” is a practice I’ve observed in numerous on-premises SharePoint deployments. Web applications, host-named site collections, and managed paths cater to every end-user URL whim. This epidemic adds challenges to already challenging cloud migrations. SharePoint Online takes a very simple approach to URL organization. Outside of OneDrive for Business, all SharePoint Online sites must fit under a single host-name (https://tenant.sharepoint.com). The table below lists all the host-names in multi-tenant SharePoint Online and their intended use.

Host-Name Description
https://tenant.sharepoint.com Default SharePoint Online host name where most authenticated sites will be provisioned
https://tenant-my.sharepoint.com Reserved for My Site Host and OneDrive for Business sites. Supports manual subsite provisioning but not site collections outside of OneDrive.
https://tenant-admin.sharepoint.com SharePoint Online admin center (think of this as a slim version of Central Administration for SharePoint Online administrators)
https://tenant-public.sharepoint.com Anonymous public site reserved for internet presence (great for small and mid-size organizations but less useful with orgs with existing web presence)

 

You can specify your own custom domain for the public site, but NOT the default internal host-name. I have seen customers implement a number of redirect alternatives to overcome this challenge including DNS mapping, http modules, tiny URL/mapping solutions, etc.

In addition to host-name limitations, you cannot add new managed paths to SharePoint Online. For the default internal host-name you get the root, /search (explicit managed path), /sites (wildcard managed path), and /teams (wildcard managed path). Although there is no right/wrong approach in applying these to SharePoint workloads, the table below outlines a popular approach I think makes a lot of sense:

Managed Path Description
https://tenant.sharepoint.com/ Reserve for corporate intranet or search
https://tenant.sharepoint.com/search/ Reserve for enterprise search center
https://tenant.sharepoint.com/teams/* Reserve for “commodity” sites such as teams, projects, and self-service provisioning
https://tenant.sharepoint.com/sites/* Reserve for divisional, departmental, or specialty sites (ex: Record Center(s), SharePoint Applications, etc)

 

Capacity Considerations

If you think the limited variety of URL options calls into question the traditional strategy of using more site collections…you are on to something. For on-premises customers, I always recommend the approach “when in doubt, break it out…into separate site collections”. This keeps content databases manageable for disaster recovery and (hopefully) under the recommended 200GB size for collaborative content. However, worrying about content databases and disaster recovery are things of the past for SharePoint Online customers…let us (Microsoft) deal with that. All signs point to re-thinking how you break up sites when moving to SharePoint in the cloud. In addition to URL limitations, multi-tenant enterprise customers are currently limited to 500,000 site collections (excluding OneDrive for Business). This limit has gone up several times since general availability...including most recently from 10,000 (thanks to Dean for pointing this out). To make up for any limitations in URLs and site collection limits, Microsoft recently announced the ability to scale site collections in SharePoint Online to 1TB. This is significantly beyond the 200GB recommendation for collaborative content on-premises. I don’t have specific guidance on how to break up sites in SharePoint Online as I don't think there is a one-size fits all solution. However, I will provide some generic guidance and best practices:

  • Continue to error on the side of breaking up sites into separate site collections
  • Keep content grouped within the same site collections where it logically makes sense and that fits within the 1TB capacity limitations of SharePoint Online (including room for future growth)
  • Site collections are the highest level securable container in SharePoint, so consider separate site collections when sites have highly uniquely permissions
  • Keep collaborative content separated from published content (ex: I wouldn’t include the Finance Department’s team sites in the same site collection as their informational/intranet pages available to the entire company)
  • Consider implementing retention/disposition strategy for both site collections and content to keep site collection count/sizes down and to recycle available site collection URLs
  • Just because site collections can grow bigger in the cloud, don't go overboard with elaborate site hierarchies. This is never a good idea as it makes it very hard to reorganize content in the future

I still like site collection provisioning for "commodity" sites such as teams and project (especially when combined with self-service provisioning). It is just too hard to predict how these types of sites will be used, where they should get provisioned, and how much space they need. What changes in SharePoint Online is the need to consider retention in commodity sites. Yes retention…that great little feature that SharePoint has supported for years, every organization says they need, yet hardly anyone implements. A site collection disposition strategy can great help manage capacity limitations in the cloud. We leverage a site collection disposition strategy internally at Microsoft, but all site collections must have two employee owners to avoid disposition of critical content when an employee switches roles or jobs. Also remember...retention/disposition does not necessarily mean delete. A disposition strategy might be a process to move high-value assets to a record center before deleting the unused collaborative site.

Templates and Provisioning

Templates enable sites to be pre-configured for quick/easy/repeatable provisioning elsewhere. Throughout SharePoint’s history, there have been a number of approaches for provisioning such as site definitions, site templates, web templates, feature stapling, provisioning providers, and more. Site templates and web templates are the only out of the box approach available for patterned provisioning in SharePoint Online. However, neither of these approaches are ideal. For example, site templates only work for subsites and do not support publishing. Web templates can miss out on new functionality “stapled” to sites in the ever-changing SharePoint Online. For a comprehensive list of provisioning techniques and their limitations, I highly recommend Vesa Juvonen’s post on site provisioning techniques.

Instead of site or web templates, it is recommended that SharePoint Online customers adopt a programmatic site provisioning strategy. Programmatically owning the provisioning process for site collections and subsites can achieve almost any desired outcome (including many things impossible in templates). This technique requires a customization, but it is highly documented and promoted by Microsoft and SharePoint Online experts. Most of the popular provisioning patterns are available on the Office 365 Developer Patterns and Practices initiative on GitHub. And solutions have been features on my blog, Vesa's blog,Channel 9, and most importantly Microsoft's SharePoint Online solution pack for branding and site provisioning. 

Since programmatic provisioning has already been thoroughly covered in other publications, I will provide an abstract. The concept is to replace standard provisioning with custom provisioning, including templates, forms, and provisioning execution.

The first step in delivering custom provisioning is defining site configurations. These configurations define the expected outcome from provisioning and are analogous to templates. Configurations can include almost anything, including branding, features, lists/libraries, page configurations, etc. A popular pattern on GitHub uses XML definitions for these “templates”, but the configurations could be stored virtually anywhere the provisioning “app” can read. These provisioning options will likely be presented to the user for selection in custom provisioning form(s) outlined below.

The second component in delivering custom provisioning are custom provisioning forms. These should replace the out of the box provision forms that exist throughout SharePoint Online (ex: /_layouts/15/newsbweb.aspx). SharePoint Online admin center already allows a custom “Start a site” form to be specified on the “Sites” portal of SharePoint Online (see image below). This is often used to enable self-service site collection provisioning. For subsite provisioning, our custom provisioning “app” can hijack the new subsite links throughout SharePoint (using a simple script-injection technique). Both these patterns have been thoroughly documented in Office 365 Developer Patterns and Practices.

Finally, the custom provisioning app needs to provision site collections and subsites based on the selected site configuration and any additional criteria specified in the provisioning form(s). The provisioning process will programmatically create sites and then add/remove components based on selected site configurations. Once the provisioning process is complete, the user can be directed to the newly created site. Again, a number of patterns are already available for download off GitHub, including applying branding, alternate CSS/logos, creating content types, script injections, Yammer integration, page/wikipage manipulation, and much more. However, almost anything is considered fair game in provisioning so long as the Client-Side Object Model (CSOM) supports it.

Managed Metadata and Content Types

Managed Metadata and Content Types can play key roles in a strong IA strategy. In on-premises deployments, these components can be synchronized across site collections, web applications, and even farms using the Managed Metadata Service. Keeping one definitive source for taxonomies and content types can greatly facilitate content search/discovery and policy adherence. Although SharePoint Online supports similar features (including content type syndication), it does not support hybrid synchronization with on-premises definitions. To support a strong enterprise content management strategy, SharePoint Online taxonomies and content types might need extra care to keep term and content type IDs identical to on-premises equivalents. Luckily, the client-side object model can help to achieve this when term sets (taxonomies) and content types are programmatically provisioned in the cloud. In fact, part of the site collection provisioning process might include the provisioning of custom content types (perhaps even setting default field values based on the site properties). It is not recommended you provision content types declaratively as was common in the feature framework. Although this can be done with a declarative sandbox solution in SharePoint Online, programmatic provision is the recommended method (unless the app is part of an app). Office 365 Patterns and Practices on GitHub contains samples for creating content types, synchronizing term sets, and even auto-tagging solutions.

Final Thoughts

This post wasn't meant to outline prescriptive guidance for information architecture. My goal was to outline some important IA considerations specific to SharePoint Online. I hope the details I've outlined helped you understand the unique constraints of multi-tenancy and some patterns for achieving information architecture utopia in SharePoint Online. Remember to checkout the Office 365 Development Patterns and Practices for samples for achieving many of the recommended patterns.

Comments

  • Anonymous
    September 01, 2014
    The comment has been removed

  • Anonymous
    September 01, 2014
    Hey Brian...thanks for the great catch! I've update the post and referenced you for the find :)

  • Anonymous
    September 01, 2014
    The comment has been removed

  • Anonymous
    September 01, 2014
    Thanks for the tip Dean...I knew the site collection capacity update was coming soon, but it must have gone public just within the last week. It absolutely DOES affect my thinking. I'd spend much less effort on grouping sites and continue to error on the side of breaking them up in separate site collections. Managed metadata navigation and content by search have come a long way to overcome past challenges of separate site collections. Thanks again for the tip...I've updated the post and referenced you for the find :) -RZ

  • Anonymous
    September 01, 2014
    Do you have any guidance around the Content Type Hub? Specifically, is there a programmatic way in O365 to publish content types from the hub for consumption throughout the tenant?

  • Anonymous
    September 02, 2014
    Really good article! Good read as an introduction into the Information Architecture for SharePoint Online projects.

  • Anonymous
    September 08, 2014
    The comment has been removed

  • Anonymous
    October 07, 2014
    Has the '/portals' managed path been rolled back ?

  • Anonymous
    October 12, 2014
    My company is planning to leverage SP Online, and I was thrilled to learn about addition of the "portals" managed path. About 3  weeks ago I created a site collection (sc) under this path. BUT ... About a week ago I have discovered that portals are not available any more (?!!!).  I.e. The site collection that I've created in the past under it are still there , but portals managed path is not available for any new sc.  The only managed paths I see is teams and sites. I am very puzzled and not sure what to make of " the case of disappearing managed path". Any thoughts?  

  • Anonymous
    October 13, 2014
    Mark - did you find out anything more on portals managed path?

  • Anonymous
    October 13, 2014
    The comment has been removed

  • Anonymous
    October 13, 2014
    I do not know the cause of the portals managed path being pulled back. If I find out (and can be disclosed), I'll let you know. I've updated the post above accordingly.

  • Anonymous
    October 14, 2014
    All of our clients are seeing the /portals managed path disappear as well. I created a ticket with Microsoft O365 Support and just got off the phone with them. The technical didn't believe me that the /portals path once existed - I had to request a screen share with him to prove it. I was then escalated to a support manager but he was unable to provide any answers. Hopefully someone can shed some light on this.

  • Anonymous
    October 14, 2014
    Found a explanation about in on Yammer (www.yammer.com/itpronetwork): Mark Kashman (Microsoft) It was not supposed to appear as it's being leveraged under the covers for our new portal deliverables, the one coming soon is the "Office 365 Video" offering. Support is working out what next mitigation steps are for sites created under this managed path ...

  • Anonymous
    November 03, 2014
    I just logged the /portals with support too.  Got a quick response.  Yes it's gone, no they're not taking away existing site collections that are using it.  No suggestion of needing to migrate to /sites.

  • Anonymous
    November 03, 2014
    The comment has been removed

  • Anonymous
    March 16, 2015
    The comment has been removed

  • Anonymous
    March 30, 2015
    Wonderful post however I was wondering if you could write a little more on this topic? I’d be very thankful if you could elaborate a little bit further. Thank you! <a href="staygreenacademy.com/.../">SharePoint Developer</a>