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).
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
Has anyone else from the SOA RM
TC reviewed the OASIS SOA-EERP whitepaper
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).