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.
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.
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.
The story of George the Baker is made available under the terms of the
Creative Commons Attribution - NoDerivatives 4.0 International license.