Build and support Components well

It's difficult to build good solutions with bad components.

The baker doesn't know whether failure is due to the components or to the solution builders.

It's extremely difficult to build a component framework: turn to those who have already built an offer.

The baker acquires a component kit from outside and tailors it to meet his requirements.

  1. It is difficult to build Components

    How do we take the needs of all the potential customers of the Components into account when we do not know them all?
    Experience plays a considerable role: those who have already built components know the requirements better. This is the reason why it is recommended to check on the market if an efficient component Framework exists before launching into building your own one.
    As the components are used by everyone, the consequences of a component evolving are more difficult to predict. How do we ensure that the existing Solutions are not disrupted by new versions of the components? Should we give priority to:

    1. forward compatibility: we ensure that the new versions of the components will not disrupt the Solutions that already use them, but we limit the evolutions of the components.

    2. growing efficacy: we do not hesitate to overhaul a component because we have developed a new design, but forward compatibility is not guaranteed.
    The Components enable us to modularize Solution Building. But decomposing into modules means many successive calls that may impact on the performances.

    Seeking the causes of an incident are more complex as they can arise from the Components, which call each other.

  2. It is difficult to use Components

    Even if the Components are well built, it is not enough: the Solution builders must use them.
    If the refusal is "political" (we want to keep our independence), we have to introduce the right governance (see the chapter on Transformation governance).
    But, the refusal may be technical:

    • Too many, we do not know how to find them again
    • We do not understand what they do
    • We do not know how to use them
    • We do not know if we should install the new version

    We must therefore introduce rules for building Components.

  3. Some rules for building components

    • Components are small: 1 or 2 pages of code. Otherwise, we have to decompose them into several components.
    • Components should reuse components.
    • Components are versioned: not only in the documentation but also when calling the Component.
    • Think of the customer of the component when we name it.
    • Organize a Component catalog.
    • Give examples of use.
Licence Creative Commons
The story of George the Baker is made available under the terms of the
Creative Commons Attribution - NoDerivatives 4.0 International license.
Table of Contents


comments powered by Disqus