Microsoft SharePoint 2013 Designing and Architecting Solutions: Gathering Requirements

In this chapter, you will learn about:

• The importance of gathering requirements.

• Defining information architecture requirements.

• Mapping information architecture requirements to logical components.

• Designing the physical architecture.

• Mapping requirements to SharePoint Online and hybrid implementations.

Microsoft SharePoint has been and continues to be many things to many people. Even today, if someone asks, “What is SharePoint?” each person has a unique idea of what the product can and cannot do. SharePoint is and always will be a platform to be implemented to meet the needs of the organization that it is meant to serve. As such, arguably the most important task of a successful implementation, is to gather all of the requirements that reflect the business goals of the organization to ensure the maximum value is attained with the implementaion of the SharePoint 2013 platform. Ultimately, the reason that everyone seems to have a different interpretation of what SharePoint is, is that a successful implementation should be molded to the needs of each different organization. Therefore, it is important for you, as its designer, to ask the appropriate questions to ensure that you are building a solution that satisfies organizational goals and visions while providing quantifiable value to the people using SharePoint.

In this chapter, you will gain an understanding of the importance of gathering requirements and then take a high-level view of the core components of the product. You will then take those requirements and map them to the logical and physical architectures to ensure a successful solution. Finally, you will examine what options you have with the new Microsoft SharePoint Online offering and discuss possible hybrid solutions. The final section, “Putting it all together,” includes some example questions that you can add to your arsenal to help ensure the success of your implementation.

Importance of gathering requirements

At the very basic level of explanations, requirement gathering should be no different than what you typically do in organizing your personal and professional lives. In your life, you may set goals and determine the plan for accomplishing those goals. Typically, the more detailed the goals and plans for accomplishing those goals are, the better chance you have at being successful at meeting those goals. The approach to implementing SharePoint 2013 is no different.

SharePoint 2013 provides many capabilities to organizations and users. Unfortunately, many organizations either attempt to provide too many, if not all, of the capabilities of the platform, or too few, approaching the implementation with little or no clearly defined expectations. The majority of this book covers the technical elements of an implementation and configuration of SharePoint. The skills necessary for a successful gathering of requirements encompasses not only a deep understanding of the technical capabilities of SharePoint 2013, but also a thorough insight into the organization, its functions, and its goals, both tactical and strategic.

Why gather requirements?

All stakeholders of the SharePoint 2013 solution should understand and be able to communicate the importance of the requirement gathering process to both other stakeholders and, ultimately, the users of the proposed solution. Although seemingly based on common sense, you may run across the situation where the organization has decided to proceed with an implementation without a clear understanding of what the implementation is meant to provide to the organization. This leads to frustration with the solution, and possibly to an abandonment of the solution by the very users that the platform is meant to assist. Organizations that have implemented previous SharePoint environments and other enterprise systems without a thorough understanding of the capabilities and value that the platform provides to the users have found many different challenges throughout the lifecycle of the solution, including:

• Failure of implementing relevant enterprise metadata and content types

• SharePoint site “sprawl” or unruly, difficult-to-manage site structure

• Inability to implement future solutions due to initial configuration decisions and actions

An implementation project that fails to properly gather and understand the requirements may cause a “rip-and-replace” reimplementation of the SharePoint platform. The effort, time, and cost of the initial nonrequirement-focused deployment would be, at the very least, wasted.

When to gather requirements

The primary deployment stage within which to gather the requirements is planning. When you finish the planning stage, you should have documented the following:

• An infrastructure design to support your solution

• A detailed description of how you will implement the solution

• A plan for testing and validating the solution

• A site and solution architecture

• An understanding of the monitoring and sustained engineering requirements to support the solution

• A record of how the solution will be governed

• An understanding of how the solution will be messaged to the organization’s users to drive adoption of the solution

Be aware, however, as you move through the future deployment stages of development, proof of concept, pilot, user acceptance testing, and, finally, production, you will likely update your requirements and plans. Like most planning, the important thing to remember is to do the right amount of planning. Too little can create significant additional work, consume unbudgeted resources, and/or ultimately detract from the overall success of the implementation. At the same time, too much planning can obviously take away time and resources up front, but also prevent corrections during a full deployment cycle.

Planning for success

Initially, the key question to be answered is, “Why are we implementing SharePoint 2013?” A clear, concise answer is the basis for a successful implementation. To that end, it is a question that can rarely be answered solely by the organization’s IT professionals. The most valid answer will come from the organizational leaders and the interpretation of their understanding of the organization’s goals and objectives. As such, it is critical to identify the individuals who are responsible for the business objectives, especially those to be addressed by a SharePoint deployment. These individuals will typically be identified by project management as key stakeholders. Additionally, more detailed business objectives to be addressed may come from key individuals within specific business or organizational units. The information gathered from these stakeholders is not only the basis for the implementation, but can also provide the initial information to be documented in the governance and information architecture deliverables. Finally, some, if not all, of these stakeholders should also be identified as potential members of the ongoing governance team or board to ensure that the solution continues to meet the needs of the organization throughout its lifecycle.

Metrics for success

If the process for gathering requirements is simply setting goals for the platform, how will you measure the business or organizational success of the SharePoint 2013 implementation? This question must be addressed and clearly answered to ensure that all stakeholders know when the goals of the project have been met. Even if the technology is close to perfect, the platform is not successful unless it has a positive impact on the organization’s goals.

Although ideally it is best to use quantifiable metrics, an information management, collaboration, or content management system is difficult to quantify for users. Therefore, look for examples from users and/or other stakeholders to provide the measurable value statements. A specific example with a simple quantitative statement of organizational value at the end can have significant impact and help to measure the success of the project. For instance, a user could say that for a specific task, instead of the previous two days of effort, the task was completed in four hours. Quantitatively, this translates to a reduction of 75 percent effort to accomplish the task. If the task is repetitive and/or completed by multiple users, this can be easily translated to a cost benefit. If 10 users did the same task monthly, with a savings of 12 hours per task execution, the organization could claim the savings of 120 hours each month for that task alone! The features offered by SharePoint 2013 are vast, and no one organization will probably use all of them. Implementing SharePoint in an organization may cause people to examine their processes and find better ways of implementing everyday tasks. With the abilities of SharePoint Search, using metadata for documents instead of folders, or even presenting people with electronic workflows, can save time and money.

Identifying stakeholders

Once the decision has been made to implement SharePoint, the stakeholders have a number of expectations. Whether formally or informally, there is a vision as to what the outcome of deploying SharePoint 2013 will provide to the organization. However, since SharePoint 2013 is meant to empower all users with access to information, and due to the fact that SharePoint 2013 integrates or connects to so many other systems, there are many people and/or groups of people who will have an impact on the success of the implementation. Identifying the individuals or stakeholders having an impact on the successful implementation is the first step in the process of gathering requirements.

In most organizations, the IT department will lead the technical implementation. However, IT is not necessarily fully aware of the organization’s goals. In a worst-case scenario of a deployment of an IT product or technology, IT will simply deploy it without guidance from the organization. You may have seen examples where IT has approached a product or technology with a “build it and they will come” mentality. With SharePoint 2013, this approach is extremely dangerous to the overall success of the deployment. As with most business- and/or user-centric solutions, user adoption is paramount to the success of the project. You should always keep in mind that the role of IT is to support the organization and its goals. You could deploy the perfect technical solution, but if the users do not adopt and use it, the project is a failure. However, a successful SharePoint 2013 implementation is still very much dependent on IT.

Who are the other stakeholders? As with most things in a SharePoint 2013 implementation, it depends. It depends on the purpose of the platform. For example, in deploying a self-service portal for company and personnel information, typically the key executive stakeholder will be the corporate communications director and/or the human resources (HR) director. On the other hand, a customer-focused extranet portal may have the chief marketing officer or similar person as its key stakeholder. Each stakeholder may have his or her own agenda and have a number of requirements that need to be met. Typically, SharePoint may not be successful when those needs are captured. A critical error in deploying SharePoint 2013 is attempting to enable all the functionality and features that come with the product in the first iteration of deployment and expecting that it will satisfy the needs of the stakeholders.

Finally, as mentioned earlier, expect the platform to increase functionality over time, preferably in an iterative or phased approach. Therefore, remember that for each phase or iteration, the group of stakeholders may change. Review Table 3-1 for the most common stakeholders that participate in a project.

Table 3-1 Potential SharePoint implementation project stakeholders

Stakeholder	Requirements Input
Executive sponsor(s)	Provide the goal/vision of the platform
Content providers	Provide type(s) of information to be made available on the platform
Users	Provide input to ensure that the solution addresses the needs of users
IT department	Provide guidance in complying with IT policies and guidelines, as well as support for connected and/or integrated systems
SharePoint project team	Provide expertise on the platform capabilities, limits, and ease of solution implementation

The more stakeholders there are, the more information you can gather to provide detailed requirements, as well as ensure comprehensive coverage of important objectives. Additionally, you will gather more support for the implementation. Keep in mind that stakeholder and user support is arguably the most important aspect of any SharePoint 2013 deployment.

The inclusion of employees who may not have official titles but are influencers within the organization can help evangelize the solution. These champions can be influential in the organization due to how much they’re respected. They can be essential in making an implementation successful.

Organizational objectives

The organizational objectives are the goals of the project put in the perspective of the organizational goals. The organizational or business objectives of the SharePoint 2013 solution should be clearly defined, documented, and measurable. Every requirement should have traceability to the objectives of the system. In fact, if a requirement does not have traceability to the objectives, it should be postponed for a later iteration or phase of the solution or removed altogether. Similarly, the implementation’s goal should connect to the organizational mission or goal. This simply defines the SharePoint 2013 project’s value to the organization.

In addition to organizational objectives, by deploying SharePoint 2013 within an organization, there can be additional value to the organization. These, too, should have traceability to organizational goals. Some of the additional organizational benefits can include:

• Ensuring less time to find and access information that organizational members need to accomplish their work

• Ensuring less time to find and utilize others’ skills and expertise

• Consolidation of organizational classification of information

• Minimizing onboarding time for new members until they are productive

• Improving customer service and/or partner collaboration by providing access to internal organizational information

Prioritizing goals

In implementing a platform based on SharePoint 2013, scope can rapidly become an issue. As such, the first step for successful implementations is to prioritize the objectives to be addressed by the system. Ideally, it is best to identify three to five primary capabilities of the platform that will provide the most organizational impact and ensure that they are implemented extremely well. Ensure that the expectations of the platform are clear and communicated to all stakeholders and users early in the project lifecycle. Also, try to keep the complexity of the solution to a minimum by relying on SharePoint 2013 native functionality. By staying within the native functionality boundaries of the platform, especially during the initial iteration cycle, the project schedule and cost will be minimized, furthering the probability of success. During interviews with stakeholders, use the time to explain the out-of-the-box features and receive feedback about whether the native functionality will be acceptable to the user. Finally, ensure that the vision of the solution, not just the initial iteration, is communicated. This is even more critical in the initial iteration of implementation of the SharePoint 2013 platform.

Mapping objectives to functionality

Once the proposed system’s objectives (goals) have been defined, the next step is to map the identified, prioritized objectives to SharePoint 2013 functionalities. This is one of the most important responsibilities of the SharePoint 2013 project team and administrators, as a broad and deep knowledge of SharePoint 2013 is critical to accomplishing this successfully. For example, an objective that ensures less time to find and utilize others’ skills and expertise could depend, and therefore be mapped to, the native SharePoint 2013 features of user profile search, My Sites, newsfeeds, community sites, and blogs. Another example would be the objective of improving customer service and/or partner collaboration by providing access to internal organizational information. This requirement would map to SharePoint 2013 functionalities of extranet support, web content management, Business Connectivity Services (BCS), and/or mobile access.

Deliverables

The requirements-gathering activities will contribute significant key artifacts for the implementation project. Different groups of stakeholders and individuals will have an impact on different deliverables. Optimally, the project team will gain this information from the stakeholder groups. The best method is by interview, capturing the respective information from each group. However, it may be difficult and too cost and time prohibitive to engage every stakeholder group in personal or group interviews. At the same time, communication solely via email can be less informative and limiting to both the stakeholders and the project team. Be flexible in the communication and information-gathering process.

At a minimum, you should deliver usage scenarios, functional requirements, nonfunctional requirements, taxonomy and metadata, content types that will be implemented, and site structure, and then work with them in defining the governance plan and documentation.

Usage scenarios

You should compile a list of usage scenarios that will capture the most common-use cases of the system. Additionally, the list should be prioritized, based on the commonality and criticality of the scenario. The usage scenarios will also provide additional information and basis for governance documentation, user documentation, and training. There is no dependency on other deliverables.

• Key stakeholders All users of the system

• Example A user will access a file from the archive (file share), make edits, and upload to SharePoint, providing metadata for the document.

Functional requirements

Functional requirements are derived from the usage scenarios and therefore are dependent on the completion of the prioritized list of usage scenarios. The list of functional requirements should also be prioritized based on criticality to business impact, commonality, and ease of implementation.

• Key stakeholders Executive sponsorship, business analysts, and SharePoint project team

• Secondary stakeholders System and application administrators of integrated or connected systems

• Example HR information requires a unique retention policy.

Nonfunctional requirements

Nonfunctional requirements are those that do not affect the functionality of the system, but are typically affected by policies and procedures of the organization. These can include organization- or IT-specific guidelines for IT systems such as security, high availability, capacity considerations, etc. Since nonfunctional requirements are not strongly tied to usage scenarios, the gathering of these requirements can be done in parallel with other requirement deliverables.

• Key stakeholders IT management and SharePoint project team

• Secondary stakeholders System and application administrators of integrated or connected systems

• Example All data must be secured via encryption—at rest and during transmission.

Taxonomy and metadata

In SharePoint 2013, the classification of the information stored within the system is more critical than prior versions. Additionally, the classification or taxonomy of the information will typically occur at multiple levels. In a simple organization, this could be implemented via a two-tier system of enterprise- or organization-wide classification and department classification. In more complex and larger organizations, it could have several tiers of classification. While gathering requirements and usage scenarios from users, the primary question to be asked in determining taxonomies will be, “How do you organize your data?” You will find individuals with the same role and/or responsibilities organizing the same type of data differently. With a well-designed taxonomy and metadata, SharePoint 2013 provides the ability for users to find the information as they desire, rather than by a fixed structure. At the same time, this ability can initially be challenging to users who have only dealt with file shares and folder structures. Most users coming from a simple folder structure have used the folder names and/or file names to provide the classification with which they feel most comfortable. At a minimum, the taxonomy and metadata will provide input to content types and site structure and, optionally, the configuration of the Managed Metadata Service (MMS) application of the platform.

• Key stakeholders Users and business analysts

• Secondary stakeholders SharePoint project team

• Example All documents in the organization must be identified with office location, department, and sensitivity classification.

Content types

Once information types and classification are determined from both usage scenarios and taxonomy and metadata, the content types and hierarchical level of the types can be defined and planned. Similar to taxonomy and metadata and, in fact, so closely related, the content type structure and level at which they are implemented can be at the organization, department, and or specific need level(s). Additionally, this may affect configuration of one or more MMS applications and their corresponding enterprise content type hubs.

• Key stakeholders Business analysts, SharePoint project team, and administrators

• Example Since all documents need to include the office location, department, and sensitivity classification, an enterprise content type will be created as the base document content type for the organization.

Site structure

As mentioned previously, SharePoint 2013 is more reliant on classification of the information than the storage or site structure of the platform. However, performance and system constraints will still affect the overall site structure for a successful deployment. The taxonomy and content type hierarchies will typically have the most impact on the site structure. The best way to describe the importance and relationship of classification and structure is to remember users will only find and use information in one of two ways if they do not already have the location of the information—either via Search or navigable site structure. Therefore, even if the SharePoint 2013 implementation is more reliant than ever on Search via metadata navigation and/or content, site structure is still just as critical.

One important thing to consider is how governance will dictate what users can and cannot do when creating new sites. You probably want to avoid situations where users are allowed to create sites that change the overall structure of the site.

• Key stakeholders SharePoint project team, administrators, and business analysts

• Example While there are a number of ways to organize sites within a specific organization, review Figure 3-1 as an example of how sites may be broken up functionally.

  

  Figure 3-1 Site structures should be broken up in functional ways.

Governance plan and documentation

During the discovery of the organizational objectives that the solution is addressing, the initial governance plan should also be considered. Governance will be “living,” in that it will and should be constantly changing as the solution matures. It is also essential in keeping the boundaries of use by keeping the platform manageable. It can also minimize the amount of configuration by SharePoint administrators to maintain the governance of the system. This is similar to having a policy within the organization not to browse inappropriate Internet sites. IT could create, administer, and maintain a block and/or accept a list of appropriate Internet sites, but the additional overhead could be significant. Rather, by communicating to all users via an Internet usage policy (governance), the organization can minimize the risk and cost of enforcement. This should be the same approach for SharePoint 2013 and good communication mechanisms of the proper use and purpose of the platform. In the final section of this chapter, you will be presented with a number of sample questions that will help determine the governance needs of an organization.

• Key stakeholders Business analysts, SharePoint project team and administrators, and the IT department

• Example All organizational files to be shared with others will be placed in the SharePoint portal.

Information architecture

Information architecture (IA) has several definitions. It is the structural design of shared information environments. For the intranet and websites, it can be considered the combination of organization, labeling, search, and navigation systems. It is both an art and a science of organizing information within software to support findability and usability. Successful IA addresses all three of the following information access scenarios:

• The user knows where the information is located.

• The user doesn’t know where the information is located.

• The user doesn’t know if the information exists.

Ignoring the first scenario, which is obvious, the platform provides access to relevant information in a combination of two ways; search and navigable structure.

The enterprise search capabilities native to SharePoint products and technologies has been in the platform for the last several versions. With the new consolidated features of the SharePoint 2013 Search engine, which could be easily be described as a combination of SharePoint Server 2010 Search and FAST Search for SharePoint 2010, the native search capabilities have become more powerful.

The site structure will define the primary navigable structure. However, again, there are improvements within SharePoint 2013 for navigation, allowing for dynamic navigation based on taxonomy. Implementing metadata or taxonomic navigation can be a very powerful tool for the findability and usability of the SharePoint 2013 environment. However, the dependency for successful implementation is a well-defined and planned taxonomy. Additionally, expect difficulty in user adoption of this type of navigation. Most users will have difficulty in moving from a single dimension folder-based structure of files and/or sites to a dynamic presentation of navigation. Additionally, if the information is not “tagged” with the proper taxonomic properties, the navigation structure can fail the organization.

All of the deliverables of the requirement-gathering phase are necessary to complete the IA. However, since you are primarily concentrated on search and navigability, the most important deliverables will be site structure, taxonomy, content types, and usage scenarios. However, functional and nonfunctional requirements, as well as governance, can have an impact on the final IA. Thus, your primary task will be to concentrate on site architecture and taxonomy or metadata architecture.

Benefits of IA

The stakeholders who have made the investment in the SharePoint 2013 environment will expect an intuitive platform for users to find the information being exposed by the solution. Additionally, good IA can have additional benefits, including:

• Reducing IT workload and costs by identifying and potentially removing duplicate or redundant information within the organization.

• Improving user experience and, therefore, adoption by providing intuitive, navigable structure(s) that reduce the amount of time to locate information that users need. As well, users will feel more positive about the system as a whole, driving even more user adoption.

• Minimizing risk of compliance of both internal and external regulations, policies, and procedures.

Site architecture

The site architecture will provide the relationship of the information in SharePoint and, optionally, outside the platform. It will show the relationship between web applications, site collections, sites and, optionally, libraries within the sites. The initial site architecture will typically start with the IA deliverable. Most organizations will be tempted to begin with organizational structure–based site architecture. Although this may benefit smaller, departmental organizations, consider the site architecture options based on usage or flow of information. The primary factors that influence site architecture are:

• Content responsibility Who is creating the content? Who is managing the content? For example, the HR department is responsible for all human resources–related information on the platform.

• Content security If there are specific security requirements for the information, this may cause a separate site hierarchy for the content.

• Content size The amount of information and/or content within a site hierarchy can have an impact on the system as a whole and influence the site architecture.

You should also minimize the depth of the site architecture hierarchy. If a user needs to navigate seven levels to access information, the number of links or clicks can be frustrating to the user. Depending on the use of SharePoint 2013 social features and Office 2013 SkyDrive Pro, this can be minimized for common information. However, users will need training and/or communication surrounding this new functionality.

Some of the other topics that should be examined may include the use of publishing sites versus team sites. While governance may dictate who will modify or review content, the features will need to be determined during the planning phases.

Metadata architecture

Metadata architecture is as critical, if not more critical, than site architecture. It allows for the classification and organization of information in many different ways. Additionally, many of the enhanced SharePoint 2013 IA features rely on good metadata or information descriptors. It can affect relevant search, findability, and organizational compliance, to name a few.

Basically, metadata architecture is the combination of content types, local metadata (columns), and organizational metadata (managed metadata).

Content types are, in fact, primarily defined by the metadata used to define the type of information. The metadata for content types will either be defined at the site (collection) level or at the enterprise (metadata managed) level. With the MMS application, first introduced in SharePoint 2010, you have the ability to manage not only enterprise metadata, but also enterprise content types (that is, content types used across site collections, web applications, and even SharePoint farms). Content types can therefore be defined at the site (collection) level or across the enterprise.

Local metadata consists of two different types of columns: site columns and list columns. Site columns are defined at the site collection level and can be used to help define local (site) content types or be used throughout lists and libraries within the site hierarchy. List columns are defined and only available within the list or library where they are defined and configured.

Managed metadata is metadata that is managed centrally in a SharePoint 2013 MMS application, and optionally available both inside and outside the SharePoint 2013 farm.

Finally, there are very strong advantages of well-designed content type and metadata hierarchies. Since the metadata architecture is hierarchical, changes at a higher level can be optionally passed to lower levels of the hierarchy. This inheritance provides a significant benefit of ease to management and administration for changes in the taxonomy.

User challenges

Arguably, the most difficult part of applying the metadata architecture will be communicating and/or training the users on the benefits and proper use of metadata. Folders, the classic IA cornerstone in legacy information management systems, will still be strongly engrained as the method for organizing information. The classic folder structure was, in essence, the classification of information by location only. However, this structure presents the following problems:

• Folders do not allow for dynamic views of your content.

• Folder structures are fairly immutable or difficult to change.

• Folders assume that everyone accessing the information organizes information in the same manner.

• Folder structures lead to duplicate content, as users may put content in two folders since the content applies to both folders.

Since users will need to change the way they work with information by adopting the process of applying metadata information, it is also extremely critical to communicate the benefits of using metadata to organize information.

Logical architecture

After the completion of the IA, the process moves to creating the logical architecture to support that IA. The logical architecture simply ensures that all the services, service applications, and external systems needed for the IA are available and documented for the implementation of the environment. In a conceptual view, one could imagine the logical architecture as the listing and detailing of all of the building blocks required for the implementation, both internal and external, to the entire SharePoint deployment.

Typically, it is easiest to start by listing the service applications needed, and then understanding and mapping the communication pipelines between the components and/or services listed. Once this is complete, the architect will easily move into the physical architecture and capacity planning of the physical servers to host the services (components) of the complete system. Figure 3-2 illustrates an example of a logical architecture with a dedicated enterprise search farm.

Physical architecture

With the logical architecture complete, the next step is to map the logical components (services) to physical servers. Even if the servers are virtualized using Hyper-V or VMWare, the virtual machines are considered, for this phase of design, physical servers. However, the virtual physical hosts need to be considered, if not by the SharePoint technical team, by the administrators managing the virtual environments. It is strongly recommended that virtual guests—physical servers of the SharePoint deployment—utilize dedicated resources such as virtual cores and RAM. Additionally, other factors, such as if and when to utilize hyper-threading (allowing for more CPU cores at a cost of overall CPU capability) or ensuring non-uniform memory access (NUMA) boundaries for RAM, should be considered by the technical architects and/or administrators of the virtual environment.

The physical architecture, as shown in Figure 3-3, will typically show the physical servers, with the services allocated to each server and communication pipelines between the servers.

Understanding system requirements

SharePoint 2013 supports several installation scenarios. At release, these include the following:

• Single server with a built-in database or single server that uses Microsoft SQL Server

  This scenario should only be used for development and/or evaluation installations of Microsoft SharePoint Foundation 2013.

• Single-server farm installation with built-in database or single server that uses SQL Server

  This scenario is optimal for development and/or evaluation installations of SharePoint Server 2013.

• Multiple server farm installation

  This will be the most common scenario for pilot, user acceptance testing, and/or production deployments of SharePoint Server 2013.

Minimum hardware and software requirements

As the SharePoint platform and its capabilities have increased from previous versions, the minimum hardware requirements have also increased from previous versions. In planning, the technical architect will need to keep these in mind when developing the implementation plan. However, as always, these system requirements should not drive the implementation. The organizational requirements, and therefore the solution requirements, should always have priority over technical requirements.

For the latest guidance on the technical requirements for SharePoint, review http://technet.microsoft.com/en-us/library/cc262485.aspx.

For all of the scenarios listed on the provided resource, the hard disk space for the system drive only provides for the base installation. You must plan for and provide sufficient space for diagnostics including logging, debugging, and other requirements. In production, you must have additional space for other operations. You must maintain, at a minimum, two times as much free space as you have RAM. So additional requirements may include:

• Drive space of five times RAM.

• Distributed cache RAM requirements.

• Workflow server farm.

• Office Web Apps farm.

• Search in SharePoint 2013 requires more resources than in the previous version.

• A single-server farm with a number of service applications will require 24 GB of memory.

All servers that belong to a server farm, including database servers, must physically reside in the same datacenter. Redundancy and failover between closely located datacenters that are configured as a single farm (“stretched farm”) are not supported in SharePoint 2013, which is a significant change from the previous version.

Most production environments will consist of an implementation based on the multiple server three-tier farm. In this scenario, separate, dedicated database server(s) will be required.

It is important to keep in mind the SharePoint 2013 software boundaries and limits. Expect them to change during the lifecycle of the SharePoint 2013 products and technologies. For more information, visit http://technet.microsoft.com/en-us/library/cc262971.aspx.

Keep in mind that the software and hardware listed above are the minimum requirements. Capacity planning, especially from the database perspective, is covered in Chapter 5, “Designing for SharePoint’s storage requirements.”

SharePoint Online and hybrid architecture considerations

With Wave 15, the emphasis on SharePoint Online is clear. With Microsoft offering a “to the cloud” message and the public release and availability of the new version of Office 365 in February 2013, many organizations are now examining the SharePoint Online platform as an option to provide SharePoint 2013 capabilities to their organizations. Of course, the first and main thing to consider when examining SharePoint Online as an option for deployment is to examine requirements. As stated previously in this chapter, requirements are sometimes very difficult to keep as the goal of all deployments.

When to consider SharePoint Online or hybrid architecture

With either a sole SharePoint Online deployment or a hybrid architecture approach to SharePoint, there are many benefits to considering the cloud-hosted model. Additionally, although SharePoint Online is available as a stand-alone, purchasable Software as a Service (SaaS) model, most organizations will move directly to Office 365, which will include one of the two SharePoint Online plans: Plan 1, sometimes referred to SharePoint Online Standard, or Plan 2, sometimes referred to as SharePoint Online Enterprise. To map to Office 365, SharePoint Online Plan 2 is currently available in Office 365 Plans E1, E3, and E4. However, one of the benefits of SharePoint Online is that the feature set can grow fairly rapidly, especially considering Microsoft communications concerning “rolling releases” of software updates and enhancements to the Microsoft Cloud offerings.

Again, the first things to consider are the features available to organizations from all possible deployment scenarios, especially between on-premises (on-prem) and SharePoint Online. Review Figure 3-4 for an overview of the features and the offerings they map to.

Arguably, the most attractive feature of moving to a SharePoint Online environment is the lowering of associated overhead of managing the infrastructure, both from a supporting hardware as well as from a manpower perspective. From a financial perspective, the cost associated with providing the functionality for the users shifts from the classic capital expenditure (CAPEX) classification to an operating expense (OPEX) classification. In essence, especially for rapidly changing organizations, the cost for user business productivity software (email, collaboration, instant messaging, VoIP audio and video conferencing, when bundled with Office 365) can be clearly planned on a per-user basis, even for thousands of users. High availability and disaster recovery planning and implementation is already included, which with on-prem (or dedicated hosting) deployments can multiply costs exponentially, if not planned accordingly.

The biggest requirement driving necessity for an on-premises or hybrid deployment is typically business intelligence capabilities. Following right behind the business intelligence requirement seems to be the exposure of line-of-business (LOB) data via BCS. However, exposing LOB data via BCS is quite possible under certain conditions in the hybrid architecture.

If the organizational requirements extend beyond a purely SharePoint Online deployment, there are still more benefits to a hybrid architecture than solely relying on an on-prem deployment. Assuming that the organization subscribes or plans to subscribe to Office 365, SharePoint Online is included in the subscription. At that point, it makes financial as well as common sense to offload as much of the configuration, management, and administration of SharePoint capabilities and functions to reduce the overhead for on-prem deployments.

Hybrid architectures can provide the following:

• Federated search Users in the cloud and the on-premises domain environment will be able to obtain search results that include content from both locations.

• BCS Makes LOB data available to applications for SharePoint and external lists in SharePoint Online.

• Single sign-on (SSO) Users who are connected to either the corporate network or Office 365 have to authenticate only once in a given session to access resources in both the on-premises SharePoint farm and SharePoint Online.

• Directory synchronization User accounts in the on-premises Active Directory Domain Services (AD DS) domain automatically synchronize to Office 365.

• One-way or two-way server-to-server trust A trust relationship between the on-premises SharePoint farm and SharePoint Online that enables secure connections and data flow.

There are three primary architectures when considering hybrid deployments concentrated on providing search and BCS capabilities. From the most basic to the most complex, they are:

• One-way hybrid search

  • SSO Users who are connected to the corporate network have to authenticate only once in a given session to access resources in both the on-premises SharePoint farm and SharePoint Online.

  • Directory synchronization User accounts in the on-premises AD DS domain use Active Directory Federation Services (AD FS) to automatically synchronize to Office 365.

  • One-way server-to-server trust A one-way trust relationship is established between SharePoint Online and the on-premises SharePoint farm.

  • Federated search Users in your on-premises domain environment will be able to get search results that encompass content from both locations.

Figure 3-5 gives an example of a one-way hybrid search architecture, showing users who are connected to the corporate network and have access to SharePoint Online.

• Two-way hybrid search

  • SSO Users who are connected to either the corporate network or Office 365 have to authenticate only once in a given session to access resources in both the on-premises SharePoint farm and SharePoint Online.

  • Directory synchronization User accounts in the on-premises AD DS domain automatically synchronize to Office 365.

  • Two-way server-to-server trust A certificate-based two-way trust relationship is established between the on-premises SharePoint farm and SharePoint Online.

  • Two-way federated search Users in Office 365 and in your on-premises domain environment will be able to get SharePoint Search results that encompass content from both locations.

Figure 3-6 gives an example of a two-way hybrid search architecture showing users who are connected to the corporate network and have access to SharePoint Online.

• Hybrid BCS architecture

  A SharePoint 2013 BCS hybrid solution provides a bridge for companies that want to take advantage of cloud-based SharePoint Online to access on-premises LOB data_while keeping that proprietary data safely maintained on their corporate intranet. The SharePoint BCS hybrid solution does not require opening holes in the firewall to allow traffic through and it does not require you to move your LOB data out into the perimeter network. The SharePoint BCS hybrid solution uses the on-premises BCS services to connect to the LOB data and then, through a reverse proxy, securely publish the endpoint out to the BCS services in SharePoint Online 2013, as shown in Figure 3-7.

Hybrid requirements

Although the SharePoint 2013 technical project team is usually considered to be completely responsible for the deployment of the supporting infrastructure of the system, most organizations will have to include other IT professionals (such as Network Infrastructure, Directory Services, and Certificate Services teams) within their organization to provide the necessary infrastructure requirements to implement a SharePoint 2013 hybrid deployment architecture. Keep in mind, however, that organizations that have already invested in an Office 365 deployment may already have these requirements in place. For example, if an organization has already deployed Exchange Online, either completely online or hybrid, the majority of the prerequisites from an infrastructure perspective should already be in place. It is beyond the scope of this chapter to detail the “how” to deploy the prerequisites, but the following requirements will be necessary:

• AD DS within a functional-level forest of Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012

• On-premises deployment of AD FS 2.0 exposed to the Internet

• On-premises deployment of the Microsoft Online Services Directory Synchronization (DirSync) tool

• An Office 365 Enterprise or SharePoint Online subscription with 15.0.0.4420 as the minimum build number (SharePoint Online Plan 2, Office 365 Enterprise Plan E1, E3, or E4)

• On-premises SharePoint Server 2013 farm that has each of the following configured:

  • Enterprise Search site collection configured with a public external URL (for example, https://sharepoint.contoso.com) by using an alternate access mapping

  • An Secure Sockets Layer (SSL) certificate issued by a public root authority

  • An App Management Service Proxy installed and published in the SharePoint farm

  • A Subscription Settings service application enabled and configured

  • A Search service application, configured as appropriate

  • A User Profile service application—User profiles contain detailed information about people in an organization. A user profile organizes and displays all of the properties related to each user, together with social tags, documents, and other items related to that user. In the BCS hybrid scenario, it is used to map the users, ACS OAuth credentials to the users’ domain credentials.

  • A Client-Side Object Model (CSOM) pipeline—The CSOM receives the incoming request from the reverse proxy and maps the OAuth user tokens from ACS to the users’ domain credentials.

  • A Site/Site collection—A site collection created expressly for the purpose of facilitating all hybrid request communication. The web application that this site collection is in has an alternate access mapping configured.

  • BCS Runtime Service SharePoint for on-premises—The BCS Runtime service is the SharePoint service application that manages all BCS functionality, such as administration, security, and communications.

  • Secure Store service SharePoint for on-premises—This is the credential-mapping SharePoint service application. In the SharePoint BCS hybrid solution, SharePoint on-premises stores the mapping of the users’ domain credentials to the credentials that are used to access the external data source.

• OData service head—The SharePoint BCS hybrid solution only supports the OData protocol. If your external data is not natively accessible via an OData source, you must use Microsoft Visual Studio to build and deploy an OData service head for it.

• A reverse proxy device with an Internet connection that permits unsolicited inbound traffic [for example, Microsoft Unified Application Gateway (UAG) 2010 SP3].

• An Internet domain (such as tekfocuslab.com) and access to Domain Name System (DNS) records for the domain

SharePoint Online will need to have the following configured as well:

• BCS Runtime Service Online & Office 365 (O365) Microsoft Online Directory Services (MSODS)—Provides directory services in O365 that you can synchronize with your on-premises AD DS. The synchronization is done through user profile synchronization and allows users to use the same account for both on-premises and cloud authentication.

• SharePoint Online Secure Store service—This is the credential-mapping SharePoint service application. In the SharePoint BCS hybrid solution, SharePoint Online stores an SSL Server certificate that authenticates the SharePoint Online request to the reverse proxy.

• Windows Azure Access Control service (ACS)—This is the Azure security token service that performs authentication and issues security tokens when a user logs on to a SharePoint Online site. It looks up credentials in the MSODS, which has been synchronized with the on-premises AD accounts. This allows the user to use the same set of credentials for both the on-premises and online environments.

Finally, it will be necessary to replace the default token signing certificate for the SharePoint Secure Token service application (one of the default service applications created upon the creation of a new SharePoint Server 2013 farm). It can be replaced with a public certificate, which is recommended, or with a new self-signed certificate that you can create in Internet Information Services (IIS) Manager. A domain-issued certificate is not supported.

A hybrid deployment can initially seem to be complex. However, careful planning, approach, and implementation is typically done once, with little maintenance needed.

Putting it all together

As you already hopefully know, gathering, defining, and prioritizing requirements for a system is arguably the most important step in a successful implementation. The balance between planning and actually implementing the system is critical. It is a well-documented fact that there is rarely too much planning. Also, planning will lower the time of implementation if done correctly. Always keep the system requirements as the primary decision-making factors for everything within the implementation. A test implementation will ensure a smooth production implementation. Finally, it is extremely rare to find too much documentation, so ensure that it is created, maintained, and referred to often. This section highlights a number of questions that may enable you, as the Microsoft SharePoint Architect, to gather the requirements that you need to build a successful implementation; while each set of questions is organized into various buckets or individual categories, they may span several.

Planning a successful SharePoint solution strategy

Prior to gathering the requirements for how SharePoint should work, it is important to understand the following:

• Who are the key players involved with the project?

• What are the reporting relationships between the stakeholders?

• Why is each stakeholder involved?

• What are the overall business objectives and vision statements for each?

• How do the business objectives relate to the organization’s strategic initiatives and mission?

• Are there any differing goals, conflicts, and so on?

• What will determine the success of the project?

• What processes are in place to maximize and measure user adoption?

• What are the plans for continuing the maintenance and monitoring of the environment?

These questions are more than just “fill in the blanks.” These are generally conversation starters to ensure that enough thought has been put into these areas. Oftentimes, these items are overlooked and it is tough to understand if the implementation was successful or not.

It is important to map the overall business objectives to SharePoint functionality early in the process to help decide if SharePoint is a good solution—these cannot be forced.

Planning a governance strategy

Once you have been able to identify who the stakeholders are and how they will be measuring success, you will be able to continue by gaining an understanding of the governance strategy.

One of the first steps in defining a governance strategy is to build a governance team that will include members of IT, Corporate Training, HR, Corporate Communications, Cyber Security, Site Collection administrators, etc. Some example questions that you will find useful when gathering governance requirements include:

• Who will make up the governance board?

• What is the vision statement of the project?

• What are the defined roles and responsibilities?

• What are the policies and standards with regard to:

  • SharePoint content

  • Information design

  • Security

  • Features

  • Navigation

  • Custom code

  • Composite applications

  • Branding

Besides knowing what rules will need to be followed, it is equally important to determine how governance will be enforced.

Planning the IA

The IA of SharePoint describes how content will be organized and accessed. This can be a time-consuming process and should be well planned prior to adding content into SharePoint. Some of the key topics around this area include:

• What type of sites will be included and how will they be accessed?

• What type of content will SharePoint contain?

• Are there any security restrictions on particular content?

• How will users find this information?

• What is the expected user experience?

• How will documents be stored?

• What properties are important for each type of document?

• What are the commonalities of these properties?

• How are the documents being stored prior to moving them to SharePoint?

• Are there any specific policies around document management?

• What managed terms and keywords are expected?

Identifying business processes that will use SharePoint 2013

SharePoint 2013 offers much more than document management. It is important to identify what business processes need to be implemented using the solution as well. It is also important to help the stakeholders understand which processes can be simplified in SharePoint and which ones cannot. The following questions will help identify possible business processes:

• What business processes are tied to content stored in SharePoint?

• Are there any policies around information stored in SharePoint?

• What type of browsers will be supported in the organization?

• Who is responsible for defining the processes?

• Who is responsible for maintaining or creating workflows with SharePoint?

• What composite applications will be available?

• Do you expect to integrate LOB data within SharePoint?

Understanding the security requirements

Security within SharePoint is a critical piece, and understanding the requirements prior to building out the farm is critical to project success. Changes in security requirements can affect how the overall SharePoint farm is constructed and the communication protocols used for each. It is important to gather the following information:

• Who will have access to the system?

• Who will maintain those users?

• How will they access the system?

• Will a user be able to access the system externally? If so, will their rights differ?

• What form of authentication will be used?

• Will the farm contain Personally Identifiable Information (PII) or information that has specific security around it?

• Are there any specific requirements on how the data should be stored? (Transparent Data Encryption [TDE], and so on)

• Are there any specific requirements on how the information should be transported?

• Will certificates be used within the system?

• Will ports be blocked?

• Will antivirus software be configured?

• What server-hardening techniques are expected?

• Are there plans for any gateway or proxy devices?

• What type of load balancers will be used and what protocols do they support?

• Are there any predefined network topologies that we need to be aware of?

• Will Rights Management be required?

• Will compliance and auditing be required?

• What is the planned response to security threats? (governance)

• What are the current password policies?

• What are the current Group Policy Object (GPO) settings?

• Will security groups be maintained in AD and/or SharePoint?

Understanding the business intelligence requirements

Business intelligence requires additional planning over and above what is needed on a typical SharePoint implementation and can be critical in not only dictating how the farm is constructed, but what SQL Server product is used for support. The following items should be considered:

• Do you plan to incorporate any of the following?

  • Reports

  • Charts

  • Dashboards

  • Scorecards

  • Key Performance Indicators (KPIs)

  • Excel Services

  • PerformancePoint

  • Microsoft Visio

• Each of these points will need to be planned not only for its existence, but also for the type of data, freshness of data, amounts expected, and so on.

Understanding the role of the Office client

Office has tight integration with SharePoint 2013. The following questions will help you determine the possible Office client solutions:

• What version of Office is available to the users?

• Will all users have a copy of Office locally?

• Do you expect that users will work offline?

• Do you expect a large number of users to be accessing the same documents?

• Do you expect coauthoring?

• Do you expect to support mobile applications?

Understanding the performance and reliability requirements

Once the content of the SharePoint site has been identified, it will be important to gain an understanding of the performance and reliability requirements. The following list of questions will help you determine the appropriate requirements that support performance and reliability:

• How many concurrent users do you expect?

• What is your expected growth or adoption rate over the next three years?

• What is the expected performance metrics?

• What services do you expect to be available at all times?

• Do you expect to span geographical areas? Distance?

• What is the distance from AD to SharePoint to SQL Server?

• When are your peak hours?

• Who is responsible for monitoring and maintaining SharePoint? (governance)

• What is the expected load on the servers?

• How much RAM can we expect to have on each server?

• What is the network speed?

• Are there any specific encryption requirements?

• Will all of the servers be virtual? Vendor? Blade distribution? NUMA boundaries? RAM allocation?

• Describe the load balancers that will be used. Who is responsible for their configuration?

• Is there a budget for Staging and Development servers?

• What is the current software development lifecycle process?

• Are there any concerns about being able to acquire the requested hardware?

• How much time is allocated in the deployment plan for performance and reliability testing?

Every SharePoint 2013 implementation is different, and it is vital to understand the requirements that will help you build a system that will promote success. This section is meant to help trigger requirements that may be critical to the architecture component; you may think of additional questions that help you drive forward to a successful project.