To drill down into the overall logical architecture of SharePoint 2013, the underlying technical components and features that factor into the design of SharePoint 2013’s Information Architecture are as listed here:
- Service applications
- Application pools
- Web applications
- Zone(s)
- Site collections
- Sites
- Lists and libraries
SharePoint 2013 allows for individual services to be configured and controlled at an extremely granular level. These “service applications” allow for key features and the resources they provide to be shared across a SharePoint farm and throughout sites.
The following is a list of the service applications in SharePoint 2013:
- Access Services Web Service Application
- App Management Service Application
- Business Data Connectivity Service Application
- Search Service Application
- Excel Services Application
- Managed Metadata Service
- PerformancePoint Service Application
- PowerPoint Conversion Service Application
- Secure Store Service Application
- Machine Translation Service
- Usage and Health Data Collection Service Application
- User Profile Service Application
- State Service
- Visio Graphics Service Application
- Security Token Service Application
- Application Discovery and Load Balancer Service Application
The image below provides an overview of SharePoint 2013’s service applications, as well as how they flow into the overall information architecture.
SharePoint 2013’s Application Pool and Web Application capabilities, as shown in the image below, have a different configuration model than those in previous versions of SharePoint.
In most cases, there should be one web application and one related zone. You also can utilize host-named site collections that have much improved scaling capabilities with reduced resource consumption.
If you are new to SharePoint, an application pool is a construct model used to gather or group web applications in a logical manner based on your organization-specific requirements such as performance needs and any security- or configuration-specific elements such as authentication.
Taking advantage of the host-named site collections option is recommended; that is the same architecture that Office 365 uses, so planning for any future possible hybrid architecture will reduce the need for future configuration changes, which can be costly and time consuming on both the IT side of the organization and the actual users of SharePoint.
There are always specific requirements that an organization may have that can cause you to go with a different configuration model, such as the need to enable apps in environments with multiple zones or the need to mix host-named site collections and path-based site collections.
The initial recommendation given previously should be followed in almost all cases, unless you have specific requirements such as those just named.
Service Applications
SharePoint Server 2013 has many powerful services, and these individual services, such as Excel Services, can be configured and activated independently. SharePoint Server 2013’s new services infrastructure design provides for granular control over which services are deployed and how services are shared.
These are technically referred to as service applications, which are really powerful resources that SharePoint allows you to share across sites throughout a SharePoint 2013 / Office 365 farm which users can access through a SharePoint hosting web application.
SharePoint 2013’s service applications are also associated with SharePoint’s web applications via service application connections. Not all services can be shared across a SharePoint farm but many of the most high-profile and powerful services do have this capability.
Web Applications & Performing Information Architecture (IA) Administrative Tasks
At the very core of SharePoint 2013/Office 365’s capabilities are the web applications, which are technically Internet Information Services (IIS) websites. This topic gets over complicated, along with site collections, on just about every SharePoint initiative, because there are core strategies to follow when creating these foundational components.
With the updates that Microsoft has released over the past six months and with new or upgraded features that may be released in the future, it is always recommended that you follow the latest instructions provided by Microsoft when performing critical functions such as creating web applications, new site collections, or other related IA tasks.
This is not a cause of concern or a statement that Microsoft is constantly changing frequent or fundamental architecture and administration tasks that you may perform on a weekly or monthly basis.
Rather, this is a practice that will ensure that you will always know that you have reviewed the published Microsoft steps so that you will have that added peace of mind.
Zones
Zones in SharePoint 2013 are representations of differing logical paths that are able to gain access to the same sites in a web application. Many different zones can be included within a web application.
As mentioned previously, in most cases there should be one web application and one related zone, and you can also utilize host-named site collections that have much improved scaling capabilities with reduced resource consumption.
SharePoint 2013’s security is one of a “claims-based authentication” first strategy, and this provides for many variables for not only user authentication but also specific app authentication and the new server-to-server authentication model.
Site Collections in SharePoint 2013 and Office 365 | SharePoint Online
SharePoint site collection capabilities have been updated in SharePoint 2013 / Office 365 / SharePoint Online and are the most common and important component in creating a best practices information architecture.
Site collections not only are a major configuration component that contain a group of SharePoint sites within them but also have a direct correlation to a person or number of persons who will end up supporting these specific sets of sites.
You will commonly hear the term “site collection owner.” This person has ownership and permissions to perform actions for all the users within this grouping or set number of sites that the collection falls under.
It is also key to understand the requirements of the site/sites within the site collection because when the site collection is created, it comes with a set of native features and functionalities that need to be specifically considered before its creation.
The web applications discussed previously are the actual hosts for a SharePoint site collection.
Web applications have the capability to host a large number of site collections, so the underlying requirements of the users and related content are key to architecting the correct number of site collections, as well as how they should be managed both near-term and longer-term.
Some SharePoint 2013/Office 365 initiatives may require only a limited number of site collections to be created, whereas others may have more granular requirements that call for a very defined set of site collections.
This also brings the underlying system architecture of SharePoint 2013/Office 365 into play here, because some site collections may be required to be created only in the organization’s SharePoint 2013 on-premises environment due to the nature of content (PII, PHI, HIPAA, and so on), whereas others may be able to be created in the cloud for sites that do not contain data with regulatory requirements or implications.
Architecting for Success Regarding URLs in SharePoint 2013 / Office 365 / SharePoint Online
The URLs (links) of site collections and the underlying sites created that are used to access SharePoint 2013/Office 365 sites are extremely simple to create from an administrator’s standpoint.
However, the architecture and planning of these links is key because the organization’s current and future requirements should always be accounted for as users frequently bookmark and embed links in documents.
The image below details an example of an organization’s SharePoint URLs for different types of sites as well as users:
