[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] OASIS SOA-EERP Whitepaper
ok – we can agree to disagree on the details, but I do need to
clarify one thing. When I mentioned “independent of any technology” I
misspoke. What I intended was the following: Note that while the concepts
and relationships described in this reference model may apply to other
"service" environments, the definitions and descriptions contained
herein focus on the field of software architecture and make no attempt
to completely account for use outside of the software domain. Examples included
in this document that are taken from other domains are used strictly for
illustrative purposes. This is a quote
from the RM, and what I originally meant by the term “technology” above was
really “software architecture” as opposed to “business architecture”. From: mpoulin@usa.com [mailto:mpoulin@usa.com] Sorry, folks, this is one
of those discussions that can run for long time because 'in
principle' we agree, but when we look into details, it appears that we quite
disagree again and again. The fundamental difference
between my view and the Christopher's one, as I understand, is in that I want to see a single, united
SOA Service spreading across the boarder of Business-Technology while Christopher protects a special role of
Technology separating business and technical parts of one business function
into business and technical services. I can continue criticizing this
approach but I think that only future will show whose view is 'more' right in
this. On another note, Christopher says: <<SOA from the perspective of a business offering services to
others independent of any technology is different that what the RM presents. >> Is this a common
understanding of RM? I have believed that SOA RM is technology agnostic (as
well as RAF); this is the power of SOA and I use it in these days by switching
from Java to .NET under the same SO Architecture in a matter of a couple of
hours. - Michael P.S. According to IEEE1471
standard (and I fully agree with it), an Architecture (SO or any other one) is
about WHAT, WHY, WHO, WHOM for, WHERE and WHEN. Technology is an implementation
means of the Architecture and is about HOW. -----Original Message----- 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 ... From: mpoulin@usa.com
[mailto:mpoulin@usa.com]
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. - Michael -----Original Message----- 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]
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----- 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). Thoughts? |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]