Make different Operational Solutions with the same Components


The work of the Transformers who create the Solutions also becomes increasingly complex…

As with the production of his Products, the Baker would like to rationalize the creation of Solutions.

A component-based approach is also a valid one in the world of Transformation: Solutions can be assembled from basic building blocks. This enables us to go quickly without necessarily turning to a Software package.

The Baker creates his Component team. He manages to cut costs and development times in half.

  1. What advantages are there in reusing components to build a new Solution?

    To become more agile in building Solutions, we need to reuse in order to have less to build.
    There are 2 forms of reuse: reusing Software packages or reusing Components .

    Reusing Software packages has had increased success over the last few years for Commodity Solutions, for which the needs are similar between Enterprises.

    But an economic activity only reaches maturity when it is capable of reusing common components to build Business Solutions: it took 200 years for Industry to arrive at its current maturity. The time taken to build a new automobile Model has been reduced from 5 years to 18 months by reusing Components.

    It will take a certain amount of time for the Software industry to do the same. But we can have great hope. Trends like "SOA", "reusable Component", "Object approach" are all heading in this way, and the results obtained in a certain number of Solution Models prove that a 70% reuse rate are realistic, that is to say that we only have 30% of the Model to Build to satisfy a specific requirement.

    Software package vendors are themselves going through this dramatic change : the new Software package offers Built are often Component-based.

    As with Product modeling, we find the same advantages:
    • Time and cost savings on the design of new Solution Models
    • Better reliability as the majority of the components have already been tried and tested
    • Uniform usability which makes life easier for the users.
  2. Do not confuse Architecture and Components

    Architecture and Components both contribute to organizing and sorting things out.
    But they go about it in two ways:

    • Architecture provides an overall vision of the Model that the different Solutions are part of
    • Components are reusable Modules that we can assemble to build specific Solutions.
  3. How to build components

    It is more difficult to Build Components than a Solution: Components must reuse Components, they must be versioned , documented and must satisfy extremely diverse needs.

    If we do not have any experience, it is important to begin modestly, know from the offset that we will have to iterate and redevelop some components, but do not give up on the idea of a high reuse rate. (See the CEISAR white paper on the Foundation).

    It is alone not enough to build good components, they must also be easily accessible and comprehensible.

  4. Acquire components

    We can acquire a bank of components or make them ourselves.
    If we want to avoid the time needed for maturation, we can purchase a component framework from outside then adapt it to our context.

    One of the most efficient scenarios, if we use a Software Package as the central Solution of our Information Systems, is when we purchase components from the vendor: interfacing work will be easier and the use will be standardized. This option is limited to the software package vendor's goodwill as they must accept to supply the components that are used to build their own Solutions.

  5. Conditions for success

    Successfully reusing Components en masse requires the conditions for success:

    • Isolate in a "Foundation" team those that build, support and recover the Components.
    • Ensure that they have gained the know-how to build components: interface quality, structure of small components that are reused by each other and not a flat list of  big components, versioning, in-depth use of Patterns, forward compatibility, suitable configuration management...
    •  Encourage and control reuse in the Solution teams.

See the CEISAR white paper on the Foundation 

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

comments powered by Disqus