Evo conf - Designing SharePoint Solutions

1. Designing SharePoint Solutions - An introduction to your SharePoint team Business Track Mark Stokes

2.  Mark Stokes, MVP  Red Plane Ltd  http://www.redplane.co.uk  Mark.stokes@redplane.co.uk  @MarkStokes  SharePoint User Group North West Leader

3. Agenda  An overview of your SharePoint Team / CoE  Project Types  Designing SharePoint Solutions

4. SharePoint Team IT Leadership Team SharePoint CoE IT Change Management Project Management Office SharePoint Farm SharePoint Users Business Partners Interfaceto SharePoint CoE Project Request / Management Assign Resources Uses SharePoint (BAU) Non CC Changes CC Changes Training and InternalComms Projects Team Project Managers BAs IT Contacts SharePoint Governance Board Technical Teams SMEs IAs AD Lead SME Lead Dev AM Feedback Business Community Activation CommsTraining Feedback IT First Line Support Support Request IT Second Line Support Escalation SharePoint Platform Team IT Pro Platform Architect(s)

5. IT Leadership Team  Sets Global IT / SharePoint Strategy  Improve Collaboration across the business  Connect with Suppliers  Provide effective people / skills search  Approves / Provides funding for platform  Must be an Authority  Provides authority to CoE

7. SharePoint Platform Team  Manages the SharePoint Infrastructure  Provides a platform suitable to support business project requirements  Ensures stability of platform  Backup / restores / DR  Server Patching  All Platform Updates must be run through Change Management

9. SharePoint COE  SharePoint Governance Board  General SharePoint CoE Management  Aligns CoE tasks to Leadership missions  Feeds back progress to the Leadership team  Escalation point for business  Project Management Office  Business Partners request projects on behalf of the business users  PMO evaluates and triages all project requests  PMO allocates CoE resources to work on the project  PMO provides Project Management processes and monitors project status

10. SharePoint CoE  Projects Team  Non-technical teams to provide PM work  Project Managers  Business Analysts  Access to technical teams for assistance

11. SharePoint COE  Technical Teams  Lead Subject Matter Expert (SME)  SMEs  Implementation Analysts (IAs)  Application Development  Application Maintenance  Activation  Communications  Training

13. IT Change Management  Provides a Quality Gate before anything is deployed to SharePoint  Governance needs to define what goes through Change Control and what doesn’t  Provide evidence of:  Risk / Mitigation  Testing on previous environments  Rollback procedures (tested!)  Etc.

15. SharePoint Users  End Users  They are important!  Remember them  Help them  Business Partners  Represent the business users to the CoE and vice versa.  Project Management roles on the business side.  Business Community  Feedback loop for the user experiences, thoughts, requests, etc.

17. Support  First Line  Second Line

19. Project Types  Platform / Programme Projects  Projects funded by the central SharePoint budget  Aims to improve the services available to the business – Such as Branding, Search, User Profiles, etc  Global information Architecture – Content Types / Managed Metadata  Business Projects  Projects requested / funded by the business  Solve specific business requirements

20. Designing SharePoint Solutions  Business Requirements  SME Review  Conceptual Design  Solution Design

21. Business Requirements  Make sure you understand the problem  Ignore the customers attempts to "talk SharePoint"  Hold a face-to-face conversation / workshop where they present their requirements to you  You will get to see a lot of thought process that they went through to get to the documented features…  You can learn "a lot" about what they want and their priorities  Question them…. Play the Devils Advocate  Make it clear you are doing this and not just being a pretentious know-it all!

22. SME Review  Provide a quick 1 or 2 page summary of the project  Is it possible?  Is SharePoint the right / appropriate tool?  Expected project size, complexity and cost  napkin quote 100% margin for error  Highlight obvious Project Risks  Is it likely to have “customisation” (development) elements?  Is it likely to require platform configuration elements?

23. Conceptual Design  Mock up the project from the customers perspective  Identify the “Questions” that are being asked of the content  Don’t worry about “how” you will architect it at this point  Work with the customer to ensure it’s what they envisioned  It’s very difficult to go back and re-architect a complex SharePoint Solution once it has been developed  But if you get your IA right (or close) then it can be less of a headache!

24. Solution Design  KISS – Keep It Simple Stupid  Start with the most simple solution  Single SharePoint Site  Single Document Library / List  No Customisations  No deployments (means no scary change control)  Only add complexity because you HAVE to  Only write code because you HAVE to

25. Why do we add complexity?  Volume of content  Content DB Limits  Logical break up of content  E.g. a separate sub site per project  Complex audiences / permissions  Need functionality not provided by the core product  Build vs Buy?  Sometimes adding complexity adds simplicity to our design

26. Where do we add complexity? Content / Nav  Multiple Document Libraries / Lists  Content Types / Managed Metadata  Multiple Sites in a Site Collection  Multiple Site Collections  Search-based queries  Multiple Web Applications  Multiple Farms  External Systems / BCS Customisations  OOTB  SharePoint Designer  Custom Code

27. Breaking Permission Inheritance  This is generally a bad idea!  It can be difficult to see / have confidence in who can see what  SharePoint has certain boundaries that cause “funny things” to happen when too many customer permissions are in place.  Only break permission inheritance when you need to  Break permission inheritance at the highest level possible  Site Collection  Sub Site  Document Library / List  Folder (yes they are not evil and have valid uses!)  Document – avoid at all costs!

28. Writing Code in SharePoint  Poor quality code is one of the most common problems with SharePoint performance  Customisations can be the biggest, most time consuming and expensive part of a upgrade project  Microsoft is moving all custom code off-SharePoint  You also have to manage the servers that host the external code  Development models and practices have changed substantially between versions  And are still in a major state of flux  Types of Customisation  Server Side – Full Trust  Sandboxed Solutions – Deprecated  Client Side – CSOM / JSOM / REST  Azure hosted – E.g. Remote Event Receivers  SharePoint App Model – SharePoint Hosted – Autohosted Apps – Deprecated – Provider Hosted

29. Putting it all together  Designing SharePoint Solutions is an iterative process.  Start as simple as possible then…  Keep adding complexity until your solution works and is scalable  Do as little work as possible to deliver the project  Less complexity is easier to manage / upgrade  The less custom code the less to go wrong / support / upgrade

30. Thank you for attending!

Evo conf - Designing SharePoint Solutions

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Evo conf - Designing SharePoint Solutions

Ähnlich wie Evo conf - Designing SharePoint Solutions (20)

Mehr von Mark Stokes

Mehr von Mark Stokes (9)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Evo conf - Designing SharePoint Solutions