SharePoint is a platform that I have found to be surrounded by a lot of misconception. Many people assume as it is a web site therefore should be managed by the web team. Others see it consuming database storage and thus to be managed by the SQL team. Others see that is platform to be developed against, and thus managed by the development team. The truth is SharePoint is all three, it’s a web site/service with a SQL backend which I highly customizable. Therefore it is important to get an understanding as to what are the roles and responsibilities to manage a SharePoint environment. The following is for roles and responsibilities that are required for both on premises and Azure Infrastructure as a Service (IaaS).
The server administrator is responsible for providing the core resources required for the running of the server. They will manage the CPU, Disk and Memory allocation. It is important that for any changes to requirements they are informed ahead of time so that they can play resource allocation for any given service/component. SharePoint system requirements change between versions and a common mistake is using the same hardware requirements form an old version of SharePoint on the new servers. You can find the latest hardware requirements here.
The network admin is responsible for ensuring the data gets across the network in the most optimized manner possible. They usually also manage the network load balancers which is used to balance traffic between SharePoint web frontends. Therefore any changes to the web frontends, roles or services on those severs need to notify the network admin so that they can ensure traffic is routed accordingly. Also they would be responsible to ensure internet traffic to servers are routed correctly and meet security requirements such as proxy and firewall configuration. SharePoint has a number of ports required to be open these can be found here.
Whilst SharePoint runs on SQL Server it does not use the good practises for SQL Server, but rather has its own good practice guide. It is paramount that SQL is configured accordingly to ensure good performance and reliability of the backend. As SharePoint uses SQL not only for storage but also processing some queries and thus an optimised backend will lead to performance gains. For a view on SQL databases maintenance for SharePoint I recommend the following articles:
Storage and SQL Server capacity planning and configuration http://technet.microsoft.com/en-us/library/cc298801.aspx
Plan for site maintenance and management in SharePoint 2013 http://technet.microsoft.com/en-us/library/cc262509.aspx
Reorganize and Rebuild Indexes http://msdn.microsoft.com/en-us/library/ms189858.aspx
How to defragment SharePoint http://blogs.technet.com/b/patrick_heyde/archive/2009/03/31/how-to-defragment-sharepoint-databases.aspx
Database maintenance for SharePoint 2010 Products http://technet.microsoft.com/en-us/library/cc262731
This is a role that is the least defined and in my experience varies from customer to customer. In some instances the SharePoint admin maintains full control of every aspect of Sharepoint dependencies including Active Directory, SQL and SharePoint. Whilst in other cases the SharePoint admin only has control of Central Administration with the server lockdown for complete minimum server requirements i.e. not Local Admin. However what they all have in common is the ability to manage SharePoint. On a daily basis the SharePoint Admin should be aware of:
- Consumption of Resources on SharePoint Server (CPU, Disk, Memory)
- Availability of Sites and Service Applications
- Errors in the Event Logs
- Status of SharePoint Health Analyzer
- Status of Service Applications
- SharePoint Backups
Fortunately all of the above can be monitored with tools such as Microsoft System Center Operations Manager. The benefit of using System Center Operations Manager is that Microsoft have a management pack to monitor SharePoint. However always ensure that these are tuned to meet your organizational SLAs.
The SharePoint administrator is also be responsible for the management of the Service Applications in SharePoint such as Search, User Profile Service, Managed Metadata Service etc. Whilst many of the service applications are setup once, they still needed to be managed and maintained to ensure a good level of system performance.
The SharePoint administrator is also responsible for applying updates to SharePoint such as Service Packs and Cumulative Updates. This will be arranged through change management as it will require down time.
The developer for SharePoint is a broad spectrum as they can be a web designer in configuring the look and feel of a SharePoint site. A .Net developer extended the capabilities of SharePoint with farm based and sandbox solutions (sandbox solutions have been marked as deprecated). To a Linux, Apache, MySQL, PHP (LAMP) developer who creates a separate web service but then connects to the SharePoint API using all or some of the following OAuth, OData and REST.
Whilst the technology or tools that the developer uses are different one thing is important, the developer must have an understanding of how SharePoint works. SharePoint also has good practices when it comes to development and how objects are to be called, used and disposed is important in terms of management of resources. There are tools available to help ensure code meets requirements for good codding practice for SharePoint Microsoft Code Analysis Framework, you can also look at SharePoint Code Analysis framework which gives a more in depth analysis of your code for the Office 365 and On-Premises. However these tools will only validate coding practices and not whether the code itself is malicious. The deployment of the code must go through change management so that the changes are tracked and recorded. Also any changes that make changes to the web.config will result in an Application Pool recycle which disrupts the service.
Site Collection Administrators
The site collection administrator is a person who manages a site collection and all of the sub-sites within that collection. There is a misconception that a SharePoint Admin and a Site Collection admin are the same. Whilst in some unique cases this is true, in most cases this is not. The purpose of a Site Collection admin is to delegate the management of a site or group of sites to people who better understand the need and requirement of a site. This helps empower workgroups to have more control over their web sites and less reliant on core IT services. It is paramount that multiple Site Collection Administrators are setup to provide cover so that management of sites can continue in the absence of the main site collection administrator. This role remains pivotal both on Premises and in Office 365.
The assets stored in SharePoint can be from just personal documents stored in OneDrive for Business to entire corporate documentation. Therefore it is important that the data is classified, and architected as to how the document is to be stored, when to be archived/disposed. Also the information architect can provide some insights on how long backups are to be retained depending on legislation. It is important that the Information Architect and the SharePoint Administrator establish a relationship as a SharePoint admin can better plan storage requirements when they are away of the documentation plans of the organisation, and the information architect can be sure that when their proposals are rolled out the infrastructure is in place to accommodate the workload.
The technical architect will usually design the solution whether it be intranet, internet and/or document collaboration. The technical architect usually has the outline of what is the purpose of the system and the vision of how it is to be used. Therefore it is important that their vision is aligned to the Information Architect data requirements, as well as the Infrastructure requirements with regards to scaling to accommodate the load of the requirements.
The governance team should be the glue between the different roles and responsibilities ensuring that each role has the required information they need in order to complete their role. As can be seen by the brief description of roles, all roles have dependencies on other roles.