veryard projects - innovation for demanding changesystems engineering for business process change

organic planning

on this page why plan?

system development principles


other material flexible architecture 
& co-evolution



other links FACE network
home [veryard project
home page]

[contact us]

organic planning - the third way

Some people ignore the complexities of systems, and merely hack with the pieces.  Hacking doesn't work.
Few people have the luxury of controlling all aspects of the present, let alone fixing the future.   Grand plans don't work either.
Instead, follow an organic process that allows the desired system properties to emerge.

organic planning - principles

Avoid excessively large projects.
Maintain a balance between small and medium projects.
Balance the projects evenly across the subject domain.
Each project has an identifiable centre, and contributes to a larger whole.
Each system must either be a simple and compact unity, or it must be made up of several simple and compact parts, one of these being major and the others minor, hanging onto it.
Interface bridges with other systems are built afterwards, incrementally. The bridges should serve the systems, and the systems serve the users. You don’t design the systems to serve the bridges.
The programme will evolve as the organization develops new concepts. Each project may feed new insights back to the programme, making it richer and more powerful.
[source: Richard Veryard, Component-Based Business, Springer 2001]

Why Plan?

"Le plan est le générateur.
Sans plan, il y a désordre, arbitraire.
Le plan porte en lui l’essence de la sensation."
Le Corbusier Vers une Architecture
According to the modernist architect Le Corbusier, the plan is a generator - it generates both activity and structure. But how to lay out the plan - does it specify the structure itself, or does it merely specify a method by which the structure will evolve?

This document is not about the design of individual artefacts, satisfying a set of requirements, built by individual projects. It is about programmes of designing many coordinated systems, satisfying the complete requirements of a large organization, forming a ‘whole’.

What do we mean by the word ‘whole’? It denotes coherence, lack of fragmentation. If a structure is whole, its parts are also in a sense whole, not fragmented but coherent. This may be because all parts are guided by the one single process, by a development programme which follows the same principles at all levels, from the preliminary sketch to the tiniest detail. Such a development programme will of course contain many projects, in series or in parallel, each developing one part. Any two parts are related, in sometimes very complex and indirect ways, but remain compatible, consistent. And yet the boundaries between parts can be clearly perceived, each part is visible and makes sense on its own, as well as within a wider context.

In most development programmes today, this vision of coherence is at best only partly achieved. We can analyse what goes wrong; more importantly, we can identify what improvements can be made in planning and executing these programmes, subject to the culture and environment of the organization.

Common sense and experience shows that such wholes cannot be implemented in a single step. Such projects are too large to be successful, producing a system too monolithic to be meaningful. The best we can achieve allows the whole to grow in many steps, over many years. Its final form cannot be predicted, except perhaps in ambiguous generalities, partly because the form is sensitive to details that cannot (and should not) be worked out in advance, but partly (and more importantly) because the organization itself learns during the development - the systems do not merely support the organization but transform it, or rather allow it to transform itself.

There are two common approaches to such multi-system design, with multi-project development. One can be called hacking, and the other can be called grand plans..

Hacking means that each system or individual component is built piecemeal, according to its own needs alone. Its features are determined by its direct costs and benefits. Each project is started and steered in isolation of other projects; communication between projects only takes place if of immediate benefit to the projects themselves. Piecemeal growth, by itself, will not create coherent wholes. This is exactly why people produce plans.

This is not to dismiss the value of the hacker's craft. Professional hackers can produce items of extreme elegance and beauty, as well as great power. The fragmentation doesn't come from the craft itself, but from the planning and management framework (or its absence).

Grand plans means that each system is built to fit a prearranged position, within a preconfigured framework or blueprint. The aim of such planning is to create coherent wholes in advance, and thereby provide order and organization in the large. The trouble with this form of planning is that it often fails to achieve the sought order. In the worst case, such a plan can be a mixture of meaningless generalities and ill-considered rigidities.

It is worth noting here an important ambiguity in the word ‘plan’. This word may be used to refer to a preconfiguration or blueprint, as in a building plan or an urban development plan. It may also refer to a scheme or schedule of activity, as in a military plan of action, or development programme. It may even refer to a combination of both.

The architect Christopher Alexander developed an organic planning approach originally for the purposes of town planning (as an alternative to the top-down approach adopted by both Ebenezer Howard and Le Corbusier).  He uses a metaphorical language to describe the intended results: whole, repair, fabric, centre, healing. We shall adopt his metaphors, and then try to define what they mean for Component-Based Business.

The overriding principle is that every project must ‘make whole’. It should repair and maintain existing wholes (this implies respect for the coherence of existing structure, although a project may abandon any particular mechanisms); it should create new wholes; it should establish a continuous fabric of wholes around itself. Thus a good project is not merely fabricating new fabric, but repairing and patching torn/worn places in the existing fabric. (Christopher Alexander calls this ‘healing’.)

(The wholes are of course sociotechnical ones. This means that there are several perspectives on wholeness, including the social and the technical.  A range of stakeholders must perceive order and stability in the result.)

Each project has a ‘centre’. Around this centre is arrayed several other, smaller centres. The rule is that, as one such centre is produced, it must contribute to larger structures, and also bring together smaller structures - it must be both unifying and unified. 

There is a much deeper notion of centre than that implied in what I originally wrote here. 
It is connected with Borgmann's notion of focus - focal things and practices.
For example, consider a project that is centred around employee data. It will bring together, perhaps, aspects of personnel, payroll, work allocation, and other related applications. It therefore unifies many views of employee into a single data structure. And at the same time, employee may be recognized as a special case of payee, so that payments to employees may be unified into the larger structure of all outward payments.

For another example, consider a project centred around the issue purchase order process. It will bring together aspects of supplies, contracts, subcontracts, service contracts and perhaps even insurance policies. It therefore unifies several views of the same process. And at the same time, it contributes to a larger structure, containing deliveries and invoices and payments to suppliers.

In general, an object contributes to a larger structure by being a subtype of a more general object, or by playing a role shared with other objects. And a process contributes to a larger structure by taking part either in the lifecycle of a given object, or in a control loop. Or both.

Peripheral objects will contribute by being part of the horizon of a central object, or by providing a supplementary information structure (e.g. an historical or geographical breakdown). Peripheral processes will contribute by establishing the preconditions for a central process. But these peripheral objects and processes become in turn the centres of their own, smaller areas.

Thus we can restate our goal as follows: to weave a fabric of centres, such that each centre supports one or more larger centre, and is supported by smaller centres. Furthermore, the fabric should be complete: there should be no ‘negative space’.

In traditional design of computerized information systems, the spaces between systems are often merely the areas that nobody has bothered about. This is negative space. But the redress for this ill is not total automation, which leaves no space at all, but deliberately created space. Space in which the system users can be imaginative and innovative, freed of the burdens of repetitive and inflexible administration. This is positive space.

(Although these concepts of positive and negative space are metaphorical, they can be linked to concepts being developed in Scandinavia and elsewhere, about human-centred systems design. The relevance of these concepts increases as IT projects have shifted in emphasis from the automation of clerical transaction processing, and towards cooperative decision-support systems. Many people now believe that user-friendliness is profoundly affected by system scope and structure, and is not simply a matter of having the right front-end.)

Systems development principles

In this approach, projects are selected, planned and managed according to a set of principles. Each organization may define its own principles, but here is a reasonable set to start from:
Size matters Provide firm guidelines to avoid excessively large projects. A maximum project size may be defined in various ways, and will vary from one organization to another.

Restrict projects to what is feasible with existing project management skills and procedures. You may hope to enhance these skills and to redesign these procedures, but don't start planning ambitious projects until you are sure you've got the capability and infrastructure is in place.

Balance matters Maintain a balance between small and medium projects. There is an ideal mixture of project sizes in progress at a given time. Within the maximum size already defined, there will be large, medium and small projects. A rough guideline should be established for the relative numbers of such projects, or for the proportion of resources devoted to projects of different sizes. (This will enable, among other things, a skills development path for project managers.) There should also be a mixture of high-risk and low-risk projects, and a mixture of urgent and non-urgent projects. Time-critical projects should be mixed with innovation-critical projects, and projects requiring much attention from senior management should be mixed with projects requiring relatively little attention.

Balance the projects evenly across the subject domain. The projects in progress at the same time should not all be concentrated on the same small corner of the overall fabric, but should be distributed between different functions, different groups of users. This allows not merely political balance but also systems balance and resource balance.

Stay centred. Each project must have an identifiable centre, and contribute to an identifiable larger whole, more significant than itself. Those managing the project must be able to show how their project will contribute to the overall fabric. The growing awareness of such larger wholes provides a helping hand towards our goal. Some of these wholes may be predicted, but some may emerge as you go along, and must be allowed to develop without preconceptions or forcing.

A larger whole has a discernible life cycle. First, one project hints at a more general structure, which it is outside its own scope and terms of reference to explore. Then other projects help to indicate the outlines of the larger whole, which gradually takes shape as each project enhances our understanding of it. A series of further projects then completes the whole.

A project will usually play simultaneous but different roles with respect to different larger wholes. Each project should therefore aim to do three things. First, it should help to complete at least one major whole that is already clearly defined. Second, it should help to pin down some other, less clearly defined whole(s), previously only hinted at. Third, it should hint at some entirely new whole(s), which will only clearly emerge with later projects. A project may use both ‘development’ and ‘maintenance’ tools and techniques.

Build a network of centres Each project should be expressed clearly in advance. A communicable vision of the project can be provided through a well-defined portion of the conceptual structure, which the project is to analyse, or for which the project is to design a system.

Each project must create, and each system must have, coherent and well-shaped decision space next to it.

Each system must either be a simple and compact unity, or it must be made up of several simple and compact parts, one of these being major and the others minor, hanging onto it.

Bridges serve systems
systems serve users.
Interface bridges with other systems are built afterwards, incrementally. The bridges should serve the systems, and the systems serve the users. You don’t design the systems to serve the bridges.
Evolve and grow the programme. The programme will evolve as the organization develops new concepts. Each project may feed new insights back to the programme, making it richer and more powerful.


A similar evolutionary approach has been tried by Christopher Alexander and colleagues in California. They developed a set of principles for urban development, and then conducted a large-scale simulation to test the principles. A group of architecture students surveyed a real area of the city, discovered what kinds of buildings would be required in a redevelopment of the area, and used the principles to grow a series of coordinated designs, without any zoning or grand design. Although such an artificial experiment cannot be regarded as a definitive proof of the approach, the obvious merit of the models and drawings give some plausibility to its claims, at least as an alternative to traditional town planning.

Empirical experience with the approach recommended here is admittedly limited. The plausibility of the approach rests on the known difficulties with the other approaches, and on the analogy with architecture and urban development. But the arguments for the grand planning approach are usually based merely on the comparison with the hacking approach. This statement of a third option should at least serve as a challenge for the proponents of grand plans to develop a new and stronger justification.

Chris Alexander et al, A New Theory of Urban Design

Oxford University Press, New York, 1987.

Alexander shows how large complex yet coherent structures can emerge from an organic process.


buy a copy - uk
buy a copy - uk
How Buildings LearnStewart Brand, How Buildings Learn

Viking Penguin 1994.

Brand shows how buildings adapt to changing requirements over long periods.  The book inspired a 6-part TV series by the BBC.

Comments critical of the architect Lord Rogers have been removed from the British edition.

buy a copy - uk
buy a copy - uk
Kevin Kelly, Out of Control

UK edition, Fourth Estate, 1994.

Kelly shows how large complex systems maintain stability and other emergent properties, outwith human management.


buy a copy - uk
buy a copy - uk
Richard Veryard, The Component-Based Business In this book, I show the business opportunities and challenges of new modes of system constructing and evolution. more

home page

contact us

veryard projects - innovation for demanding change
in asssociation with 
This page last updated on June 20th, 2001
Copyright © 1994-2001 Veryard Projects Ltd