SPOF is a very hackneyed expression, nowadays. However, a certainty remains: SPOFs must be addressed, or your company will loose a lot of money in downtimes. To address them, you must first identify them. One of the objectives of the Network Architecture process is to prevent SPOFed architectures to go into production and to identify SPOFs in the existing production architectures.
This, contrary to the opinion of many, is not a lost race. There is a finite number of 4 kinds of SPOFs, that you must all look for:
- The hardware SPOF: your hardware (whether servers, network equipments, etc.) is not redundant.
- The network SPOF: your hardware is redundant, but the network links that connect equipments are not crossed. They should normally deserve all redundant hardware just as well.
- The configuration SPOF: your hardware is redundant, the network deserves it well but the clients are not aware that they should be connecting to the failsafe servers if the main ones are not available. In my experience, this one type of SPOF accounts for a huge part of forgotten SPOFs and related losses in unplanned downtimes.
- The technology SPOF: one of your technologies fails (whether hardware, software or network). As it is the same in the main architecture and in the redundant architecture, both suffer from the same downtime.