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).


About Frank Schophuizen (fschop)

Hi, my name is Frank Schophuizen and I am working as a consultant in CM, Agile and ALM for TOPIC Embedded Systems. I have over 30 years experience in software development in the technology industry, with the last 15 years mainly in process improvement, deployment and integration of methods and tools in the area of Agile (SAFe, Scrum), CM and ALM. I am strongly interested in the complexities of collaboration and integration in multi-project and multi-site organizations. I have worked with various technology companies such as Philips, ASML, NXP and Vanderlande, and with various tool vendors such as Atlassian (e.g. Jira, Confluence),IBM Rational (e.g. ClearCase, Synergy, Jazz products) as well as open source tools (e.g. SVN, Git, Jenkins, Trac, Eclipse). I am living in Eindhoven, the Netherlands, with my wife. We have 3 adult children. My main hobbies are classical music and photography.
This entry was posted in configuration management. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s