Creating a tiered software support services model is an effective way of managing software support services and their costs based on business need. The idea of tiered support services is to have a standard set of services distinguishing one support tier from another that correspond to standard application classifications.
Definition of Tiered Software Support
The definition of tiered software support is having distinctive levels of support ranging from unsupported to fully supported software. Most tiered software support models focus exclusively on the user support services through the service desk. But, a true tiered software support model accounts for the entire application and infrastructure stack along with the ancillary services at each of the support tiers.
Overview of Tiered Software Support Model
The easiest way to describe this in the most simple terms is that you set up a basic method for classifying applications, or business services, based on their criticality to the business. Each classification corresponds to a level of “goodness” that is required to support the application and the business functions that will rely on its use.
Then you define a set of support tiers, often no more than 3 to 5. Each of the tiers offers a distinctive level of support which also corresponds to the application classifications. Each of the tiers defines the unique technical and infrastructure services as well as the application and user support services for each tier.
This usually results in a business service, or application, classification scheme having no more than 5 classifications that correspond to a tiered support model also having no more than 5 support tiers. Many organizations find they only need 3 levels of classification and 3 tiers which can be due to everything being very critical or covered by stiff regulatory requirements, or it can be due to not having enough distinction to warrant more.
As with nearly all other advice I offer, my best recommendation is to shoot for three initially and resist adding more until you absolutely have to. Oh, Unsupported is a Tier so maybe you’ll need four to start.
Factors Affecting Application Classification
I think the easiest thing to do here is to point you to the previous post Designing a Software Support Model. In that post I have included a comprehensive framework for the various factors to be considered.
The key factors to be considered are the risk management requirements usually derived from regulatory issues and the nature of the data in the system. Another key factor is in how much downtime the business can tolerate at peak demand. The final key factor is the type of service supported by the application and the need for recurring maintenance, customization, reports, or in-house technical analysts to support the business analysts
Factors Affecting Support Tiers
In order to understand how support tiers work together it can be useful to think about the ITIL models for service level agreements. Using this approach, IT analyzes the application portfolio and the business requirements for reliability, performance, user experience, data retention and archive, privacy, security, and compliance from the far end of the service model.
From there everything rolls down into the lower, and common, infrastructure components where the highest application service requirements defines the minimum standard for the common elements. This means that any common infrastructure systems such as servers, VM, SAN, network and DBMS shared by multiple applications of differing criticality must meet the requirements of the most restrictive, highest classification of application.
It is because of this approach and the increasing number of common components in today’s heavily virtualized and consolidated infrastructures and shared architectures that many organization find they can only create 3 tiers of support. Putting these together can be as simple as this example.
Remembering ITIL again here will help remind us this has to be top down. So a 24×7 tier 1 application has to be supported 24×7 by the service desk, 24×7 application support team, 24×7 infrastructure team and 24×7 by any vendors including the hardware, software and ancillary systems required for normal operations. This is the ITIL relationship of the SLA, OLA and under pinning contracts.
Assigning the Support Tier
In most of the tiered support models I have set up or helped customers with it seems best to use a minimum support construct based on triggers from the business function, data or the “goodness” required following the idea from above.
So when you review the application support requirements with the customer, they define the criticality and you map it to the minimum support tier based on their requirements. In doing the assignment though you have to consider some customers will declare a high criticality but not want to meet the requirements of the appropriate support tier, especially when it adds expense or might delay implementation.
An example might be that if an application will contain PII or PHI then it must be Tier 1 and cannot be run as Tier 2 or Tier 3 even if the department wants to support it themselves. Remember, these are business requirements, not IT requirements which can still be exempted through a risk acceptance policy. This is the best way to keep a customer from putting the organization at risk from over inflating the criticality or understating it.
Handling Cloud Computing
It is important to take a minute and address special circumstances of tiered software support in the age of cloud computing. Keeping in mind my orientation is that the tiered support model is a business requirement intended to minimize risk, not an IT requirement.
Accordingly, if a functional manager wants to purchase a cloud service or a hosted application, they still will need to go through the application, or cloud service, classification and support tier assignment process with some assistance from IT. This then drives vendor selection and the vendor management requirements.