Am working on my forthcoming book concerning the delivery of user adoption and platform governance, and thought that I would share a summarised section which concerns the creation of SharePoint support. a crucial area that relates to how SharePoint services will be managed.
Nb. Am also working on an article which goes into further detail looking at SharePoint support and what are the necessary items to put in place to guarantee success (rather like my Ten Steps for SharePoint implementation article :D). This will be available soon…
Please read on though – hope the summary is useful!
The complexity of the SharePoint platform being implemented is directly related to the resources available and needed to effectively support them. For example, the support arrangements for single server environment with search services enabled only is nowhere near the same as a multi homed SharePoint environment utilising business a myriad of application services, judge the kind of resources needed to manage and support these services.
Building support services is like building a foundation of a house. If you are about to buy a house then the first thing you would do is carry out a structural review. You do this because you don’t want the risk of buying a house which is about to come crumbling down.
Likewise, if you are about to build a new house then you want proper foundations to ensure that anything you add on the house can be factored in, of course without compromising on its structure.
Henceforth, there is no difference in the practice of building SharePoint support services. It is crucial that an understanding of the how the foundations of SharePoint support is going to be designed is done. The following is a non-exhaustive list of the areas that need to be reviewed if you want to start building support services for an existing SharePoint environment. If you are doing this from scratch, then the following list is again relevant.
- List each of the servers on a per farm based; for example, production, pre-production (stage/UAT), development, test, engineering (lab) etc.
- List solutions and services assigned to the farm. These will include those which are (a) supplied internally (b) supplied by third party (c) included with the farm (for example, search services may have been split into several servers in the farm(s) )
- List connected components (e.g. external databases, connected web services) that are integrated.
- List in detail the externally connected monitoring systems; for example, SCOM, Nabel, etc.
- List client applications that are being used with SharePoint by information workers (for example, Microsoft Office – list the products, and browsers being used, like Internet Explorer, Firefox, Chrome etc).
- List any plans to procure, produce and/or implement any additional component which has the capability of being implemented with SharePoint.
- Be aware of the regional splits in your SharePoint environment; if you have multiple implementations of SharePoint in different regions, detail those and who are responsible for those.
- List teams responsible for the connected infrastructure. This relates to those organizations which have split support teams based on specific areas of technology. For example, your organization might have a network team responsible for platform engineering, storage engineering, etc. There might be a separated SQL database team, a separated E-mail team, even a separated disk storage team. All of these are crucial for SharePoint since SharePoint will be directly dependant on those components.
Importantly, consider an infrastructure diagram of the SharePoint environment as being useful; since (a) that shows the true nature of the SharePoint environment, (b) that it will educate the evolving SharePoint team and most importantly (c) shows to all that SharePoint is a ‘service’ of equipment, components and resources. This infrastructure diagram should be classed as a working document and regularly updated with any changes to the environment in any of the above areas. Make sure that when you do this include buyin from associated technical teams since then you and they can benefit from the knowledge!
