veryard projects - innovation for demanding changesystems engineering for business process changecomponent-based development - component-based business

component ecosystems

the context for cbd

model
implications
notion finder
home
four ecosystem model
separation
seven ecological principles discussion

pdf version of this page
requirements ecology

designing components to satisfy ecological principles

software supply: trends and strategies

testing

component diffusion (pdf)

cbb notions

cbse notions

eco notions
veryard projects
home page

component based business (cbb)

component-based software engineering (cbse)

contact us

component ecosystems


CBD is commonly described in terms of a set of notions (interface, service, encapsulation, reuse, plug-n-play). But these notions do not have a single interpretation from all perspectives. Even the notion of component itself means something different, according to whether you are talking to Java programmers or respository managers or potential purchasers.

Take reuse, for example. There are several different reasons why reuse might be important to different stakeholders in different ecosystems.

reuse times four
Some people think reuse is terribly important, and other people don't care a fig for reuse, but do care about critical mass or quality. We need to find a way of building useful bridges between them. What is the connection (if there is one) between reuse in the Device-Supply ecosystem and critical mass in the Service-Use ecosystem? There are lots of ungrounded claims that more reuse leads to greater quality, but where's the proof, and what would actually count as a valid proof?

In short, how can a software engineer persuade a business manager to invest in "reuse", when they don't share a notion of what reuse is, and what value it might have?


Should the software engineer adopt a business management notion of reuse, or should the business manager understand the technical notion of reuse? Neither of these - instead, we need to find ways of connecting these two notions of reuse together.

When faced with conflicting terminology, most people try to smooth out the conflicts and agree a single homogeneous set of terms. This approach has three potential dangers.

Rather than smooth out the differences, our approach is to understand them explicitly, and to build bridges and connections between them. This is not just an intellectual exercise but an important commercial one. We believe that the dominant players in the component marketplace will be those that can understand and engage with multiple perspectives, and can straddle multiple ecosystems.


veryard projects - innovation for demanding change

cbse as hybrid

veryard projects > cbse > component ecosystems > hybrid

The inventor and former Patent Office Examiner Arthur Pedrick is regarded with awe in the patent profession for his extraordinary skill at drafting strange patents. Patent law is designed to prevent silly patents being granted, but it didn't stop Pedrick. My father, who was a patent agent, took great delight in a device that combined the functions of nuclear fall-out detector and catflap, apparently invented by Pedrick's cat Ginger.
 
more http://www.patent.freeserve.co.uk/pedrick.html

Component-based development (CBD) is a similar hybrid, in the sense that it yokes together disparate concepts and mixes metaphors. Furthermore, many of the so-called gurus seem unaware of this. Endless arguments about what exactly a component is, or how you measure reuse, cannot be resolved without recognizing that there are multiple contexts.

To help make these contexts explicit, we have developed the model of four ecosystems described on this page. This should provide a decent basis for saying what CBD actually is - or even defining some other, more coherent notions. It also helps us to build conceptual bridges between the different perspectives, and find practical ways of collaborating across multiple ecosystems.


four ecosystem model

separation

To analyse the context for software component development, we separate the whole into separate ecosystems.

The first separation we draw is between the demand-use side and the supply side. This separation will be familiar to most readers.

Component-based development enables a further separation, between the external service (accessed through a component interface), and the internal component assets or devices that deliver the service. This second separation applies equally on the demand-use side and on the supply side, yielding four ecosystems altogether.

service use ecosystem

  
activities ecological principles
Using services

Demanding services

Architecting / configuring use of services

Subscribing to service publications

An important element of strategic thinking around a business process is to decide: which bits are to be routine and mechanical, consuming as little management time and attention as possible; and which bits are to be strategically interesting, on which management time and attention is to be focused. Thus some business services need to be as boring as possible, while others need to be as exciting as possible. And it’s important to get the balance right - too much excitement is painful or stressful, while too little excitement is death. This balance is a critical survival factor for the ecosystem as a whole; we call this the pleasure principle.

Furthermore, some services give value to their users by being unique, while others give value to their users by being common. The best-known example of the latter is communication services: how much value you get from your email or fax service depends on how many of your friends and associates are also using email or fax. Thus your decision to use a given service sometimes depends on your estimate of the number of other users. We call this the connectivity principle. (It is sometimes known as the  critical mass principle.)

service supply ecosystem

  
activities ecological principles
Providing / delivering services through stable interfaces

Architecting services

Publishing available services

In this ecosystem, services are competing for survival. Between two services, the more available service will usually win over the less available. Hence there is a strong technological and commercial pressure for services to increase their availability; we call this the availability principle. (It is sometimes known as the commodity principle.)

Some aspects of availability are as follows (depending on the nature of the service):

  • Global 24-hour access. Instant response.
  • Any hardware and software platform. 
  • Available in Arabic, Chinese, English, Hindi, Russian and Spanish.
  • Easy to use. Low entry cost. Good support. Minimum learning curve.
  • High reliability. Safe and secure. Low risk.
  • device supply ecosystem

      
    activities ecological principles
    Architecting devices

    Providing devices to deliver services (build, buy, assemble, reuse)

    Managing devices as assets

    In this ecosystem, competitive survival depends on delivering the greatest quantity of service with the smallest amount of work. This is often called reuse; software reuse should be focused on achieving economies of scale in software, based on effective asset management and knowledge management. We call this the energy conservation principle.

    device use ecosystem

      
    activities ecological principles
    Using services

    Demanding services

    Architecting / configuring use of services

    Subscribing to service publications

    In this ecosystem, competitive survival depends on getting the expected services (and their associated benefits) from a given configuration of devices. This in turn relies on an ability to predict and control the behaviour of components-in-use, including the emergent properties of large distributed systems. We call this the quality principle.

    Also relevant in this ecosystem is the ability to easily substitute devices and reconfigure systems. We call this the flexibility principle.

    Finally, the robustness, flexibility and evolution of the ecosystem depends on a reasonable heterogeneity of software and services. We call this the biodiversity principle.


    veryard projects - innovation for demanding change

    Ecological Principles

    veryard projects > cbse > component ecosystems > ecological principles


    For a business or software component to be viable, it needs to be simultaneously viable in all four ecosystems
     
    service use service supply device use device supply
    Pleasure Principle

    Connectivity Principle

    Availability Principle Energy Conservation Principle Quality Principle

    Flexibility Principle

    Biodiversity Principle


    veryard projects - innovation for demanding change

    Connectivity Principle

    veryard projects > cbse > component ecosystems > ecological principles > connectivity 

    (also known as critical mass - see below)
    Value comes from the number of other users of "the same" component, within some domain.

    network externalities

    standards

    critical mass

    size and survival


    veryard projects - innovation for demanding change

    Energy Conservation Principle

    veryard projects > cbse > component ecosystems > ecological principles > energy conservation


    Competitive survival depends on delivering the greatest quantity of service with the smallest amount of work. This is often called reuse; software reuse should be focused on achieving economies of scale in software, based on effective asset management and knowledge management.

    Energy conservation also entails an interest in the operational efficiency or performance of a component.

    economies of scale

    lifetime costs

    recycling intellectual property

    supply consolidation

    more Economies of Scale in Manufacturing
    Reuse


    veryard projects - innovation for demanding change

    Flexibility Principle

    veryard projects > cbse > component ecosystems > ecological principles > flexibility


    The ability to easily substitute devices and reconfigure systems.

    substitution

    reconfiguration

    more The Nature and Nurture of Flexibility


    veryard projects - innovation for demanding change

    Biodiversity Principle

    veryard projects > cbse > component ecosystems > ecological principles > biodiversity


    The robustness, flexibility and evolution of the ecosystem depends on a reasonable heterogeneity of software and services.

    Biodiversity entails a genuine choice of available solutions to a given problem or requirement. For example, an office may run some of its computers using Windows NT and some using Linux.

    Biodiversity is often regarded as a cause of dissatisfaction in its own right, and IT directors may dream of imposing a software monoculture across their organizations. There are many costs associated with biodiversity, but there are also some potential benefits.

    vulnerability of monoculture

    innovation from the fringes

    evolution and biodiversity

    more Notes on Evolution


    veryard projects - innovation for demanding change

    Availability Principle (Commodity)

    veryard projects > cbse > component ecosystems > ecological principles > availability

    (also known as the Martini principle - any time, any place, anywhere)
    Components should be as available as possible, in order to offer the greatest possible value (utility) to the greatest number of potential users/uses.

    Between two services, the more available service will usually win over the less available. Hence there is a strong technological and commercial pressure for services to increase their availability; we call this the availability principle. (It is sometimes known as the commodity principle.)

    Availability is defined as making things more widely accessible, eliminating the barriers to use. Wherever you want it, whenever you want it. Easy, safe and cheap.

    Some aspects of availability are as follows (depending on the nature of the service):

    Examples

    retail
    consolidation
    One way of making things more available is bringing them under one roof. A department store or superstore is more convenient for shoppers. An ecommerce website takes this principle of convenience further, and should make as many choices available as possible.
    diversity Requisite variety. A component that runs on many different platforms, a component that offers a choice of operating protocols, a component that can handle multiple data formats - these are components whose variety makes them available to a wide range of users/uses.
    granularity A healthy market needs to offer a good mix of different granularities. This increases overall availability.

    Although perhaps most of the early transactions in the software component market have been in fine-grained components, there will be a trend towards a greater choice of granularity.

    For some, the transaction costs of buying lots of small components may be greater than the transaction cost of buying a few large components. For others, the reverse will be true. Thus the transaction cost argument works both ways.

    ease of
    acquisition
    How easy is it to find, evaluate and acquire a component? Anything that makes it easier and safer - documentation, demonstration versions, case studies, user or analyst recommendations, quality accreditation, clear price-list - increases the availability of the component.

    Philosophical and social implications

    The trend of technology towards a fundamentally undifferentiated supply of the available has been identified and analysed by philosophers of technology, including Heidegger and Borgmann. Their analysis indicates that this is a very broad and powerful trend, and they go on to explore some of the philosophical and social implications of this trend.
     
    more Borgmann on Availability

    veryard projects - innovation for demanding change

    Quality Principle (Consistency, Firmness)

    veryard projects > cbse > component ecosystems > ecological principles > quality


    Getting the expected services (and their associated benefits) from a given configuration of devices. This in turn relies on an ability to predict and control the behaviour of components-in-use, including the emergent properties of large distributed systems.

    assurance

    performance

    reliability

    feature interaction


    veryard projects - innovation for demanding change

    Pleasure Principle (Delight)

    veryard projects > cbse > component ecosystems > ecological principles > pleasure


    Value comes from achieving an appropriate level/balance of excitement and attention.  Foreground components gain value if they are interesting and attention-absorbing.  Background components gain value if they are routine and require little or no attention.

    satisfaction (I can't get no)

    attention

    excitement

    more Pleasure Principle

    veryard projects - innovation for demanding change

    Discussion: Why Many Ecosystems?

    veryard projects > cbse > component ecosystems > discussion


    My characterization of the four ecosystems is preliminary. I'm not even sure that there have to be four of them. I am however fairly convinced of the need for some such model of a number of separate ecosystems, able to support at least the distinctions I want to make and probably some more as well.

    We also need to recognize that there is some interfolding of the four ecosystems, in the sense that each may impinge into the environment of the others. However, I don't think this observation forces me to accept the validity of a single whole system.

    The idea of dividing a situation into multiple ecosystems has more general applicability. To take another example, a manufacturing company would typically have models of the production process and also models of the sales and marketing process. (The production process could have an enterprise model, an information model and so on. Similarly, the sales and marketing process would have multiple models.)

    We could usefully regard the production process and the sales and marketing process as belonging to two separate ecosystems. There are known problems in joining / yoking the information model of one process with the information model of another process, which popular fantasies of the global enterprise-wide information model fail to address. There are similar problems in joining the enterprise model belonging to one process/ecosystem with the enterprise model belonging to the other. Of course, production impinges on sales & marketing, and vice versa, but the coordination between the two processes is not simply a matter of merging the models.

    People from the production ecosystem just don't speak the same language, or recognize the same problems, as the people from the sales & marketing ecosystem. Of course they come to a pragmatic accommodation with each other, but this doesn't represent a true meeting of minds, or shared intentionality. And that's true even when they are all divisions of the same company. And it gets all the more interesting in a distributed or federated situation.

    So I think there is a lot of mileage in the general idea of producing models of multiple ecosystems, and problematizing the interactions across ecosystems. I will defend that idea much more strongly that I will defend the particular model I have produced of the CBSE or CBB world. However, the four ecosystem model allows me, I believe, to throw some new light on a number of CBSE and CBB topics.
     
    more CBSE Component-Based Software Engineering
    CBB Component-Based Business


    We use the word ecosystem, rather than markets or industries or networks, because it is more general. An ecosystem may contain human agents or organizations, or it may contain intelligent software agents, or it may be a hybrid.

    The natural world can be regarded as a single global ecosystem, because there are some connections between all the parts. (Birds may visit even a remote island, carrying new species of plant or insect.) However, for many purposes it is simpler to regard a semi-isolated part as a separate ecosystem.

    Instead of the biological/ecological metaphor of ecosystem, some readers may prefer to think in terms of a political economy.



    Some economists use the term ecologies rather than ecosystems, but I prefer to reserve the term ecology to refer to the scientific study of ecosystems.

    In delineating an ecosystem, I think one is saying that the interactions within the ecosystem are somehow different to the interactions across the boundary of the ecosystem.

    Here's a simple analogy. People work in universities according to a certain logic. They interact with each other in particular ways, compete for particular tokens of success, and so on. People work in industry according to a different logic. I think it's fair to characterize this as two separate (but connected) ecosystems. In the academic ecosystem, there is an ecological principle of "publish or die"; this principle is largely absent from industry. The two ecosystems have different pressures, different time horizons, different ways of thinking about all sorts of problems. This is precisely why it's worth having many bridges and joint activities between the two ecosystems; but these are likely to fail if they don't recognize that there are different principles on each side.

    If I'm operating in two ecosystems at the same time, what are the implications of this? Do I become schizophrenic? In many companies, the marketing department operates in a different ecosystem to the production department, and the resulting inter-departmental tensions and conflicts can be very damaging unless carefully managed.

    I think the ecosystem metaphor is more useful than the market metaphor in dealing with these multiple roles and the conflicts between them. A bird that wants to do well in the bird-worm ecosystem has to spend a lot of time pecking at the ground, but a bird that wants to do well in the bird-cat ecosystem has to spend a lot of time flying away. The features or defences that are useful in one ecosystem may be a handicap in another ecosystem. A simple characterization of a market as a set of buyers confronting a set of sellers doesn't go far enough for my purposes.

    I'm no biologist, and I haven't studied how professional ecologists handle these situations. My focus is on ways of modelling that will support business strategy and change management, and also IT planning and technology transfer.

    recommended reading


    My new book - click here for more information buy it from Amazon.com buy it from Amazon uk
    Kevin Kelly. New Rules for the New Economy. 10 ways the network economy is changing everything. 

    US: Viking Penguin;
    UK: Fourth Estate. 1998

    A systematic analysis of the strategies for successful business in the new world.

    This is the open, distributed, connected, chaotic world he described in his previous book. Out of Control: The New Biology of Machines, Social Systems, and the Economic World.

    buy it from Amazon.com buy it from Amazon uk
    Albert Borgmann. Technology and the Character of Contemporary Life.
    A philosophical inquiry. 

    Chicago University Press. 1984.

    A classic account of technological change. Borgmann introduces what he calls the device paradigm, in which technological progress increases the availability of a commodity or service, and at the same time pushes the actual device or mechanism into the background. buy it from Amazon.com buy it from Amazon uk
    Jared Diamond. Guns Germs and Steel. A short history of everybody for the last 13,000 years. 

    Vintage Random House, 1998

    Provides a large look at the history of the world. Explains why the people in some parts of the world developed faster and further than others, without appealing to inherent genetic (racial) differences.

    The relevance of this book here is its contribution to the topic of biodiversity.

    buy it from Amazon.com buy it from Amazon uk


    author details

    Richard Veryard is a technology consultant, based in London.

    acknowledgements

    David Iggulden provided discussion and feedback at many levels. Vincent Traas asked some good questions. Thanks also to the CBDi Forum, in particular Paul Allen, Ian Graham, Simon Holloway, David Sprott, Lawrence Wilkes and Paul Winstone.

    final remarks

    “A wit has said that one might divide mankind into officers, serving maids and chimney sweeps. To my mind this remark is not only witty but profound, and it would require a great speculative talent to devise a better classification. When a classification does not ideally exhaust its object, a haphazard classification is altogether preferable, because it sets imagination in motion.” [Kierkegaard]

     
    top

    veryard projects
    home page

    contact us

    in asssociation with 
    CBDi Forum
     
    This page last updated on November 6th, 2003
    Copyright © 1999-2003 Veryard Projects Ltd 
    http://www.veryard.com/CBDmain/compeco.htm