Interconnect the Solutions from different domains


But each Solution manages its own data and doesn't communicate with the others. The same information is entered several times and leads to discrepancies.

Exchanges between Solutions become an acute problem as we develop the use of IT Solutions.

The sum of good independent Solutions doesn't make a good global Model. We need to find an overall vision and establish the Process and Information map, define which information is shared between the domains and, from that, deduce our "Enterprise Architecture".

The Baker equips himself with Solutions that communicate with each other. The Solutions Map is defined and an exchange mechanism chosen. We build some interfaces between Solutions. From here on, there are no more discrepancies between the pieces of information.

  1. Dynamism and order

    The diversity of the Transformations leads to a growing number of Solutions: we have to not only manage Distribution, Production, Resources and enterprise management Solutions, but also

    • Accompany the new Offers made possible by the digital opportunities
    • Manage the multi-channel
    • Add data analysis Solutions (Big Data)
    • Interconnect partner Solutions, which are increasingly integrated with those of the Enterprise
    • Allow the different Models to access the different Solutions

    Do we need a framework to ensure that these multiple Solutions are part of a coherent whole or should we leave every freedom to each Solution to not harm the dynamics?

    In actual fact, we do not have a choice; different factors lead us to create an overall framework:
    • Group the information that enables us to manage the Customer together: his/her behavior, Product equipment, expectations, profitability, risk...
    • Agglomerate coherent management data
    • Control the end-to-end Processes whatever the channels used
    • Offer a uniform Usage to Users so that they are not afraid of crossing from one Solution to another.
    • Share identification and security Functions

    The real difficulty is in setting up a framework that not only does not slow down the initiatives, but actually accelerates the Transformation projects.

    Different methods contribute to this. We have grouped them together under the term "Foundation":
    • Interconnect the Solutions from the different domains properly
    • Reuse Components to build new Product Models
    • Reuse Components to build new Solution Models
    • Provide consistent user Usage
    • Harmonize the Transformation Processes

    In this scene, we cover the first method: Solution exchanges.

  2. The different Solutions need to exchange with each other

    1. Solutions supply other Solutions

      The first Solutions installed in the Enterprise were independent of each other. We had to re-enter the same information in the different Solutions, which represented a heavy workload, data entry errors, update discrepancies, in short a growing inconsistency in the Enterprise information system.
      Then, we understood that we had to interconnect the Solutions to avoid these difficulties and let the information from one Solution flow automatically to another; for example:

      • Production feeds into Distribution.
      • Payroll feeds into accounting.
      • All Solutions feed into the management Solution.
    2. Data is shared

      The same Customer Information is useful in different Solutions: Distribution Solutions of the different Product lines, maintenance Solutions, billing Solutions... We must therefore be able to share the same Customer information between different Solutions.

      In the same way, Information which describes the Enterprise structure or the user rights and responsibilities are useful in all the Solutions.

    3. End-to-end Processes cross several Solutions

      Customer order management can cross different Solutions: quotation Solution, contract management Solution, billing Solution, payment and litigation management Solution, delivery management Solution, sales statistics Solution... Each Solution must be able to feed into the next Solution in the context of an end-to-end Process, while safeguarding the context of the Process.

  3. Different types of exchanges between Solutions

    There are different types of exchanges between Solutions:

    • Synchronous or asynchronous
    • Query or updates of information
    • Triggering IT Services (that are frequently implemented today as a Web Service)
    • Data replication
    • Flows between Solutions
  4. How do we properly define the exchanges between Solutions?

    The multiplication of exchanges generates significant complexity: certain IT directors complain that they have become plumbers, spending their time connecting Solutions.

    It is quite common that building these exchanges takes more effort than building the functionalities awaited for by the users of the Solution.

    To limit this complexity, there are 3 ways:

    1. Limit the number of Solutions: look for Solutions broad in scope so that a certain number of exchanges are taken into account inside each Solution.

    Choose between many small Solutions or few large Solutions

    2. Group together the different exchanges in wide reaching Services. For example, if we need to

    • know the customer's name by his/her login, for a sales Solution
    • know the customer's address by his/her login, for a billing Solution
    • know the customer's account by his/her login for a customer payment management Solution

    we can then set up a single exchange Service that, from the customer login, provides all 3 pieces of information: it is then up to everyone to only use what he/she needs. The challenge is finding the right compromise between reducing the amount of exchange types and the increasing heaviness of each exchange.

    3. Tool making exchanges so that each build of an exchange Service is quicker.

  5. An overall vision is necessary

    The most important thing is to deal with the exchanges as a coherent whole and not as continuous additions of exchange formats as the Solutions are set up.
    The right approach consists in:

    • Defining the Enterprise data Model
    • Defining the Solutions map
    • From there, deducing the list of exchange Services.
  6. See the white paper from CEISAR

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