--- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > > > > Is the combining/aggregating/merging of data a RWE? Or is it the > > > actions resulting *after* that activity that are important? e.g. > > > direct mail campaign, identification of a correlation between data > > > points resulting in special promotions, etc. > > Hey folks, anybody? > > - Michael
Michael probably you are asking about alignment of code to business. Well I wrote several weeks ago that alignment to the way of thinking of users provides maximum customer satisfaction. In other words for user is most important to have the functionality in his intentions or way of thinking. So my opinion is that in cases when user expects to get aggregation of data this is more important,when user expects to have direct mail campaign this is more important, etc Kamen > ----- Original Message ---- > From: Rob Eamon <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, June 27, 2008 4:14:48 PM > Subject: [service-orientated-architecture] ESB/Intermediary in SOA (was Data services (was Re: Definition of SOA)) > > > --- In service-orientated- architecture@ yahoogroups. com, Michael > Poulin <m3poulin@ .> wrote: > > > > Rob, I even capitalised the service action name. A "Client Business > > Data" or "Single Customer View" are not services, they are RWE of > > the services. > > Those describe the data or message submitted to or returned by a call > to an operation. A service may have operations that simply read or > write the data, but there should be more operations in the service > than just those (as we've already agreed, I think). > > Is the combining/aggregati ng/merging of data a RWE? Or is it the > actions resulting *after* that activity that are important? e.g. > direct mail campaign, identification of a correlation between data > points resulting in special promotions, etc. > > In other words, is the "Client Business Data" or SCV the end point? > Or are they really steps along the path to the "real" activity? How > many business folks will say "Ah, now that I have the Client Business > Data, I'm done. My day is complete."? > > IMO, noone would ever say that. That's because they intend to do > something with that data after they get it. So we should focus on > that "do something" and not only on the data retrieval. > > > I agree with you that just a data retrieval with an execution of an > > SQL statement is not a service - it is pure technical solution > > dictated by particular type of the data storage. > > +1 > > > BTW, do we consider an abstraction like a business data storage > > being a business thing? > > Yes, it is at least implicit in the service defintions. How a > business service stores or accesses its data is of no concern--it' s > an implementation detail. > > > It seems that existance of business data model (which is very > > important business thing becuase it carries > > business information, knowledge, business treasure) w/o a > > definition of the place where this information materialises is a > > bit incomplete.. . > > Yes, as I mentioned earlier in the thread, the model is indeed > important. It materializes in the services and operations, > represented by the data/messages/ events exchanged by the consumers > and providers. > > > At the same time, I think that an aggregation of business data > > according to business rules from different data sources may be > > accepted as a business service because it can provide new RWE > > unavailable via simple data retrieval. What do you think? > > Presumably the data aggregation is intended to serve some actionable > purpose, as I mention above. I think we agree that a service can do > whatever it needs to perform its work, including aggregating data > from various sources (be they other services, data abstraction > layers, direct database accesses, etc.). > > -Rob >
