Providing products which can merge disparate data

The scenario described by Fuzzy isn’t that different from what I imagine you find at many customer sites over the planet. People create more than one system, which grow and eventually overlap. This could be because of growth of the systems, because of the merger of departments, or because of poor design on the part of the customer. I have been on a couple of customer sites recently where they are storing data in more than one system, in fact they’re storing the same information twice.

The challenge we should really address is how we seamlessly handle that challenge. We should be capable of searching and reporting results from more than one instance of our product, and the Web Service project I have spent the last year or so one gives us a good infrastructure for that. Then we just need to handle the creation of data, and determining where new data should go. That sounds like a customer configuration problem to be. We should also come up with some sort of plan as to how to return results from non-TRIM systems. That could be as simple as publishing an integration interface specification for a Web Service which will also be searched at the time of a query.

So really the question should be: why aren’t we doing more to make this sort of scenario transparent to the user? Why do we still expect the customer to merge systems?

[tags: work architecture]