cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Five 9's? Fuggedaboutit!

3154
Views
0
Helpful
2
Comments
Beginner

tap_9s.jpg

I was going to write a lengthy piece to promote the importance of of both Telephony API's and the reinforce the growing trends toward both cloud computing, Web-oriented architectures, VoIP and community-building, but Alex Williams at Read-Write Enterprise did a great job of it here, as a sequel to this. That's why I'd like to launch another theme in support of Recombinant Communications by talking about a concept that should be left behind - if it hasn't been totally abandoned already. That is the "ideal" of "Five 9's".

For those of you too caught up in the world of "six sigmas" to remember Five 9's, here's a refresher. It is the bugaboo of every equipment vendor or service trying to win business built on "telco-grade" service level agreements "SLA's". In the bad old days, when all computers and switching systems had to go into those windowless "lights out" central office buildings, prospective purchasers (meaning incumbent carriers) added a little something called "NEBS-compliance" to the mix. Here's a link to the 30-page "quality assurance" document still in use by Verizon to support "NEBS testing". You literally have to set your product on fire and drop it out of a building to provide data on its heat dissipation, fire resistance and seismic tolerances. [It's telling that while the document has a glossary of abbreviations and acronyms covering things like CO, FTTP and the like. NEBS is never defined. FYI: it is an old Bellcore term for "Network equipment-building system" specifications.]

NEBS is an artifact of the monolithic communications industry. It was a time when the dominant, incumbent carriers had total control over the pace of innovation and introduction of new services. NEBS testing (and testing in general) often extended the time it takes to deploy new services by a factor of ten. High levels of reliability and availability took precedent over rapid and responsive introduction of new services and applications. The notion of Five 9's comes out of this same school of thought. It refers to the number of significant digits in the measure of computer system and network uptime. Five 9's is 99.999% availability. In any given year (which equates to 525,600 minutes) Five 9's equates to a little more than 5 minutes).

Think of that the next time Facebook freezes, Gmail is unavailable, or the "Fail Whale" appears as you try to take a Tweet break. Heck, think of it as you make sense of a slightly mangled transcription of a recently received voicemail message. My point is not to defend such failures, but to point out that we end-users (well, at least my "sample of one") would rather live with these minor mishaps than do without new services altogether. The speed at which new applications and services are introduced and how they evolve over-the-top of IP-based networks is both dazzling and beneficial to end users.

Today's world of telco mashups and telephony API's is built on "Four 9's" at best and, in the case of speech-to-text transcription, something on the order of 85% recognition rates (with human intervention as a frequent fallback). On smartphones, mobile apps fail routinely. People are accustomed to dropped calls and the occasional need to "reboot" their mobile devices. In spite of such shortcomings, or perhaps because of them, mobile subscribers feel more attached to their devices than ever before. Going mobile has a more daring, game-like quality to it because of a certain amount of risk-taking and improvisation.

As we enter the second decade of the new millennium, mobile mashups are more popular than ever and the world is on the threshold of high adoption rates for voice command, voice search and message dictation. The fun is just beginning. And, in no small way, we owe it all to the End of Five 9's.

2 Comments
Beginner

Interesting post, I'm definitely identified with the type of user you describe: someone that prefers innovation over to bullet-proof solutions. However, things change a little when you are a company that sells services to other companies and make money out of it. How much in $$ do those 5 minutes mean? And how much more would it be to have 15, 30, 45 min of downtime per year? Can you also convince customers of having more glitches but more features as well? And how about competitors that will claim they can do Five 9's?

All those questions become even more important in environments where the service is critical: either because of safety and legal reasons (911) or because the impact to your business now and in the future can be too bad (think of Barclays, Amazon and the like).

Talking to customers on a daily basis, the first thing they tell you is: "You need to understand my business first to help me improving it later". From that perspective, I think some areas of the business could do with more innovation and less reliability but others would still need to ensure they are up as much as it's technically possible (even at the expense of features).

To your examples: I, as a user, can live with Facebook and Gmail downtime. Why? Well, because they are free services and I'm not making a living out of them. I think the situation would be quite different if I needed them to be up to get my paycheck and would for sure ask for some penalties if they had a glitch in their service.

To resume, it's a question of how much (again in $$) you value your downtime vs. the new revenue you can get from new services deployed. And that won't change as fast as we think (or would like to)

Jose.

Beginner

Jose: I think you are exactly right. There definitely are mission critical, phone-based services that are well suited to five nines, high-availability, fully-redundant installations. They must be served. Now we must build a continuum from nice-to-have/can live without services which are "free", fun time sinks which can be supported with on-the-fly infrastructure. Your framework of exposing the "value of downtime" is the starting point for establishing how much an enterprise might be willing to pay for mission-critical, hardened solutions. As we move from the rock-solid PSTN to the shared Internet for IP-Telephony and the like, we have to map different apps to different levels of reliability and sell the appropriate solution.

Mobile phone users in the U.S., for example, have been conditioned to accept dropped calls, relatively poor voice quality and other sub-optimal conditions. Voice-to-Text translation is often flawed. Both test the limits of end-user patience, but have not (with the exception of the 911 service that you cite) proven to be life-threatening. The challenge for this community going forward is to help define a continuum from mission critical to recreational applications and services and then bullet-proof them as the associated financial gains or losses justify.

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards
This widget could not be displayed.