1

Design Problem:
A department aligned system (an application/UI and database, which we'll call System A) is used to manage both customer information and customer transactional data like orders, charges, billing information, etc. Connected to System A are 15 downstream systems - all with UI (about 12 are department aligned systems, the rest are not). Customer and order data is replicated to the downstream systems via an ESB. ESB queries System A database to retrieve data which need to be replicated. A few downstream systems connect directly to System A tables. The structure of the customer related tables is very department centric.

Now there is a requirement to decentralize the customer data maintenance (as customer data is currently being managed in different department aligned systems), i.e., build an Master Data Management system for customers, to streamline business processes of various departments. Part of the MDM push is to restructure the customer related tables into a more flexible table structure to cater to other department's customer data. Also, the 15 downstream system interfaces should not be affected.

Which solution would be appropriate?

Solution 1 - Rewrite System A (including customer orders modules)
This requires:

  1. Rewrite System A to be System B (both application/UI and database). System B having: 1) a database with flexible customer table structure 2) rewrite of System A customer order modules
  2. Migrate all System A data onto System B
  3. Rewriting all ESB stored procedures
  4. Create adapters in ESB layer to abstract message format changes and not impact existing downstream interfaces
  5. For downstreams that connect directly to System A database tables, create database views to mimic old customer table structures

Solution 2 - Retain System A, Create System B
This requires:

  1. Create System B having a read-weite UI and database with flexible customer table structure (this will become part of MDM)
  2. Make customer modules/UI in System A readonly; maintenance of customer data will be in System B; no further changes required in System A; all downstream systems will continue to connect to System A
  3. Create component that will replicated data changes from System B to System A

I'm reserving the pros, cons and risks I have come up with for later because I don't want to influence any answer.

Any input is appreciated.

Kromster
  • 468
  • 1
  • 6
  • 17
rro
  • 279
  • 2
  • 8
  • Given that the current trend is to decentralise data storage in order to improve flexibility of separate systems, the requirement seems to be a bit of an odd one to me. Have you tried suggesting to keep both systems but implement a service to provide & store customer data for other departments as part of system A? – Jules Mar 01 '16 at 14:11
  • Sorry for the confusion. I meant decentralize customer management. The architectural decision was to completely rewrite entire System A (both customer related tables and otherwise - Solution 1 I described in y question). I am now questioning the decision to rewrite entire System A as there is no benefit in rewriting the non customer related modules (table structures and application logic). – rro Mar 01 '16 at 14:26
  • For solution 1 requirement 4, are you sure that it is technically possible to create such views to mimic old customer table structures? Has this been evaluated or experimented? For solution 2 requirement 2, after System A has been made read-only, how do the downstream systems continue to function? Are all downstream systems satisfied with read-only access? For the overall question, can you tag all of the components that have human user interfaces? – rwong Mar 01 '16 at 17:12
  • @rwong - for solution 1 number 4, yes it is pssible to create views to mimic the old customer structures, but not without challenges or performance impacts. For solution 2, not all System A modules will be made readonly from the UI, only the customer modules of System A will be made readonly since maintennce of customers will be in System B. – rro Mar 04 '16 at 01:09

0 Answers0