Close this search box.

Building a Best Practices Information Architecture for SharePoint 2013 and Office 365

EPC Group approaches the architecture and design of SharePoint 2013 and/or Office 365’s Information Architecture (IA) using a the three-prong approach that provides placeholders for the requirements that must be documented but also sets expectations for the SharePoint project team to design an IA that is scalable and has organization’s long-term SharePoint roadmap in mind.

The Context, Users, and Content approach to the information architecture design, as mentioned above, is meant to instill a 360 degree view of the overall project goals and future business needs as well as the other “moving pieces” within the organization that are not typically taken into consideration. It is extremely important to think of not only what content is going to be created and where it is going to be stored but how it is going to be viewed. The image below shows an overview of SharePoint 2013’s content from both an authoring perspective as well as how users access it and some of the devices and their properties they may utilize.

Note: This image show an overview of how users may access content and details regarding the user experiences and limitations on some popular devices that must be planned for in the design.

Based on the availability of the stakeholders or team members within the organization for which you may need to facilitate meetings and gather specific information, it is a best practices approach to first start with a more broad set of questions in these initial sessions.

Initial Questions You Must Ask

What currently exists? The following questions can assist you with finding your initial IA baseline:

  • What content management, content storage systems, or technologies currently exist within the organization?
  • Do you need to take into consideration any previous versions of SharePoint that may exists?
  • Does your organization have a complex or even massive file share environment in place?
  • Is there an existing intranet with documents or static content that will need to be analyzed and considered? If so, who owns or updates this content?
  • What does your organization consider to be a record?
  • Is there a retention policy or schedule in place from your legal or compliance department?
  • Are there environmental considerations such as both a “private cloud” (on-premises) as well as a “public cloud” (hosted Office 365) that may have separate IA requirements or hybrid architecture considerations?
  • Are there any globally specific regulations such as those in the European Union (EU)? If so, some social features and components as well as their specific fields may need to be excluded within SharePoint Governance model and vetted by the legal and compliance stakeholders.

Some of these questions can be political landmines that you may need to carefully step around while also ensuring the right audiences or stakeholders are included and briefed on the SharePoint effort so that they have a communication channel into at least part of the decision making process. Do not bring a blank piece of paper to the meeting and just ask them, “What do you need and how do you want it?”

Information Architecture Requirements Gathering Sessions

You must be prepared in every SharePoint information gathering session with questions, topics, and agenda items that are relevant to the audience you are interviewing. You must have a solid idea of your baseline requirements as well as how those baseline requirements play into the phase or even multiple parallel phases you are addressing while always keeping the long-term roadmap in mind.

There are also specific regulatory considerations, laws, and industry specific questions that must be considered because if they are ignored the organization may be open to litigation or penalties. The following questions should be asked and considered around any data being stored within SharePoint:

Sensitive But Unclassified (SBU) Information

  • SBU information is any information, the loss, misuse, or modification of which, or unauthorized access to, could adversely affect the national interest or the conduct of Federal programs, or the privacy to which individuals are entitled under the Privacy Act, but which has not been specifically authorized under criteria established by an executive order or an act of Congress to be kept secret in the interest of national defense or foreign policy.

PII – Personally Identifiable Information (PII)

  • PII is information that can be used to uniquely identify, contact, or locate a single person or can be used with other sources to uniquely identify a single individual.
  • Sensitive PII
  • Sensitive PII is a combination of PII elements, which if lost, compromised, or disclosed without authorization could be used to inflict substantial harm, embarrassment, inconvenience, or unfairness to an individual.

Examples of Sensative PII Data

  • a social security number by itself, or
  • an individual’s first name or first initial and last name in combinationwith any one or more types of the following information, including, but not limited to:
  • social security number
  • passport number
  • credit card number
  • home telephone number
  • personal cell phone number
  • clearances
  • bank numbers
  • date and place of birth
  • mother’s maiden name
  • financial records, etc.

Note: This information may be in the form of paper, electronic, or any other media format.

  • PII is information that can be used to uniquely identify, contact, or locate a single person or can be used with other sources to uniquely identify a single individual.

Protected Health information (PHI)

PHI is any information about health status, provision of health care, or payment for health care that can be linked to a specific individual. Under the US Health Insurance Portability and Accountability Act (HIPAA), PHI that is linked based on the following list of 18 identifiers must be treated with special care:

  • Names
  • Dates (other than year) directly related to an individual
  • Phone numbers
  • Fax numbers
  • Email addresses
  • Social Security numbers
  • Medical record numbers
  • Health insurance beneficiary numbers
  • Account numbers
  • Certificate/license numbers
  • Vehicle identifiers and serial numbers, including license plate numbers;
  • Device identifiers and serial numbers;
  • Web Uniform Resource Locators (URLs)
  • Internet Protocol (IP) address numbers
  • Biometric identifiers, including finger, retinal and voice prints
  • Full face photographic images and any comparable images
  • Any other unique identifying number, characteristic, or code except the unique code assigned by the investigator to code the data

Who are the individuals that will be able to provide you with insight into what content exists and who may own or access this content? As the requirements gathering sessions progress you may find that there are multiple version of documents stored in several locations but ensure you are working toward an IA design that will provide a “one version of the truth” principle to eliminate duplicate content that can lead to inaccurate reporting and metrics.

You may experience team members that are “content hoarders” in some departments, divisions, or business units that will push back on your requests and may not provide you exactly what you are wanting in initial sessions.

These types of issues must be identified, addressed, and resolved. These individuals must be approached by either a manager or stakeholder that can provide them with an enforceable directive to ensure their participation and assistance with the content identification and clarifications specific to their area of the IA design.

Note: It is very important to keep in mind that your analysis and efforts around the design of SharePoint 2013’s IA is one of the more difficult and tedious processes within the overall implementation. The identification and content analysis effort you are performing is more than likely a task that has been put off by the organization for many years. If it was easy, anyone could do it but it is not, and you must remain focused and consistent in your effort as consistency is key!

Planning For Future Content Growth

There may be questions around content and how it’s used that may not be able to be answered until a future phase or other external business decision is made which may cause you and the project team concern. There is no way to control these issues that are out of your hands and it may affect the IA.

In these cases you need to follow the most scalable model that will allow the IA to meet current requirements as well as those on the future roadmap that you have been able to identify.

Once you have identified the key users and stakeholders that have the in-depth knowledge of the content in a given area or department you should also consider that user or stakeholder to be a future SharePoint Power Users or Content Owner as this will ease the transition over to the new platform.

It will be very beneficial for you to document their input carefully and under no circumstances put the content and/or documents that are required for this user or set of users to do their job in a “migration” holding pattern or somehow affect the permission and access to the content.

Note: All business or mission critical content must be identified and these types of users, the ones who really understand the content in their department or given “area,” can help you ensure this content is approached with extreme care and consideration.

  • The question of “what is a record” in your organization is typically defined by managers and those organizations that are larger in nature may have a “records manager” or “compliance officer” who can help you make huge strides towards your goals.
  • These managers or officers can help you understand what the key underlying records are to the organization. In many organizations, the retention schedule or related “company enterprise content management initiative” may not yet have all of these spelled out in a manner for which you can immediately use but this is where you can start to see how the IA will scale and identify some timelines around when this information can be provided or when it may be available.

The information architecture design and related analysis you perform will be the driving factor around areas such as site structure and the services and functionality provided by SharePoint 2013.

Whether your organization’s SharePoint 2013 implementation should be departmentally structured and follow closely to the company’s organizational chart or should have a functional hierarchy based around the major functionalities of business units and their related divisions should be determined once you fully understand the options SharePoint 2013 provides to you and your team. Traning becomes crucial in these cases.

The Technical Side of the Information Architecture Design

The technical side of the design of SharePoint’s IA can be confusing to non-technical project team members or content owners so it’s important to keep your audience in mind when discussing certain components and technical terms.

If you walk into a meeting with content owners or a records manager without SharePoint technical knowledge, you will lose their attention and interest very quickly if you jump right into a conversation about site collections and web applications. It is your job to take the “business speak” and turn it into “technical speak” in defining your requirements.

This “technical business analyst” type approach will make your discussions with the business much more productive and will require some preparation prior to the actual meeting(s). Have a defined plan and approach with questions specific and meaningful to that particular stakeholder, department, or set of users ready prior to engaging with them.

Understanding SharePoint 2013’s Logical Architecture

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 IA are as follows:

  • Service Applications
  • Application Pools
  • Web Applications
  • Zone(s)
  • Site Collections
  • Sites
  • Lists & 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 for which they provide to be shared across a SharePoint farm and throughout sites. The following is a list of the service application 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.

Detailed overview showing SharePoint 2013’s information architecture flow and structure

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 as 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 as well as 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 those that require mixing host-named site collections and path-based site collections. The initial recommendation above thou should be followed in almost all cases unless you have specific requirements such as those I just named.

A diagram of SharePoint 2013’s Web Applications showing an example of a best practices configuration

EPC Group’s Information Architecture (IA) Design “From the Trenches”

EPC Group will continue to build on this topic throughout this the weeks to come and share additional posts around SharePoint 2013 | Office 365’s SharePoint Online Information Architecture Design considerations as well as how this design ties into the underlying system architecture of SharePoint 2013, Office 365 and/or SharePoint Online.

Errin OConnor

Errin OConnor

With over 25 years of experience in Information Technology and Management Consulting, Errin O’Connor has led hundreds of large-scale enterprise implementations from Business Intelligence, Power BI, Office 365, SharePoint, Exchange, IT Security, Azure and Hybrid Cloud efforts for over 165 Fortune 500 companies.

Let's Get to Work Together!

Talk to our Microsoft Gold Certified Consultants