> For example, when a service needs to know something about a customer
> and an account, it can
>
> (a) go to both CustomerManagement and AccountManagement and correlate
> the data itself
> (b) go to ODS and retrieve the aggregated information
>
> Approach (a) would support a strong concept of data ownership and
> autonomy, which I like very much. Scenario (b), though, is very
> attractive for many because it consolidates the data integration logic
> in a single place. For this purpose, I'm not as much concerned with
> how the data gets into the ODS (via data replication, Web service
> calls or RSS/Atom feeds). I'm unsure whether putting a single
> "know-all" entity in the center is such a good idea ...
Hi Stefan,
One thing option (a) also supports pretty well (at least in Europe) is
easier compliance with the Data Protection and Privacy laws because you
would have to (potentially at least) authenticate to each of those
sources if you went looking for data, and then you could use policy
decisions to determine if you belonged to part of the organization that
had been given access to this information by the customer. Once you
centralize the data, you may lose the context that would allow you to
provide appropriate access controls. Of course, it might be easier to
respond to a data protection disclosure request, but I think the
potential for abuse is a lot higher with option (b).
On one hand, this thread is somewhat relevant to some of the Information
Sharing challenges faced by the US Government. I think the core
challenge is the same: get the right data to the right people at the
right time (provided they're entitled to see it), but instead of one
ODS, there's loads of them. Have been doing some thinking in this area
as well lately, so this thread is very timely input. Thanks for
bringing it up Stefan.
ast
________________________________________________________________________
***************************************************************************************************
The information in this email is confidential and may be legally privileged Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
