Robustness

There is no such thing as a perfectly robust system. In an electronic system, a single light might go out, and the whole system stops; in a biological system, a single organism may die off and disrupt the work; in a social system, an individual may decide to run off to live with the penguins in Antarctica and leave a gap in their society. We are interested in finding the most efficient ways of dealing with such occurrences. Therefore, we asked the teams how they would deal with any absences or issues.

• We found that in most teams, there would be several people working on same/similar tasks, so that they could pick up each other's work in case of absence/dropping out. Redundancy is a the most common/efficient way to ensure robustness.
  For each part, there would be at least one back-up person.
  There are several people working on relevant things, so if somebody dropped out, someone else should be able to pick up the work.
• We also found that, in order to achieve redundancy, certain amount of flexibility is needed from the members -- they need to have the skill/ability to switch between tasks.
  Everyone has their main area of responsibility, but helps around where they can, so there is flexibility.
• A common answer was that people could replace those who work within their area of expertise (e.g. wet-lab for biologists, modelling for engineers), yet couldn't help those in other areas. -- Specialisation is very evident in teams, and has to be taken into account when planning for redundancy.
• Another important factor is the cost of redundancy: several people admitted that, in order to be able to replace another member of the team, they would need to do extra research and need extra time, which they would not necessarily have. -- Additional resources are needed to ensure robustness; a trade-off between cost and efficiency may be needed.
  I would be able to replace people within my own area of expertise, it would just depend on how much time I am willing to give to learn the things I need.

Relevance for bacterial system design

In terms of bacterial system robustness Wittebolle and colleagues (2009) discussed a principle they called “insurance hypothesis”. This means that (1) there should be functional redundancy and (2) the need for relative abundances among those redundant species. Redundancy is the taking over of a population with redundant function (ie the same function) after disturbance of the original population. In other words, there are multiple strains able to perform a particular function and are therefore in the same functional group. They showed that for a population to respond adequately to stress, there has to be an even distribution of those redundant members in functional groups. Considering that populations in bioreactors for example are often exposed to perturbances, the bacteria need to have mechanisms in place to counteract these. If the populations are diverse enough, there is a high chance for “backup strains” with parallel pathways, which makes the system more robust.

We therefore should think about specifically introducing redundancy into our system. That way, if one strain fails, another one could pick up its task. However, as we have discussed previously, we still want to achieve a high degree of specialisation as well. It therefore looks like realistically seen, we need to find a trade-off between strain specialisation and functional redundancy to make the system as robust as possible without severely impairing the population's output efficiency.

Wittebolle et al (2009). Initial community evenness favours functionality under selective stress. Nature 458: 623-626.