The 55th Installment
“Beyond the Scope of the Assumption and Designed Values”

by Yukio Namba,
Professor, Master Program of Information Systems Architecture

Beyond the Scope of the Assumption and Designed Values

In the wake of the Tohoku Earthquakes and following the tsunami, as well as the Fukushima Daiichi nuclear disaster, I started to see an expression using "beyond the scope of the assumption" on many occasions. Unfortunately, it seems to me that the expression is used as an excuse and to evade accountability, for example, when saying they could not handle because the scale of the tsunami waves were beyond the scope of the assumption. Behind this, it sounds like they are saying that it is not their responsibility to handle something beyond the scope of the assumption because it is designed and built to handle the disaster within the scope of the assumption and it is the responsibility of those who came up with the predictive values.

In the disaster, Guinness-worthy coastal levees were powerless against the recent tsunami waves. Even so, it does not always produce practical solutions to build coastal levees that are bigger than the substantial size because things are determined based on the balance of cost and convenience. For example, if we build strong coastal levees that can bear 30-meter tsunami, can we get a sense of absolute security? By thinking the circumstances in a time span of 4.5 billion years over the history of the Earth, you can never say tsunami exceeding the assumed scale would not hit the coastal areas.

From the technological standpoint, designed values are determined based on possibilities as well as damages and cost required to correspond in case a disaster hits. Even the coastal levees built along the Sanriku Coast were used to be effective against previous tsunami. In addition, the coastal levees that were destroyed in the recent disaster absorbed some of the energy from tsunami waves until at least destroyed and I am sure that it was effective to slow down the trains of tsunami waves attacking the city.

In the world of the information system, there are many occasions beyond the scope of the assumption, such as poorlythought-out requirements, unforeseen system behaviors, and the occurrence of external threats.

Poorlythought-out requirements occur most commonly among inexperienced designers who do not fully understand the nature of intended business. To avoid this, they must not only understand the various needs and requirements of users but also the backdrop of the business and fully understand the contents of the demands before summarizing the requirements (specifications). However, even if it was done properly, of functions of the constructed system, the sum of rarely used functions and never used functions is reported to be 64% according to the CHAOS report submitted by the Standish Group.

In this case, despite intensive efforts, if it is only aimed at providing the maximum requirements to prevent omission of specifications, it actually designs and builds unused functions. It is indeed a waste of money and causes a prolongation of delivery time and as a result, it could play a part in quality loss attributed to the complication of system.

There are many types of unexpected system behaviors. Problems, such as so-called latent bugs, occur when undiscovered bugs due to insufficient testing come to the surface resulting from an alteration of usage environment. In addition, when usage conditions change or it goes beyond a certain range, the system load increases sharply causing the system to slow down or shut down. In this case, again, designers are blamed that testing was insufficient or the specification environment was poorly assumed.

The occurrence of unexpected external threats, such as targeted virus attacks that have been given much attention recently, has an impact to disable antivirus solutions that are dependent on antivirus software. In this case, it is necessary to consider the combination use of backward incidence to monitor the intrusion of threats at the exit than what we usually do to prevent virus when it comes in.

Are these events really a matter of designers and developers? Certainly, there are many occasions that they have no choice but to be blamed, but it is not always the case.

When designing a system, they must assume the usage environment and decide on the designed values covering the environment to build a system that can clear the determined conditions and conduct testing to check the specs. Although it is up to a sense of the designer to decide what are taken as designed values and vice versa, many are determined depending on the economic cost-benefit performance.
In this case, there is no choice but to determine designed values in anticipation of possible changes in the usage environment within the system lifetime in addition to the current usage environment. Despite this, it is undeniable that conditions behind designing change if the external environment makes unexpected changes and thus, an event beyond the scope of the assumption occurs in the end.
In case of an outbreak of events beyond the scope of the assumption, no amount of crying will do anything. Instead, measures must be taken immediately to minimize the damage. In the case of a tsunami, the way around is to quickly evacuate to safer places, and in the case of an information system, the situation must be handled accordingly to prevent the spread of the impact as well as to identify the extent of the impact.

To make it possible, it prompts developers to ultimately depend on their response capabilities (local knowledge) because they must handle any unseen situations that cannot be prepared for. In other words, it is required to keep their organizational capabilities elevated. However, it is not easy to increase organizational capabilities in a brief space of time. It requires consistent efforts and it consequently leads to management problems. For that standpoint, the chief information officer (CIO) plays a significant role.