[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] OASIS SOA-EERP Whitepaper
I am more in agreement with Ken, Boris and Michael on this. In fact, in my review of the SOA-EERP specs, the issue never came up, but then, I was part of the initial work on SOA-EERP so that's not surprising. For me this is all of-a-piece, and self-consistent, and SOA-EERP is just putting in place a set of structured specifications that, like the SCA and Security pieces, fit into the overall mosaic that are inching us closer to a robust SOA Ecosystem. There is still a lot of work to be done, and a ton of lessons that need to be learned, partcularly where scalability breaks down in the attempt to use all of these specifications together, but I am confident we'll get there. Cheers, Rex mpoulin@usa.com wrote: > Between Christopher and Boris positions, I am rather closer to the > Boris' one. > > While I agree with Christopher that unaccessible function is not a > service, I think that 'capability' is an ability to realise a business > function and this capability is not about visibility or interaction. > This is why I agree with 'service' (which provides visibility and > allows for interactions) is not the same thing as the function or > ability to execute the function (=capability). Despite this small > difference, I do not have a significant difference with Christopher in > this topic. > > However, I do not see at all how this 'service(capability)' can lead > to a <<distinction between a business service and a SOA service >>. I > do believe and write in all my later BLOGs that such separation is the > root of all the worst mistakes in dealing with Service Orientation. > The real - business - value of Service Orientation is in convergence > between manual and automated parts of the business service. All > technical service interfaces and 'contracts' are immaterial until they > have an association with particular business meaning. To me, SOA > Executions Context comprises Business Execution Context and Technical > Execution Context; I wrote about this in a few messages a year ago. > SOA context is the business context, first of all. Service Orientation > is the natural business methodology that finds its a part of its > implementation in the Technology. This is why it is Business who has > to lead SOA technical initiatives, not other way around. The RAF > statement about positioning of SOA between Busienss and Technology > fully reflects my statement about Business-Technology relationship. > > I think that the statement <<*/Services /*are performed by people, > machines, and hardware/software applications, and represented by SOA > services>> is ABSOLUTELY correct. This is what I was waiting for the > long time and expected SOA RAF to put in place. > > Orientation of Business on service is well visible at the top of the > business structure but it is dissolved in the service implementation > via processes in the middle of the structure. Technology, i.e. > automation, is one of possibilities of implementation of SOA in the > Enterprise. Different services may have different interfaces to its > consumers; some services may have a postal interface as well as a Web > interface simultaneously and <<accessed via a network endpoint >> is > only one among many others. Even more, automation in Business SOA > Services is not an enabler as many of us think but it is an improver, > enhancer, facilitator or alike. > > This is how I look at SOA and I believe that the existence of SOA RM > and RAF are enabling SOA-EERP, making the solid ground for it. > > - Michael > > > > -----Original Message----- > From: Bashioum, Christopher D <cbashioum@mitre.org> > To: mpoulin@usa.com <mpoulin@usa.com>; soa-rm@lists.oasis-open.org > <soa-rm@lists.oasis-open.org> > Cc: Laskey, Ken <klaskey@mitre.org> > Sent: Tue, Apr 6, 2010 3:38 pm > Subject: RE: [soa-rm] OASIS SOA-EERP Whitepaper > > The problem here is the intuitive notion of a “service†as > performing some function for another, as opposed to the less intuitive > but absolutely necessary notion of making that “function†> accessible to another. The side-effect of this is that many folks now > call every function a “function-service†and voila, they are done! > Unfortunately, they then avoid the harder work required to make a > capability - intended for consumption by others - actually consumable, > i.e., the stuff the RM points out like visibility, interaction (across > different execution contexts), and real-world effect. If they just > focus on the functionality (capability) and assume it is a service > because it is stated to be so, it will end up being the same old > “stovepipe†that we’re trying to get away from. > This is why the distinction between a business service and a SOA > service is necessary, and why I keep pointing it out. The business > side of the house is looking at what the business does for another > (the end result of some set of business processes – done on behalf > of another), wherease the technology side of the house **must** do > things very differently if they want to enable the business side of > the house via a SOA context. > The EERP whitepaper seems to confuse this distinction. I didn’t read > the xml schemas, but I did read the whitepaper, and the whitepaper > seems to indicate that the quality of service is for a business > service that is made available on the network via a SOA service. The > business service may be accomplished via humans (e.g., Amazon’s > mechanical turk), but the business service is accessed via a network > endpoint and any associated processing that is necessary to make the > business service accessible over that network (i.e., the SOA RM service). > *From:* mpoulin@usa.com <mailto:mpoulin@usa.com> > [mailto:mpoulin@usa.com <mailto:mpoulin@usa.com?>] > *Sent:* Monday, April 05, 2010 2:12 PM > *To:* Bashioum, Christopher D; soa-rm@lists.oasis-open.org > <mailto:soa-rm@lists.oasis-open.org> > *Cc:* Laskey, Ken > *Subject:* Re: [soa-rm] OASIS SOA-EERP Whitepaper > While I think that a White Paper would be really useful, replacement > of the word 'service' by the word 'capabilities' may have unpleasant > effect in the business meaning of 'service'. In Business, people, > machines and HW/SW serve the business needs/tasks. Service as a means > of accessing capabilities is too abstract and difficult to expand on > the area of corporate business (according to RAF, SOA is in between > and in both Business and Technology). > An alternative interpretation is that people, machines and HW/SW > perform service by utilizing capabilities. Service cannot exist > without associated capabilities. If capabilities are unaccessible, no > service exists. Service is an activity/action with capabilities. > Service can exist w/o consumers; the opposite is also correct - > consumers may have needs/intents to use a 'service', which is not > available yet (it is known as 'demand'). > That is, the capabilities may exist w/o a service while opposite is > incorrect. How much this re-interpretation changes the 'service' > semantic in RAF? > - Michael > -----Original Message----- > From: Bashioum, Christopher D <cbashioum@mitre.org > <mailto:cbashioum@mitre.org>> > To: soa-rm@lists.oasis-open.org <mailto:soa-rm@lists.oasis-open.org> > <soa-rm@lists.oasis-open.org <mailto:soa-rm@lists.oasis-open.org>> > Cc: Laskey, Ken <klaskey@mitre.org <mailto:klaskey@mitre.org>> > Sent: Thu, Apr 1, 2010 7:08 pm > Subject: [soa-rm] OASIS SOA-EERP Whitepaper > Has anyone else from the SOA RM TC reviewed the OASIS SOA-EERP whitepaper > http://docs.oasis-open.org/soa-eerp/whitepaper/EERP-Model-UseCase-WhitePaper-cd03.pdf > They reference the RM, however, there is one paragraph that caught my > attention: > */Services /*are performed by people, machines, and hardware/software > applications, and represented by SOA services. The qualities of a > business service are expressed by means of the Business Quality of > Service (bQoS) specification. The nature of bQoS varies across > industries and services. > The RM would change this to > */Capabilities /*are performed by people, machines, and > hardware/software applications, and represented by SOA services. The > qualities of a business service are expressed by means of the Business > Quality of Service (bQoS) specification. The nature of bQoS varies > across industries and services. > I think we may need to do something about addressing the idea of a > capability that is intended for “othersâ€, i.e., a business service > – which is enabled in Software by a SOA service in front of a > capability. We’ve talked about it, but I think a whitepaper on this > will be useful. > Note that such a whitepaper would also go a long way towards helping > to navigate the SOA Standards landscape, as I think the main issue > between the various SDOs on SOA is about using the term “service†> to mean “functionality intended for others†vs. as an IT artifact > that enables access to such funtionality (which is the RM view). > Thoughts? -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]