Why should I make my MDM SoA enabled?

A Car Sales Manager is capturing the details of a customer, who visited his showroom. After jotting down the client's address details, the Manager wants to check out if the address is a valid one. How can he achieve it?

A PRO in the same organization receives a call from the customer that he wants to change his address in the system records. The PRO logs in to the silo-ed application and enters the new address. When entering the address, the PRO wants to check if the new address is a valid one. How can she achieve it?

MDM and SoA make this happen. MDM is more like a service provider and SoA is a framework helping the consumers to access the service with ease. A Location Master Repository tied up a SoA framework makes any consumer to use the services of the Location Master. This way, the same master data gets reused throughout the organization for multiple purposes.

In one of our projects, the client had a unique requirement to assess if a product is worth promoting and if found promotable, what is the promotion to be given to it. Such a requirement was addressed using a SoA framework on a product portfolio MDM. The architecture had BEA AquaLogic Service Bus interacting with Kalido MDM to provide the services. The challenges lied in identifying the streams which would consume this service and evaluating if its worth considering a service. The service found its usage in many CRM applications in the organization.

MDM - SoA Marriage

After a long break from blogging, I am starting my series of explorations with MDM and SoA. When would somebody go for a SoA implementation for an MDM solution? Is it because it's a enterprise-wide initiative to make everything the SoA way? My current project proved to be a big failure on this front. We had to build an MDM solution and the enterprise architecture team had a clear focus to make anything and everything SoA enabled. The MDM solution was built on Kalido. Who are the consumers of this MDM data? Answer is . A series of downstream CRM applications. Sounds good. Where would the SoA architecture fit in? Is it just in the Consumer world or also in the Sourcing world? We had to design the reporting solution completely SoA. But during a period of stress testing, it proved that the SoA framework just couldn't handle the volumes the downstream applications were streaming. The MDM Solution would get a huge number of updates from the ERP stack everyday and all these changes had to be donated to the consumers. The SOAP message was just too big to be parsed by the reporting solution. The users had to wait for a considerable amount of time to get their reports out.

So my question is whether you design the MDM solution the SoA way expecting in future that things with performance would get solved or wait till things get solved and then re-architect the solution?

Currently, we have the SoA suite disabled and reports are being fired out from the databases directly to the reporting solution.