On Jun 1, 2006, at 6:42 PM, Andrew S. Townley wrote:
> On Wed, 2006-05-31 at 19:07, Stefan Tilkov wrote:
>> 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).
>
Excellent point! Obviously, that's another downside - having
consolidated data easily accessible is both nice and risky.
> On one hand, this thread is somewhat relevant to some of the
> Information
> Sharing challenges faced by the US Government.
(Almost) anything affecting the US is relevant for global players
everywhere; for example, in nearly all of our existing engagements in
Germany and Switzerland, SOX compliance is an issue.
> 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.
Thanks for all the great responses!
Best regards,
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.
> **********************************************************************
> *****************************
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor --------------------
> ~-->
> Home is just a click away. Make Yahoo! your home page now.
> http://us.click.yahoo.com/DHchtC/3FxNAA/yQLSAA/NhFolB/TM
> --------------------------------------------------------------------
> ~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
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.
