Friday, 31 January 2014

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:

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}) ]
       STOP TASK@

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 😃

Creative Commons License
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

Monday, 6 January 2014

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.
Creative Commons License
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"