‘Contextual complexity’ provides an ‘objective’ perspective (as far as it can be) on the realities of the context and is the basis of exposing givens, realities and unspoken assumptions. When practitioners wish to establish their Contextual complexity (by undertaking ‘Symptom Sorting’) they will have to examine the types of phenomena manifested in the particular situation with which they are concerned and describe in objective terms, as far as possible, the nature of the context in which these phenomena are arising. There is then a range of organisational forms that can be matched to the contextual complexities. Four typical examples are described below.
Migration and transition between these four types of organisational forms (or types of ‘communities of interest’ (CoIs) as they might be more appropriately called) over time may occur as either institutional forms become firmer or as greater agility is required. From any transition or migration as a result of changing contexts follows the need to morph to the adapt and access the necessary capabilities required, including the kind of interoperability that is suitable. This continuum is illustrated below:
Organisational Form Type 1: Self-contained, pre-defined, ‘establishment’:
This type of organisational form is for systems in contexts that are well known with mostly linear relationships:
* There is a single design authority responsible for design, development and implementation;
* The subsystem capabilities and data regarding, for example, coordinate systems in use, spatial accuracy, data consistency, etc are determined at design-time and sharing is enabled through pre-determined mechanisms;
* The relationships between subsystems are agreed in advance of any interaction;
* Any exchanges between subsystems are point-to-point and have pre-defined information exchange requirements; External exchange with other systems (‘interoperability’) is minimal;
* The systems and their subsystems remain linked over ‘long’ periods of time during which the configurations and overall relationships are largely static;
* Certainty and efficiency of these systems are high, but flexibility and robustness are low, as the system relies on the whole system working as intended;
Such self-contained systems are good for stable, well-understood and physically and virtually protected environments, but not flexible in the face of unexpected change.
Organisational Form Type 2: System of Systems (SoSs), established institutionally over time, ‘enterprise’:
In this type of form, ‘systems’ work with a common, agreed context, though each sub-organisation has its own sub-intent. Each of these intents is pooled with the others, following the formulation of a common intent, into a standardised system-of-systems where user interactions and processes are streamlined as well. For these SoSs it can be noted that:
* The systems ‘participating’ in SoSs are semi-independent entities who agree to share selected information via agreed mechanisms;
* The design authority for the system is established by a committee of nominated design representatives;
* The participating systems may not join and leave as they please, as the agreements established through the SoSs put obligations on them that they have agreed to at the outset;
* Interoperability is obtained using pre-agreed standards that can be open source or proprietary, based on the ‘harmonization’ of data specifications regarding semantics, reference systems, and scale etc;
* The overall relationships are firm and well-defined between the systems, and reliable collaboration can be achieved under the agreements;
* The effectiveness, flexibility, certainty etc. can be modest because of collaboration overhead that can occur for individual systems; the robustness is medium as there are no common services involved;
Systems of Systems are good for partners working together in familiar, ongoing contexts over time.
Organisational Form Type 3: Federations – federates join and share services in a ‘plug and play’ manner (regularised coalitions, ‘community’):
In this case, events define the ‘context’ which are shaped by circumstances, the user needs are context-driven and fluid. Federations are established are largely agreed ‘on-the-fly’. In a federation, a number of collaborators have their own intent, parts of which are traded-off to achieve shared goals as circumstances require. This shared intent is formulated based on consensus and compromise between federates and owned by all federates. Shared federation resources are established and relied upon by the federates. Federations can be imagined as collaboration through and / or the provision of services in the ‘Cloud’. These ‘come-as-you-are’ communities-of-interest are characterised as follows:
* Federations are context-driven groupings of pre-existing entities, with nested and overlapping memberships that have ‘porous’ boundaries between them;
* The federates explicitly join the federation and, whilst remaining ‘independent’, accept obligations from, and subordinate themselves to some aspects of the federation;
* The federates place obligations on the federation in return to provide common services;
* The relationships between federates are determined in the moment, and can be transitory or long-term – all exchanges between the federates are negotiated dynamically;
* The interoperability between the federates is based on open standards and relies on these enabling standards being implemented among federates upfront and evolved over time;
* Overall, these federations are enduring and adaptive though they require a minimal ‘critical mass’ to be viable;
* The dynamic run-time effectiveness is high. Overall, certainty is high, but local levels of service may be lowered as federates may drop in and out.
Federations are good for real-world situations of all types where diversity enables effective, successful operations, as in cross-agency and cross-disciplinary working where federates work in flexible, complementary ways.
Organisational Form Type 4: Independent ‘Ad-hoc’ ‘Social Networking‘ activity built on whatever is available (extreme coalitions, crowds and crowdmapping):
This organisational form is found in contexts that are ever-changing and unpredictable. As such there are no pre-established user requirements and built-in assumptions are minimal – actual needs emerge with the dynamics of the situation. Each entities’ individuality and integrity is retained and communities form on an ad-hoc basis in a self-organized manner, following a transient shared purpose. The characteristics of this kind of setup are as follows:
* Independent entities share information and come together as they choose and / or as circumstances dictate;
* There is no design authority, other than that pre-existing resources and infrastructure are used if available;
* The interoperability is virtual and emergent – largely socio-technical. Interactions take place with whatever and ‘whoever’ is available, between ‘entities’ that offer technical and non-technical services;
* People and entities join and leave as they please – there are no obligations on anybody;
* The relationships that are formed are of a transitory nature and largely emerge by themselves;
* The ad-hoc collaboration is enabled and achieved via wikis, social networking etc;
* For such a setup, effectiveness, timeliness and flexibility can be high. These ad-hoc communities can also spontaneously disperse, so the robustness in this type of user scenarios as such is low, but resilience in the face of unexpected disruption is high, as there are no single points of failure;
In summary, ad-hoc collaboration is good for disasters and high-tempo activity in the face of uncertainty and dynamically changing circumstances in which flexibility and adaptation are required and / or essential.
For an example of these constructs applied in the Geoinformation context see also:
* Broenner C. (2012): Appropriate Interoperability: From technical to socio-technical. In: Behr, F.J.,et.al. (Editors): Geoinformation – Catalyst for planning, development and good governance. Applied Geoinformatics for Society and Environment 2012, pp 203-210.
(c) 2012. The abaci Partnership LLP