Kamen, it is Rob who is asking. I just propagated his question. > Michael probably you are asking about alignment of code to business.
No, the question is not about alignment; it is about what we can consider as a Real World Effect - only a new meta-data (Rob, please, correct me) resulted from an actions or also new information (actual data) described by the old meta-data ( i.e. new values aggregated according to known rules or meta-data). > 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. Customer satisfaction is a *slicky* ground. A SOA service cannot be sure it satisfies a consumer because 1) consumer decides about it by itself; 2) satisfaction and fulfilling the needs are not the same things. Also, how does a service know if a customer need is objective or subjective? Don't we know about frequent conflicts of interests between a person and organization, between a business unit and the enterprise it belongs to? Who said that customer's way of thinking is right for its own organization (i.e. fits into organization business model or addresses real problems in that model)? Believe it or not, but I lived in the country where customer satisfaction (in any business) was measured by a sum in hard currency on his/her bank account (desirably abroad) and/or by a number bottles of vodka, for free of cause. Did it relate to their business? - No, not at all. - Michael ----- Original Message ---- From: kaburov <[EMAIL PROTECTED]> To: [email protected] Sent: Saturday, June 28, 2008 5:14:59 PM Subject: [service-orientated-architecture] RWE based on data aggregation (was ESB/Intermediary in SOA (was Data services (was Re: Definition of SOA))) --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <[EMAIL PROTECTED] .> wrote: > > > > 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. > > 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: service-orientated- architecture@ yahoogroups. com > 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 >
