Wednesday 30 October 2013

From Dependable to Resilient, from Resilient to Antifragile

Dependability refers to a system's trustworthiness and measures several aspects of the quality of its services – for instance how reliable, available, safe, or maintainable those services are. Resilience differs from dependability in that it focuses on the system itself rather that its services; it implies that the system when subjected to faults and changes
  1. will continue distributing its services
  2. without losing its peculiar traits, its identity: the system will “stay the same”.
Antifragility suggests that certain systems could actually “get better”, namely improve their system-environment fit, when subjected to some system-specific extent) to faults and changes. Recent studies of Professor Taleb introduced the concept of antifragility and provided a characterization of the behaviors enacted by antifragile systems. The engineering of antifragile computer-based systems is a challenge that, once met, would allow systems to self-evolve and self-improve by learning from accidents and mistakes in a way not dissimilar to that of human beings. Learning how to design and craft antifragile systems is an extraordinary challenge whose tackling is likely to reverberate on many a computer engineering field. New methods, programming languages, even custom platforms will have to be designed. The expected returns are extraordinary as well: antifragile computer engineering would enable to realize truly autonomic systems and ambients able to meta-adapt to changing circumstances; to self-adjust to dynamically changing environments and ambients; to self-organize so as to track dynamically and proactively optimal strategies to sustain scalability, high-performance, energy efficiency; to personalize their aspect and behaviors after each and every user. And to learn how to do better while doing it.

Monday 28 October 2013

On Resilience and Elasticity

Computer systems are not dissimilar from critical infrastructures in which different mutually dependent components — in fact, infrastructures themselves — contribute to the emergence of an intended service. Thus, in computer systems the software infrastructure relies on the quality of the hardware infrastructure, and vice-versa a hypothetically perfect hardware would not result in the intended service without a corresponding healthy software infrastructure. Software resilience refers to the robustness of the software infrastructure and may be defined as the trustworthiness of a software system to adapt itself so as to absorb and tolerate the consequences of failures, attacks, and changes within and without the system boundaries. As a resilient body is one that “subjected to an external force is able to recover its size and shape, following deformation” (McGraw Hill, 2003), likewise software is said to be resilient when it is able to recover its functional and non-functional characteristics — its “identity” — following failures, attacks, and environmental changes. As critical infrastructures call for organizational resilience, likewise mission- and business-critical computer systems call for software resilience. Understanding and mastering software resilience are key prerequisites towards being able to design effective services for complex and ever changing deployment environments such as those characterizing ubiquitous and pervasive environments. Thus, how can we define (software) resilience? The term Resilience refers to a system’s ability to retain its intended function in spite of endogenous conditions, external actions, and environmental changes. The concept of resilience goes back to Aristotelian idea of entelechy (Aristotle, 1986), a central topic in Aristotle’s philosophy whose meaning and relationship with resilience is ingeniously captured by Sachs’ translation (1995): Entelechy is an entity’s ability of “being-at-work-staying-the-same”. This definition tells us that an entity — be it e.g. a physical person, an organization, or a cyber-physical system — is resilient when both the following two conditions hold:
  • The entity is able to exert purposeful active behavior (Rosenblueth, Wiener & Bigelow, 1943) to continuously adjust their functions in order to compensate for foreseen and/or unpredicted changes in its execution environment. This corresponds to the first part of Sachs’ definition: “Being at work.”
  • As a result of the above behavior, the entity is able to retain their “identity” — namely their peculiar and distinctive functional and non-functional features — in the face of the above mentioned conditions, actions, and changes, and despite the adjustments carried out by the entity so as to improve its system-environment fit. This refers to the second part of Sachs’ definition: “Staying the same”.
Another way to refer to resilience is through the concept of elasticity, namely “the ability of a body that has been subjected to an external force to recover its size and shape, following deformation” (McGraw-Hill, 2003). In this case the system does not exert any purposeful behavior but it only makes use of its internal characteristics and resources so as to mask the action of external forces. An example of the use of elasticity to achieve resilience can be found in a classic strategy of organizational resilience (Stephenson, Vargo, and Seville, 2010). In the cited reference it is remarked how organizations often interpret resilience as the result of the “redundancy of their physical resources such as plant and machinery, locations or buildings, and the lifelines infrastructure on which they rely”. Software resilience is the application of elasticity and resilience to entities in the software layers: The trustworthiness of a software system to adapt itself so as to absorb and tolerate the consequences of failures, attacks, and changes within and without the system boundaries.

References

  • Anonymous (2003). McGraw-Hill Dictionary of Architecture and Construction. McGraw-Hill Companies, Inc.
  • Aristotle (1986). De anima (On the Soul) (H. Lawson-Tancred, Trans.). Penguin classics. Penguin Books.
  • Sachs, J. (1995). Aristotle’s physics: A guided study. Masterworks of Discovery. Rutgers University Press.
  • Rosenblueth, A., Wiener, N., and Bigelow, J. (1943). Behavior, Purpose and Teleology. Philosophy of Science, 10(1), 18–24.
  • Stephenson, A., Vargo, V., and Seville, E. (2010). Measuring and Comparing Organisational Resilience in Auckland. The Australian Journal of Emergency Management, 25(2), 27-32.

Saturday 26 October 2013

Fidelity

Elasticity, robustness, resilience, antifragility — these properties all refer to an important aspect of individual and collective systems, namely the compliance between corresponding figures of interest in two separate but communicating domains. I will refer to this property as FIDELITY. A special case of fidelity is given by real-timeliness and synchrony, in which the figure of interest is the physical and the system's notion of time. Here I will discuss about several aspects of fidelity in individual and collective systems. A first issue that I intend to address is to clarify what is meant by the above properties and what is their distinctive character as well as their peculiar differences — in Aristotelian terms, what is their genus and what are their differentia.