Best approach to Architect the integration of two separate databases?

Question

I\'ve ran into the following questions at work, and I don\'t have the experience or knowledge in order to answer them, I\'m hoping that some of you wiser folk may be able to poi

Answer 1

Sounds like you need to do some serious data-modeling.

You definitely need it for the long term so that you don't get yourself into serious strife. (if there's one thing that will have a significant impact on your ability to support / extend systems and support business growth - it's data management). The good thing about (business) data is that your business stakeholders will (or should) have a good understanding of it and be suitably motivated to support you. The value such an exercise will bring should be an easy sell. Having some of this in place in the short term will help as well.

Data sources which come with packages products (Commercial Off The Shelf - COTS) will not be open to change without putting those systems at risk - but that doesn't mean you can't use ETL and other databases to create data marts that bring disparate data together. In this sort of an approach the data modeling, and data mapping between systems will be important - but also the timing.

You will have more flexibility with in-house apps - but you might want to resist tactical changes unless you have a very compelling reason, otherwise you'll probably have to re-work them anyway.

As part of this exercise you'll want to consider the System of Record of each piece of data - where does it come from? Who owns it? You can start at a high-level by drawing up a conceptual data model, this will probably deal more with logical datasets than specific "columns".

Use this information to guide further decisions.

In terms of your immediate approach (and your question): in general terms it'd think about putting a layer of abstraction between your systems and the data, so that the applications are cushioned from change when that happens.

Create a new EF data model, responsible for providing information that only the application needs, while duplicating some common entities such as the Employee.

The big issue with duplication is getting the data into a state thats muddy - which is the "real" record. This can easily kill you. What are the benefits of this approach in your context? Would you be doing this from a supportability perspective? Ease of development?