Sonny Mian describes a SharePoint CoE as "
In its simplest form a SharePoint CoE is a team of SharePoint experts which promotes collaboration and best practices around SharePoint to assist business adoption of SharePoint solutions by establishing and governing information architecture, defining platform strategy, addressing challenges and evolving SharePoint practice/development to economise delivery of SharePoint solutions while mitigating ever increasing security, privacy, regulatory and compliance risks.
A successful SharePoint CoE aims to ensure that it remains closely aligned with business strategy by managing SharePoint's Cost, Risk and Adoption."
My Answer: I guess it all comes down to what you need for your CoE, I see it as predominately a solutions mapping advisory service that maps solutions based on your Infrastructure. Customers bring an application in for review/suitability on SharePoint, the project/solution is verified for its suitability to SharePoint (on-premise or SharePoint 365), I get the high-level requirements and map each of these to a Work Breakdown Structure (WBS) and lastly do solution mapping. The solution mapping allows me to choose a suitable way to achieve the requirement. This will enable me to estimate the time for each piece of the solution mapping. It works well for creating your high-level design and estimating efforts/costs on a project. An added bonus is that external agencies/consultancies don't go out and over-engineer coded solutions that SharePoint can quickly achieve.
For me, CoE is for guidance, making sure all development and usage follow the SharePoint Governance document. This keeps the farm stable, reduces delivery time, improves service to the business, and the list goes on.
SharePoint governance should focus on the implementation of standards, roles and responsibilities, and processes to extract value from SharePoint data while managing risks, dealing with compliance requirements and keeping people and entity information secure.
CoE needs to be tied closely to your platform providers, i.e., infrastructure. You need to know what is available on your farms, capacity considerations, patches, and service running. This allows me to map solutions that are appropriate, given our capability, while maintaining the integrity of the farms.
Another nice benefit is that all code and architecture need to be reviewed and meet our CoE development standards. So, we minimise risk, as the architecture developed has to be approved, the code is checked, and it is pushed through the correct environments. Testing is required to move the application to the next environment.
The CoE should also speak to infrastructure to highlight missing features, potential changes to the service and review the architecture with the Infrastructure team. In my experience Infrastructure can get useful information from the CoE about forthcoming requirements that they need to respond to.
The CoE should also provide core coding libraries for code that is shared across custom-developed applications. The best example of this is a common logging block. In my CoE, we used Microsoft's SharePoint logging block and customised it for simplicity and uniform use. We also have a developer standards document that we require all developers to adhere to. Another core block is a configuration list used at a site collection level. This is like a property bag but can be edited using SharePoint as it goes to a SharePoint list. The list values are cached for 2 minutes to ensure optimum resource usage.
In large enterprises, the various business units benefit as the CoE provides concise advice, as generally seen before. The SMEs working on specific projects are aware of similar or reusable code. The CoE can also assist with vendor selection and building relationships with partners. This centralised pool of expertise also allows for providing expertise in more specific areas of SharePoint, such as search, workflows, or BI, which are good examples.
What Does the CoE SME need to know
- Farm(s) architecture
- Governance - What service is offered, and how is it offered via SharePoint
- Experience in building a wide range of technical solutions using OOTB features, SPD, InfoPath, PowerShell, Visual Studio, 3rd party software such as Nintex and web parts. This includes consulting, implementation
- Experience in integrating SharePoint with various technologies to build business solutions.
- Migration experience such as SP2007 upgrades, moving sites and content databases, migration tools such as Metalogix, Quest, AvePoint, the list goes on...
- Upgrading solutions - How to upgrading deployed solutions, how to install patch and service packs safely, change control in your DTAP environments.
- Good communication skills.
This list really does go on and it's hard to find the right candidates for a CoE but I think they key takeaway is you need good communicators to interact with each other, the business service divisions and the clients (projects requested).
Also See:
