Because a cloud service provider, in this case Microsoft, can technically access the information stored in Office 365, each organization needs to consider this as part of their governance strategies. When considering security in the cloud, there are two primary threats: the threat of it being a cloud service, thus exposed to the public web, and the threat of the service provider employees accessing information.

Cloud service providers take very seriously the custody and security of data they store or process. There is nothing more critical to the backbone of establishing a trusted relationship with customers than security. Because of this, they take very seriously how they isolate content from other customers and how they prevent their staff from accessing customer data. We encourage you to review carefully all Microsoft policies currently in place to determine your organization’s comfort level with the Office 365 policies in place at this time. The threat posed by a cloud service provider having a breach due to an employee accessing your content is somewhat unrealistic. The sheer volume of data and the steps necessary to crack encryption keys and breach the security architecture present a very low probability of success for a breach. Then you have to factor in the end game; ask yourself how far an employee would be willing to stick their neck out to make it worth their while to take this type of action. They could lose their job, face the possibility of litigation or criminal prosecution, and permanently damage their professional reputation. Typically, and in the case of most cloud service providers, they do require the need to access individual instances to provide support services based on your requests. In the case of Microsoft employees accessing individual instances of Office 365, they access configurations based only on your support requests. It is in the best interest of the organization to protect your content and your configurations. We believe the threat of a vendor damaging or accessing your information is no greater than the same threat from a disgruntled employee or from a visitor to an organization’s private network, and thus should generally be disregarded as a threat. In the event your organization has confidential, highly sensitive, or proprietary information that will be stored in Office 365, our recommendation is that this subset of information be stored in an on-premise instance of SharePoint. The same recommendation should be made during the Information Architecture (IA) design for on-premise solutions where a handful of employees have access to this type of information.

The threat of the public Internet is the second consideration that we need to address. Public cloud service providers staff network operations centers (NOCs) 24 hours a day, 365 days a year. The professionals working in these NOCs are at the top of the IT world and specialize in network security. When comparing the security of Microsoft’s NOC team to the typical organization’s IT security team, they are far more secure and advanced because of the round-the-clock monitoring and access to tools most other organizations will not typically have. For this reason, 9 times out of 10 the security of information in Office 365 SharePoint is more secure than an organization that currently has a SharePoint instance open to the public web.

There might be circumstances that will prevent you from having any content in the cloud. These are usually related to your local government’s content privacy acts or to specific regulations within your industry. These same regulations will prevent you from having a SharePoint 2013 on-premise instance with public web access. In these cases, you do not have an option, and you should consult all your government and industry-related compliance specialists or representatives prior to choosing an ECM solution.

The next challenge that organizations must consider, and often much more impactful then security, is that of accessibility. While there is limited offline access to Office 365 SharePoint, it is assumed that using the solution requires Internet access.

Accessibility to the Internet is becoming more ubiquitous every day, and performance improvements are constantly being made. The most common mistake organizations make when evaluating accessibility of Office 365 with on-premise SharePoint is not accurately identifying and diagnosing availability issues within their own network.

Every network, whether cloud or on-premise, will face accessibility issues from a user’s point of view. These could be due to poor Virtual Private Network (VPN) connectivity, physical network infrastructure issues with switches or routers, poor wireless connectivity, or any number of other issues related to the network. In each of these cases, downtime is going to happen. Organizations need to compare their internal service-level agreement (SLA) over a period of a year or two with the current SLA of the cloud service provider. Many are surprised to discover that their internal availability has been less over the years than that of Office 365. Now add to that the ability of your users to access the public web, and you might have a slight degree in difference when comparing the availability of on-premise versus the cloud. This is especially true for organizations with large numbers of remote employees, but for the most part, organizations find the availability within the tolerable range of productivity, and this is improving every year.

Similar to availability of the public web, Office 365 does suffer from bandwidth limitations that users within the firewall using an on-premise SharePoint will not face. The transfer rates of the web will most likely impact users attempting to upload or download large documents. This is also an issue when bulk-loading large document sets or folders and performing the export scenarios we talked about in Chapter 9.

Actions demanding large amounts of bandwidth can be very challenging when working with any cloud solution. The frequency of these activities will help determine what type of solution is best for your situation.

As you can see, the arguments for moving to Office 365 are stronger than not in most cases, and this will be the general trend over the coming years. We also see a lot of interest in a hybrid approach, which could be useful in the following scenarios:

The benefit of the last hybrid scenario is that it avoids all the issues discussed with eDiscovery and large document actions because these actions will tend to happen in the on-premise configuration of SharePoint rather than in Office 365. In this scenario, the day-to-day document creation and editing will happen in a very flat version of your IA configured in Office 365, and then you can migrate the final documents to your on-premise SharePoint ECM solution. This approach gives users the most up-to-date cloud and mobile experience but also requires a formal policy and training on where and when to create content and then moving or migrating it to when completed.

Whether your organization chooses Office 365, on-premise, or hybrid, there are very few technical limitations to accomplishing the goal. Just remember that the ECM principles outlined in this book and the IA planning need to remain the same.

Besides Office 365, the other area where SharePoint is very unique and deserves additional consideration is when working with third-party services and tools.

This segment of tools for SharePoint is one of the oldest categories of third-party solutions. These types of solutions relate specifically to on-premise instances of SharePoint. In the world of ECM, they often get grouped with archive tools. While the technical approaches might be identical, the use case of backup and recovery is distinctly different. The use of tools for performing archive imply content that is designated as discoverable and should be kept intact with the original IA. Backup and recovery deals with the ability to restore content in the case of data loss or disaster from unplanned events. The content in a backup and recovery system might or might not be discoverable, and content can be modified. It’s recommended that organizations first explore the built-in SharePoint functionality for backup and recovery before considering a third-party solution.

The primary considerations for ECM in backup and recovery are going to be the retention policies placed on backups, the discoverability of backups, and the frequency. Third-party solutions typically offer greater granularity of options for scheduling backups and the types of backups, even including special rules based on content types and metadata. Most organizations consider SharePoint backup and recovery as part of a broad backup and recovery strategy, which can include disaster recovery, which is the process of making sure that an organization can be up and running in an alternate location rapidly. If disaster recovery is part of your organization’s planning, considerations for moving the environment farm or for farm replication will be required. There are both out-of-the-box SharePoint options and more robust third-party tools available for this.

A growing category of third-party solutions is in the area of business intelligence (BI). These tools allow organizations to manipulate and visualize data and, in a larger context, also incorporate the concepts of BigData. Currently, this is largely dominated by transactional type data, but we are starting to see this blend into the world of unstructured content as well. SharePoint offers some out-of-the-box visualization technology in the Enterprise CAL with the Performance Point features. However, there are third-party tools that exist that take BI even further. These third-party solutions today are closely tied to SQL server and are often add-ins to SQL instead of SharePoint. Because BI and BigData have not yet found their place in the unstructured content or ECM world, they are not tremendously useful in visualizing and analyzing content. However, they do participate in ECM when you are considering the usage of the platform from an analytics standpoint. Creating and manipulating data around the types of content users are contributing to the system, the frequency of content, and even pattern identification across metadata are allowing organizations to get a window into SharePoint adoption that they would not otherwise have had. This is used to spot risky behavior or inconsistent usage. For example, analyzing patterns across content might help an organization identify that a particular document is misplaced in the wrong library, without browsing libraries manually or using search functions. Prior to acquiring these types of solutions, we recommend that you have a specific business goal or outcome that your organization is trying to achieve.

A very popular category of third-party solutions related to ECM comprises the various Business Process Management (BPM) and workflow tools. As we stated in Chapter 2, the biggest difference between BPM and workflow is the administration layer of the workflows created. BPM tools allow you to create many workflows, version workflows, deal with change management, track in real-time document processing, and provide a larger range of workflow events and triggers. The typical workflow in ECM is related to content approvals. Organizations that are extending SharePoint into other applications such as human resources, bids, and proposals, and other line-of-business processes have a much greater need to integrate ECM content with the larger business process.

For these organizations, the functionality in out-of-the-box SharePoint workflows might not be enough, or because of the number of workflows, the administration of the workflows might be too time-consuming. In these instances, we tend to see a large adoption of third-party BPM tools. As always, we recommend that organizations start with the out-of-the-box workflows until they hit a limitation. However, there is the additional consideration of the number of workflows. SharePoint does not allow you to version or manage workflows collectively. If your organization is faced with 10 or more moderately complex workflows, it is worthwhile to consider a solution that allows you to version those workflows and manage them in a single location. Versioning of workflows allows you to have different versions of workflows running on content based on the evaluation of specific metadata properties, which might be critical to maintaining compliance under certain circumstances.

While ECM ensures that content is timely, accurate, and secure, it does not always consider the quality of information. The quality of the content and the metadata of documents are the responsibility of the user most of the time. However, there is a class of third-party tools called content enrichment tools. These tools help improve the quality of content without the help of users. They can provide auto-classification of content, automatically apply content types and taxonomy terms, or generate summaries. In some cases, they can extract critical or known elements included in the content, such as people, places, and values. Content enrichment tools operate on content when it is modified, uploaded, or in bulk, initiated by a workflow or by the individual user. They use natural language processing (NLP) or predictive coding to read the body of documents to produce results.

It is important for the organization to understand how it will use such a technology. If the purpose of using such a technology is to feed a workflow, accuracy is paramount, so the vendor’s tool should be put through a pilot project or proof of concept.

If the purpose of using such technology is to improve the quality of search, performance and inclusion of keywords are important. Various tests of real documents should be run with the tool and compared to search without the additional metadata. For organizations in regulated industries, you will have the additional consideration of making sure that metadata is not added to a library that should not be visible to some users who have access to the library. An example of this might be personally identifiable information, like extracting or exposing Social Security numbers. Content enrichment is a great benefit to ECM processes and should be considered during the planning stages with the ECM committee.

While SharePoint has built-in functionality for remote BLOB storage (RBS), many organizations find that they do not have the ability to configure it correctly. This is a consideration for on-premise SharePoint only. There are various third-party solutions that make the setup and maintenance of RBS a lot easier. All the same considerations given to RBS as an extension of what SharePoint already provides should be considered with any third-party solution. Organizations will choose a third-party solution when the staff, or other internal expertise, is not present to configure connectors for RBS manually. Additionally, some of these solutions provide a dashboard that gives a sense of the usage of content externalization and a way to monitor performance and other system-related storage issues. The primary consideration organizations need to make with such a solution is its reversibility. When you commit to content externalization, you are limited to the things you can do with SharePoint, and you might be limited in the future when planning an upgrade.

User governance, content governance, monitoring, and security tools are the largest category of third-party SharePoint solutions that have a moderate influence on ECM. We group them together because they all fall under the scenario of observing adoption of the platform. Chapter 6, covered the importance of user adoption, and these tools can help with that effort. Because they tend to be platform-level solutions for on-premise SharePoint installations, they end up being a part of all applications deployed on the platform. In the area of ECM, these tools can be very useful in the early days of an ECM deployment to see how users are adopting the system. It can help to point out where active usage is taking place and to detect functions that are not leveraging the platform fully. It can also point out inconsistencies in usage and, more specifically, identify the behavior of individual users. We see such tools used very early on in ECM adoption and on an infrequent basis when the platform success is being evaluated or there is a specific need to audit content and usage. The biggest consideration for ECM planning is to know how these tools will direct or influence IA. Very often, such tools have specific requirements on sites and site collections. The ECM team, if the tool is already in place, needs to be aware of any of these restrictions before planning the use of the application. If the solution comes later, the team needs to test fully the solution in a test or development environment to make sure that it does not break any functionality that is already configured in the farm.

We understand that most organizations are faced with many content silos. Because of this, not all of their content is located in SharePoint. An organization might have another critical line-of-business (LOB) application, such as accounting packages, enterprise resource planning (ERP), or customer relationship management (CRM). In an ideal world, these applications are integrated with SharePoint. Integrations are a broad category, and there are many third-party solutions available. Integrations tend to be very specific from SharePoint to another vendor’s product, so the choices of any one specific solution can be limited. For example, Microsoft and SAP have partnered to create Duet, which is integration with SharePoint and the SAP ERP solution.

There are also the integration scenarios where content needs to be synchronized between one platform and another. What we have found is that the general content sync scenarios are done on a case-by-case basis by many one-off integrations. Microsoft and a group of other organizations called OASIS have created a standard called Content Management Interoperability Services (CMIS). This standard is available in SharePoint and many content management platforms offered by third-party vendors for exchanging content and metadata. The standard includes functionality around things such as holds, records, and metadata. If your organization does not use a tool that implements this standard, you need to independently be aware that content migration from one platform to another might not include metadata, hold, record declaration, and other audit information that is critical for compliance and security. If integration is an important component to your SharePoint implementation, it needs to be considered at the very beginning, because retroactive integration almost always fails. Extensive testing needs to be done prior to any implementation.

While the functionality in SharePoint is very robust, it has some limitations compared to more mature records management platforms. These limitations exist mainly from a custody management, auto-scaling, and linkage of content types to retention schedules. There is a handful of third-party records management solutions that install externally or within SharePoint to provide this functionality. They will allow better reporting on custody of content. They address the problem of putting content into separate records management locations where large amounts of content will exceed the best practices of SharePoint sites and site collection sizes. And they help relate and automate the creation and update of content types based on published retention schedules. The best part of these solutions is that they use the terminology and practices that are recognized by records management communities. Governments or other highly regulated organizations typically need these solutions. First, the organization should identify the limitations of out-of-the-box SharePoint records functionality. If they are numerous, consider a third-party solution.

As we mentioned in Chapter 2, document imaging and image capture are a big consideration for organizations with paper documents that they want to store inside of SharePoint. Image capture is one area where the built-in SharePoint functionality needs to be augmented with third-party technology. When considering image capture solutions, it’s important to note that most of the best capture solutions live outside of SharePoint. The second element that you need to consider is acquiring a tool to get document images and related metadata that has already been captured and converted from an external capture product into SharePoint libraries as a bulk loading process that includes metadata. This can often happen if a third-party organization is contracted to perform a backfile conversion of paper records. The content and its associated metadata will already be available to be uploaded in bulk to SharePoint. The processes used for capturing document images with high-speed scanners are less technically complex than extracting data or providing auto classification of documents using optical character recognition (OCR) or intelligent character recognition (ICR) software. You will find that picking the best-of-breed capture solution without regard for integration with SharePoint is important as a stand-alone consideration. Investing in integration efforts that meet your specific requirements and finding a bulk upload tool and process that will meet performance demands is more important than choosing a capture solution for its integration with SharePoint. In document capture solutions, you should look for scan quality, conversion or OCR/ICR quality, and file size as primary considerations. In our experience, the capture solution that produces the highest quality images, with the best OCR results and the smallest image size, are the slowest of capture solutions. If speed is a primary consideration, incorporate this consideration from a capture and process design standpoint early on. You might find that multiple tools to support the requirements will be necessary.

Over the last three years, there has been a lot of hype about the benefits of social in the area of content creation and management. These tools can be beneficial to the nature of the content and to adoption. A well-implemented approach to social will take communication type content and move it to feeds. This ultimately reduces this amount of content in the ECM system and focuses the system in line with business documents, which makes it easier to manage, organize, and secure. So implementing social in your SharePoint environment will reduce the frequency and need for certain kinds of content while increasing the ability to manage the system. Because social is engaging, it is a way to bring users frequently back to the system; this can be both good and bad for adoption. In some cases, this encourages adoption only on social elements, but with most social implementations, the conversations are accompanied with document references, so this helps increase the adoption of the ECM system. Social is functionality that most organizations say they want, but they do not put a lot of thought into how they will use it. If your organization is considering social, first work with the out-of-the-box functionality in MySites and see whether this is meeting your goals with social. If it is not, consider the elements that are missing and then look at third-party tools. Like so many third-party add-ons, these can make upgrading to newer versions of SharePoint complex. Records management teams need to consider also where social conversations fit on their retention schedule and whether this content needs to be maintained and or monitored.

Third-party tools abound in the SharePoint space. The categories we have already outlined in this chapter include specific considerations, but we also need to highlight other critical elements that are true for any third-party tools. We highly recommend that your organization take the time to understand the following: Too many organizations have ignored these issues, and they have been forced to delay upgrades to newer versions of SharePoint and either remove or replace a third-party application. Following are some considerations you should be aware of:

The bottom line is that the ECM team needs to test all third-party tools against an ECM criteria checklist. If they do not fit for ECM, the team should have the option to omit their inclusion to the ECM application portion of the farm. So many organizations just assume that third-party tools will not impact SharePoint’s ability to be migrated to and from or that the tools will not impact the ability for the platform to be upgraded. Remember that your greatest tool for ensuring platform migration, upgrade, and continuity of your content is the approach to IA that we covered extensively in Chapter 4.

We always recommend the approach of sticking with out-of-the-box features until those features are not satisfying a strategic business need, making a third-party tool necessary.

Finally, while system integrators are not a third-party solution, the community of system integrators in the SharePoint space is one of the strongest in the world of enterprise applications.

Most SharePoint projects, if only for validation, involve some third-party expertise. SharePoint system integrators are firms that bill per project or per hour to help implement SharePoint. All system integrators are different. You will find that some system integrators specialize in platform and security, which makes them most fit to stand up the farm and configure users and security. Others will focus on ECM and architecture. It is very important not to contract with a system integrator who has no ECM background for your ECM project.

When evaluating system integrators, we recommend viewing existing projects they have completed, if possible. System integrators will tend to tell organizations that if it is SharePoint, they can do it. They will always lead with their talent and make it clear that if they don’t have the answer, their team of architects is so well connected that they can get the answer, even if from Microsoft directly.

It is often very hard to weed through who is really good and really not. The best and only way is to view current implementations they have done and compare them to this book and your own standards. Make sure that you know where the systems integrator is most successful. For example, some integrators come into projects where things are already broken, while others are very strategic and come in early on with the proper project management, planning, and best practices. A proactive and highly experienced integrator is best for any new ECM project or initiative. And a more reactive integrator is good for when something on the platform level breaks and you need specific support for a feature or issue.

The best advice we can give for working with integrators is that they are usually motivated by good references and profitable projects. This twofold motivation can work to make sure that everyone works toward and achieves the desired results. If you are working with a potential integrator, it’s a good idea to cultivate a long-term view of how the project can be beneficial for the integrator from a client reference standpoint. At the end of the project, you want to make sure that the integrator delivers what was promised and that they make a reasonable profit margin doing so. This ensures that integrators who do a good job will be around next time you need them. This is a good time to remind you to incorporate good solid project management practices. If your systems integrator doesn’t have a qualified project manager, this could be an indication that they aren’t prepared to deliver at a reasonably professional level.

There are many ways to accomplish a technical objective, so make sure you are working with an integrator who seeks out the simple and straightforward approaches instead of the more costly and complex ones. An effective way to balance this is to bring in an independent high-level ECM architect to design and plan the implementation and then hire an integrator who is responsible for implementing the application based on the design, the fixed requirements, and the budget. Because this is not possible in all cases, the next best approach is for the ECM committee to fully design and plan their ECM implementation prior to receiving consultation on implementation. In any case, find a way to separate the strategic design from implementation. The problem you will face with this approach is contention between the planning and implementation teams, but this tends to be the lesser of two evils when the parties are interested in a successful implementation.