> warehousing/ODS/general OLAP issues? Forbidding the BI folks to
> directly access the underlying data via SQL is not going to make
> them your friends, and alternatives such as providing them with the
> message/ XML-level access only is not what they're looking for,
> either.
>
> My current thinking is to provide a read-only SQL view for services
> that maintain some data; this view would be decoupled from the
> actual relational data representation, its definition would be
> versioned, its lifecycle would be governed by the same means as the
> "normal" service interface, it would be stored in the registry, etc.
1. Design your business measurements as part of your business
processes. (i.e. how do you measure the success important aspects
of your processes?)
2. Design your data "bus" architecture along with your service "bus"
architecture. (i.e. how does the information align that is being
collected from your services, see Kimball, et
al. http://ralphkimball.com/ for what a conceptual data bus is and
how to design it incrementally.)
3. I agree I would not try to do the data aspects of this via XML or
service interfaces. I would look to do this via HTTP / XHTML for
some things, and read-only SQL for other things as you say.
I think the important aspects are prioritizing the data development
activities from business value just as you would services, and
following good data analysis designs just as you would follow good
service designs.
-Patrick
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.
