A Comedy of Errors!

Shakespeare is a constant source of inspiration. As Aristotle touched and influenced all sides of what is now modern science, so Shakespeare did navigate so masterfully through all the meanders and rivulets of the human soul that he's become a touchstone we can hardly fail to refer to in any work of art.

And not just art, actually!

Some years ago I was writing my doctoral thesis on resilience of distributed software systems. The main "character in the play", so to say, was a programming language for the specification of error recovery tasks. The idea was that, when an error is detected in a software program, this would trigger the execution of a second program meant specifically to deal with the errors found in the first one. The second program was written in the programming language I conceived, designed, and implemented during my doctoral studies, which I called ARIEL. ARIEL code was a series of "guarded actions", namely commands that would only be executed when a condition (the "guard") was verified as being true. The hidden side of ARIEL was the so-called Backbone (BB), a system of agents watching the user program and its own components and gathering information about what the user program was having problems with: exceptions, missed deadlines, crashes — much of the whole lot. The general scheme was as follows:

As I said already, programs in ARIEL are given by one or more "guarded actions". An example of those actions is given below:

IF [ FAULTY TASK {MYTASK} ]
THEN
     RESTART TASK {MYTASK}
FI .

I wrote a translator, called "art", to convert lists of guarded actions like the one above into a new program, equivalent in meaning but more suited for being quickly interpreted by a machine ("art" stands for ARiel Translator, natcherly). The new program was called RCODE ("recovery code"). If something went wrong in the main program (for instance a distributed application including a task called "MYTASK"), and if the BB would become the wiser of the bad news, then the BB would start a new special task: the ARIEL interpreter. This task would execute the ARIEL RCODE and eventually bump in the (RCODE translation of the) above IF statements. Condition "FAULTY TASK {MYTASK}" would be found true and as a result TASK {MYTASK} would be restarted. Simple strategy, innit?

ARIEL could do more complex things than that of course. For instance it could manage groups of tasks and make use of special characters to represent subsets of a group of task. As an example, in the following guarded action "STOP TASK@" means "stop of faulty tasks in the current group", in this case group "MY_Group", while "SEND {DEGRADE} TASK~" means "send the DEGRADE message to all the non-faulty tasks in the current group":

IF [ FAULTY (GROUP{My_Group}) ]
THEN
       STOP TASK@
       SEND {DEGRADE} TASK∼
FI

Okay so by now you will be asking "but what ARIEL has to do with Shakespeare and his Tempest??" Well, the name originally came after the spelling of letters "R" "E" "L" (“[a:*]-[i:]-[el]”), for REcovery Language. But then, while reading The Tempest, I found this fragment:

ARIEL My master through his art foresees the danger
            That you, his friend, are in; and sends me forth—
            For else his project dies—to keep them living.

(Shakespeare, The Tempest, Act II, Scene I)

I was amazed—it all seemed to fit together so nicely! In Shakespeare's Tempest spirit Ariel is a magic creature, the invisible assistant of Prospero, the Duke of Milano. All was going a-okay with Prospero and his daughter Miranda, or at least until his brother Antonio decided it was time for him to replace his brother as the new Duke. Antonio wastes no time and has Prospero and Miranda abandoned on a raft at sea, where they would have certainly died were it not for supplies and some books of magic, courtesy of good-hearted Gonzalo. Thanks to those books ("...through his art…") Prospero calls forth "his familiar spirit Ariel, his chief magical agent". (Amazing, isn't it??) And Ariel starts serving Prospero along several threads of action. In particular he conjures a Tempest that brings all characters in the same scene. There Prospero can keep an eye (Ariel's actually) on everybody, good and bad alike. Many "wonders" take place until all wrongs are righted and all evil is banished. All errors are recovered, we could say. Precisely what we expect to have when the ARIEL program stops processing! Magic, isn't it 😉

For more information about this "Comedy of Errors" (and recovery thereof!), you could also have a look at this book! Or ask me your questions here of course 😃

A Comedy of Errors! by Vincenzo De Florio is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Permissions beyond the scope of this license may be available at mailto:vincenzo.deflorio@gmail.com.

Fractal Social Organizations

In our previous post we discussed the challenges of Community Resilience, and especially those pertaining to response/recovery/reduction, as enunciated in the report by Colten, Kates, and Laska. Through that report we understood that one of the major problems following the event was one of coordination. Coordination among institutional responders was difficult and inefficient, and even more so it was between institutional and “informal responders” (non-institutional responders, originating in “households, friends and family, neighborhoods, non-governmental and voluntary organizations, businesses, and industry”, called by the authors “Shadow Responders”). We saw how a major challenge of Community Resilience is that of being able to solve those coordination problems. A possible way to reformulate it is that of conquering the complexity and engineering practical methods to dynamically create a coherent and effective organization-of-organizations as a response to disasters. The major goal of such an organization-of-organizations (OoO) would be that of enabling mutualistic relationships between all the involved social layers and produce mutually satisfactory, self-serving, controllable “social behaviors” enhancing the efficiency and the speed of intervention. In what follows I discuss now one such possible OoO that I call the “fractal social organization.”

In what follows I will make use of Professor Knuth’s characters to label paragraphs that contain information intended for nerds like me. All sane people willing to preserve their sanity may skip those paragraphs with no repercussion on the already compromised readability of this text.

Fractal Social Organizations (FSO) are an application of fractal organizations to socio-technical systems. In a nutshell, they are a “special” organization-of-organizations whose building blocks are “special” socio-technical systems called Service-oriented Communities (SoC). I’ll now try and explain what is so special in SoC and FSO.

An SoC is a service-oriented architecture that creates a community of peer-level entities – for instance human beings, cyber-physical things, and organizations thereof. These entities are called members. No predefined classification exists among members. No specific role is defined; for instance there are no predefined clients or servers, service requesters or service providers, care-givers or care-takers, nor responders or assisted ones. Depending on the situation at hand a member may be on the receiving end or at the providing end of a service. Members (may) react to changes. If something occurs in a SoC, some of its members may become active. Being active means being willing to play some role. Service availabilities and service requests, together with events, are semantically annotated and published into a service registry. The service registry reacts to publications by checking whether the active members may play roles that enable some action.

This is in fact like in dataflows, in which it is the availability of the inputs that triggers the execution of a function. Members become like the virtual registers in Tomasulo’s algorithm…

This check is done semantically, by discovering whether the published services are compatible with the sought roles. “Costs” may be associated with a member being enrolled. Enrolments may be done in several ways, each aiming at some preferred goal – for instance speed of response, safety, or cost-effectiveness. Furthermore, the optimization goals may focus on the individual member, or have a social dimension, or take both aspects into account.

A nice thing with the SoC and the above assumptions is that they enable mutualistic relationships. In this paper Sun et al. suggested that two elderly persons requiring assistance could find an adequate and satisfactory response by helping each other – thus without the intervention of carers. An interesting thing not yet done is to experiment with mutualistic relationship with more than two members and with different roles – for instance mutualistic relationships between two service providers (for instance, an institutional responder and a shadow responder in the response phases of some crisis). (Obviously this would call for agreeing on collaboration protocols, establishing common ontologies to reason on possible triggering events, discussing policies and modes of intervention, and several other aspects; we consider this to be outside the scope of the present discussion).

In fact one of my future goals is to try and simulate the SoC behaviours to see whether new mutualistic relationships would emerge!

As mentioned before, no predefined role exists in a SoC, though the creation of a new SoC calls for appointing a member with the special role of service coordinator. It is such member that hosts the service registry and performs the semantic processing. The coordinator may be elected and there could be hot backups also maintaining copies of the service registry as described in here or elsewhere. A SoC may be specialized for different purposes – for instance crisis management or ambient assistance of the elderly and the impaired. More information on an SoC devoted to the latter and called “Mutual Assistance Community” may be found, e.g., here.

A major aspect of the SoC is given by the assumption of a “flat” society: a cloud of social resources are organized and orchestrated under the control of a central “hub” – the service coordinator. Of course this flat organization introduces several shortcomings

In particular scalability and resilience: if the size of the community becomes “too big” the coordinator may be slowed down; and of course in the presence of a single and non-redundant coordinator a single failure may bring the whole community to a halt!

The Fractal Social Organization was created to solve the above mentioned shortcomings. The nerdy definition of FSO is as follows:

A Fractal Social Organization is a fractal organization of Service-oriented Communities. A Service-oriented Community is a trivial case of a Fractal Social Organization consisting of a single node.

In practice, if a SoC is allowed to include other SoC as their members, we end up with a distributed hierarchy of SoC, one nested into the other. This is a little like nested directories in a file system or “matryoshka dolls” (but such that each doll may contain more than a single smaller doll.)

This is nothing new of course. Society includes many examples of such “fractal organizations”; “the tri-level system (city, state, federal) of emergency response” in use in the States and mentioned in CARRI report no. 3 is one such example. The added value of the FSO is that it implements a sort of cybernetic sociocracy. Sociocracy teaches us that it is possible to lay a secondary organizational structure over an existing one. The idea is that the elements of a layer (in sociocracy, a “circle”) may decide that a certain matter deserves system-wide attention; if so, they appoint a member as representative of the whole circle. Then the appointed member becomes (temporarily) part of an upper circle and can discuss the matter (e.g., propose an alternative way to organize a process or deal with a threat) with the members of that circle. This allows information to flow beyond the boundaries of strict hierarchies; real-life experimentation proved that this enhances considerably an organization’s resilience. Through the sociocratic rules, an organization may tap on the full well of its social energy and create collective forms of intelligence as those discussed by George Pór here. FSO propose a similar concept. Whenever a condition calls for roles, the coordinator looks for roles by semantically matching the services in its registry. If all roles can be found within the community, the corresponding activity is launched. When certain roles are missing, the coordinator raises an exception to the next upper layer – the next matryoshka doll up above, that is to say. The role shortcoming event is thus propagated to the next level upward in the hierarchy. This goes on until the first suitable candidate member for playing the required role is found or until some threshold is met. The resulting “responding team” is what I called a social overlay network: a network of collaborating members that are not restricted to a single layer but can span dynamically across multiple layers of the FSO. Such new “responding team” is in fact a new ad hoc Service-oriented Community whose objective and lifespan are determined by the originating event.

Much is yet to be done. The FSO protocols have not been even formalized and only a partial and static version of the system is currently being implemented. Some results are already available though: my mathematical model of the activity of a flat service-oriented community shows the emergence of self-similarity, modularity, and a structured addition of complexity, which we conjectured in our previous post as being two of the most important “ingredients” towards community resilience. The idea is being used, albeit in a limited form, in the framework of a national project in Flanders. IBM selected FSO as one of the winning projects for their Faculty Awards for 2013. Only future will tell if all this will lead to a practical definition of an FSO for community resilience.

Fractal Social Organization for society {0,1,1,1,1,2,2,3,3,3,3,4}. More information and other pictures available here.
Fractal Social Organizations by Vincenzo De Florio is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.
Permissions beyond the scope of this license may be available at mailto:vincenzo.deflorio"gmail.com.

The Challenges of Community Resilience

In my last post I discussed collective forms of resilience. I now focus on a particular aspect of this “social resilience”, namely what is largely discussed as Community Resilience.

According to RAND,

“Community resilience is a measure of the sustained ability of a community to utilize available resources to respond to, withstand, and recover from adverse situations. […] Resilient communities withstand and recover from disasters. They also learn from past disasters to strengthen future recovery efforts. The Resilience in Action website offers toolkits, training, multimedia, newsletters, and other resources to help communities build and strengthen their resilience.”

From the above definition we can observe that resilience in this case also includes a community’s ability to learn from the past and become more robust in so doing – a sort of social antifragility.

As important asset to understanding Community Resilience is paper “COMMUNITY RESILIENCE: LESSONS FROM NEW ORLEANS AND HURRICANE KATRINA,” by C. E. Colten, R. W. Kates, and S. B. Laska, research report 3 of the Community and Regional Resilience Institute (CARRI). The three Scholars provide an insightful discussion of several important factors that resulted in the resilience behaviors that emerged during the Hurricane Katrina events. Their definition of resilience is slightly different from RAND’s; it is

“a community or region’s capability to prepare for, respond to, and recover from significant multi-hazard threats with minimum damage to public safety and health, the economy, and national security.”

Accordingly, the authors identify four major “activities” responsible for the emergence of resilience: anticipation of threats; response to threatening events; disaster recovery; and vulnerability reduction.

It is interesting to note that in this case vulnerability reduction is carried out, so to say, “outside” the system: the greater resilience is reached by strengthening the protection and emergence infrastructures, thus it is not a consequence of a system’s learning processes but rather of the processes of the designers and the managers of the system; it is thus more enhancing elasticity rather than achieving antifragility.

After analyzing weaknesses and strengths of New Orleans and discussing the above major activities, the authors discuss anticipation/response/recovery/reduction before, during, and after Hurricane Katrina. Ongoing and future action to improve the performance of the above activities is reported. Lessons learned are finally summarized.

A remarkable fact observed by the authors is that the response to the disaster was far from ideal:

“Through extensive media coverage, the world saw remarkably inadequate rescue operations, the failure of complete evacuation, […] What amazed many worldwide was that these extensive failures, often attributed to conditions in developing countries, occurred in the most powerful and wealthiest country in the world.”

This is particularly surprising in that the severity of the situation was well known, as it was also well known how the New Orleans area would have had difficulties in the face of catastrophic events:

“New Orleans was a catastrophe waiting to happen with extensive and repeated warnings from both scientists and the media that the “big one” would eventually hit the city.”

This fact in particular stirred my imagination. I was born in a land rich with seismic and volcanic activity, though considerably less wealthy and powerful, which made it quite obvious to me that it would be preferable to learn about Community Resilience failures in an indirect way.

The major lesson that I derived from this case is that an event like Katrina disrupts several concentric “social layers” at the same time, and that one of the major problems following the event is one of coordination. Multiple concurrent responses are triggered in each of the social layers, including

• the individual, the family, people sharing the same location, citizens, etc.;
• pre-existing organizations of the city, the region, the state, the nation;
• pre-existing organizations for civil protection, defense, order, etc.

A major classification among the above responders is that of Institutional responders (namely the social layers corresponding to the above pre-existing organizations) and informal responders (non-institutional responders, originating in “households, friends and family, neighborhoods, non-governmental and voluntary organizations, businesses, and industry” and corresponding to informal care-givers in ambient assisted living).

Coordination failures derive from a number of reasons, the most important of which are possibly the following ones:

• Conflicting goals and conflicting actions among the triggered responders. Multiple uncoordinated efforts often result in wasting resources and in some cases they mask each other out.
• As a simplistic way to avoid or recover from this kind of failures, institutional responders tend to refuse or do not blend their action with that of informal responders.
• Resources owned by institutional responders are not shared dynamically according to the experienced needs.

The report by Colten, Kates, and Laska provides rich and valuable knowledge, which helps understand how relevant the above reasons were in determining the quality of resilience and the speed of the recovery after Katrina. It also provides us with a major challenge, which the authors enunciate as follows:

“[Responders] would have been able to do more if the tri-level system (city, state, federal) of emergency response was able to effectively use, collaborate with, and coordinate the combined public and private efforts. How to do so, in advance of hazard events, is a central task of enhancing community resilience.”

Is it possible to find a satisfactory answer to the above challenge? Which tools, which form of organizations may serve as an effective foundation on top of which community resilience may be built? Let me just focus on the response to the events. The answer, in my humble opinion, should be characterized by the following attributes:

• Scalable: The building blocks of the response organization should be applicable at all social layers, ranging from micro scale (individual or small groups) up to macro level (national or world-wide institutions).
• Fractal: The building blocks of the response organizations should be free from the hard restrictions of pure hierarchical organizations. The action and role of each social layer should not be restricted by its hierarchical level into that of a controller or that of a controlled, but rather dynamically defined.
• Context-driven: The above mentioned action and role should be defined through an assessment of the context and situations at hand, possibly involving multiple collaborating entities and layers.
• Self-servicing: Forms of mutualistic collaboration should be identified so that common requirements may become mutually satisfactory.
• Service-oriented: Services and assets should be easily and quickly localizable, shareable, and accountable.
• Semantic: Services and assets across the social layers should be semantically described in a uniform way allowing for quick service matching.
• Collaborative: Collaboration among entities in different social layers should be easy to settle and result in the spontaneous emergence of new temporary inter-layered “social responders”. Said “social overlay networks” would combine responders of different scale and different originating social layers and exist until some originating purpose is being reached.
• Modular: Self-similar collaborative “patterns”, or modules, should be reusable at different scales. A dynamic ranking mechanism should allow the performance of modules in a given context to be tracked.

My next post will describe an organization matching the above attributes – the fractal social organization.

The Challenges of Community Resilience by Vincenzo De Florio is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.
Permissions beyond the scope of this license may be available at mailto:vincenzo.deflorio@gmail.com.

The Need for Collective Forms of Resilience

It is remarkable how, in the course of its history, mankind has time and again locked in on biases and privileged directions that confine its progress and welfare. A classic example is given by the geocentric model of the Ptolemaic system. Two other examples of such lock-ins are represented by the concepts of individualism and competition, both of them eloquently captured in Hobbes’ definition of the “natural state of things” as “the war of every one against everybody”. In fact the individual-centric and purely competitive models became heavy cornerstones of our societies and were celebrated in many an important work. Examples of this may be found in Locke’s “Essay Concerning Human Understanding” (1689) and Smith’s conjecture of the “Invisible Hand”, which influenced and reverberated for centuries in the work of many scholars and philosophers.

A strong argument against any theory only considering individualism and competition was issued by Darwin, whose principle of mutual struggle appeared to bring irrefutable scientific evidence to the supremacy of the concepts of competition and the individual.As a matter of fact, Darwin himself was well aware that competition and mutual struggle are an important strategy though not the only one, and that in nature in certain cases it is collective cooperation rather than individualistic struggle that results in the winning strategy. In fact in his “Descent of Man” Darwin refers to the "power of sympathy" and states that

"those communities, which included the greatest number of the most sympathetic members, would flourish best, and rear the greatest number of offspring".

Among the first ones to highlight that both cooperation and competition coexisted in Darwin’s treatises was probably Pëtr A. Kropotkin. In his work "Mutual Aid: A Factor of Evolution" Kropotkin raised an important question:

"Who are the fittest? Are those organisms the fittest which are constantly waging a war of extermination against every other organism in the struggle for existence, or, are those the fittest which cooperate with each other in the preservation of the common life of all?"

Kropotkin’s answer is the same as Darwin’s: through several examples in the societies of animals and men he remarks how both competition and collaboration are important strategies towards survival and welfare of animal species and societies:

“It is evident that no review of evolution can be complete unless these two dominant currents are analyzed [...] The struggle between these two forces make, in fact, the substance of history.”

More recently, the limitations of the pure individual-centric, competitive-oriented model—especially when the environment becomes resource-scarce and turbulent—were masterfully discussed by Hardin in his “Tragedy of the Commons”. In that celebrated treatise the great scholar remarks how such model, coupled with an ever increasing overpopulation, results in the rapid exhaustion and pollution of earth resources and is introducing unprecedented turbulent and chaotic scenarios in our global ecosystem.

In more recent times the necessity to extend the purely individualistic and competitive model so as to include other forms of interaction emerged in several domains. Ecology, biology, mathematics, computer science, sociology, and economy, are examples of disciplines that time and again put to the foreground the efficacy of other forms of interaction in systems ranging from bacteria to business ecosystems. As an example, beginning with the 1980s economy and management science experienced a crisis of the traditional concept of organization- environment relations: The classic model of a so-called focal organization taking individual actions to capture value under a system of pure competition revealed intrinsic weaknesses when facing ever more complex and turbulent environments. The awareness of the need to go beyond the purely individual models of organization and strategic choice and of pure competition initiated a process of rethinking that led to the emergence of concepts such as collective strategies, co-opetition, and business ecosystems.

Collective resilience strategies are not new; they are the default strategy used in nature to protect the individual and the species. Individuals unite either to become a social predator or a social prey; the unite to augment artificially their perception; to benefit from different features in different contexts, and so on. It is only through collaboration that the individual and the species compensate for the very slow speed of evolution with respect to the onset of change. Thus I believe an important requirement for the resilience of future cyber-physical societies will be the ability to learn from both nature and practice how to establish dynamically mutualistic relationships as exemplified, e.g. in the Canary Agent and Miner Agent scenario discussed here.

The Need for Collective Forms of Resilience by Vincenzo De Florio is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
Permissions beyond the scope of this license may be available at mailto:vincenzo.deflorio@gmail.com.

The Black Holes of complexity

Is it good or is it bad if the hardware and software complexity are hidden to the software designer? If you're a designer, you will probably tend to say "It's very good! Why the hell should I be interested in the type of transport protocol my software's going to use? What difference would it make if I knew what system calls are being executed in the background? Or if my software stores local data in SDRAM memory chips or elsewhere??" I'm sure the general opinion would be that all the above choices don't really matter that much — apart maybe from some difference in performance!

What is certainly true is that the road to complexity hiding provided the developer with abstract ways to compose ever larger "blocks" of functionality in short time and in easy and intuitive ways. First modules and layered organization; then object orientation; and more recently visual languages, services, components, aspects, and models, provided the developer with tools to compose and orchestrate highly powerful and sophisticated software systems in a relatively short amount of time.

But... there is a but regrettably. First of all, though hidden, still such complexity is part of the overall system being developed. And secondly, as it's become so easy to deal with complexity, more and more functionality is being put in place. In other words, software (and in general, computer systems) have become sort of black holes of complexity: they attract more and more complexity that simply disappears from our sight although makes the system more and more "heavy" — hard to predict and control.

As I mentioned somewhere else,

Across the system layers, a complex and at times obscure “web” of software machines is being executed concurrently by our computers. Their mutual dependencies determine the quality of the match of our software with its deployment platform(s) and run-time environment(s) and, consequently, their performance, cost, and in general their quality of service and experience. At our behest or otherwise, a huge variety of design assumptions is continuously matched with the truth of the current conditions.

A hardware component assumed to be available; an expected feature in an OSGi bundle or in a web browser platform; a memory management policy supported by a mobile platform, or ranges of operational conditions taken for granted at all times — all are but assumptions and all have a dynamically varying truth value. Depending on this value our systems will or will not experience failures. Our societies, our very lives, are often entrusted to machines driven by software; weird as it may sound, in some cases this is done without question — as an act of faith as it were. This is clearly unacceptable. The more we rely on computer systems — the more we depend on their correct functioning for our welfare, health, and economy — the more it becomes important to design those systems with architectural and structuring techniques that allow software complexity to be decomposed, but without hiding in the process hypotheses and assumptions pertaining e.g. the target execution environment and the expected fault- and system-models.

How to deal with this problem is still a matter of discussion. My idea is that it should be made possible to express, manage, and execute "probes" on the dynamic values of our design assumptions. While the "black hole" would remain largely hidden, those probes would help "enlight" on the likelihood that our hypotheses are actually met by the current conditions of the system and its deployment environment. A possible way to organize those probes could be maybe that of a distributed organization of cooperating autonomic digital entities, each of them representing a different unit of information encapsulation: a layer, an object, a service, etc., mimicking the structure and organization of the corresponding entities. A fractal social organization of said probes could provide with autonomic ways to deal with ever growing amounts of complexity without reaching the event horizon of unmanageability.

The Black Holes of complexity by Vincenzo De Florio is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Permissions beyond the scope of this license may be available at http://win.uantwerpen.be/~vincenz/.

ANTIFRAGILE 2014: 1st Workshop "From Dependable to Resilient, from Resilient to Antifragile Ambients and Systems"

As well-known, 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 goes one step further and 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 N. 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 and ambients 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 promises to enable realizing 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, and energy efficiency; to personalize their aspects and behaviors after each and every user. And to learn how to get better while doing it.

The ambition and mission of ANTIFRAGILE is to enhance the awareness of the above challenges and to begin a discussion on how computer and software engineering may address them. As a design aspect cross-cutting through all system and communication layers, antifragile engineering will require multi-disciplinary visions and approaches able to bridge the gaps between “distant” research communities so as to

• propose novel solutions to design and develop antifragile systems and ambients;
• devise conceptual models and paradigms for antifragility;
• provide analytical and simulation models and tools to measure systems ability to withstand faults, adjust to new environments, and enhance their resilience in the process;
• foster the exchange of ideas and lively discussions able to drive future research and development efforts in the area.

The main topics of the workshop include, but are not limited to:

• Conceptual frameworks for antifragile systems, ambients, and behaviours;
• Dependability, resilience, and antifragile requirements and open issues;
• Design principles, models, and techniques for realizing antifragile systems and behaviours;
• Frameworks and techniques enabling resilient and antifragile applications;
• Antifragile human-machine interaction;
• End-to-end approaches towards antifragile services;
• Autonomic antifragile behaviours;
• Middleware architectures and mechanisms for resilience and antifragility;
• Theoretical foundation of resilient and antifragile behaviours;
• Formal modeling of resilience and antifragility;
• Programming language support for resilience and antifragility;
• Machine learning as a foundation of resilient and antifragile architectures;
• Antifragility and resiliency against malicious attacks;
• Antifragility and the Cloud;
• Service Level Agreements for Antifragility;
• Verification and validation of resilience and antifragility;
• Antifragile and resilient services.

ANTIFRAGILE is co-located with the 5th International Conference on Ambient Systems, Networks and Technologies, June 2 - 5, 2014, Hasselt, Belgium.

For more information please visit ANTIFRAGILE 2014.

Lessons From the Past

I must confess that until a few time ago I didn't know the extinction of dinosaurs is not the only or the most severe of the extinction events our Earth has experienced. Citing from Wikipedia,

"the Cretaceous–Paleogene (K–Pg) extinction event [..] was a mass extinction of some three-quarters of plant and animal species on Earth—including all non-avian dinosaurs—that occurred over a geologically short period of time 66 million years ago".

[Wikipedia]

This certainly sounds quite bad, but in fact not as bad as the so-called Great Dying,

the "Permian–Triassic (P–Tr) extinction event [..] that occurred 252.28 million years ago. [..] It is the Earth's most severe known extinction event, with up to 96% of all marine species and 70% of terrestrial vertebrate species becoming extinct. It is the only known mass extinction of insects. Some 57% of all families and 83% of all genera became extinct."

[Wikipedia]

Thus some 252 million years ago a chain of events produced a catastrophe that affected so deeply the terrestrial ecosystem that it is conjectured "it took some 10 million years for Earth to recover" from it. Nevertheless, the Earth ultimately did recover from it, which led to so big a change in natural history that scientists had to clearly separate what was before from what followed, the Paleozoic ("Old Life") from the Mesozoic (the "Middle Life"). Among the many important questions that raise when considering so catastrophic an event, some that I feel are particularly relevant here are:

• Q₁: Was there any "common reasons" behind the P–Tr extinction event? In other words—were there "common triggers" causing such a widespread correlated failure?
• Q₂: What was the key ingredient—the key defensive strategies that is—that made it possible for the Earth to survive in spite of so harsh a blow?

Now in order to attempt an answer to the above question I recall the following facts:

• F₁: "Mineralized skeletons confer protection against predators" [Knoll]
• F₂: "Skeleton formation requires more than the ability to precipitate minerals; precipitation must be carried out in a controlled fashion in specific biological environments" [Knoll]
• F₃: "The extinction primarily affected organisms with calcium carbonate skeletons, especially those reliant on ambient CO₂ levels to produce their skeletons" [Wikipedia].

In other words, one of nature's many independent evolutionary paths was particularly successful (F₁) and thus become widespread; regrettably, the adoption of the solution implies a strong dependence on predefined and stable environmental conditions (F₂); and, finally, a correlation exists between the class of species that adopted the solution and that of the species that were affected most by the P–Tr extinction event (F₃).

If we read the above with the lingo of computer dependability and resilience we could say that:

• A given solution became widespread (for instance a memory technology, a software library, a programming language, an operating system, or a search engine).
• The solution introduced a weakness: for instance, a dependence on a hidden assumption, or a "bug" depending on certain subtle and very rare environmental conditions.
• This translated in a common trigger, a single-point-of-multiple-failures: one or a few events "turned on" the weakness and hit hard on all the systems that made use of the solution.

A good example of this phenomenon is probably given by the so-called Millennium Bug.

What can we conclude from the above facts and analogies? That solutions that work well in the "common case" are those that become more widespread. Regrettably this decreases disparity, namely inter-species diversity. Species that externally appear considerably different from each other in fact share a common trait -- a common design template. This means that whenever the "common case" is replaced by the very rare and very bad "Black Swan", a large portion of the ecosystem is jeopardized. In fact the rarest the exceptional condition, the more widespread is the template and the larger the share of species that will be affected. This provides some elements towards an answer for question Q₁: yes, there were common triggers that ultimately produced the P–Tr extinction event by increasing the diffusion of the same "recipes" thus paving the way to large amounts of correlated failures. On the other hand, the Earth did survive the Great Dying and other extinction events. Why? My guess for an answer to Q₂ is that Nature introduces systemic thresholds that make sure that disparity never goes beyond some minimum. The key ingredient to guarantee this is diversity: it is not by chance that mutation is an intrinsic method in genetic evolution. Mutation and possibly other mechanisms make sure that, at any point in time, not all of the species share the same design templates. In turn this guarantees that, at any point in time, not all the species share the same fate.

Interestingly enough, similar solutions are sought also when designing computer systems. In order to decrease the chance of correlated failures multiple diverse replicas are executed in parallel or one after the other. It's called design diversity and it's often based on design templates such as N-version programming or Recovery Blocks.

(It is worth remarking how the adoption of the design diversity templates also decreases disparity... yes, it's a never ending story.)

The major lesson we need to learn from all this is that diversity is an essential ingredient of resilience. Bring down diversity and you decrease the chance the ecosystem will be able to withstand the Black Swan when it will show up. (And, given enough time, rest assured it will show up). High diversity means that a large number of systems will be put to test with new conditions when the Big One strikes. Even when most of the system-environment fits will decree extinction (or system failure), still a few systems, by chance so to say, will have the right elements to pass through the sieves of the Black Swan with limited damage. And it's those limited few that are going to inherit the Earth.

Lessons from the Past by Vincenzo De Florio is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Permissions beyond the scope of this license may be available at http://win.uantwerpen.be/~vincenz/.