I have had some interesting discussions with colleagues about whether a client organisation cares about the technology being used by a vendor in an outsourcing situation. Some have said that the performance is defined by the SLA’s and you do not need to understand how it is being delivered. I feel that a reasonable level of due diligence is appropriate.
A sensible vendor will set the SLAs for worst case scenarios from their point of view. What the client needs is not only the worst case performance levels, but also an understanding of what the normal performance will be. Also, a client is interested in the level of assurance when things really go wrong; will the vendor meet their SLAs. Lifting the lid on the vendor’s offering and understanding the solution supporting the SLAs will give the client a clear understanding of what is supporting the performance being offered. Blind faith in the ability for a vendor to deliver will not help you when the vendor’s systems have gone down.
It was pointed out to me that a client who buys a non-dedicated, i.e. shared with other clients, disaster recovery (DR) will be fine when they have their own private disaster. However, a major disaster that affects several clients could leave the DR vendor incapable of delivering an adequate service.
Let’s look at some sourcing and outsourcing experiences where lifting the lid has been important.
One of the UK’s major high street store organisations was looking for a DR facility. It was agreed that n+1 redundancy was appropriate. One option was to link their current west of London data centre (DC) to a DR facility just east of Heathrow. The sites were greater than 35km apart, an oft used minimum separation distance. The communications supplier costed the required two links between the DC and DR sites to provide redundancy. We asked to see the route down to the manhole to manhole level. For less than a kilometre the two links shared a common duct. One careless road repair team could cut both links; n+1 was not being achieved.
One of our transport companies had issued an RFP for a spares management system. I was tasked with reviewing the software packages being offered. The client had a leading contender. The review uncovered that the software was a monolithic piece of code, the documentation was limited and the application development environment was extremely dated. When challenged, the vendor owned up that the package was at the end of its life and due for redevelopment. Time to review the alternatives!
I was doing a communications strategy for a car manufacturer. During discussions (but not central to the strategy) it transpired that the UK to New York transatlantic link was overloading and creating user distress in the NY office. The equipment supplier was saying nothing was wrong and the network supplier was saying another link was required. Would I look at it? Next morning, before the USA was at work, we linked into the NY office using the public network and logged on. It only took 15 minutes to identify that the equipment was not supporting the correct protocols and was turning each user key stroke into multiple IP packets. A few users could easily overload the link. The client declared the vendors equipment as not fit for use, replaced it with some fully functional IBM equipment; no new communications capacity was required.
I understand the advantages of the blind faith argument, no need to understand the technology and stand behind the legal framework. I am less than convinced when things start to go wrong. It is then important to be able to understand what you have bought.
Ian Richmond
Email: ‘About’ and ‘Email Me’ link.