on this page
on other pages
|veryard projects home
The context for this analysis is an
According to the ecological model of component supply, there are multiple ecosystems, driven by different ecological principles. To make good money from software components, you have to respect all these ecological principles, which means you have to straddle multiple ecosystems.
Each advance in software engineering makes it more difficult for the software engineer to remain a true generalist. Some software engineers will become specialist component engineers, deploying formal methods to create and verify robust and widely reusable software components. Others will concentrate on satisfying local business requirements, designing context-sensitive and user-friendly interfaces.
A lot of the discussion of component-based development today is based on the premise that good components are scarce. A lot of the techniques are based on this mindset of component scarcity. However, if CBD takes off, we will quickly move into a world of component abundance. Indeed, we may even get into a world of component pollution, in which it becomes an antisocial act to overpublish redundant components.
Standard components that can be configured in countless ways. For a business using CBD effectively, this establishes the possibility of mass customization, whereby the business can respond flexibly to the needs of individual customers, without losing economies of scale and scope.
Existing CASE and OO vendors are starting to move into the CBD marketplace, and there are some exciting new players as well. Use of the current tools still demands considerable manual effort. Shells and interfaces often have to be built by hand, and the matching of component requirements is poorly supported. Over the next couple of years, we can expect the tools to become more powerful and easy to use, covering a greater range of the CBD processes. This will enable still greater productivity and scaleability.
CBD increases the separation between demand-driven and supply-driven software organizations. (This applies to in-house software factories as well as to commercial software houses.)
Close relationship to customer base.
Focus on the services that are wanted in the selected market.
Competing on value.
|Close relationship to technology base.
Focus on exploiting existing software assets.
Competing on price/cost.
In the past, the supply-side could be divided into two modes of software supply.
Off-the-shelf. Some suppliers designed and marketed products for sale into an identified market (or ecosystem). These were standard products, with little or no variation, and were typically expensive to modify or integrate. If many users bought the same product, then the development and marketing costs could be shared between them, reducing the individual cost to each user.
Bespoke. Some suppliers designed and delivered one-off products to a particular customerís specification. These were typically much more expensive per user than standard off-the-shelf products, and took longer to deliver, but were (at least in theory) much closer to the customerís requirements.
Component-based development enables a third mode of software supply.
Mass customization. Suppliers who are able to respond to the needs of a single customer, while achieving economies of scale across multiple customers.
There are many ecosystems containing only off-the-shelf and bespoke suppliers, in which neither mode of supply can eliminate the other. However, as soon as mass customization becomes effective in a given supply ecosystem, then off-the-shelf and bespoke supply are ecologically doomed, and will eventually be eliminated from that ecosystem. These suppliers may survive in the short term by switching to other (perhaps smaller niche) ecosystems, but for how long?
|Do you think there are any software supply ecosystems in which a supplier can be safe from competition from software mass customization? How would you be sure?|
Bespoke. A software house that specializes in bespoke software development may detect increasing difficulties competing on price. If your competitors are achieving better economies of scale, without compromising quality and flexibility, then they will be able to undercut your prices.
Most software houses still bid for bespoke work on the basis of a simple formula: estimated cost plus contingency plus profit. There may be some opportunities for you to reduce costs or contingency, by improving your software process. But if your competitors are doing this too, this wonít be enough.
There are two possible strategies for survival. You can either move up the "food chain", concentrating on supply and packaging of services (while subcontracting the software engineering side to cheap suppliers in Bangalore). Or you can embrace the ecological imperative: conservation of energy.
Instead of bidding for bespoke work on a cost-plus basis, you must try to determine what the customer is willing to pay. If this isnít enough to cover your costs, then you need to find a way of satisfying the customer that leaves you with some residual value. If you have developed some software components that you can sell to other customers as well, this might well make up the difference. (There are other forms of residual value, but this is the most likely one for a software house to exploit.)
Off-the-shelf. Meanwhile, a software product vendor with a standard fixed range of products may detect increasing difficulties maintaining market share, or entering new markets. If your competitors can offer more flexible products, with greater availability and lower total cost of ownership, then they can erode your customer base.
The challenge for such suppliers is to leverage the economies of scale, to get wider flexibility and availability from an equivalent device base, and to get much greater internal levels of reuse. This is basically an architectural issue: how to improve the internal configuration and layering of the product. (Some suppliers will choose to keep the benefits of this improved architecture to themselves, while others will choose to open up the architecture to customers and third parties.
Selling commodities to a large customer base demands retail capability. Most software firms won't have this capability, nor will they wish to acquire it.
Many people may believe that ecommerce makes software retailing easy. But you just have to look at the bulk of ecommerce sites to see how wrong this belief is.
A few companies will develop the necessary retail capabiility. Some companies will acquire and implement a complete ecommerce solution, which they will then operate under their own brand name. But most software will be sold through third-party retailers.
Where do you shop? At the store with the best prices? At the nearest store? At the store with the greatest total range of products? At the store with the greatest relevance to your needs, so you don't have to scan through stacks of stuff you're not interested in before you reach the stuff you want? At the store with the most helpful staff?
The Internet reduces distance, practically to nothing, and connects people very easily. In such a network, trading monopolies emerge very easily. How many online booksellers, music retailers, travel agents can the Internet sustain? Customers gravitate to the companies with the lowest prices, the widest selection, the best search facilities and other features. Success breeds success. In each sector, there will only be a small number of big players, plus a multitude of tiny specialists.
Exactly the same will be true for the software component market.
|Kevin Kelly. New Rules for the New Economy.
10 ways the network economy is changing everything.
US: Viking Penguin. UK: Fourth Estate. 1998
This page last updated on June 24th, 1999.