![]() ![]() ![]() |
component ecosystemsthe context for cbd |
Take reuse, for example. There are several different reasons why reuse might be important to different stakeholders in different ecosystems.
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?
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.
2. The agreed terminology becomes so complicated, that it becomes practically unusable.
3. The agreed terminology leaves out some perspectives or stakeholders.
![]() |
cbse as hybridveryard projects > cbse > component ecosystems > hybrid |
![]() |
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.
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.
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.) |
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): |
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. |
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. |
![]() |
Ecological Principlesveryard projects > cbse > component ecosystems > ecological principles |
service use | service supply | device use | device supply |
Pleasure Principle | Availability Principle | Energy Conservation Principle | Quality Principle |
![]() |
Connectivity Principleveryard projects > cbse > component ecosystems > ecological principles > connectivity |
In many cases, the network externalities are negative. The utility of a car is reduced if there are too many other road users; the utility of a holiday may be reduced if there are too many other holiday-makers.
The most common examples of positive network externalities come from communications technology. A phone or fax has no value to you, if you are the only person that has one. The more people that share this technology, the more valuable it becomes.
Similar externalities apply in many other situations. My choice of word processor is influenced by the fact that I want to exchange word processed documents with my friends and associates. An organization selecting a software development tool is influenced by the number of other organizations using the tool - among other things, they want to know that there will be lots of people in the job market (available as employees) familiar with the tool.
Success breeds success. To him that has, shall be given more.
Standards don't have to be universal. Often there are parallel or rival standards. CORBA and COM. PC and Macintosh and UNIX.
Within each market sector, if there are rival standards and competing notations, this adds complexity and reduces network externalities. But it doesn't follow that there should only be one standard, even within a single sector of the market, and certainly not across all market sectors. I certainly don't expect components for nuclear power stations to be documented in the same way as components for banking systems. (See also comments on biodiversity below.)
The practical value of a standard depends on one thing alone: the density of the population adhering to the standard. Technical purists may prefer Betamax to VHS, but it was VHS that achieved the critical mass. Microsoft understands this very clearly.
You may prefer to have a single universal standard. You may prefer to have a single universal platform. You may prefer to have a single search engine that will find every component in the universe, and present its description in a single universal notation.
But when you are operating in a given standard, on a given platform, using a given search engine or notation, what matters is how large and diverse a population this does give you access to. Perhaps there are lots of other components operating in a different standard, on a different platform. But if your search engine already gives you access to more components than you need, you must either decide to forget about the components it isn't giving you access to, or use a second search engine.
Ideally, I might want to be able to converse with everybody in the world. But I'd need to learn thousands of languages, which is impossible, even for the most gifted linguist. Most of us can only manage a few languages, and many people get by with only one. The major world languages have a large population of speakers, providing a critical mass of people, reading material, general opportunities. Minor languages, whatever their cultural importance or poetical wealth, lack this critical mass. This is why people who speak Basque or Finnish or Welsh are under greater pressure to learn other languages than those who speak Castillian or Russian or English.
In a real ecosystem (as opposed to Aesop's fables) the animals concentrate on eating the food that is available to them, and don't waste energy regretting the food that might be found in some other ecosystem. If there isn't enough food, they either migrate or die.
![]() |
Energy Conservation Principleveryard projects > cbse > component ecosystems > ecological principles > energy conservation |
Energy conservation also entails an interest in the operational efficiency or performance of a component.
Recycling, of course, implies movement and use. Conservation certainly doesn't mean hoarding. Competitive advantage doesn't come from possession and preservation of static intellectual property, but from the rapid development and exploitation of new intellectual property.
![]() |
Economies
of Scale in Manufacturing
Reuse |
![]() |
Flexibility Principleveryard projects > cbse > component ecosystems > ecological principles > flexibility |
(Note: this probably means that the new component has the same interface as the old one, but a different specification. Beware of gurus who tell you that interfaces and specifications are the same thing.)
And if possible, I'd like to do this without having to re-test the whole system.
![]() |
The Nature and Nurture of Flexibility |
![]() |
Biodiversity Principleveryard projects > cbse > component ecosystems > ecological principles > biodiversity |
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.
evolution - richer basis for adaptation and innovation requisite variety - enhanced ability to respond to the complexity in the environment technical robustness (especially in the face of software viruses targeted at a particular platform) commercial robustness (as protection against vendor monopoly)
![]() |
"While the dominance of a single computing environment -- the one powered
by Microsoft software and Intel chips -- offers the benefits of compatibility
among machines, some say it may share the vulnerabilities of fields planted
with just one crop."
[source: "Illness Is Fast Becoming Apt Metaphor
for Computers" John Markoff
http://www.nytimes.com/library/tech/yr/mo/biztech/articles/14worm.html] |
![]() |
Recent worms and viruses have swept across the Internet, prompting comparison with the ease with which disease organisms sweep through human populations, and their herds and crops. |
![]() |
The best insurance against this vulnerability is the software equivalent of biodiversity: software diversity. |
![]() |
Art Amolsch, editor of FTC Watch, a Washington policy newsletter, is quoted as proposing that no government agency be allowed to run more than 34 percent of its personal computers on one proprietary operating system. |
Healthy evolution is divergent - it promotes
biodiversity.
Biodiversity promotes further evolution.
Biodiversity is a Good Thing.
Sorry Bill.
![]() |
Notes on Evolution |
![]() |
Availability Principle (Commodity)veryard projects > cbse > component ecosystems > ecological principles > availability |
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):
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. |
![]() |
Borgmann on Availability |
![]() |
Quality Principle (Consistency, Firmness)veryard projects > cbse > component ecosystems > ecological principles > quality |
When components fail, do they fail cleanly, or do they cause secondary problems?
![]() |
Pleasure Principle (Delight)veryard projects > cbse > component ecosystems > ecological principles > pleasure |
Some suppliers may interpret this as a need for promotion and publicity: brand image management, advertising, public relations.
We've probably all seen the INTEL INSIDE stickers on the outside of computers. Some analysts even question the commercial value of this campaign to Intel. But just imagine if all the other suppliers of all the other components - hardware and software - wanted to put a sticker on the outside of your computer.
The whole point of a component is that it should be invisible most of the time. You probably don't have a sticker on your car, telling you what is the brand of spark plugs in the engine. Indeed, the spark plug manufacturer probably doesn't care whether you've even heard of him. The only attention he wants is that of the engine designer, and possibly the engine repairer.
![]() |
Pleasure Principle |
![]() |
Discussion: Why Many Ecosystems?veryard projects > cbse > component ecosystems > discussion |
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.
![]() |
CBSE Component-Based Software Engineering
CBB Component-Based Business |
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.
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 | ![]() |
![]() |
Kevin Kelly. New Rules for the New Economy.
10
ways the network economy is changing everything.
US: Viking Penguin;
|
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. |
![]() |
![]() |
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. | ![]() |
![]() |
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. |
![]() |
![]() |
top | ![]() ![]() |
|
|
This page last updated on November 6th,
2003
Copyright © 1999-2003 Veryard Projects Ltd http://www.veryard.com/CBDmain/compeco.htm |