SEM2007 Approach

Approach

The motivation for this project came from Biomimicry, "a new science that studies nature's best ideas and then imitates these designs and processes to solve human problems." (A Conversation with Janine Benyus). Part of the Biomimicry methodology maps the problem statement to a set of biological challenges and habitat conditions, then looks for species, often called 'champion adapters', that are particularly adept at solving these challenges. This can either lead to published information that can then be applied in the design situation, or suggest opportunities for further research. This approach can be very fruitful, but currently requires access to experts in biology.

The unique nature of 'champion adaptors' also reduces the ability of re-use. In Biomimetics - its theory and practice, Julian Vincent pointed out that "every time we need to design a new technical system we have to start afresh, trying and testing various biological systems as potential prototypes and striving to make some adapted engineered version of the biomimetic device which we are trying to create." Although a Biomimicry Portal is under development, its focus has been on specific architectural functions. The Patterns project was intended to be complementary to both approaches by investigating and documenting more general and recurrent natural solutions, structured in a form that would be easily accessible and usable by designers. Such information could be distributed using the Biomimicry Portal. In addition, the information could help facilitate ""A holistic view of biomimicry [that] involves incorporation of life’s general characteristics in design and application of these characteristics across multiple spatial, temporal and organizational scales of engineering influence." (John Reap, 2005).

The original intent was to identify and document recurrent solutions from nature, using examples and counter-examples from human design to help communicate the concepts to designers. This approach proved to be limiting, in that it suggested a discontinuity between natural and technical systems, where the intent was a smooth transfer of knowledge. It also considered technical solutions and examples as an afterthought. To resolve these issues, the project shifted to looking systems in general, based on the following assumptions:

• There are really very few 'new' ideas. A lot of innovation involves rediscovering and adapting existing ideas, often from other fields.
• Good designs are those that 'fit' well within a context. This ties the design to a specific 'place' and a larger system.
• Designs can deliver powerful and unexpected benefits when the larger system is considered.
• Systems of even moderate complexity often act in complex and unpredictable ways, through iteration and interaction between components.
• Although apparently contradictory to the previous assumption, systems are fundamentally simple and based on a relatively small number of principles, otherwise they would quickly self-destruct. This does not imply that we understand how these systems work.

These assumptions suggest a number of implications:

• Studying effective solutions from other fields can be an effective and efficient way to deliver innovation.
• 'Good designs' are useful, solving real problems.
• 'Good designs' reveal themselves over a period of time, due to the unpredictable and dynamic nature of systems. We need to watch how designs are used, fine-tuning them to improve the 'fit'. Great designs build in feedback loops and adaptability.
• Man-made and natural systems share common underlying principles. Knowledge learned from natural systems can be transferred to man-made systems. A common set of tools and measurements can be used to determine how well our technical systems compare to natural systems.

This new approach shows promise in reducing barriers making transfer of knowledge between the natural and technical domains difficult. It also opens up additional sources of input to develop patterns - technical systems can be analyzed for potential solutions. Technical examples can also be more easily incorporated, potentially allowing designers to identify 'off the shelf' components during solution implementation. In addition, contradictions or 'lessons learned' from systems that have not been successful can help in the development of patterns. These contradictions often reveal the forces or drivers underlying problems which may not be obvious in natural systems - when properly resolved, these drivers often seem to disappear.

A call for volunteers in the September 2006 BioInspired! Newsletter and a posting to the Biomimetics listserver - sixteen individuals volunteered, of which the following have been key contributors to the project: list disciplines?

• Denise DeLuca
• Martha Love
• Tom McKeag
• John Reap
• Fil Salustri
• Lynne Sopchak
• Eileen Stephens
• Maibritt Pedersen Zari

The volunteers are geographically dispersed, across North America through Europe to New Zealand. At the suggestion of Fil Salustri, a Wiki was created to provide a common platform for shared content creation and editing. The MediaWiki platform was chosen based on the ease of learning how to contribute and modify input, the support for hosting on a shared web server, and the familiarity of many people with Wikipedia, which is built on an advanced version of MediaWiki.

Aside from the learning curve required to use the Wiki effectively, many of the volunteers were unclear both about the details of the project as well as the details of patterns and pattern language. A number of conference calls were scheduled involving a range of participants. These calls helped to clarify the project for everyone. A decision was made to use conference calls to do the initial discussion and documentation of each patterns. One of the participants suggested that we start with the list of Life's Principles from Biomimicry - Innovation Inspired by Nature, adding additional ecosystem principles from other sources. Although a top-down approach to pattern development is only recommended for domains of knowledge that are very well understood, the approach provided a clear starting point, and allowed all participants to contribute.

One-on-one calls were scheduled with participants to explore the Life's Principle of greatest interest to them. A Wiki template was used to guide the discussion and documentation of the pattern - this helped increase consistency. The rigor of the patterns approach has led to wide-ranging discussions on exactly what these principles really mean, and how they can best be 'operationalized' such that a designer can effectively and efficiently apply the insights from the principles in problem analysis and solution development. Principles and patterns share many characteristics, in that they both describe how things work and provide guidance on developing specific solutions. However, principles are frequently phrased as "overwhelming obvious ideas that are often accepted as a matter of faith." (Jan Erlendsson). In a private communication to the team, Maibritt Pederson Zari pointed out that:

• "... it is not always easy to make distinct principles as often they are linked."
• "... it is not clear if some of the principles in the draft list are not in fact subsets of others, or that some important principles are not there yet."
• "... such lists, particularly the simplified ones really need some kind of explanation for each principle so some of the more subtle or complex aspects of each one are not overlooked or missed out ..."
• "Each principle represents a lot of information that might not be immediately apparent."

In contrast, patterns explicitly describe:

• the context in which the pattern is useful
• the underlying problem, including the drivers or forces that cause it to occur
• the specific steps required to apply the pattern in generating solutions
• a range of sample implementations of the pattern
• any caveats or restrictions that limit the applicability of the pattern
• how the patterns relate to each other in a hierarchy or network, ideally mapping the full breadth of a domain of knowledge

At the time this paper was published, three prototype patterns had been started. Work on these patterns continues to define terms, clearly articulate the problem and the underlying drivers, identify the right context, and document both the details of the solution and how it can be implemented.