--- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > > <<What's often overlooked among these layers are the schemas. Many > service designers allow schemas to become skewed in support of the > service layer, but there is a real opportunity to build a data > architecture that is fully capable of facilitating individual > services (usually through shared schemas) but can also be used > outside of the service layer by other parts of the enterprise that > can benefit from its usually uniform, abstracted view of enterprise- > wide data.>> > > +1 > > Data model/schema in a data store may be a business data model. > Services do not need to use the entire business data model but its > sub-models/sub-schemas/views. Those certainly may be reused outside > of services. DAL is the example of this approach.
+1. Random thoughts that this post triggered: * It's BA or EA that we should worry about, not SOA. SOA is not a discrete level of architecture, it's a style. Apply SO, where it makes sense, but a BA/EA needs to address more than just SO--such as where DAL may fit in, or how the various data models are to be leveraged. * DAL might be leveraged by an SO system, but DAL is not related to SO. A DAL is data oriented. Service wrappers around data access is still data oriented. -Rob
