Nightmare of component based development (4)

It has been a while since I posted about the nightmare of component based development. But, I promised to revisit, so here is another one.

Component based development may be a blessing to some product developments, but it can also be a nightmare to others. In part 1, I discussed the problems of finding a stable baseline as a reference for new development when developing multiple components simultaneously. Part 2 discussed the issue of reducing scale which resulted in both early and late integration. Part 3 focussed on the issue of ownership when developing multiple incarnations of a component simultaneously.

As the title says, component based development can be a nightmare. Complexity of systems and products continuously increase, and functionality originally designed and marketed as separate products, is being integrated. For example a camera in a mobile phone, GSP tracking in car navigation systems, medical monitoring in watch integrated with cellular communication, and much more. What originally was designed as a product becomes a component within other products. Components may be split or merged into other components. And what originally was marketing by company A may becomes an integral part of a product line for company B.

Even though component based development may be a nightmare - if not done properly, the need for componentization and flexibility with components is growing. It seems unavoidable that some day we have to face the problems of component based development anyway, whether we want or not. And this day will probably be sooner than we may expect.

Trying to integrate different products and components, that were designed with different architectures, is a challenge by itself. If there is time to do it properly, we may come with a proper solution, a new architecture. But there is never enough time to do it properly, so we need a way to at least control it in a proper way. It may even become worse when the need for integrating existing products and components exceed the need for new functionality. That may lead to a completely different approach to systems design and may redefine the term "reengineering".

Now what can we do?
Well, we cannot make a chaos-beyond-control first and then hope for a generic solution to regain control over the chaos. We don't have time to do that because the competition will beat us in the meantime. it must be a controlled evolutionary path.
This means that configuration management will become more important to control product development, and it may well become the most important control discipline. It will not only control the work products (inputs, intermediate work products and outputs), but also strategic roadmaps information and the information and knowledge of the company that is required for product development. It will be too difficult and too extensive to oversee all information by a single person or even by a team of people.

The "art of integration" will be a combination of product architecture and configuration (and knowledge) management, and these two will become even inseparable and indistinguishable.
Configuration management may even become more an integration of product architecture and project architecture (or more general, the architecture of an organization and its processes).