SharePoint 2013 Case Study: Re-architecting a department solution to the enterprise

  • Article

Status: Final

Introduction

A common task in SharePoint management is re-architecting a SharePoint solution up the adoption ladder to a department solution or even to an enterprise solution.  In this posting, I discuss a real world example involving scaling a department SharePoint solution to an enterprise solution in response to changing organizational needs and direction. This posting first presents some general background on the project and the department and corporate needs driving it.  It will also present some additional needs that were identified by my team over the course of discussions with the customer.  After identifying and collating these customer needs, I next engage in a needs analysis, in which I review various methods, including SharePoint, Active Directory, IIS and other features and capabilities, that can be used to meet each need.  The results of the need analysis are then summarized in matrix form.  I then present the various SharePoint-based solutions proposed to meet the customer needs, selecting one of these as the solution that best meets customer needs overall and the solution that was in fact selected by the customer lead IT architect for implementation.  This posting doesn't present the requirements analysis that was actually engaged for this effort as this would expand this posting beyond the 5-10 page limit.  Instead, the solution space is developed from the needs analysis so as to keep this discussion compact.

Background

A large corporate customer had a need to consolidate various department-scope SharePoint instances into a single SharePoint instance supporting all departments so as to reduce costs and minimize duplication of effort. Corporate reviewed the SharePoint instances of all its departments having their own SharePoint instance, and then selected the SharePoint instance of a specific department, call it "ABC", for scaling to the enterprise. This instance was originally a SharePoint 2010 point solution stood up to meet some individual projects and provide team sites. Over time, its scope was expanded to support several external partner sites and to provide document management services to the department. During this period, other departments in the customer organization were also standing up their own SharePoint solutions to meet information needs. Levels of SharePoint user adoption, expertise, branding, infrastructure, authentication methods, etc, varied from department to department. It was in this environment that senior leadership identified potential cost-savings also identified needs as consistent branding, single-point corporate information sourcing, streamlined user management, etc, all of which were common challenges associated with SharePoint adoption.

Department ABC's SharePoint infrastructure was selected for factors involving network environment, geographic location of staff and data center, administrative expertise and perceived robustness of the SharePoint infrastructure. This infrastructure hosted two web applications. One web application was externally facing and hosted sensitive, host-named external partner sites. This web application was configured to use forms-based authentication. The second web application hosted a few miscellaneous internal sites used in specialized departmental applications and a legacy application site used by all corporate departments; it was configured to use NTLM authentication.

Network access was managed through a native-mode Active Directory network implementing a resource-focused user group strategy. All departments administered user access to SharePoint-based resources by assigning SharePoint permission levels directly to user accounts or adding user accounts to SharePoint user groups. The corporation as a whole numbered approximately 1500 users. Individual departments numbered up to several hundred users. Most department content databases were <50 GB. Corporate network resources were situated in a single AD DS domain. Most geographically distributed departments were part of the same domain. Those that weren't were in planning to do so.

Both corporate and department ABC had critical needs directing this effort. The primary corporate needs were of course to consolidate the various SharePoint instances, so as to implement a single-source, SharePoint-based location for corporate content, and to do so using department ABC's SharePoint infrastructure. Corporate also wanted to ensure that: 1) all corporate users should be able to access the enterprise SharePoint; 2) single sign-on; 3) each department would have maximal capability to administer its content and access to its content; 4) all department sites would implement consistent branding; and 5) industry standards and best practices would be used to develop the enterprise system. The primary needs of department ABC were that: 1) this effort would have no impact on existing operations; 2) department ABC would continue to own and administer its sensitive external partners sites; 3) sensitive external partner content would remain fully secured and 4) corporate would assume maintenance and administration of the legacy application site.

After reviewing these needs, reviewing the proposed environment for the enterprise SharePoint instance, reviewing SharePoint best practices and conducting assessments of departmental SharePoint instances and interviews with their stakeholders, several additional needs were identified: a) simplifying user access administration; b) minimizing site URL lengths and c) communicating corporate direction on site usage across the enterprise. Summarizing these needs, we have the following:

  • Consolidate all SharePoint instances
  • Support access across the enterprise
  • Single sign-on
  • Departments administer their own sites
  • Implement industry standards and best practices
  • Minimize adverse impact on existing operations
  • Department ABC maintains ownership and operations of its external partner web application and sites
  • Sensitive external partner site remains fully secured
  • Ownership and operation of legacy application site will be assumed by corporate
  • Simplify user access administration
  • minimize URL lengths
  • Communicate corporate site usage across the enterprise.

These were the most critical needs identified for the customer and are the ones analyzed in this case study.  Typically, after identifying needs, an analysis is performed that translates these needs into requirements, and this is followed by a design process that would identify the SharePoint features and capabilities that would meet these requirements. However, such a process would be beyond the scope (and length) of this case study.  Instead, this case study will stop at the needs level and then identify the SharePoint and other features and capabilities that can be used to meet those needs.  The next section then analyzes these needs and identifies how they can be met.

Needs Analysis

Consolidate all SharePoint instances

Consolidating all SharePoint instances into a single enterprise SharePoint instance could be met in several ways, with varying degrees of cost and complexity:

  • An entirely new SharePoint instance could be deployed, and then all department content (except for department ABC's external partner content) would be migrated to that instance.
  • A new web application could be provisioned on department ABC's existing farm and deployed as the enterprise content web application.
  • A new site collection could be provisioned on department ABC's second web application (the web application not Internet facing) and department content migrated to that site collection; or a new site collection could be provisioned for each department on that second web application.

Deploying it as a new farm is the simplest option, but one that would likely involve additional capital expenditures to increase hypervisor resources and would involve the greatest overall change to the existing IT environment. In any case, corporate has deemed department ABC's SharePoint infrastructure as the platform on which to build the enterprise instance.

The option opposite to this one, deploying the enterprise as a single site collection, presents immediate concerns regarding capacity management. Migrating all departmental content into a single content database would immediately present a content database that exceeded 200 GB in size, which would be well over Microsoft's recommended maximum size of 100 GB per content database, and would pose immediate scaling problems.

Deploying the enterprise system as multiple site collections in a single content database presents the same capacity management concerns. The one variant here that remains open would be to deploy the department sites in their own dedicated content databases to the existing web application, which in turn requires departmental sites to be dedicated site collections, since site collections cannot cross database boundaries.

The middle option was to deploy the enterprise as a new web application provisioned on Department ABC's SharePoint farm. This option meets corporate direction to use department ABC's SharePoint infrastructure as the platform for deploying an enterprise SharePoint instance.

In summary, of the three options, the best option meeting this need is the option involving deploying the enterprise SharePoint instance as a new web application on the existing department ABC's SharePoint infrastructure.

Ensure accessibility to the enterprise

Ensuring accessibility to the enterprise instance's content across the enterprise, could be met by deploying the enterprise instance to the corporate AD DS domain. So long as the enterprise SharePoint instance is deployed within the same domain containing corporate users, all users will be able to connect to the enterprise SharePoint instance. Since Department ABC's SharePoint instance is situated on resources within the corporate domain, design proposals can take credit for this without having to specifically implement it.

Single sign-on

Providing for single sign-on could be met by:

  • Deploying the enterprise instance to the corporate AD DS domain
  • Implementing Windows Integrated authentication

Typically, the browser that is used to access SharePoint sites will be running under the same authentication credentials that were used originally to log into the network. When using Windows Integrated Authentication, those credentials are passed through the browser to Using Windows authentication takes advantage of the existing authentication provider, AD DS, to provide single sign-on to all resources and tools available within the domain.

To enable this, the SharePoint web application must have NTLM or Kerberos or both authentication providers enabled. A new web application provisioned on department ABC's existing farm (or on a new farm) as the enterprise content web application would need to be configured to use NTLM to support the need for single sign-on.

In summary, given the existing AD DS environment, this need can be best met by employing claims-based authentication using Windows Integrated Authentication methods (NTLM or Kerberos).

Departments administer their own sites

Enabling departments to administer their own sites can be met by:

  • Deploying departmental sites as site collections or
  • Deploying them as subsites to a root enterprise site collection.

Deploying department sites as subsites in a single site collection would enable departments to administer their own site content and the access to that content. Site owners would have Full Control permission level to be able to perform all site administration. Department sites can also create subsites as needed.

However, deploying the enterprise SharePoint system as a single site collection where departments were provisioned with subsites in this site collection would run up against the capacity management problem discussed previously, in that total departmental content across the enterprise already exceeded 200 GB, which is significantly greater than Microsoft's recommended maximum content database size of 100 GB. Therefore, this deployment option is contraindicated but still useful for comparison purposes.

Deploying department sites as site collections enables the maximum scope of administration possible for a site. Deploying department sites as site collections also facilitates more effective capacity management in that a content database can be dedicated to a single departmental site. This would not be possible were department sites merely subsites within a single site collection, since site collections cannot be distributed across multiple content databases but must reside within a single content database. Site collections dedicated to departments can be deployed to the existing internally-facing web application, to a new web application provisioned on department ABC's existing farm or to an entirely new farm dedicated to the enterprise.

In summary, deploying department sites as site collections best meets this need.

Implement corporate and industry standards and best practices

Implementing industry standards and best practices is accomplished by reviewing such sources of information as:

  • Microsoft TechNet SharePoint Library
  • Microsoft MSFT blog posts and wiki articles on SharePoint
  • National Institute of Standards and Technology articles on network and website design
  • IEEE
  • ISO
  • Customer corporate documents
  • Governance Plan

The standards and best practices found from these sources are then implemented and referenced in the design process. For example, on any issue involving SharePoint limits, thresholds and boundaries, The Microsoft TechNet reference, Software boundaries and limits for SharePoint 2013, would be followed. Other industry standards include those published by the Institute of Electrical and Electronics Engineers (IEEE), International Standards Organization (ISO). Third parties are not the only sources of such documents. The customer corporation also had a number of security, design and administrative procedures and practices that needed to be followed, and these were continually reviewed for the applicability to various aspects of the design. These standards and best practices are communicated to the enterprise, as appropriate, via a governance plan.

In summary, this need can best be met by referencing Microsoft, corporate and other industry standards where ever appropriate in the design and development documentation and then communicating these standards to the enterprise via a governance plan.

Minimize adverse impact to existing operations

Minimizing potential adverse impacts of the enterprise system on existing department ABC's SharePoint operations - particularly on its external partner sites - can be accomplished in several ways, each presenting varying levels of separation and dependence:

  • Deploying the enterprise SharePoint instance as a completely new farm
  • Deploying the enterprise instance as a new web application on department ABC's farm
  • Deploying the enterprise instance as one or more site collections to an existing web application on department ABC's farm

Other aspects that can also be engaged to minimize potential adverse impacts include:

  • Using a separate application pool (which would then drive the need to have a separate web application) and
  • Using a dedicated service account

The most effective way to prevent enterprise operations from affecting department ABC's existing SharePoint sites is to deploy the enterprise instance as an entirely new farm. Further separation can be accomplished by deploying the farm to a separate hypervisor. These options would come at significantly increased cost but would also be simpler to implement since there would be fewer dependencies to be mindful of. Separation at the farm level would be the highest SharePoint-based separation possible. Any issues affecting web application resource usage, web server operations, or operating system operations would have no impact on department ABC's farm. Only problems at the hypervisor or network level would impact both farms. Corporate customer direction precludeed this option, but it is still useful to engage it for comparative purposes. Since separation at the farm level is precluded, we must analyze separation within the farm.

  • Corporate direction

Deploying the enterprise system as a separate web application running within its own dedicated application pool accomplishes an intermediate level of separation. Web applications sharing an application pool also share web server resources. For example, memory leaks impacting one web application in the shared application pool would also impact the other web applications sharing that same application pool. Cross-site scripting attacks on one web application would not impact other web applications. Using separate application pools, worker process failures, memory leaks, etc impacting the enterprise web application would not impact the other web applications hosted on department ABC's farm.

Deploying the enterprise system as one or more site collections hosted on department ABC's second web application would provide minimal separation. User account mismanagement, branding problems, design problems, and such would have no impact on other site collections hosted on the web application, but failures of worker processes, memory leaks caused by an enterprise site collection would have immediate impact on non-enterprise site collections also hosted in the same web application.

In summary, the best option that met this need, given customer direction, was the option to deploy the enterprise system as a new web application, running within its own application pool, on department ABC's existing SharePoint farm.

Department ABC maintains ownership and administration of external partner web application and sites

Ensuring that department ABC maintains ownership and administration of its existing external partner sites can be accomplished in several ways, including:

  • The enterprise SharePoint system is deployed as a completely separate SharePoint farm
  • The enterprise SharePoint system is deployed as a new web application on department ABC SharePoint infrastructure
  • The enterprise SharePoint system is deployed as multiple site collections

The simplest option meeting this need would be to deploy the enterprise SharePoint instance as a completely new and independent farm. This option completely separates ownership, administration and resources of the enterprise system from department ABC's system. However, this option is precluded by corporate direction.

The second option is to deploy the enterprise system is deployed as a new web application on department ABC's existing SharePoint farm. For this option, department ABC retains ownership and overall administration of the existing SharePoint infrastructure on which the enterprise system will be deployed and it retains ownership and administration of the existing web applications hosted on that farm, including the web application hosting external partner sites. The enterprise SharePoint system administrator performs as an assistant to the existing farm administrator and administers just the one web application.

For the third option, department ABC retains ownership and overall administration of the existing SharePoint infrastructure, and the enterprise SharePoint system is composed of multiple site collections within the existing internal-facing web application. In this option, the enterprise SharePoint administrator performs effectively as a site collection administrator.

In summary, the first option for meeting this need is not available, leaving the other two options. Both of these other two options meet the need of ensuring, or at least facilitating department ABC maintaining ownership and administration of its existing SharePoint infrastructure.

Sensitive external partner content is fully secured

Ensuring the security of external partner content can be accomplished using a wide variety of different SharePoint and Active Directory features, including:

  • SharePoint farm
  • Web application
  • IIS application pool
  • IIS application pool service account
  • AD DS corporate domain
  • AD nested user groups
  • SharePoint site collections
  • SharePoint sites
  • SharePoint permissions inheritance
  • SharePoint permission levels
  • SharePoint user groups
  • SharePoint security scopes
  • SharePoint securable objects
  • SharePoint Search Service Application
  • SharePoint Managed Metadata Service Application
  • Governance

Deploying the enterprise SharePoint as a separate farm accomplishes complete separation and fully secures external partner connect from corporate users. However, this option is precluded by corporate direction.

The enterprise system can be deployed as a separate web application running in its own dedicated application pool. This helps ensure security isolation down to the worker process level and is the recommended approach to implementing security isolation for web applications. This is further augmented by running the application pool under its own dedicated service account, which helps ensure that if one application pool service account is compromised that this won't adversely impact other web application security.

Using separate web applications also enables each web application to use a different suite of service applications. This is critical in that service applications can inadvertently surface sensitive content to unauthorized users.

For example, while search results are filtered based upon security scopes, and items a user is not authorized to access will not normally appear in the search results, if that user's permission assignments have been mis-configured, or that user's account has been added to the wrong SharePoint or AD DS user group, that user may see results not otherwise visible to that user. This is where configuring search scopes can be useful and add an additional layer of security. If sensitive content needs partitioning even at the content index level, a new search service application can be provisioned that is dedicated to corporate enterprise content, as each search service uses its own content index. This approach would require that the enterprise system be deployed at least as a separate web application, since different service application connections can be configured only at the web application level. In any case, SharePoint search provides additional means, such as search scopes and entirely new search service applications, for augmenting content security, particularly with respect to department ABC's external partner content.

As another example, global term stores (i.e., term stores available across all web applications to which the service is connected) can be isolated administratively by assigning them to groups and then assigning their administration to different persons. However, users will normally still have read access to the terms themselves. Multiple web applications may be connected to a single managed metadata service and thus all of these web applications, their site collections and sites, will share these terms. If enterprise keywords functionality, for a managed metadata service, has been enabled, all of the site collections within the host web application to which the managed metadata service is connected will use the same keyword store. These keywords do not have ACLs attached to them. Term stores can be isolated by enabling local term stores, which are available only to users within the site collection in which they were created. Local term stores are managed by the site collection administrator and not at the farm level. To isolate terms and keywords while also maintaining control over them at the enterprise level would require provisioning separate managed metadata service applications, one for sensitive external partner content and the other for corporate enterprise content. This approach would require that the enterprise system be deployed at least as a separate web application on department ABC's SharePoint infrastructure so that it is configured to connect to an enterprise managed metadata service and the web application hosting sensitive external partner content connects to its own dedicated managed metadata service.

Using an AD DS nested user group strategy within a corporate domain facilitates more effective and accurate user permissions management. Where the enterprise employs an AD DS nested user group strategy aligned with the corporate hierarchy, this hierarchy aligns perfectly with SharePoint site hierarchy that is aligned with the corporate organization. Using this strategy, the SharePoint administrator need only populate SharePoint site user groups with the appropriate matching AD DS user group. Membership of the nested user groups are continually updated and maintained by system administrators, and thus these user groups are the most accurate available on the network. Using these AD DS user groups to populate SharePoint user groups eliminates duplication of effort where both the systems administrators and the SharePoint administrator must both manage a user's permissions. Instead, any changes to the user's domain account (e.g., disabled, deleted, etc) are automatically passed through to that person's authorization to access SharePoint resources. It also minimizes the likelihood of the SharePoint site administrator overlooking a needed permission level change or mishandling that change, which can otherwise occur when the administrator is managing permissions for hundreds of users individually.

SharePoint user groups are containers for security principals and are visible across the site collection. They can include individual Windows and AD DS user groups and accounts and the built-in security principals. They cannot contain other SharePoint user groups. A SharePoint security strategy that employs SharePoint user groups to manage user resource access helps meet the need of securing external partner content by minimizing the likelihood that a SharePoint site administrator overlooks a needed permission level change or mishandles that change.

The SharePoint security framework employs security scopes and permissions inheritance, which consists of a SharePoint access control list (ACL) attached to an item (i.e., securable object) and to those child items inheriting their security scope from the parent item. When a child item's security scope is disinherited from its parent, a new security scope is created that bounds just that item and its child items, and so on. This SharePoint ACL can include all of the usual security principals associated with NTFS and it can also include SharePoint-specific security principals, such as SharePoint user groups. This enables access control to all resources in SharePoint in the same fashion that NTFS ACLs control access to network resources. Effective management of security scopes, through effective management of SharePoint user groups, their membership and permission assignments, helps prevent unauthorized access to content. Item ACLs remain attached no matter how that item may be presented to the user, whether in a list, in a web part, on a web page or even in search results. This ensures that content at any level will not be visible to the user if the user is not authorized to view that content.

A securable object in SharePoint is any item having a SharePoint-based ACL attached to it. In SharePoint, securable objects start at the site collection level and end at the list item level. A site collection is a securable object just as a list (or library) item is a securable object. Intermediate levels, such as sites, are also securable objects. Securable objects are integral components of the SharePoint-based security framework, along with SharePoint user groups and scopes. Securable object component of the SharePoint security framework helps meet the need of security external partner content by enabling administrators to control access to all sites and content within SharePoint down to individual items in lists and libraries.

The final key component that can help secure sensitive external partner content from corporate enterprise users is governance. A governance document can provide direction on how to administer user permissions in a way that minimizes the risks associated with mis-handling user permission assignments. A governance document can provide direction to users on how to effectively implement and manage content security in a way that minimizes risks. Governance also may involve the creation of a governance committee of stakeholders that routinely reviews any or all aspects of the SharePoint farm in order to ensure that effective security measures are implemented and diligently maintained. Governance is a key element in ensuring the need to secure sensitive external partner content, for the purposes of communicating security needs across the enterprise, providing quality assurance that security measures are being implemented and for providing direction on how security measures are to be implemented.

In summary, the best means for securing sensitive external partner content would be to deploy the enterprise SharePoint as a new farm. However this option is precluded by corporate direction. The next best means for meeting this need is to deploy the enterprise SharePoint as a new and dedicated web application on department ABC's existing SharePoint farm; and the web application should be provisioned to run within its own dedicated application pool under a dedicated service account. Other recommendations here include:

  • Deploying an AD DS nested user group strategy aligned with the corporate hierarchy
  • Employing SharePoint user groups to control access to SharePoint-based resources and populating those user groups with AD DS domain user groups
  • Provisioning separate Search and Managed Metadata service applications dedicated to enterprise content and connecting the enterprise web application to these instances and not to the existing Search and Managed Metadata service applications servicing external partner content web application
  • Drafting and implementing a governance strategy that provides direction on effective implementation of security measures and establishes a governance committee to provide quality assurance on security measure implementation.

Ownership and operation of legacy application site will be assumed by corporate

This need is driven by the direction of department ABC and the function of the application site, which serves the enterprise and not just department ABC's needs. Migrating this application site to corporate control is a logical need given its user base. The application site exists as a highly customized site collection, contained within the same content database containing the other site collections on department ABC's secondary, internal-facing web application. It sits on a wildcard inclusion managed path. Preparing this for migration would involve first moving the site collection into its own content database. Ownership and administration of the application site can be migrated to any one of the enterprise SharePoint systems discussed thus far, whether to a dedicated farm, a dedicated web application, or remaining as a site collection within the current web application that is hosting. In terms of administration, however, a reasonable case could be made for moving the legacy application site into the enterprise web application or into a separate enterprise farm. This would more clearly separate administrative boundaries. Since a separate farm is precluded by corporate direction, the best way of more clearly delineating the boundary between the legacy application site and department ABC administration would be to move the site into a dedicated enterprise web application.

Simplify user access administration

Meeting this need involves an integrated strategy composed of AD DS user groups, an AD DS nested user group strategy, SharePoint user groups and governance. User administration for the existing sites was generally accomplished using SharePoint user groups and assigning security principals to this groups. There were also many instances of security principals being assigned SharePoint permission levels directly. This approach is adequate when administering a few tens of users or even a hundred, but becomes impractical when needing to administer permissions for 1,500 users. Populating SharePoint user groups with AD DS domain groups greatly facilitates effective user administration. It ensures that the routine and constant user group and permission changes performed by systems administrators are instantly propagated to the access control of SharePoint-based resources. The current corporate AD DS user group strategy is resource-focused. This approach is adequate when access to resources is based upon membership in the organization only, but is inadequate when resource access must be further administered based upon sub-organizational membership and affiliations. In this case, SharePoint user administration is best accomplished when it can employ an AD DS nested user group strategy that is aligned with the organizational hierarchy. Another key component for meeting this need is governance. The overall approach needed to simplify user access administration needs to be documented and communicated across the enterprise so as to ensure consistent and effective implementation.

In summary, the best approach to resolving this need involves:

  • Deploying an AD DS nested user group strategy aligned with the corporate hierarchy
  • Assign resource access permission levels to SharePoint user groups and not to individual user account
  • Populate SharePoint user groups using AD DS user groups.
  • Document this user administration strategy in governance documents and communicate these to the enterprise

Minimize URL lengths

This need was derived from user interviews, which found that path-based URLs seemed more understandable and intuitive than host-named site collections. Path-based URLs to corporate sites was also identified as the de facto standard over the course of multiple Internet searches and reviews of corporate sites. This need could be met using the following features and methods:

  • Explicit inclusion paths
  • Acronym naming
  • Deactivate Minimal Download Strategy feature
  • Governance

Managed paths were deemed easier to maintain and modify than host-named site collection URLs, Explicit inclusion managed paths were chosen over wildcard inclusion managed paths in that it eliminated the additional wildcard name from the URL. The total number of corporate departments was significantly less than the recommended limit of 20 per web application. Managed paths would also be recommended if the dedicated web application approach to implementing the enterprise SharePoint would be used, since using different web application pools enables enhanced security.

Corporate department titles frequently involved three or four words, and the resulting acronym of each department title was found unique in every instance. Using department title acronyms ensured minimum department site URL length. Ensuring consistency among department site names and their associated content database names would help to ensure properly tracking site collections with the content databases that contain them. This would be a naming policy that would be recommended that the corporation would implement.

The Minimal Download Strategy feature, when activated, results in a URL that is less intuitive and lengthier. Deactivating this feature results in the URL appearing as expected and it eliminates the additional parameters tacked onto the URL and needed for implementing this feature.

Using short URLs is not just a technical issue but also a user task. URLs are built whenever administrators and users create sites and subsites, lists, libraries and folders. These might be created using entire titles and may include spaces, which are then URL encoded, making the URL difficult to understand by users. The use of nested folders in document libraries, along with title naming, can significantly complicate maintaining user-friendly and decipherable URLs. Resolving this is not a technical issue so much as a governance one. Effective URL naming methods and guidelines are communicated to administrators and users through governance, and URL naming would be one component of the customer governance portfolio.

In summary, this need can best be met by employing a strategy of using managed paths, department acronyms for site and content database naming, de-activating the minimal download strategy feature and defining and communicating a policy for minimizing URL lengths.

Communicate corporate site usage across the enterprise

Communicating corporate needs and guidelines to site collection administrators, site administrators, power users, developers and routine users falls into the area of governance. The customer did not have a governance program, and department ABC also did not have a governance program for its existing site. A governance program was drafted that included suggested guidance in the following general areas:

  • IT governance
  • Information management
  • Application management

The initial proposed governance team membership would be composed of the following:

  • Corporate leadership representatives
  • Department leadership representatives
  • Site collection administrators
  • Corporate and department QA representative
  • IT leads
  • Developer leads
  • Security leads

The initial proposed portfolio would be those needs discussed above that involved governance. The proposed governance method would be applicable to any of the proposed technical solutions.

In summary, this need can best be met by implementing a standard corporate governance system for the enterprise SharePoint comprised of a governance plan, governance standards and regular governance meetings of SharePoint stakeholders.

Needs Analysis Summary

Collating the analysis results into a matrix obtains the following:

Solution Development

Three general solution proposals were identified from the needs analysis, ranging from deploying the corporate SharePoint as subsites in a single site collection hosted on an existing department ABC web application to deploying the enterprise SharePoint as an entirely new farm. There were some minor variations among these three, but these were the primary ones. An additional aspect to all of these solutions was the recommendation that the corporate network team deploy a nested user group strategy to its Active Directory that was aligned with the corporate organizational hierarchy.

Proposal A: Minimal Separation

This proposed solution would not meet all needs but would engage some of them and would involve the minimum change to the originating department's existing SharePoint infrastructure.

 

Proposal B: Intermediate Separation

This proposed solution was the optimal solution that met most needs. It did not provide complete separation of department ABC SharePoint infrastructure from corporate SharePoint infrastructure, but meet the critical needs of consolidating department SharePoint instances across the enterprise while also using department ABC's SharePoint infrastructure as that infrastructure designated by corporate to be the enterprise SharePoint infrastructure and ensuring maximal separation of operations under these circumstances. This proposal was ultimately selected for implementation by the customer lead IT architect.

Proposal C: Full Separation

This proposed solution was the optimal solution that ensured full separation of operations. It met all needs except for the critical one, of corporate designating department ABC's SharePoint infrastructure as the corporate SharePoint infrastructure. It was provided to show the full range of possible solutions and where the optimal solution fit within that range.

Conclusion

This posting has presented a case frequently encountered in SharePoint deployments where an existing SharePoint farm is designated to be scaled from supporting department-level information management needs to supporting the information management needs of the enterprise. At a very high level, this posting presented some key customer needs and analyzed how they could be met. It did not engage in requirements analysis but limited solution analyzed and design to the needs level. A range of solutions meeting these needs in part or whole were developed and proposed, and then the solution best meeting customer needs was selected. All proposed solutions used native SharePoint and Active Directory features and capabilities. This posting was based upon a real-world example, and the best solution proposed here was the one that the lead customer architect in fact chose to implement.

Further Study

  • Systems engineering methods applied to SharePoint solution development can help organize the solution development process so that it is traceable, documented and repeatable. For example, during the process of listing out customer needs and then analyzing each one, it is quickly found that a SharePoint feature helping meet one need can also meet other needs. Putting these findings into a matrix helps to see patterns and simplifications in solution development.
  • This posting stopped at the needs level. A more formal solution development process would derive requirements from these needs, and these requirements would then become the contractual basis for the project. Rather than a needs matrix, instead there would be a requirements matrix.
  • tbd

References

Notes

  • IGDLA: Identities, Global groups, Domain local groups, and Access.
  • Developing a deep understanding of SharePoint features and capabilities is helpful in more readily identifying how customer needs and requirements can be met by SharePoint features and capabilities.