Extract from the white paper: The role of the architect – The Cercle CESAM
Preamble

The evolution of a product line is dictated by changing needs. These changes in needs can come from several sources, such as the market, future business needs, or the desire to introduce new products into the product line.

THE ESSENTIAL

Controlling the scope and technical debt (management of obsolescence and technical choices of implementation) of the line of products via strong governance is a major challenge for its maintenance and development.

THE MAIN PITFALLS

Among the main pitfalls:

  • There is no governance or no solid governance (i.e., which is not recognized in the company or supplanted by other processes – by projects for example);
  • Governance that is too rigid or decorrelated from operational needs, which no longer allows adaptation to market changes;
  • The project that forces the product line to make a change and ultimately distorts the product line;
  • Obsolescence management:
    • We cling to all the functionalities, even those which are no longer relevant, which leads to a maintenance cost that is too high;
    • The obsolescence of components not taken into account in the creation leads to a maintenance cost that is too high for the product range, even jeopardizes it;
    • Creation and maintenance are decoupled and have no common rules.
BEST PRACTICES

Here are some good practices to consider:

  • Set up feedback from projects to the product line within governance to reinject what could be reused and understand what is not used;
  • You have to make sure that the maintenance and the evolution of the product line are done at the right moment, that is to say at the moment when you need to make an instantiation. It is a question of piloting the line of products according to the deadlines of the project;
  • Move architects between product line maintenance and projects to improve the relevance of architectures to project needs;
  • Have meshed during the creation of the product line the documentary architecture (from specification to testing) on the architecture of the product line in order to promote the capitalization of projects and configuration management;
  • Do not hesitate to prune certain elements/functionalities or even to make a new range of products if you realize that maintaining or changing the line of products no longer makes operational or economic sense.
TESTIMONIALS

We have compiled here several verbatim statements from project managers or system architects from different companies, which echo this phase:

Nowadays we sometimes spend a lot of time finding test reports, justifications for design choices, etc. due to a lack of link between the documentation and the architecture, and of sharing between the different entities.
We are mainly working on extending product lines (by adding new artefacts) to gain in efficiency and even address new markets more quickly.
Development environments vary enormously over very long series: we have to keep old PCs only to make changes in the event of problems with these old products.

This post is also available in pdf format.DOWNLOAD
Any comments?

Your comments will be considered by the members of the Cercle at the next monthly meeting.