We all know that SharePoint is Microsoft’s fastest revenue
generating product in company history. Currently
80% of enterprises have bought it; Microsoft has more than 68,000 SharePoint
customers today. At Synesis IT, our Collaboration
service line is growing at the same pace. However, we are not planning for
business continuity and high availability for our clients during the planning
and sales stages and continue to ignore this aspect during development and
deployment of the solutions. Because of
this failure, SharePoint is not considered a Tier1 application in most companies.
SharePoint poses general challenges, such as:
·
Spread of environments
·
Inconsistent development
·
Different governance models
·
Poor operations management
First we need to change our own perception of the value of
this downtime. Think about high availability and business continuity
technologies to protect against outages.
We can incorporate load balance technology today to build our solution
for high availability, but forget to consider disaster recovery. Before we put a SharePoint environment into
production, very often we forget to test it against a number of simulated
situations, such as the following:
·
Failure of hardware components
·
Data corruption
·
Loss of a server
·
Network outage
·
Loss of data center
The penalty for failure is to have to re-seed the secondary
Web Front End (WFE) (re-starting from scratch) — a time-consuming process that
leaves the enterprise temporarily vulnerable to data loss and, potentially,
very unhappy customers. We need to remind
our customers during the beginning of our engagement that a business continuity
plan is as valuable as any other part of the SharePoint farm design.
Strict business continuity management constraints have low
RTO and RPO. RTO refers to Recovery Time Objective, or effectively the mean
time between failure and restoration of service on one or more sites. RPO
refers to Recovery Point Objective, or the amount of data (measured by time)
that can be acceptably lost (for example, 5 minutes). If we fail to do a business impact analysis
for SharePoint within our engagement model, we will fail to provide good value
of SharePoint service. Our customers’
organizations will be impacted by the lack of a suitable business continuity
management plan, and associated service level agreements (SLAs) for the
service. If you do not know the business importance of a service, or the costs
associated with outage and data loss, you cannot effectively define SLAs for
that service. These SLAs will not only define the agreements for recovery
objectives and service availability, they will often help determine what
backup, recovery, and availability solutions are required to meet them.
Moreover, they are likely to feed into other key design aspects for a
SharePoint deployment, ranging from storage planning to governance guidance for
the creation and deployment of customizations.
I hope no developer will use
SharePoint without first understanding the important people and business
considerations to every SharePoint-based solution. Let us all work together to stay alert while
making SharePoint a Tier1 application. We have to change our way of thinking
and realize that SharePoint should be considered as a service, but this can only happen if it first it becomes Tier 1. It
is imperative that our clients understand the value of having SharePoint as
Tier 1 for their Disaster Recovery and Business Continuity plans, and everybody
at any organizations should strive to reach this goal.