Supported, Certified, Recommended - My Guide to Supportability of Products

Working for Oracle, I get a lot of questions regarding the support of numerous products on various platforms. The reasons for those questions differ. Sometimes, the respective support information cannot be found by customers, partners, or even internally, while other times details are missing or a specific configuration is not listed. More often than not, however, I also get the questions "Is this certified?" or "Is this a recommended configuration?"

Given those questions, I started looking into "support definitions" used by various vendors, trying to find out whether the answers to those questions are Oracle-specific or whether there is a common ground. Turns out that there are quite some similarities between "support levels" across vendors. Hence, this is "My Guide to Supportability of Products".

Why Nuances Matter

Unless a specific configuration (of hardware and/or software) is "not supported", finding a support statement for a given combination of software and/or hardware products is not that difficult generally. What is harder, is to understand what "support" actually means.

Support by definition simply means: "give assistance to, especially financially; enable to function or act." Glancing across the "support definitions" of various vendors, this definition broadly holds. It means that a supported configuration is one for which the vendor will provide assistance to enable you to use this particular setup. Note that this definition leaves open to what degree this assistance is provided. For example, the performance with which a solution "works" is usually not part of this basic definition. That holds equally true for enterprise solutions as well as consumer products.

Take my cable-based internet service provider as an independent example. The provider's documentation states explicitly that internet speeds measured at home may deviate from the "numbers" offered by my internet plan. While this is understandable, the question arises when should I open a support request because my network speed is "not good enough", not even by objective measures? The other question would be, how long will it take the vendor to find the potential issue and fix it, if the vendor is able to solve the problem all?

These questions apply to my cable provider in the same way as they would to an Oracle Database running on any supported platform or to any other hardware/software system. The answers to those questions depend on the "support level" in which one is operating.

What Level of Support to Expect?

Different vendors may use different terms, but in the end, I have found that one way or another most vendors use a version of the following support level classifications which in turn will lead to a certain support experience that one can expect:

1. Recommended configurations - usually reflect the highest level of support one can get for any given configuration. It typically means that a given combination of hardware and/or software products is not only fully supported, but also recommended by the vendor. Oftentimes, recommended configurations include the vendors' own offerings (in the case of Oracle, this would mean Engineered Systems, while in the case of my cable-based internet service provider, recommended configurations include their own wireless routers). Some vendors only recommend setups that are certified (see definition below); others may base their recommendations also on complementary data. Either way, most vendors will have a good amount of experience with recommended configurations of which there usually aren't too many permutations, either, which typically leads to a rather satisfying support experience in that a solution can be provided quickly regardless of the issue(s) reported. For recommended configurations, one could even expect to get some performance guidance or other qualitative measures, as vendors have likely run some tests on those configurations.
2. Certified configurations - a certified configuration is the second-highest level of supported configurations, as it implies that the vendor has actively tested (at least functionally) this configuration (which is Oracle's basis for declaring a configuration "certified") or otherwise gained sufficient knowledge about it so that assistance can be provided based on experience. The more experience a vendor has with a given configuration, the more pleasant the support experience should be, as a solution to an issue can typically be found faster. A subgroup of certified configurations is what I would call the "accepted standard components group". In this group, individual components follow an accepted standard, hence are generically supported (e.g.: external USB hard disks are supported as the USB standard is certified). However, this type of generic support is likely less specific (read: "more time required") when it comes to corner cases with such components.
3. Supported configurations - represent the third and most common level of support. Whether a configuration is recommended in the group of supported configurations depends on many factors and the vendor's decision. Recommendations for supported configurations are often provided as "best practices" and should generally lead to a pleasant support experience. Given the variety of configurations supported in this category, some individual investigation into the root cause of a reported problem is usually inevitable, which sometimes can lead to a slightly longer support experience, especially as vendors cannot always and often have not tested every supported configuration. At times a proposed solution may also not be fully aligned with one's expectations. Unfortunately, the latter is often a side-effect of supporting a broad spectrum of configurations. In other words, if a vendor supports many configurations, the solution to solving a particular problem may sometimes involve extra time to investigate the issue and/or changing the configuration (in parts) to get the best solution.
4. Un-supported (un-listed) configurations - are normally those configurations from which one should stay away. However, the problem is with the "un-listed" part. Most vendors provide positive support lists (they list what is supported, not what isn't). Hence, a configuration that is un-listed always leaves a bit of doubt whether this configuration is actually un-supported or one could simply not find the respective support information. Sometimes, configurations are supported based on general policies or accepted standards as mentioned above. This is one aspect to check explicitly. Other than that, there is no easy way to get absolute certainty about the support status of a supposedly un-listed configuration. Thus, if in doubt about the supportability of a given configuration, one should ask the vendor, because an un-supported configuration is not likely to get any support, and hence, it is better to ask in advance than to have regrets later. The only exception: If a vendor explicitly states that a solution is not supported or no longer supported, there is usually no need to re-confirm as those statements are normally reviewed regularly and will be updated should the policy change.

Tip: Avoid Extremes!

Before getting into the more nuanced extremes, let me first make a very important clarification "un-supported" is by no means equivalent to "does not work"!

While supported configurations are generally known to work, the absence of a support statement frankly does not say anything about the technical feasibility of a given configuration. The reason why a solution is not supported can be manifold. In the end, however, it is best to stay away from un-supported configurations.

Also, remember that declaring support is a declarative act that takes into account many factors and if one is lucky, the support of a given configuration is declared based on good grounds and ample (new) experience with this configuration, ideally gained by (functional) testing. However, "getting support" basically means getting "a written promise" that the vendor is willing to help with issues reported. How well the vendor's organization can do this will depend on their experience - not the declaration! This leads to two tips:

1. Use recommended and certified configurations whenever possible (with few deviations).
2. Do not use un-supported configurations even if deemed working by some standard.

One would think that those are obvious suggestions, but more often than not, I have seen people and even myself deviating from those suggestions for some reason, for some time, and on some systems, which might be acceptable. However, the downsides of this decision need to be considered carefully:

Deviating from recommended and certified solutions may be sometimes necessary, but one should stay within a certain range of deviations, maintaining a supported configuration at all times! The more one deviates, the less experience can be applied by a vendor for support, which in turn can lead to a less pleasant support experience.

One particular deviation that should be considered in this context, albeit fully supported, is the one that uses "extreme configurations" on either the upper or lower end of possible configurations. The best way of describing the challenges that come with this approach is by drawing a car analogy. While both, the 1953 BMW Isetta as well as the brand new Bugatti La Voiture Noire are presumably (very) reliable cars, getting quick and good support for either of them when needed will be rather challenging. While for the Isetta finding spare parts and experienced service personnel is the main challenge, finding any experience-based support for the Bugatti will generally be rather difficult due to its rarity.

Using un-supported configurations, however, is not a good idea for many reasons. One reason is: Un-supported configurations are usually not considered during future development. In other words, although an un-supported configuration may work by "some standard" and based on "some tests" (remember that I said: "un-supported" is by no means equivalent to "does not work"), it does not mean it will work in future. If, however, an un-supported configuration stops working at some point in time due to an unintentional change (during future development for example), there is no way to claim support. This is one of the main reasons to avoid un-supported configurations - the chances for those configurations to work for all eternity assuming they work currently are diminishing as time passes - unless, of course, a formerly unsupported configuration is converted into a supported configuration.

One scenario in which using un-supported configurations is often considered, even if only temporarily, are upgrades, migrations, or generally transitions. In such cases, an un-supported configuration is used for some period of time (assuming it works) with the intention to establish a supported configuration later. Oftentimes, the un-supported configuration does not deviate much from supported configurations (in extreme cases it could even be a combination of otherwise supported configurations). In the end, however, it is an un-supported configuration that will be subject to limited support or no support at all. The support limitations can come in different ways; for example, in that, a supported configuration must be re-established within a certain amount of time for continued support and/or service. In any case, one should stay away from using un-supported configurations, even if only temporarily.

Last but not least, some vendors offer customer-specific support. This type of support is generally a subcategory of the supported configurations as discussed above with the exception that the support is provided as a one-off, for a given configuration, and/or a special customer or both. While such support can be useful at times, it can, in a way, be seen as a violation of the "Use recommended and certified configurations whenever possible (with few deviations)" principle discussed above with the respective consequences. In other words, if a configuration requires one-off support, chances are that it is similar, but yet not similar enough to a supported configuration and hence, will potentially require extra time and attention when it comes to finding the solution to an issue.

Conclusion - Three Simple Guidelines for Best Support

There are quite some similarities between support levels across vendors. Whether you want to use an Oracle software product, you want to set up your best cable-based internet access, or whether you want to use any other software/hardware configuration, it is best to follow three simple guidelines in order to get the best support from any vendor:

1. Avoid nuances and use a configuration that falls into the desired level of the three support levels (the fourth level describes non-support and hence, is likely not desired).
2. Avoid extremes and use recommended and certified configurations whenever possible.
3. Avoid using un-supported configurations and don't use them in production.

DISCLAIMER: This article is based on my review of the support guidelines for software and hardware products provided by various vendors. Above are my own interpretations of those guidelines. This article does not reflect the opinion of those vendors nor does it claim to be fully accurate. If you have any questions regarding support or guidelines from any vendor, please, contact the vendor directly.