In reading the responses, I’m not sure I’m communicating
effectively. I think there are some fine distinctions that I’m not able to
get across, but I think they are important so will try again. See my embedded
responses below ...
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
*CDB* - agree
and this capability is not
about visibility or interaction.
*CDB* - not exactly.
Turns out that when making a service visible, it is the capability that the
potential consumer is searching for, not the interface. If the capability
meets the pontential consumer’s need, the interface will be important. So description
of the capability that the service provides access to is important
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).
*CDB* - Excellent! I
think we are in total agreement on this statement. In fact, this is the main
point of my asssertions all along
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 >>.
*CDB* - precisely
because of separation of concerns. The capability provider is focused on the
capability itself, not on how to make the capability accessible, or enforce
access restrictions, etc. In the realm of automation, and automated capability
would be the business logic. The “SOA service” would be the message processing
logic that deals with all the particulars about enabling the consumer to
actually access the capability.
From a business perspective,
a service would be a capability that is *intended* for others to use.
From an implementor’s viewpoint, providing the capability is one concern.
Providing all the stuff so that consumers can access the capability is the
other concern.
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.
*CDB* - agreed
All technical service
interfaces and 'contracts' are immaterial until they have an association with
particular business meaning.
*CDB* - agreed. In
fact, in “contract first” development, the business drives what gets built by
first dictating the “form, fit, and function” of what it needs via the service
interface and “contract”. The builder then builds according to this
specification. This is where business and IT connect most directly.
Previously, the business could only give functional requirments, and form and
fit were left up to the developer. That was bad.
To me, SOA Executions
Context comprises Business Execution Context and Technical Execution Context;
*CDB* - agree partly.
Turns out that the Business Execution Context would drive many things such as
policies regarding terms of use, etc. But there are other things that are applicable
to SOA Execution Contexts that may not be applicable to Business
Execution Context - such as physical connectivity (e.g., network, phone, post
office, etc).
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.
*CDB* - agreed
The RAF statement about
positioning of SOA between Busienss and Technology fully reflects my statement
about Business-Technology relationship.
*CDB* - not sure what the RAF statement said, but in
general I agree that SOA does fit between the two
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.
*CDB* - this is where we have a problem again. The “business
service” is performed by people, machines, and hardware/software applications,
and are represented (made accessible to potential consumers) by SOA services
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.
*CDB* - this is a big
difference. SOA from the perspective of a business offering services to others
independent of any technology is different that what the RM presents.
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.
*CDB* - this gets
back to my point. I would state this as a “business service” may have
different interfaces or channels to its consumers. Some of those interfaces
will be accomplished via a SOA service. Note here that the real world effect
may or may not be carried across the interface. It may be accomplished out of
band. For example, if the interface to the bookseller’s business service is
via messages across the network, the real-world effect is a debit to my credit
card and a book that shows up on my doorstep. If the interface to the business
service is via telephone, there may still be a whole lot of processing before
the information actually reaches the business service of providing books. The
telephone operator will need to interact with the consumer to get credit card
info, address info, etc, and then authenticate and get authorization from the
credit card company, and then will be able to enter the actual order into the “business
service”. The real-world effect of that interaction between the phone operator
and the consumer is the same as if the consumer interacted via the network
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.
*CDB* - that’s my point. The automation in the SOA
context is for providing access to the business service, but that business
service itself may or may not be automated.
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.
*CDB* - I think there is some good stuff in the SOA-EERP,
but the distinction I am trying to make is still important, most especially
when dealing with automation. Note that the EERP assumes automation, as the QOS
information is all sent via machine-processible messages – not postal mail or
telephone.
So --- I think we are in agreement on a lot of the stuff, but
the fine distinctions are *hugely* important in the world of IT. I
sincerely hope I was able to communicate my concerns – I am not in any way
suggesting that all stuff has to be automated, but I am suggesting that if a
business wants to have their capabilities be accessible in a SOA, it will have
to be aware of and make the distinctions that I (and the SOA RM) are trying to
make.
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?
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).