Keys to the Design Process of SharePoint 2013's Underlying Technical Architecture
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
As a baseline, how do you currently protect sensitive and very important data that exists in your enterprise? It is important when developing compliance policies to actively look for ways to reduce any exposure risks that may exist. Depending on the size of your organization, you may have designated resources for litigation, eDiscovery, and maintaining your current “compliance status.” Small to mid-size businesses, though, will more than likely have resources that wear “many different hats,” and SharePoint Server 2013 will provide you with many industry-leading capabilities to manage compliance.
It is also important to ask questions of your organization, such as these:
- How does your organization quickly find information?
- How does your organization ensure policy consistency?
- How does your organization scale the compliance solution to the enterprise?
- What is the current strategy on cost control and information management or compliance?
As you consider the questions asked in the previous sections, also consider the following list of technical architecture design process points. This is a proven checklist of items that should be followed:
- Business requirements of the organization
- Functional requirements of the organization
- User experience and devices from which SharePoint 2013/Office 365 will be accessed
- Logical design
- Boundaries of SharePoint 2013/Office 365
- Information architecture design
- Technical architecture
- Define, iterate, and revise
- Outcome
- Server counts
- Database design
- Server roles
- Storage requirements
Ensure That You Start with What You Currently Know
Ensure that this process first takes into consideration the items that have already been uncovered and are known to the project team. These items also take into consideration any roadblocks or lessons learned that you may have gained from previous IT initiatives within your organization.
The following is a list of items you should consider that you may already have a good deal of insight into:
- Legal and compliance requirements
- Constraints
- Cost
- Data center utilization goals
- Evolving business needs
- Risks
- “Undersizing”
- “Oversizing”
- Unknown limits and workload patterns
Several factors influence an organization’s decision regarding which architecture (that is, on-premises private cloud, public cloud, or hybrid cloud) they are going to design and implement for their short-term and long-term SharePoint roadmap needs, such as these:
- The overall size of the organization and user base
- Security issues
- Legal and compliance issues
- Any project or deployment time constraints
- Complexity of customers’ current environment
- Physical locations
- Current identity infrastructure
- Current IT infrastructure model and future IT roadmap
- Network bandwidth issues
- Software/hardware issues
- Any vendor service level agreement (SLA)
- High-availability/backup issues
- Internal resource issues and related training
- Support alignment
- Service reporting
- Standards adoption and management
- Development alignment
- Infrastructure alignment
- Development platform management
- Governance
What Is a SharePoint “Private Cloud?”
To first describe and baseline a private cloud deployment, you should first understand the elements that will typically be considered and implemented.
When you host SharePoint as an infrastructure for a specific workload or combination of workloads, you must consider the following factors:
- Application platform for line-of-business (LOB) applications
- Business intelligence implementations
- Collaboration, community, and/or project sites
- Internet/intranet publishing portal
- Personal sites
- Enterprise search
But Should I Prepare for a Hybrid SharePoint Platform?
Obvious differences exist between SharePoint 2013 on-premises (private cloud) and hosted (public cloud), as well as a hybrid SharePoint 2013 deployment, which allows for a middle ground for you to tailor based on specific requirements, concerns, security requirements, and custom development strategies.
There is an inherent trade-off between complete control of your SharePoint environment and customization strategy and a managed service or SLA that you will adhere to for your environment.
As detailed in the preceding section, major considerations must be vetted by both the business and technology sides of the company and the review of content or intellectual property and even governing laws at a state, province, or country level. There are also considerations related to business intelligence and the organization’s requirements to connect to other LOB systems and how the cloud or hybrid cloud may affect or work with this other data and related permission strategies.
Nine key architectural areas should be considered within a SharePoint 2013 deployment:
- Deployment architecture
- Network architecture
- Infrastructure and server architecture
- Permission architecture
- Cloud architecture
- Software architecture
- Business architecture
- Data architecture
- Information architecture
A hybrid SharePoint 2013 environment enables your organization to be flexible and provide for the capability to store sensitive and highly confidential content on-premise within your own data center while storing collaboration or non-sensitive data within a public cloud such as Office 365, Microsoft Azure, or AWS. The issues that have continued to compile in the news with the NSA’s IT administrator Edward Snowden’s leakage of classified data has undoubtedly hurt the reputation of the public cloud. The NSA’s PRISM data mining program has also piled on concerns around organization’s asking itself, “How safe is the cloud?”
One of the largest impacts that EPC Group has seen around this issue has been with some clients or potential clients who have offices in the EU and whose executive management or IT leaders have absolutely refused to store data within cloud storage facilities based within the U.S. This is another key reason I believe that the hybrid cloud model will continue to take hold as it gives organization’s options around where specific types of data are stored while still giving them secure “identify management” options to access it in a seamless manner.
SharePoint 2013/Office 365 hybrid deployments also provide organizations with robust options for business intelligence (BI) initiatives, because the private side of the hybrid cloud will more than likely already exist on the company’s network in its Active Directory (AD) forest, which will allow BI initiatives to securely access other line-of-business (LOB) systems within the organization. Office 365’s Power BI capabilities also allow cloud-based data the analytical and robust reporting required which can be seamlessly federated via Azure Active Directory, a REST-based (REpresentational State Transfer) service that provides identity management, to your on-premises data to allow you to architect and tailor the security model that will work best for your organization.
One major concern of organizations in past releases of SharePoint was how some “Test” or “Development” environments that were not properly implemented, that were not backed up or under the organization’s disaster recovery strategy, or that duplicated the effort of the organization’s central SharePoint deployment quickly became a “Production”-like environment.
In SharePoint 2010, 2007, or 2003 implementations, there is concern about the risk that these types of environments (that is, Development environments that quickly became a SharePoint production environment with a great deal of content) can bring when they are not following the company’s overall IT strategy, SharePoint roadmap, and governance policies, and are causing additional effort, risk, and concern about document security.
At the very beginning of your organization’s SharePoint 2013 initiative, a company-wide SharePoint Governance and Communication strategy message must be established and communicated to all team members, both non-IT and IT, because an employee or team member who would like a place to store and access content without going through the proper channels can establish an unapproved SharePoint site by sending an email or placing a phone call to a very long list of hosting providers.
This user who may not know or understand the organization’s SharePoint roadmap and/or governance strategy could unknowingly be putting the organization at great risk in a number of areas. This team member may not understand the implications of storing data in an environment that he or she knows little or nothing about.
This is a key reason that preparing this strategy and a SharePoint hybrid-capable type of corporate communication message can be extremely valuable without ruling out possible hybrid needs of future projects, vendors, and so forth.
Understanding SharePoint 2013’s System Architecture
SharePoint implementations can be best approached by categorizing the underlying servers and hardware regardless of virtual versus physical, by categorizing the system architecture to cover these underlying components. The SharePoint system architecture roadmap components must be developed by the business and functional requirements of the information architecture, which contains the planning for sites, document libraries, and ultimately the content.
SharePoint 2013’s underlying system architecture must take into consideration the needs of the organization in terms of metrics such as these:
- Number of SharePoint users as well as any possible future estimates if expansion is on the horizon
- Amount of content to be stored by individual departments, business units, and users
- Size of that content and considerations for large files such as CAD drawings or media files such as large videos
- Performance requirements of these users, as well as their location
- Number of data centers and their locations
- Onsite deployment, cloud deployment, or hybrid (mixture of both onsite and cloud)
- Immediate requirements of the business (that is, company intranet), as well as longer-term requirements (that is, business intelligence and analytical SharePoint service) that may require security around federation or other access needs
- Disaster recovery strategies
- Network security, Active Directory, performance, acceleration needs, and so on
- Development environment and related Visual Studio/Team Foundation Server (TFS) strategy