Microsoft Learn company training plans is worth a look

Overview: Microsoft Learn has a nice feature to ensure users are trained on MS technologies. You can create collections of learning resources and add these to plans. Then, specify who should do the training and record the progress.

An example of a plan for new joiners to ensure they are skilled.

Thoughts: I like this tool as you can create a set of courses for users to attend, and it tracks their completion/progress.  For instance, in a Centre of Excellence, users are expected to have completed some training before being given access to a Power Platform Dev environment.

I have not been able to add my own company's content, so I may have a recording of governance and standards for an environment that devs need to be aware of. I'd like the ability to add wikis or mp4s that users watch and then accept they have completed. It may be there, but I can't find it. Also, the portal's branding should allow enterprises to add their own logos. This would be a great Learning Management System (LMS) with customised content.

Low code CoE thoughts

Key areas to address for a Low Code CoE:

1. Portfolio of Products
2. People/Skills/Experts
3. Process/ALM
4. Platform/Governance/Cleanup/Architecture/NFR's (scalability, SLAs)
5. Promotion/delivery/training

Consider putting the project through a Business case validation, particularly for larger projects.  The business case is how your business visualises and communicates a proposed project, which should continuously be refined.  Points to cover:

1. Business Case (Idea)
2. Customer Segment >
3. Value Proposition (what do they get) > 
4. Channels (API, website, AI Services, .. ) Customer Achievement (get and retain) >
5. Revenue (how to make money)
6. Key Resources (patches, maintenance) covers technology and data.  What tech, people need to build and continue delivering.  Data: where does it come from, quality, restrictions, relevancy.
7. Partners (dependency e.g. AWS, Azure, Mendix, OutSystems, UiPath, Microsoft, and backup options)
8. Cost breakdown

CoE needs to clearly understand its boundaries and responsibilities.  

I am a big fan of Total Ownership, clear requirements and goals, using RACI, and stand-ups. For the rest, I try to be agile and malleable. Big projects require more oversight and planning, so I allow teams to change and focus on delivery.  

Consultant Bingo - A master class

I love a useless term to baffle the room as much as the next fellow, but watching a master in a meeting today:

STRIDE Model is Microsoft's Security/Threat classification model.  I had to look it up and found another acronym.  STRIDE is for Threat modelling as part of risk management.  Acronym for: 

1. Spoofing a server
2. Tampering a file
3. Interlude: Scope and timing
4. Reputing an order
5. Information Disclosure
6. Denial of Service
7. Elevation of Privilege's

The DREAD Model is pretty much the same as STRIDE.

CIS framework or MITRE framework—a Security framework for benchmarking. It is closely related to the SOC (Security Operation Centre).

'RESPECT' for: "I evaluated my DTAP environments cross Federation services using the STRIDE model over the DREAD model because it is simpler.  Of course, all the cross-cutting concerns have been dealt with." 

Three Amigos—Backlog review: The PO, SM, and Team members meet to discuss design, development, and testing.

YAGNI is an XP principle: "You Aren't Gonna Need It." This principle basically means only creating code for requirements, not what you feel may be needed later on.  

Pareto Rule - roughly 80% of consequences come from 20% of the causes.  Or 80% of outputs come from 20% of inputs.  So 80% of the revenue may come from 20% of your clients.  Also referred to as the 80-20 rule. The same principle applies to the 90-10 rule.  Pareto analysis 80% of a project's benefits can be achieved by doing the correct 20% of the work.

Rindelmann Effect - Individual members become less effective as the size of the group grows.  I opt for small, focused teams even for large programmes as more people do not equal more technology delivery. 

A hockey stick pattern is a chart pattern that shows a rapid increase after relative stability.  For example, pizza sales might drastically increase when a pandemic strikes as people no longer go out to eat and tend to order more delivery pizza.

GIGO - Garbage In Garbage Out.  It is the same idea as FIFO or LIFO.  

WSJF (Weighted Shortest Job First) is a technique for prioritizing tasks in the scale-able Agile Framework (SAFe). It is pronounced "Wiz-jiff." I'm not a fan of this technique.

The CIA Triad is confidentiality, Integrity, and data Availability. Basically, as part of DevOps, SecDevOps, and BizOps, all stakeholders must continually consider the CIA.

OMGA - (Owner, Member, Guest user, Application User) is a security structure used to control access.

6 hats/ Six hat thinking - helps with creative thinking within group decision-making.  

ProActivity Hunt - SOC tries to imagine scenarios/hypothetical situations and, using data capture, verify if there are security risks.  I've only ever heard this term at Microsoft.

TV pickup is a phenomenon that occurs in the United Kingdom, involving sudden surges in demand on the national electrical grid, which happens when a large number of people simultaneously watch the same television program and an advert break or half time happens as we all switch on our tea kettles et al.  

Useful Glossary:

The Architecture Review Board (ARB) functions as governance to ensure IT projects/programs align with the business's IT Architecture and IT initiatives align with the company's IT goals.

Change Advisory Board (CAB) - a board of members that evaluates changes and the associated risks to the business.  It has a strong technology influence, not only technical.  Sometimes, CABs in companies are IT-focused, dealing with IT change requests, and are more like an ARB.

ExCo (Executive Committee) - a collection of decision makers, mainly board members/higher-ups, who make strategic decisions.

MMSP (Managed Security Service Provider) - People, Processes and Technology to protect your business. Outsource service that manages & monitors enterprise security.  IAM, Cloud security, app security, data security, and network security.  Includes MXDR - Core monitoring.

Kill Chain - the steps that trace stages of an attack from the early reconnaissance stages to the exfiltration of data.

SOC (Security Operations Centre) - usually the CoE/security team within a business. 

PAM (Privilege Access Management)—CyberArk and Azure have a PAM that allow temporary recorded privilege escalation for users with dedicated admin accounts.

Enterprise Architecture is one level up from solution architecture. The main frameworks are TOGAF (I am 9.1 certified), the Zachman framework, and the Federal Enterprise Architecture Framework (FEAF), also called FEA. I have used ArchiMate and, briefly, LeanIX (SAP) for modelling within the TOGAF framework to describe the Architecture of a government department; it's okay.

BCM (Business Capability Map) describes what a business does to help build IT services strategically and reduce cost and complexity. It is useful for Asset/Portfolio management and "as is" and "To Be" Architecture.

Open Source Software Licencing for dummies/me: 

1. Public Domain Licence: No restrictions, go for it.

Following are the Permissive licences from most open to most restricted:

2.1 MIT Licence: This is a common permissive (open-to-use) licence.  Simple to understand, anyone can reuse and modify code, but the creator is not liable for any future use.  MIT is almost identical to a 2.2 BSD licence.  It is excellent as you can freely use it, and I would like to offer my code with MIT licencing.  

2.3.GNU General Public Licence (GPL): This is a nice open-source licencing you can reuse or modify, but your work must be open-source and available to all.  If you use GP, make source code available; anyone can use your derivative.

2.4 Apache and Apache 2: These are also Permissive but more protective than MIT licences.

3. Copyleft: This is more restrictive. Users can reuse, but any derivations are bound by the copyleft licence on the originals.

4. Proprietary: Most restricted, closed source; no change or redistribution is allowed.  

Code Reviews for SharePoint

Overview:  Customisation in SharePoint takes different forms and having suitable environments to test code in before setting it free in production is essential.  This post looks at various types of customization and how to code review.  As a solutions architect and when I was running the Application Development CoE for a large multinational having standards and a code review checklist help immensely.  Improving code quality and finding issues early reduces the cost of building applications so code reviews are a good idea.

There are several automated tools for performing code review that target different application platforms (think FTC in SP2010 vs App Model in SP2013).  When automating the tools, it is good to select the templates/rules that match your organisation and maturity.  Ensure you customise the rules so they not reporting issues when in fact these are your standards (an example is naming in FxCop differs from the SharePoint code naming conventions used by different businesses).

Note: The code review requires depends on CSOM, FTC or JavaScript.  Depending on what is being created/built will require different code review.

There are several automation tools that can help identify poor quality code early within the development process.  Like peer reviews, these tools can help developers implement their code in the correct manner.

Note:  Define your coding standards, have up to date architecture diagrams for architects and have the rules when and what features your developers can use.  It's fairly common for outsourcing companies to build a solution to find out you don't allow the technology they have built with.  I remember an InfoPath based solution coming into my app development center a few years ago and they could not understand that the organisation would not merely turn on InfoPath.

Note: A lot of the tools we previously used in SP 2010 for FTC solutions are not relevant to SP 2013, namely SPDisposeCheck.

Code Review Tooling Options:

1. Visual Studio
2. FxCop (Config in VS so it runs with the same rule set as SPCAF)
3. StyleCop (Config in VS so it runs with the same rule set as SPCAF - forces enforcement of code style at design time)
4. SPDisposeCheck (SP 2010 only, don't use in SP2013 even for FTC solutions)
5. MSOCAF
6. SPCAF (SharePoint Code Analysis Framework)
7. Black Duck - Build into CI/CD pipeline checks for open source software and identifies potential security issues and highlights licencing concerns.

The 3 areas where code reviews can be performed are:

1. Developer at run time (think Visual Studio)
2. Continuous delivery (think gated check-ins)
3. Formal Code reviews (think solutions architect and quality manager) 

Manually reviewing code is better than nothing (automate where possible) and some basic rules and guidance is provided below.

Summary:
Code reviews improve maintainability, pick up bugs, ensure efficient code, code that shall run in production, improve security, performance and reduce the total cost of ownership.  Automated tools are worth considering and the top tool for me is SPCAF.  Do code review early, often and automate.

JavaScript Code Review Checklist:

1.> Project Structure - js into script folder in the solution file (group images, css, js and file types so the projects are easy to understand and consistent in layout)

2.> use strict directive on all pages "use strict";

3.> Always use Javascript namespaces - avoid conflicts

4.> Move hard coding to constants at the top of the file, not single use meaningful info like undefined in.  Move declarations to the top.

5.> Only used approved frameworks like jquery, notify if any other frameworks are used.

6.> Commenting.  Ensure method names tell coders what the method is performing.  Add comments that explain the method.  Don't be afraid to add value by adding inline comments. 

7.> Display friendly messages to the users if something goes wrong and add error handling to tracking /logging such as console.log() or log to ULS from an app using the provide JS api or log to a common logging mechanism.

8.> Single spacing  (no flower potting)

9.> Remove commented out code/unused comment out calls etc.

10.> Always end your switch statements with a default statement.

11.> Ensure coding standard are consistent consider using http://www.jslint.com/

12.> Code adheres to your agreed coding standards and example is http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml

C# Coding Standards for SharePoint

This is a checklist, the recommendations need to be matched to your business and some scenarios such as complied C# for PowerShell plugin won’t use all the items in this checklist.

1. Have you followed the Enterprise design guidelines, branding guidelines and coding standards.
2. Have you used the Commenting standards e.g. http://msdn.microsoft.com/en-us/library/b2s063f7.aspx
3. Avoid declaring inline literal strings
4. Check empty string using length e.g. if (email.Length()=0) don't use if (email.Empty || email = "")
5. Use StringBuilder for concatenation don’t keep appending strings
6. Return Empty array rather than null
7. Methods must be short and focused.  Method names must be meaningful
8. Use method Overloading, not different names for the same method.  Try keep Classes small i..e under 500 lines.  If larger use #Regions to split up the code.  Pass objects into Methods rather than multiple variables if more than 6 parameters.
9. Enumerators should be used where possible, code is more understandable and options are easy to reuse.
10. Only import namespaces you need and dlls.  Split code into separate assemblies and use company standard naming with appropriate namespaces naming.
11. Make helper functions i.e. don't rewrite code several times - refactor
12. Open connections (SQL and SharePoint) as late as possible and ensure you wrap in error handling and dispose of connections in the finally statement
13. Reuse core code libraries (ensure commonly re-used functionality is add into core libraries cross-cutting concerns/logging/ email)
14. Use exception Management/Try catch.  Try catch must try catch specific errors and lastly catch all errors.  No business logic must rely on using catch statements.  Don't throw exceptions within exceptions.  Catch errors as specifically as possible, die gracefully and appropriately, log the errors using the CoE code core block that puts exceptions in the farms ULS and event viewer.   And potentiall the enterprise logging platform.
15. Dispose of SPSite and SPWeb Server site objects where appropriate. Run http://code.msdn.microsoft.com/SPDisposeCheck before deployment
16. Run stylecop and code analysis on code regularly and before deployment
17. Your code is x64 bit compiled. 

Have a common code/core code library that deals with cross cutting concerns, logging, caching etc.

using Microsoft.Practices.ServiceLocation;

using Microsoft.Practices.SharePoint.Common.ServiceLocation;

using Microsoft.Practices.SharePoint.Common.Logging;

ILogger _logger = SharePointServiceLocator.GetCurrent().GetInstance<ILogger>();

Exception ex = new ApplicationException("This is my test exception");

_logger.LogToOperations(ex); 

Security in C# and SP

1. Plain text passwords are not in stored Web.config, Machine.config, or any files that contain configuration settings. 
2. Input surfaces such as application pages, site pages, web parts and other customizations perform client and server side validation to protect from cross-site scripting (XSS) and SQL injection. 
3. Minimal use of elevated privileges to interact with SharePoint objects. 
4. Sensitive data is not stored in URLs, unencrypted cookies in hidden form fields, query strings or with code. 

HTML/CSS

Section 508 US Standard to ensure federal agencies 

WCAG 2.1 compliant standard should be adhered to and will cover: Jaws/Browser testing, screen zooms and brail readers.  WCAG 2.2 is due out in 2021.

RWD testing e.g. Mobile/Phone testing

SEO

SQL Standards (Establish SQL standards), a small example is:

1. No spacing in naming objects
2. Do not use reserves words in SQL
3. Name tables in sigular e.g. "Patient" not "Patients"
4. No Underscore in table naming and use Camel case e.g. "PatientResult", underscores are fine in column and Store proc naming.  
5. Do not prefix tables e.g. "tbl_Patient" or "tblPatient" 
6. Prefix view with "vw" e.g. vwPatientHistory
7. Boolean columns prefixed with "Is" e.g. IsActive
8. Stored Procs prefix with "usp" not "sp".  E.g. uspDeletePatient, use the format usp_Verb_Noun
9. Prefix functions with ufn 
10. label foreign key using the prefix fk and follow the format fkTableColumn e.g. fkPatientId 
11. Make your -SQL readable not on 1 line.  Use line-breaks, no empty lines and indent spacing to make the code readable.
12. How to comment must be standardised

This list goes on but as a starting point...  Pls post if you feel anything else is relevant.

SharePoint CoE & Estimating SharePoint Projects

Overview:  On Tuesday 21st of February I present a real world experience of a method of estimating and providing a high level design for SharePoint projects as done in our CoE at the SharePoint User Group UK (SUGUK) meeting in Nottingham.

Here is the slide deck (pptx) 1.1MB

Also see:
http://blog.sharepointsite.co.uk/2011/11/sharepoint-center-or-excellence.html

SharePoint Center or Excellence

Overview: What is a SharePoint Centre of Excellence (CoE)?  I suppose all CoEs share the maxim of "Realising the potential of <SharePoint> <Technology> <Stack>".  There are a lot of consulting firms and large organisations claiming to have CoEs.  I have come across different meanings for an SP CoE, ranging from a group of developers that are assigned out on projects to CoEs providing guidance on development, customisations, infrastructure, processes, governance and advising on IT pro tasks/administration.  I'm far more in the advisory/governance camp for your CoE to add the most value.

Intake Process leveraging share services resulting in Maintainable Apps 

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).

Other opinions:
Sonny Mian - has written a series of posts on CoE for SharePoint - Part 1.

ShareFest session on Coe for Shire

Also See:

http://blog.sharepointsite.co.uk/2012/02/sharepoint-coe-estimating-sharepoint.html  - Updated 25 Feb 2012.