The kernel of the recent Fit-for-Business Broadband workshop that I co-hosted was a model of how the broadband business creates value for users. This newsletter presents the model, and points out a few things that are not so obvious in prospect, but are useful to think about when considering broadband economics. What is perhaps most valuable is to have a language (of ‘application performance hazards’) in which to discuss the subject.
The model here is a (highly) simplified version of a general and robust method for reasoning about performance, application outcomes and end user value. This generalised methodology was developed for the military in the early 2000s, and led to the creation of a new branch of mathematics (namely ‘ΔQ’), which is the bedrock of network performance science.
Costs and benefits
The field of play we work within is conceptually quite simple: there is a finite broadband supply, which is turned by applications into ‘business value’. This value may be interpreted differently depending on its context: enterprise, public sector, consumer or military.
In this simplified model, we’ve taken the case of a single application and user class, whereas the general (and considerably more complex) model takes account of multiple concurrent and diverse users and applications. The basic ideas remain the same regardless.
The question we need to answer is: in creating this business value, what are the costs we must incur, and how do these costs relate to the properties of the broadband supply?
The technical nature of supply
The chart below summarises the conceptual model of how broadband supply is turned into something of business value.
The broadband supply has four key properties:
- Connectivity (“Wi-Fi available here!”)
- Continuity (the thing you briefly lose when a DSL line retrains)
- Capacity (the ability to cope with demand for volume)
- Stationarity (the ability to cope with demand for schedulability)
It is this last factor, stationarity, that often tends to be forgotten. For example, the top-speed package of a cable service provider may have more variability of loss and delay (i.e. ‘non-stationarity’) than that of a basic DSL line, due to the nature of its shared medium. As a result, it may be less suitable for some applications like 2-way video and unified communications.
Performance hazards
These four factors in turn determine the performance hazards of the application. For instance, what are the chances that a streaming video application will exhaust its buffer and show the ‘circle of death’? This concept of hazards is a central and critical idea. It is borrowed from the study of safety-critical systems (like air traffic control) and the analysis of their failure modes.
A performance hazard can be latent, i.e. it could happen, but not in the current circumstances. This is a bit like being the carrier of a gene sequence that pre-disposes you to a disease that will only afflict you in later life. Alternatively, the hazard could bearmed, and could happen in the current circumstances. Armed hazards have a certain probability of maturing which results in an impact that drives business risk.
There is a surprising level of subtlety to the degrees and types of performance hazard that exist; categorising them is beyond the scope of this article. The performance hazard may have a technical mitigation cost, such as running the application over a separate and dedicated parallel infrastructure.
When we run the application operationally, these performance hazards either do or don’t mature. As a consequence, we experience a particular level of technical application performance and availability. These are the (only sustainable) sources of value of a broadband network: you can fool some of the people all of the time, and all of the people some of the time, but you can’t perpetually disguise a failure to create the core value that users seek.
So that’s the technology supply side.
Business value demand side
When we look at the business side, we see something that is a bit like a profit and loss balance sheet.
The ‘top line’ is driven by the fit-for-purpose application outcomes that we experience, such as successful voice calls. Meanwhile, there are three sources of ‘cost’ to subtract to get the ‘bottom line’:
Direct loss + (Self-)insured risk. There an immediate hit that you take for any application failure: it could be a simple embarrassment when a VoIP call fails, or a serious business process outage. As a result, you have to (self-)insure excess risk. For instance, if you are a consumer inviting your friends round for a Netflix movie, you may keep a DVD and a lot of bonus beer around if you can’t rely on the service working. For a business user, you may travel to see a key client rather than pray that WebEx won’t let you down.
Catastrophic risk. Things can, and do, go very wrong in ways that insurance can’t cover. Say you are a public sector body, who has decreed that everyone will work from home so you can sell off your office space. Then one day a national broadcaster announces that it’s going online-only for key channels, and the application performance for many users suddenly becomes unacceptable at 4pm when the kids come home from school, and you have no means to back-out.
Mitigation cost. There are additional business costs that you may incur to mitigate the effects of failure, for instance by maintaining backup business processes and facilities. This is above and beyond the insured risk cost.
These collectively ‘taint’ the business value of the application. What is notable is that the more valuable the underlying thing that broadband enables, the more we require dependability to contain or eliminate these costs.
Summary and conclusion
The full model is presented below.
The take-away is simple: the nature of supply drives the performance hazards, which in turn determine the benefits and costs. If the hazards are not managed or mitigated, the costs can outweigh the hoped-for benefits. Thus for broadband to meet its full economic and social potential, it has to be dependable.
At present a lot of broadband business and policy-making organisations are struggling to make good plans, since they lack an appropriate language in which to talk about the domain. The language of ‘application performance hazards’ fills that gap of shared understanding. This particular version is a simplified model designed for a less technical audience. Nonetheless, it contains all of the key elements needed for robust reasoning, and is grounded in the reality of how broadband operates and creates value.
To keep up to date with the latest fresh thinking on telecommunication, please sign up for the Geddes newsletter
Read It Now
