Sustainable Lifecycles in
Information Ecosystems
Main Page People Documents & Software


  • To develop a re-usable experimental framework in which driving forces of ecosystem dynamics can be explored and used to inform key design decisions in species of infohabitants.
  • Definition of a minimal, core modelling language for describing resource utilisation and information exchange between infohabitants.
  • Definition of a set of design principles and hazard analyses (supported by experimental analysis and neutral to software design method) which are key to the success of species of infohabitants in open, loosely structured ecosystems.
  • Case studies relating the observed or reported behaviour of existing, large scale, distributed systems to the responses predicted by our laboratory experiments.
  • Analysis of the divergence between experimental predictions and case studies, with the aim of identifying potential additional driving forces.

  • Description of Work

    The principal aim of this project is to develop a new approach to the design of infohabitants which brings experimental methods from the empirical sciences into the design process. This will be done by building a laboratory framework in which controlled experiments can be performed on ecosystems formed from species of infohabitants, with the behaviour of members of each species being determined by key design decisions made during their construction. These design decisions are the variables in our experimental framework and by exploring the changes in aggregate behaviour of the ecosystem when we change these decisions we gain an experimental understanding of the relationship between these aspects of design and ecosystem behaviour under laboratory conditions. This forms a virtuous cycle in which the results of empirical experiments based on an original set of design variables allows us better to understand appropriate use of these variables; to hypothesise new design decisions; and thus to perform yet more insightful experiments.

    This laboratory framework provides part of the foundation for scientific study of information ecosystems and their design but it also strengthens practice through the production of design rules and investigation of real systems. The contribution to design rules is through the insights into the effects of design choices on ecosystem behaviour, gained through our experiments and necessary in order to make design choices which respect the integrity of the ecosystem. Understanding of real systems is strengthened by using our laboratory behaviours to form hypotheses about the large-scale driving forces which might be expected in real systems and comparing these "pure" results to those observed in practice - with discrepancies driving the search for new driving forces.


  • A minimal, core modelling language for the experimental analysis of resource utilisation and information exchange between infohabitants.
  • A set of design and hazard analysis rules guiding the construction of infohabitants.
  • A laboratory framework which can be re-used and extended by those interested in the empirical analysis of information ecosystems.
  • Case studies relating laboratory results to behaviours observed in real-world, large-scale, open systems.

  • Overview

    Central to this project is the notion of ``lifecycle'. This has two distinct but interacting meanings in information ecosystems. One is analogous to the biological meaning of the word: the progressive sequence of changes experienced by an organism from the moment of fertilisation until its death. For each infohabitant, this is determined by the design of the ``species' to which it belongs and by the environment through which it interacts with other infohabitants under resource constraints. The second meaning of ``lifecycle' is the design lifecycle for a software system. The features possessed by each software infohabitant, enabling it to exist in the ecosystem, are created by designers using a method appropriate to their task and domain. The interaction between the lifecycles experienced by infohabitants and the lifecycles used to design them is via these features. Global properties of an ecosystem (such as its sustainability or the successional change in its species composition) ultimately are determined by infohabitant lifecycles. It is crucial that those designing infohabitants understand as much as possible about the potential effects of their design decisions on global properties of the ecosystem - otherwise designers would be pushing out infohabitants blindly, without concern for the overall health of the system and without knowing how the ecosystem is likely to react. This requires the niche occupied by each infohabitant to be an appropriate one, both from the point of view of the infohabitant and from the perspective of the ecosystem - for example a well designed symbiotic infohabitant would do badly if it occupied a niche which causes it to be attacked as a parasite. The work described in this proposal gives a framework for understanding this issue by blending methods of experiment from ecology with methods of design from computer science.

    The main idea is depicted in Figure 1. This shows, in the centre, a laboratory ecosystem in which experiments are run involving numerous species of complex infohabitants within a controlled environment. Two major processes surround the laboratory. To the left is the design of infohabitants which is constrained by design rules (determining key features infohabitants can have) and hazard analyses (warnings of threats created by design choices). These controls on design are extended and revised in the light of analyses from laboratory experiments, allowing us to feed empirical results relating to ecosystem behaviour back into the definition of design controls - a ``virtuous cycle' of design --> experiment --> redesign. The second major process (to the right) develops an overall theory, for our experimental systems, of the response of ecosystem properties to design decisions.  This influences the conduct of subsequent experimental analyses, which are used to reinforce and extend the experimental theory. It is also compared to case studies from real-world systems which either confirm the experimentally observed behaviour or generate exceptions to it. These exceptions prompt theory revision, giving a second ``virtuous cycle' of experiment --> theorise --> validate --> re-theorise --> re-experiment.

    Figure 1: Conceptual Overview of the Project

    Our aim is to innovate in the design lifecycle and validate with respect to ecosystem lifecycles. We are interested in relating the methods we use to design ecosystem inhabitants to aggregate behaviours observed at the ecosystem level.

    Laboratory Experiments and Large-scale Applications

    Our proposal emphasises the synergy between formal design theory and empirical observation/experiment. The inspiration for this framework derives from the biological sciences. Many of the basic concepts of biological ecosystem theory have their origin in highly controlled experiments tailored to the exploration of particular properties. An example is the analysis of predation between animal populations. An early landmark in this field was the definition in the late 1920's (independently) by Lotka and by Volterra of a set of equations which describe stable oscillations in numbers between predator and prey populations (with the cycle for predators lagging that for prey). Several empirical experiments were run to investigate whether a simple natural system could exhibit this behaviour and all failed to confirm it - the belief then being that such cycles could not be sustained solely through the predator-prey interaction. Then in 1958 Huffaker constructed an experimental system in which one species of mite preyed on another in an artificial environment of oranges, interspersed in places with barriers to make it more difficult for predators to catch prey. This system produced the results which the Lotka/Volterra model predicted and led to a series of refinements of the model driven by more complex experiments (for instance Utida's study of damped oscillations). These experimental results were used as the starting point for numerous analyses of field data from naturally occurring ecosystems. Many of these exhibit cyclic oscillations reminiscent of the experimental model - a classic example being Elton's analysis of Canadian lynx and hare populations. Although (according to Krebs) nobody has found a pure predator-prey oscillatory cycle in field populations, this does not diminish the value of the theoretical and laboratory-based work, which gave the field scientists an insight into the driving forces in such systems and a starting point for exploring those additional factors which explained why the basic predator-prey model did not apply.

    The analysis of information ecosystems is at the Lotka and Volterra stage.  We want to understand how the design of complex inhabitants leads to large-scale properties of ecosystems but if our first step is to study fielded systems we will lack the insights needed to gain from the experience (just as Huffaker would have gained nothing from studying a field population directly). Instead, what we need are precise models of design which give us expectations of the driving forces in such systems.  We then conduct empirical experiments (under carefully controlled conditions) to produce actual systems with large numbers of comparatively simply designed inhabitants for which the properties we hope to find are observed. Finally, we survey fielded systems to test whether they behave in similar ways. Our expectation is that their behaviours would be more complex but that an analysis of the differences from our "laboratory" systems would be revealing, just as the differences between Huffaker's mites and Elton's lynx deepens our understanding of natural species interactions.

    Infohabitant Species Design

    There has been almost no fundamental research on design methods for information ecosystems but one thing is clear: the notions of design method from traditional software engineering are inadequate. This is because traditional software design assumes a closed system where the task of a design team is to delineate the functions of system components and combine these precisely, so that we obtain a tightly integrated system. In an information ecosystem, we do not have a closed system and the inhabitants of such systems require a high degree of autonomy, so tight integration of a traditional sort will not do.  Instead we need methods which allow autonomy of systems within the looser framework of the ecosystem.

    The ``control knobs' on our experiments are design choices.  These are ``conceptual' features of infohabitants - that is, they are important concepts in the design of infohabitants but would not necessarily be identifiable in a single structural component of the inhabitants source code. For example, the ability to revise beliefs about its own knowledge is a conceptual feature which leads an infohabitant to be structured in particular ways but there is unlikely to be a single software component in an infohabitant which has entire and sole responsibility for revising beliefs - instead the fact that it does belief revision will be reflected in several areas of the implementation of the infohabitant.  We intend to focus on three types of feature which are essential to the UIE, although we may discover other features as this project (and others within the UIE) develops.

    Capabilities:  It is envisaged that ecosystems may contain huge numbers of inhabitants and that these inhabitants have a great deal of flexibility in choosing those others with which they interact. It will not be possible to pre-supply each inhabitant with information about the capabilities of other inhabitants; nor will it always be possible to acquire such information from their source code. However, it is necessary that capability information is available in a readily accessible form - otherwise the aim of large-scale, opportunistic interaction cannot be realised. This capability information must be formal, because it will be used without human intervention, but it must be supplied by human designers, because it is not always derivable retrospectively from implemented systems. Design methods must therefore incorporate formal languages for describing capabilities and allow designers to connect them reliably to structural features of the deployed systems. Recent work at Edinburgh has shown how comparatively simple, generic uses of formal languages can be used to provide remarkably effective capability descriptions (which can include ``softer' forms of recognition such as tagging to indicate functionality). This should form the starting point for work on the new project.

    Communication: For an ecosystem to be productive it must be possible for its inhabitants to share information with reasonable degrees of freedom and reliability. Reliability of communication requires formal languages and protocols. Freedom of communication requires inhabitants to possess key properties: reflectiveness (to be able to reason about their own capabilities), openness (the ability to engage in communication without knowing beforehand with whom the communication will take place) and group awareness (the ability to adapt individual behaviour to suit the needs of a group). Reflectiveness is a natural consequence of having a formal capability language. Openness requires mechanisms for negotiation to be addressed in design lifecycles, since there is no guarantee that the objectives of agents will immediately coincide. Group awareness is necessary for ecosystems to exhibit behaviours not attributable independently to individuals, such as ``resource lock' where the resource choice of an individual is determined by the previous choices of other individuals in its social group.

    Resilience: Ecosystems are loosely constrained environments where inhabitants cannot entirely be trusted to supply the right information accurately and there is no guarantee that the information required to make a decision will be provided. The architectures of inhabitants must be flexible enough to allow action when information may not be available but resilient enough to limit the damage caused by precipitant action and/or action taken on false information. A repertoire of methods exists for providing this ability but they are not well integrated into the lifecycle so, for example, it is often difficult to tell when looking at the description of a system which aspects of it are to do with its normal operation and which are responsible for fault tolerance. This makes it difficult to re-use the ``normal' or fault-tolerant parts of systems (since these are intermingled) or to adapt systems for new environments where a different form of fault tolerance may be needed.

    31 July 2002, W Vasconcelos