First of, I want to thank you all for your comments. I also agree with you John (Jones) that leveraging a real-time pub-sub interface is a great alternate option for keeping the Enterprise Repository synch'd up. However, here are some of the reasons I introduced an ETL interface into the mix for keeping the Enterprise Repository in synch.

A) For Systems of Records that are legacy systems and/or packaged vendor products it may not be feasible to extend these to create a publication process.

B) ETL has cross-business domain and enterprise business concept transformation logic and this logic is kept separated from the system of Record. Also, all of the relavant extraction and transformation logic required to create a single business concept from various Systetms of Record is included in a single ETL process instead of in the muliple pub/sub messaging processes.

C) Scheduled ETL is also effective in insuring that only the finalized stable state of long running business transactions across the various Systems of Record is applied to the Enterprise Repository.

D) ETL process includes information filter logic and it filters and transforms select System of Record transactions by correlating this information across business domains based on enterprise worthiness, relavance and priority.

E) Finally, the enterprise could choose scheduled ETL process as the primarily synchronization mechanism for the Enterprise Repository and this could be run during the SoR transaction downtimes so as to not affect the operational and transactional systetms and also to increase responsiveness of the business service.

Surekha.

Why not set up a real-time pub/sub interface between the legacy systems and the Enterprise Data Store? Then there is no data latency waiting for the ETL jobs to run when the data required by the requesting service hasn't been populated yet.

I'm glad to see an article about the use of ETL withn a SOA environment. At our company we're seeing the dichotomy between the hype of SOA, the ability for everything to be encapsulated as a service via loose coupling with an application's web services API, and the fact that a huge chunk of corporate data out there is still in legacy formats, such as VSAM, ISAM, COBOL, and other hard-to-get-to forats with no APIs.

Great article, and very informative!