Kamen, we are talking about 2 things in here. 1. Satisfaction. I do not like this term because we are trying to deal with measurable things in SOA. 'Satisfaction' carries more connotation than 'need'. The latter represents concrete requirement. I think if a service meets requirements, its work is done well, we can control it. But we still do not know for sure that the customer is satisfied. This is simple semantic.
2. As of meta-data, I just tried to re-phrase (seems like with no success) Rob's explanation why an aggregation of data appears as a service in question - is it real SOA service or not. That is, we mostly agree that just retrieval a data with SQL expression from a database is not a service's but a data access component's work, it does not bring a RWE. At the same time, an aggregation of data via the same SQL, plus, aggregation business rules, brings concrete, new business value, i.e. the RWE. This is not about a user and its interest in meta-data. It is about what we consider a service in SOA. - Michael ----- Original Message ---- From: kaburov <[EMAIL PROTECTED]> To: [email protected] Sent: Sunday, June 29, 2008 9:30:25 AM Subject: [service-orientated-architecture] RWE based on data aggregation (was ESB/Intermediary in SOA (was Data services (was Re: Definition of SOA))) I see I have seen in many cases that most users do not need metadata. Probably metadata can be compared with plan or base of a building. Most users do not need plan or base without other parts but they need the building as a whole Michael why don't you agree that many people are satisfied when they have what they need? I think satisfaction and fulfilling the needs easy can merge into one another. Probably you agree that fulfilling the needs of a customer, amount in bank account, number bottles of vodka for free can merge into one another. Because if client is satisfied or he has what he needs he will pay for it. And these money can buy vodka. I agree that there are frequent conflicts of interests between a person and organization, between a business unit and the enterprise it belongs to. But each company has something in common or common style of the company. This style for me is the user's way of thinking. It is better anthropologists, sociologists, business analysts or other similar specialists to outline this style and they to describe the common way of thinking in company. This description will show what is more important for company and case - so some users will need metadata other users will need the information( actual data) described by the meta-data... If the code is aligned to this way of thinking in the company most users are satisfied. Kamen --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <[EMAIL PROTECTED] .> wrote: > > 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: service-orientated- architecture@ yahoogroups. com > 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 <m3poulin@ .> 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 <reamon@> > > 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 > > >
