Sunday 25 September 2016

SharePoint Support Models

Overview:  Large organisations tend to use a tiered support model also called the escalation model.

The Problem with Tier Support Models:
A user finds an issue and explains it to level 1, the Level 1 support guys figures out it's too difficult or not on his easy path and pushes to level 2,  the whole bug needs to be re-explained generally involving the business user that reported the bug and the level 1 support person.  This goes on for 3  to 5 levels in bug organisations and is eventually passed onto engineers or the vendor.  It takes an astronomical amount of time, and provides a poor impression to the business user.  Coupled with a tracking system that the end user don't know how to use and the support people trying to add as much content as possible so as to cover any responsibility as they have not missed anything.  It's just a disaster.  Anyone doing Level 1 and 2 support is generally not happy and poorly remunerated so the turn over is high, end use satisfaction is not good.  A lot of time and focus is wasted.  To me the fundamental problem I have with Tiered support models is a lack of Total Ownership.  Support people pass the problem and tick off the easy fixes.  I have seen multiple support escalation software products and fundamentally the products don't tend to make much difference, it's the implementation of the support process and the quality and ownership of staff that determine good support models (but its far easier for people to blame software).

On the plus side, Level 1 support people are considerably cheaper and if they have good knowledge basis and training they can return 70% plus of incidents at this 1st stage.  Funneling tougher questions to more specific staff.

DevOps: DevOps relies on close collaborative deployment and support, so the upside is you have the developers and they understand the infrastructure and are best position to fix mistakes cleanly and quickly.  In traditional enterprises, we tend to have hundreds or even thousands of applications and you loose economies of scale by having to keep dedicate higher cost people around to do support and it generally affects sprints as people need to be pulled out to fix bugs.  On the plus side, you get fixes done quickly and correctly.

For me the answer is "It depends...", if you are a tech company with 1 main product, think Facebook, AirBnb then devops is clearly the choice approach.  If you are a company that has legacy applications such as a bank, an application supporting mortgage applications has been used for 10 plus years, tier support is much cheaper and effective.  So the tough question would be what about the same bank that is now developing a new complex application, ideally if governance would allow it then I would start developing the product and use DevOps, allowing better deployment and support in a rapidly changing environment.  Once the project starts maturing then the question is when can I move the product to a tier support model.

Summary: DevOps works well in an Agile environment and support is vastly improved, assuming the product is not changing and the number of incidents is low, this the time to transition to a tier support model.