The Need for Middleware (5 of 5)

Our final blog in this series is about a solution that is “outside the box” thinking.  Rather than force a decision to change, we believed that an interim step to integrate systems would allow for the least disruption.

The solution of having a middleware platform would allow users to continue to use the systems they are familiar, but provide synchronized data, either through syndicating it on the backend, or re-inserting it on the front end.

As part of our recommendation, we proposed Middleware with the Data Warehouse.  Therefore, the existing systems would feed their data into the Middleware, where there would be a series of business rules, validations, normalization routines, and mapping functions – all based on business rules derived from the Data Dictionary work.  From there, we envisioned this Middleware acting as the Constituent MDM with a single user who would be the expert on the business rules and Data Governance. The MW/MDM would feed the Data Warehouse (DWH), which would also be receiving the transactional data.  From there, business consumers would be able to access the transactional data with the normalized constituent data.

The next step in the progression of the Middleware solution would be to have the Constituent MDM as the main entry point, therefore having multiple users.  The Constituent data would then get fed to the Middleware, matching it with the transactional data and then on to the business consumers.

A final step in the progression would be the paring down of any non-critical databases or apps, therefore further eliminating up-front redundancies and only mildly taxing the Middleware rules prior to the DWH delivery.