banner banner  

What is the primary purpose/essence of componentization?

What is the primary purpose for componentization of a complex product (or a problem)? The componentization allows partitioning a complex product (or problem) in to much smaller components (or cohesive self-contained problems), where each of the components can be addressed individually (e.g. to build each component as best as it can be and to test individually). Once the satisfied with the functioning and operation of each of the component, periodically assemble the components together to build and test the product to make sure that (a) each of the components properly collaborating with other parts (e.g. in step-1), and (b) all the components are fulfilling their respective roles as intended for proper operation of the product.
The primary purpose for componentization can be grasped by observing the design and making of a working prototype of new innovative CBD-product. Mankind invented countless CBD-products such as automobiles, computers or airplanes and also working on inventing many new CBD-products each year. It is essential to gain insights into the process of inventing and building a new product (e.g. fully working prototype). There is no valid reason, why design of a new software product different from the design of a new innovative physical CBD-product, such as design of first Airplane by Wright brothers or many other new products invented each year.
Please kindly review this very interesting example for designing and building new innovative product, referred to as artificial kidney. Please kindly pay attention to 15 seconds bit starting at 1 minute 55 seconds. Let me paraphrase the 15 seconds bit, as I understood it: Essential purpose of the real component-based engineering is ability to look, feel and test each component independently to optimize individually for making each component as best as it can be. Periodically bring the components together to build product for making sure that (a) each of them properly collaborating with other parts, and (b) all the components are fulfilling their respective roles as intended for proper operation of the container product.
In light of the above example we must comprehend, why and what manner the components are useful in designing and building complex products. The componentization reduces the complexity by substantially increasing the degree of specialization and division-of-labor, since each component in the CBD-structure can be evolved individually (e.g. to optimize or improve incrementally). These powerful industrial engineering factors allow evolution of each of the components by redesigning little-by-little for making the component as best as it can be individually, when designing a new product in step-1 (and each new of the subsequent releases of future model in step-3). This is the purpose of ‘fix-and-test’ cycles in step-1 & 3 of CBD-process for redesigning each component little-by-little to make it as best as it can be.
The City_GIS presents a software application created by using CBD-process (that achieved the CBD-structure), where each component is built and tested as an autonomous application and each component allow optimizing individually for making it as best as it can be. Real CBD must 'version' and 'sandbox' source code of each component to evolve it little-by-little not only in step-1 but also throughout the life of container-product (in each future iterations of step-3).
Furthermore, the components are conducive to increase the degree of automation, which can substantially increase productivity and quality, while reducing the complexity by eliminating many routine error prone manual activities. For example, intelligent CASE-tools can be employed to eliminate creating communication code and testing coupling interfaces.
All of the above benefits can be secure and may be maximized by achieving an ideal CBD-structure by identifying SCC (of optimal size/complexity) that are equivalent to the physical active-components for creating and assembling real-software-components. However, to secure the above benefits, it is not necessary that even a single component in the CBD-structure is reusable, standardized or has any property erroneously attributed to software component today.
The true essence of CBD and components can be discovered by investigation and objective analysis of the design of first prototype of a new innovative product. It is not hard to find, why and how software products are different from products from mature or crowded product families, where the properties such as component reuse or standardization are very useful (e.g. for evolution ecosystem for 3rd party component-vendors). But in case of unique one-of-a-kind products, very few active components can be reusable or standardized.
It is error to define reusable software parts are software components, just because few physical components are reusable. It is error to define standardized software parts are software components, just because few physical components are standardized. To invent real software components equivalent to large physical active-components, one must discover unique set of essential properties that are universally shared by each and every active-component in the world.
The purpose for discovering the unique set of essential properties (or hidden-nature) are (a) one must be able to unambiguously identify each component and (b) one must be able to unambiguously differentiate any other being (e.g. a thing or part) form the components (i.e. if and only if the being is not a component). Any competent designer can identify multiple SCC (Self-Contained Components) in any large software application, once he discovers the unique set of essential properties and hidden nature of the real components.

Philosophical perspective for componentization of a complex problem:

The componentization is a kind of compartmentalization of a large or complex problem; into smaller problems. The compartmentalization for engineering problems is defined as “the separating of two or more parts of a system to prevent malfunctions from spreading between or among them”. The compartmentalization for minimizing cognitive-dissonance in psychology is defined as “act of splitting an idea or concept into parts and trying to enforce their distinctness in the mind”. Usually a team of engineers (or experts) work on designing and building a complex product (or solving a complex problem). The team and each engineer can work more and more effectively, if each of the work assigned to each engineer is compartmentalized (or compartmentalized) to higher and higher degree. Achieving an ideal CBD-structure (e.g. City_GIS) is best possible solution for the compartmentalization (by minimizing cognitive-dissonance).
The componentization of a complex problem (e.g. a product) is a process of partitioning the complex problem into smaller self-contained problems. Let’s define the equation for total complexity of an ideal componentized product (or compartmentalized problem) as: Sum of complexities of finding solutions for all the compartments (i.e. smaller problems) plus complexity of assembling all the compartments (where, in case of real-CBD, complexity of assembling all the compartments must be less than 10% of the total complexity of the product). It is extremely unlikely to find a perfect pre-built component, so each of the components in the CBD-structure must be custom designed. Of course, each engineer responsible for any component can leverage any and every technology and reusable libraries at his disposal to build the component.
For example, each component such as City_ATC in City_GIS can be created by using any and every technology, tools and reusable libraries at his disposal. If a perfect City_ATC component were to readily available as an open source solution, it is a component having near zero complexity in the equation for the total complexity. That is, the problem is already solved, if a perfect reusable component is already available. In that perspective, componentization is to partition the remaining complexity (after eliminating all the complexities of problems already solved completely, mostly or partially). Obviously team of engineers need to solve only remaining problems to build each complex product (e.g. CityGIS).
Please kindly pay attention to this important point (in the light of above example): The componentization of a complex problem (e.g. a product) is a process of partitioning the complex problem into smaller self-contained problems (not yet been already solved) for effectively solving each of them by a team of engineers, where for example, by assigning each of the smaller problems to one of the engineers to solve in a way consistent with his skills, training and domain knowledge. The complexity of building solutions (e.g. compilers, libraries, tools or RDBMS) that already exist doesn’t add any complexity to the total complexity of the problem being addressed by the engineers (except of course complexity of using the existing solutions for addressing each of the smaller problems). For example, if a component (e.g. RCC for City_ATC) uses a RDBMS, it can only add the complexity of using RDBM, but not the complexity of building the RDBMS.
The complexity a team of engineers must address to solve a large problem (e.g. City_GIS) is the complexity of issues and problems still remaining to be addressed. If the large problem is partitioned in to smaller self-contained problems, the complexity of each smaller self-contained problem (e.g. RCC for City_ATC) is the complexity of issues and parts still remaining to be addressed (by leveraging all the available solutions and reusable parts). The software engineering paradigm exist today is mainly focusing on reducing the complexity by providing ready to use solutions and reusable parts (to minimize issues and parts that still remain un-addressed). But this paradigm fail to compartmentalize the remaining un-addressed problems for each member of the team of engineers to address each of the un-addressed problem effectively and efficiently.
Since designing and developing most of the large software products is similar to designing & building one-of-a-kind prototype of a newly invented product, each large software application is still left with numerous un-addressed problems and issues. The primary essence of the CBD and components is to reduce the complexity by partitioning the large problem (still remaining to be solved) in to smaller self-contained problems (still remaining to be solved), where each smaller self-contained problem can be addressed/solved and evolved/adapted much more effectively & efficiently by each engineer in a manner consistent with his skills, training and domain expertise.
The componentization is the most effective and efficient method known to the mankind today for addressing any complex problem by each member of a team of experts in a manner consistent with one's skills, expertise and domain knowledge. The complex problem is partitioned into self-contained smaller-problems (i.e. components), where each large or complex component is successively partitioned into self-contained sub-components (i.e. even smaller-problems, so on, for addressing each individually by using expertise/knowledge of a team-member), which results in a structure of a hierarchy of swappable-modules (logically equivalent to the CBD-structure).
Where philosophically, the reuse represents using of existing solution. In case of a software or one-of-a-kind experimental product (e.g. prototype of a spacecraft or Jet-fighter), its designers must design many custom components for satisfying unique needs. So the engineers must solve many large un-addressed problems (i.e. custom components), where they use many small existing solution (i.e. reusable parts such as GUI-API) for addressing each of the large problems (i.e. each custom component or sub-component). Although it is an irrefutable fact of componentization, this fact is counter intuitive and in contradiction with existing paradigm of software engineering and especially so called software components, which has been pre-occupied and even obsessed with non-essential properties and nature such as reuse or standardization.

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