OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] Service definition at nauseum (restarted)


Just for the record, +1.

Well said, Jeff.

Cheers,
Rex

Estefan, Jeff A (3100) wrote:
>
> I’m beginning to think that any attempt to come up with a fully agreed 
> upon, industry standard, mathematically precise definition for “SOA 
> service” is futile. This is largely due to the fact that the 
> interpretation really depends on one’s perspective (e.g., business or 
> technical) and, of course, the fact that there are a lot of smart 
> people in our community with very strong opinions.
>
> So without throwing in the towel just yet, let’s try this thread…
>
> If the primary objective of the SOA paradigm is better alignment of IT 
> systems that implement the services a business provides, then when we 
> refer to SOA services, we need to be clear whether we are talking 
> about the “business service” itself (whatever that is) or whether we 
> talking about the IT capabilities that implement the business service? 
> I know some feel they are the same thing but that is an impractical 
> position because the business and technical communities have always 
> been and probably always will be comprised of stakeholders that come 
> from different backgrounds, experiences, and formal training. As a 
> consequence, these stakeholders represent different perspectives. It 
> is a very rare individual who is able to fully grasp the key concerns 
> of both perspectives.
>
> If we focus our definition more toward the IT side (with sensitivity 
> to business), then perhaps we could state something to the effect that 
> “A service (in the context of SOA) is a business-aligned capability …” 
> or more specifically, “A service (in the context of SOA) is a 
> business-aligned IT capability …”. My preference is the latter because 
> it reduces the ambiguity and takes a stand on the scope of the problem 
> space we are trying to model.
>
> This makes sense if we think about the different delivery channels for 
> the banking example we all keep citing, i.e., the online or ATM 
> machine (self-service) delivery channels versus the bank teller 
> (human-mediated) delivery channel. In both cases, the IT capability 
> that implements the banking services needs to exist 24x7 in order to 
> support all delivery channels of banking services the financial 
> institution (service provider) provides. So while the delivery 
> channels (and their availability) is different, the banking services 
> are the same and these banking services depend on IT systems to 
> implement the banking services.
>
> If we don’t choose a perspective, then we’re going to have to develop 
> a much more abstract definition that can be further specialized into a 
> business perspective or a technical one and I think that would only 
> lead to further separation of the two camps, which would be a bad 
> thing IMHO.
>
> - Jeff
>

-- 
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]