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"