banner banner  
 

Evolution of an ecosystem for the third party reusable component vendors

A product-family is said to be crowded product-family, if dozens of new product-models are designed each year. Examples for crowded product-families include automobile, cell-phone or computer, since hundreds of new models of cell-phones or cars are released each year. A product-family is said to be mature product-family, if the product was invented decades ago and early product-models were very successful and substantial research has been done for decades to constantly improve the product-models and various components by 3rd party component vendors. For example, product-families such as product-family for car, computer, cell-phone or airplane was invented decades ago and today each is a mature product-family and product-models belong to each family is evolved by autonomously evolving their components (where 3rd party component vendors have been doing research and evolving many of the components for each mature family).
If a newly-invented physical CBD-product becomes successful in the marketplace, sooner or later many competing product-models likely be built in the family of the newly-invented product (e.g. of a product family such as cell-phones). The competing product-models of the product-family must be evolved over time. Such successfully evolving physical product-families provide an environment conducive to create an ecosystem for third party component vendors to marketing reusable components to competing product-models, since the products are often evolved by evolving each of the third party components autonomously as well. A mature product-family or crowded product-family is often supported by ecosystem of such third party vendors for various components, tools and parts, where the third party venders of each component also invest in research and development to evolve the component.
Any mature industry or product-family usually has an ecosystem of component-vendors. So when designing a new product-model, a product maker can tap into the ecosystem for components (e.g. auto-battery, CD-player, DRAM or CPU). It is important to recognize the distinction between ecosystem for RSCC (e.g. active-components) and ecosystems for other kinds of parts or tools. For example, makers of any product belong to a family can tap into ecosystem for many other kinds of parts (e.g. ingredient-parts) and tools (e.g. machinery) etc.
The software industry also has a mature ecosystem for many kinds of parts (e.g. reusable libraries) and tools (e.g. compilers, IDE, RDBMS/SQL or CASE-tools) etc. For example, until right kind of components that can enable true CBD for software-products (that is comparable to the CBD of physical products) are invented, there won’t be a planned ecosystem of component-vendors selling such right kind of software-components. But of course, today the software industry has mature ecosystem for many kinds of tools, frameworks and parts (where some of them are insidiously believed to be component-frameworks, component-models or component-processes for true CBSD).
 Kindly keep in mind, the difference between real-software-components and other kinds of useful software parts erroneously referred to as software-components.
Another example to illustrate the deference between (i) ecosystem for true components (or CPs short for 'Component-Parts') and (ii) ecosystem for tools and parts (e.g. ingredient-parts): The industry for designing and building complex semiconductor chips (e.g. semiconductor-fabs) has a huge and mature ecosystem for tools (e.g. provided by Applied Materials, KLA-Tencor, Advantest, Cadence, Synopsys or Lam Research etc., for making the chips) and parts (e.g. silicon wafers, material and masks etc., to use as ingredient-parts) to build the IC-chips (i.e. integrated circuit chips). But there is no ecosystem for replaceable sub-components for the IC-chips, except may be for packaging each IC-chip in a casing. On the other hand, the auto-industry has ecosystems for (i) sub-components (e.g. auto-battery, tires and electronic-devises in dashboard etc.) and (ii) for ingredient-parts (e.g. steel, plastic) to build components and for tools (e.g. CNC-lathes, robotic-arms, pressing-machines and forgings) to perform various manufacturing tasks.
Standardization of functionality and interfaces to coupling/collaboration of components is required to foster an ecosystem of third-party components for each product-family. Obviously product families such as cell-phones and computers are more conducive for the ecosystem of third-party components (e.g. makers of products belong to these families use higher percentage of reusable components) than other product-families such as cars or analog-watches (e.g. makers of products belong to these families use lesser percentage of reusable components). The ability to use software for differentiating from the product-models of competitors is the reason electronic products (e.g. cell-phones or TVs) and devices (e.g. ICs such as CPU or DRAM) are more conducive to standardization and increased reuse of such components.
On the other hand, the car-makers must differentiate their products from competition by innovating and custom designing many of the core-components (e.g. engine, gearbox or suspension etc.), while depend on or collaborate with third-party component vendors to build non-core components such as CD-Players, car-battery, air-bags and dials/meters in dashboard etc. In many cases, the component vendors collaborate with the car-makers to custom design/build CPs for each new car model.
Often a mature and crowded product-family can have a viable ecosystem of third party vendors for reusable-components (i.e. active-components), where each vendor for each component (e.g. auto-battery, CD-player, Hard-drive, power-supply, alternator or memory-card) offers wide range of component-models to select for the designers of the CBD-product. This kind of selection for the components and ability to use software (e.g. applications and OS) for differentiation from competition allow cell-phone or computer designers to maximize reuse of components. In many cases, a third party component vendor collaborates with product designer to custom build a version of a component for a product model (if the model is mass-produced).
In case of components and products such as automobiles (since can’t use software for differentiation like cell-phones), nearly 80% of the large active-components are custom designed for each product-model. In case of mass-produced products such as Honda-accord, there is incentive for vendors to custom design even very small components such as break-pads (since they can sell millions for Honda company and millions more to services shops, which are needed to replace worn-out break-pads). So obout 90% of the components (i.e. active-components) are custom designed for just one product model, so neither reusable nor standardized. Hence it is mistake to believe software can be build by assembling third party components (but of course software can use other kinds of useful software parts, which are erroneously referred to as software-components).
Analyzing each ecosystem for third party component-parts of each of the mature product-families and evolution of the ecosystem since the invention of the early product-model of each product family, provides valuable insights into the nature of the CBD of physical products and physical active-components. Most of the software applications are not like physical products belongs to a crowded or mature product-family. In general, designing and developing a new software application is analogous to designing and developing a newly-invented physical-product or a one-of-a-kind experimental prototype for a new product-model (e.g. experimental Jet-fighter or spacecraft).
It is required to custom design most of the CPs, since it is not practical to find pre-existing CPs for such one-of-a-kind prototype-models/newly-invented physical-products. For example, the software-industry deals with many product-families such as compiler, video-games, search-engines, Operating-systems, RDBMS, banking-finance, supply chain for manufacturing, ERP or CityGIS, where each product-family needs different kind of CPs. For example, refer to City-GIS example, where no CP/RCC (e.g. City_ATC or City_LandMarks) can be reused in another product-family listed here). Also multiple newly-invented software-products are introduced each year, where each of the new software-products belongs to a new product-family.
Today developer of many large software applications use many types of useful parts belongs to various kinds (e.g. reusable, CASE-tools or standardized etc), where useful parts belong to each kind of software components possess a set of given properties (e.g. reusable, standardized or have properties for satisfying a certain component-model such as EJB or UML) referred to as components. It is misleading to refer such useful software parts as components, because this misconception (e.g. focus on useful but non-essential properties) prevented discovery of essential properties and hidden nature of the physical components (i.e. RSCC). Today software experts have known (or defined) and have been using many kinds of software parts (that are mistakenly assumed or misleadingly referred to as the components) but yet to discover properties and nature of the active-components of the physical-products.
It is essential to define accurate structure and process of the CBD of physical products for using as the basis for defining true CBD for the software products. One must always keep in mind an irrefutable fact that, no other kind of useful physical-part except the physical components can enable the CBD-structure for the physical products. Confirmation bias that, the software components for true CBD and CBSE (CBE for Software) were already invented decades ago, preventing many researchers from investigating and analyzing hidden nature of the CBD of physical products to discover right kind of software components that can enable true ‘CBD for software’ (i.e. the software-CBD that is comparable to the ‘CBD for the physical products’).
 
   
 

Copy Right © 2013 SPPS Systems Pvt.Ltd. All Rights Reserved.
This Website presents patented and patent-pending Inventions and Discoveries