Discussion on background-papers
h.we...@uvt.nl
view, the service is not consumed in the conversion process; it is the
resource that enables the service. So the service causes the
conversion event to happen.
At the same time, the service is exchanged, taken away from the
provider and added to the customer.
From a REA perspective, I guess that the thing that is exchanged must
be created somehow as well. Can we say that the conversion event
creates the service instance?
For the rest, my feeling is that the choreography, if represented, is
esp related to the exchange process rather than the conversion
process. But I have to think about it.
Some other points:
- I talked with Jaap about the OMG call. It turns out that the Cordys
company is taking the initiative. This is nice because OMG is mainly
industry-driven. So we can take a backseat approach.
- I talked this week with Olav Zimmermann, the author of SOAD.
Currently, SOAD as service design method does not exist anymore and
has been replaced within IBM by SOMA. The acronym SOAD is still used,
though, by Olav, but now for a design decision framework. This
framework is not for service identification, but there is a
relationship: we could use this framework for phrasing service
identification decisions in a precise way. See esp
http://www.zurich.ibm.com/pdf/csc/SOAD-QOSAv21.pdf
Hans Weigand
I must clarify one sentence at least, about the conversion process and the
resource. I wanted to say: the conversion event consumes a resource.
This is what we called the enabling resource. For example, the barber, or
the time of the barber.
At the same time, some resource is converted, the subject of the
service. For example, my hair.
Now the service is not only a conversion process, but also a resource that
is exchanged. What is exchanged is neither the barber, nor my hair, but
the hair dress service. That is what I pay for.
How is the hair dress service (as resource) created and destroyed again?
Can we say that it is created by a conversion process (at provider side)
and consumed by a conversion process (at customer side)?
Then perhaps the "result" link should be read the other way round: the
conversion event creates the service - like the conversion process type
realizing the service type.
At the same time, however, there are the subservices. From the main
service perspective, calling a subservice results in a conversion event
(e.g. subservice hair wash). But I now start doubting whether this is
still consistent. Or is the problem in that that take both an external and
an internal view on the service?
To be continued..
Hans
Paul Johannesson
Hi,
See comments below.
/Paul
On 12 Sep, 15:29, "hans.weig...@googlemail.com" <h.weig...@uvt.nl>
wrote:
> view, the service is not consumed in the conversion process; it is the
> resource that enables the service. So the service causes the
> conversion event to happen.
process some resources are produced and other consumed/used. And a
service, as any other resource, could then be consumed.
> At the same time, the service is exchanged, taken away from the
> provider and added to the customer.
> From a REA perspective, I guess that the thing that is exchanged must
> be created somehow as well. Can we say that the conversion event
> creates the service instance?
and another conversion process that consumes it. For example, in one
conversion process, barber labour and scissors are used/consumed, and
a hair dress service is produced - in another conversion process, this
hair dress service is consumed and nice hair is produced.
>
> For the rest, my feeling is that the choreography, if represented, is
> esp related to the exchange process rather than the conversion
> process. But I have to think about it.
ordered.
>
> Some other points:
> - I talked with Jaap about the OMG call. It turns out that the Cordys
> company is taking the initiative. This is nice because OMG is mainly
> industry-driven. So we can take a backseat approach.
> - I talked this week with Olav Zimmermann, the author of SOAD.
> Currently, SOAD as service design method does not exist anymore and
> has been replaced within IBM by SOMA. The acronym SOAD is still used,
> though, by Olav, but now for a design decision framework. This
> framework is not for service identification, but there is a
> relationship: we could use this framework for phrasing service
> identification decisions in a precise way. See esphttp://www.zurich.ibm.com/pdf/csc/SOAD-QOSAv21.pdf
have a look.
Hans Weigand
Hi
I have taken a closer look, and Paul is right that some clarifications
must be made. Let me try to build up the model step by step.
1. conversion process type use service type. Right, this is derivable.
2. REA exchange and REA conversion. Our assumption is that a service is a
resource, and hence exchanged as any resource/value object. Hence we
better model how a resource is exchanged in REA, and then see whether
there is something specific for services. My claim is it is not (see
more below). The second assumption is that a service changes the state of
some resource (the resource being the subject of the service, the state
being the goal). This has to do with REA conversion processes. See 3.
3. As we said, a service type is realized by a conversion process. What
does that mean? Claim: It means that there is a conversion process that
contains conversion events, and one conversion event *creates* the service.
This gives one answer to the question what "results" means. I think we
mixed up two things here. Anyway, I would say now first that the
arrow should be reversed and the label is "create", in the REA conversion
event meaning of the word.
4. The point is that a third assumption of our model is the duality
between service and process. A service is realized by a process, a
process uses (sub)services, that are realized by processes etc. If we say
that a service type is realized by a process type, then it is consistent
to say that the service is created by some event, and not vice versa.
5. In a complete service "value exchange" there is an exchange of a
service (two exchange events) and two conversion events. This is
differnt from a normal goods exchange, where the goods already exist
before and continue to exist afterwards. In the exchange of the
service, first a service instance is created, then this is taken from
the provider, then it is received by the customer, then it is consumed
by the customer. The sequence here is the logical sequence, since what
is special is that these events co-occur (if they would not co-occur,
then the service exists for some time in a between state - but then it
would be a material good).
6. So some conversion event creates the service (and in this way, a
processs realizes a service type). At the other side, the service is
consumed again (life is short..). This conversion event is accompanied by
a "creative" event - which is of course the value added to the "subject",
the realization of the "goal".
Similarly, at the back-end the conversion event that creates the service
is accompanied by a destructive event - which is the use of the enabling
resource(s).
7. As recalled in 4, a process uses subservices. A subservice is a
resource. The use of a subservice is not different from the use of any
other enabling resource.
8. The creative event in 6 may be seen as the other sense of the "result"
arrow.
At the consumer side, the service is consumed (destroyed in REA sense),
but this is accompanied by a creative event. It could be said that this
creative event "results from" the service. But this is a derived
relationship.
9. It is good to test the model with an instantiated example.
Barber offers hair dressing service
1. conversion event: time of barber is used
2. conversion event: a hair dress service is created
3. exchange event: hair dress service is deliverd
4. exchange event: hair dress service is received
5. conversion event: hair dress service is used/destroyed
6. conversion event: hair of Birger is cut
10. Now if the barber uses subservices step 1 above is expanded into
a conversion event: hair washing service is used/destroyed (after having
been exchanged, after having been created by assistant, after time of
assistant is used plus some shampo)
11. Now the relationship with real process, or work process. The idea
behind this relationship is that we wanted to make a bridge with process
modeling in general, and bpel processes in SOA in particular. So the point
of including it is: to describe orchestration. Assuming that REA does not
contain this concrete level (but a lot has been written in REA, so are we
sure?). The bridge is: a process implements a REA process, and the process
performs calls of services (those services that are created by conversion
events part contained in the REA process). It performs them in a certain
ordering, but this is not explicitly modeled.
12. In my view, if choreography is modeled somewhere, it should be related
to the REA exchange process. A choreography does not produce something,
like a process, but describes an interaction between two actors. The REA
exchange process is abstract: it only describes the economic effect. It
does not say how the interaction is established. In some REA ontology,
there is a notion of business event and business transaction,governed by
economic agreements/contracts. This I modeled in sheet 3b. My feeling is
that this is choreography; the business events being the message
exchanges.
13. My view on choreography is hence a bit different. Anyway, I would say
that an atomic service in SOA is by definition a black box, so then it
does not make sense to talk about actions realizing the atomic service.
However, is this necessary or SOA specific? Perhaps the word atomic is
misleading?
Hans
Dr. Hans Weigand
Infolab, Tilburg University
email: H.We...@uvt.nl phone: +31 13 4662806 fax +31 13 4663069
Paul Johannesson
See comments below.
/Paul
I have taken a closer look, and Paul is right that some
clarifications
must be made. Let me try to build up the model step by step.
1. conversion process type use service type. Right, this is
derivable.
the service is consumed by the process, i.e. it does not exist after
the process.
2. REA exchange and REA conversion. Our assumption is that a service
is a
resource, and hence exchanged as any resource/value object. Hence we
better model how a resource is exchanged in REA, and then see whether
there is something specific for services. My claim is it is not (see
more below). The second assumption is that a service changes the state
of
some resource (the resource being the subject of the service, the
state
being the goal). This has to do with REA conversion processes. See 3.
resources when it comes to exchanges.
3. As we said, a service type is realized by a conversion process.
What
does that mean? Claim: It means that there is a conversion process
that
contains conversion events, and one conversion event *creates* the
service.
This gives one answer to the question what "results" means. I think
we
mixed up two things here. Anyway, I would say now first that the
arrow should be reversed and the label is "create", in the REA
conversion
event meaning of the word.
conversion process includes a conversion event that creates the
service.
4. The point is that a third assumption of our model is the duality
between service and process. A service is realized by a process, a
process uses (sub)services, that are realized by processes etc. If we
say
that a service type is realized by a process type, then it is
consistent
to say that the service is created by some event, and not vice versa.
"create" from process to service?
5. In a complete service "value exchange" there is an exchange of a
service (two exchange events) and two conversion events. This is
differnt from a normal goods exchange, where the goods already
exist
before and continue to exist afterwards.
that create them. However, there does not have to be a process that
uses them. If I buy some goods, I can just leave it without ever using
it in another process.
In the exchange of the
service, first a service instance is created, then this is taken
from
the provider, then it is received by the customer, then it is
consumed
by the customer. The sequence here is the logical sequence, since
what
is special is that these events co-occur (if they would not co-
occur,
then the service exists for some time in a between state - but then
it
would be a material good).
6. So some conversion event creates the service (and in this way, a
processs realizes a service type). At the other side, the service is
consumed again (life is short..). This conversion event is accompanied
by
a "creative" event - which is of course the value added to the
"subject",
the realization of the "goal".
is accompanied by a conversion event that improves the value subject.
though we should check this again.
13. My view on choreography is hence a bit different. Anyway, I would
say
that an atomic service in SOA is by definition a black box, so then
it
does not make sense to talk about actions realizing the atomic
service.
However, is this necessary or SOA specific? Perhaps the word atomic
is
misleading?
In fact, Maria, Birger and I discussed this the other day, and came up
with the following slides:
http://stockholm-meeting-aug-2008.googlegroups.com/web/ServiceNotion-ba1.ppt?gda=Y_KWvkcAAADjQMKQvHY8Lph5cHqISah37_KFhMWb0ooXU8s-UM6vBBBysbKVK_2wkrfXindxIQqvdM6dWi70g_tXI1zEURIYeV4duv6pDMGhhhZdjQlNAw&gsc=FoPxVAsAAAAkA8ysdbAU4hvxLuID3Sxe
(or see Files at the Google group)
We reduced the figure by taking out some superfluous elements, see
slide 2. There is also a third slide, mirroring the previous one but
for exchange processes. The main difference is that we now have
exchange events instead of conversion events, and these change rights
on resources; they do not change features of resources.
h.we...@uvt.nl
I think we agree on most parts. Your rephrasing of a "goal" (wrt some
subject) into a conversion event is elegant I would say.
The only remaining point of discussion so far seems to be the
choreography part.
Note that we have not yet modeled the service policy and rules (we did
in Stockholm, but it has not been thrown into a ppt), this should not
be forgotten.
maria
On 13 Sep, 19:40, Paul Johannesson <pauljohannesso...@gmail.com>
wrote:
>
> See comments below.
>
> /Paul
>
> On 12 Sep, 15:29, "hans.weig...@googlemail.com" <h.weig...@uvt.nl>
> wrote:> Paul, I will take a closer look at your comments next week. In my
> > view, the service is not consumed in the conversion process; it is the
> > resource that enables the service. So the service causes the
> > conversion event to happen.
>
> The idea was here to keep close to REA. Whenever there is a conversion
> process some resources are produced and other consumed/used. And a
> service, as any other resource, could then be consumed.
>
conversion? Rather than the service itself? Sometimes I have trouble
seeing services as being 'consumed' in a stock-flow-perspective, i.e.
services are not 'in stock', e.g. cannot be 'increased/created' or
'decreased/consumed'. On the other hand, if the service itself is not
consumed or produced in the conversion than of course, as you point
out, the service is not just any resource, rather a special case of
resource.
Hans Weigand
Maria,
I understand your hesitation. Purely from a conversion point of view,
there would be two conversion events: one adding value to the subject, and
one consuming resources.
However, if the service exchange is an economic transaction, we view the
service as a resource exchanged. Then it makes sense to introduce a
service/creation and service/consume event in between. To split up a
conversion process into more fine-grained steps is not new. What is
unusual is the abstract character of the in-between product.
Still, the chain as a whole still consumes resources from the provider and
adds value to the subject at the customer side.
An important constraint on the model is that the creation and consumption
of the service co-occur. This is another way of saying that services
cannot be put in stock.
Hans
Dr. Hans Weigand
Infolab, Tilburg University
email: H.We...@uvt.nl phone: +31 13 4662806 fax +31 13 4663069
ba
==============================
(What is discussed in this post is accompanied by a slide in the file
ServiceNotion-ba3.ppt attached to this group. It is a really simple
bare-bones slide containing some core concepts as I understand them.
Now that I have made this post I will go through your conversation
above to see what I can learn from it and think about how to adjust
the model accordingly.)
After meditating a bit around the service models that was produced
during the workshop in Stockholm an attempt to make them more compact
and even more to the point. The attempt was (increadibly sloppily)
documented in the file ServiceNotion-ba2.ppt currently uploaded on the
Google discussion group groups.google.com/group/stockholm-meeting-
aug-2008. The work was never finalised properly as other matters came
about.
Fundamental to the models is the will to accomodate concepts from the
REA business ontology. This has the dual purpose of a) grounding the
models on a well-known and sound foundation, and b) being able to use
the models in a value model setting. In particular, the e3value
modelling is quite similar to REA.
A development of the orignal REA was introduced by Hruby through the
dichonomy of events into conversion events and exchange events.
Conversion events are thougt to occur as a result of the conversion of
a resource, exchange events occur as a result of transfers of resurces
(between agents). The service models reflect the dichonomy in that
they are being two -- one covering the conversions and one the
exchanges. Their structure are very similar though, and this is
perhaps a hint that they can and should be unified (more on this
below).
Currently outlined service models are understood (by me, at least) in
the following way:
* A conversion/exchange business process is a set of conversion/
exchange events. This is the definition of process taken directly from
REA.
In e3value a value activity correspond roughly to a conversion
business process.
* A service is an abstraction of a business process. The main purpose
of service at design time is to abstract away from the innards of a
business process.
* The goal of the business service is the same as one event in a
business process.
* A business process is implemented at run-time by a work process.
* A work process is realized by composing one or several services.
* Composition can mean two things (this is to unify the conversion and
the exchange models).
** Composition, in case of a conversion work process, is analogous to
orchestration. Intuitively, this can be thought of as invocation of
processes (in effect making them sub-processes) through service calls.
Unrolling a composed conversion process gives a hierarchical structure
consisting of services and sub-services.
In e3value this would correspond to a value activity that uses other
value activities in order to produce a resource.
** Composition, in case of an exchange work process, is grouping.
Unrolling a composed exchange process gives a flat structure
consisting of services.
In e3value this corresponds to a value interface that groups a number
of value ports.
* A service is a resource and is, as such, subject to consumption and
production in a business process.
Some questions this far:
(1) Is the idea of separating service concept in two aspects,
tentatively called design time and run time, fruitful? Without this
separation, it is hard to rationalise why there are two process
concepts (conversion/exchange and work) at the type level.
(2) As it stands there is no obvious way to distinguish a business
service from a software service. Is this good or bad? A criterion
involving the inclusion of humans in the loop doesn't help much.
(3) As I understand it, if a resource is altered in any respect, then
this is done in a process (a service being an abstraction of a process
change anything). Furthermore, when chosing between which of the two
processes that does the alteration I'd chose the work process. That's
the process whose production and consumption of resources is
manifested as a set of events. Is this the way to think of it?
(4) In a process, a resource can be used to change the properties of
another resource. On the question: "Can a service change the rights on
resource?" we can answer "Yes, a service can be used as a 'rights-
changing resource' in a process". Is this how one should see it?
(5) Returning to the state where no unification of conversion and
exchange processes was attempted, is there a distinction between
conversion services and exchange services?
(6) My understanding is that a distinction between process
implementing a conversion and process implementing an exchange
processes can be made based on how they affect resources. A property
of a resource is always altered in a conversion. No property of a
resource is altered in a exchange (the resource is merely transfered/
conveyed).
Formulted differently, a work process implementing a conversion
process realizes an orchestrated conversion service. A work process
implementing an exchange process realizes a grouped exchange service.
Is this way of seeing it too simplified?
(7) ...
this will be continued and clearified asap in order to have a clear
view of what should go in the CAiSE09 paper and what should go into
the VMBO ...
Concerning a method for identifying services.
=============================================
There are two types of events, conversion events and exchange events.
In a value model, e.g., the e3value, events are generated in two
places -- in the Value activities and in the Value Interfaces. Value
activities are generating conversion events whereas value exchanges
are generating exchange events. We should therefore expect to find
service candidates mainly associated with value activities and value
interfaces, and their combinations.
to be continued ...
Hans Weigand
Some remarks
- the work of Erl is relevant (but I don't have the book yet). One thing
that we could use directly, I think, is the distinction between task
level, entity level and utility level. Although the notion of entity
service is debatable, not whether it is a useful concept, but whether this
should be called a service. Perhaps it can, if is clear that we are
talking about a data service : employee data service, customer data
service,etc. A service that uses certain IT resources and provides storage
and retrieval of data. Anyway, I think the distinction is useful at the
micro-level design of a software service. It is not applicable for
business service identification.
- the SOA magazine article, and the very idea of a SOAD method. Nice
overview, useful for intro. What strikes me most, upon reflection, is that
people (including our BUSITAL) still go for a "centralized" design
approach, whereas SOA is inherently decentralized. By centralized I mean that there
is a certain actor or task force group that is designing services -
perhaps using a combination of various techniques and methods.
Decentralized means that different stakeholders are identified (or
involved when needed) and the service design is the outcome of a
negotiation process. For example, the IT department is responsible for
software services. Each stakeholder tries to optimize from his local
perspective. This does not exclude the use of certain methods or
techniques, but it drops the assumption that seems to underly current work
that at the end of the day there is an optimal design. Optimal should be
indexed by stakeholder. Ideally, for each technique/method that we
propose we should make clear which stakeholder can use it, or in which
negotation it can play a role.
- about Birgers's comments. Certain choices that you present seem to me
not real choices, but let me throw in my contribution.
* I agree with what you say about the composition of conversion events
and the hierarchical structure. Only one point: when a conversion event is
executed by another actor, there is also an exchange involved.
* composition of exchange events, what you call grouping. This is not so
clear to me, but it is interesting. I don't see why it necessarily has a
flat structure (cf discussion on whether value interfaces should allow for
decomposition). More important is the question what this "grouping" stands
for. You talk about a work process. I guess you make here a link to
choreography?
* design time/run time. I think it is useful to distinguish a work process
that implements a process type and realizes a process - on design level.
What this work process also takes into account are the business rules. At
run-time, we have instances of this work process.
A work process describing a complex exchange (choreography) also may have
to comply to certain business rules/policies.
* I think it is good to have a generic service ontology, but at the same
time, more specific things should be said about software services, and
about how sofware services interface with non-software services. E.g the
levels of Erl (see above), specific for software services. Recognition of
the fact the the user of a software service is not always (often not) the
customer [example: an online check-in service at KLM is used by the
passenger, but the passenger is not the one who pays the KLM IT department
for it] This is because a software service is usually a delegated task.
* who is altering the resource? (3) I think both the REA process and the
work process, at different levels of abstraction.
* I don't get your point on right-changing resources
* I don't get the point of your remarks on conversion and
exchange process (6), although obviously I think the distinction is
useful. What is confusing to me is the sentence "a work process
implementing an exchange process realizes a grouped exchange service" -
particularly because we have not identified a thing like "exchange
service" yet. Who are provider and customer of such a service?
Although I don't get all the points, I think the discussion is very
useful, and we are progressing.
Hans
ba
now. As I read through my post I see that some things are indeed
really confusing (typos, some scratch remarks that should not have
been there, etc.). I'll will try to straightened that out. In the
mean time I post a comment to one of your remarks.
/birger
On Oct 22, 1:35 pm, Hans Weigand <H.Weig...@uvt.nl> wrote:
> Some remarks
> - the SOA magazine article, and the very idea of a SOAD method. Nice
> overview, useful for intro. What strikes me most, upon reflection, is that
> people (including our BUSITAL) still go for a "centralized" design
> approach, whereas SOA is inherently decentralized. By centralized I mean that there
> is a certain actor or task force group that is designing services -
> perhaps using a combination of various techniques and methods.
> Decentralized means that different stakeholders are identified (or
> involved when needed) and the service design is the outcome of a
> negotiation process. For example, the IT department is responsible for
> software services. Each stakeholder tries to optimize from his local
> perspective. This does not exclude the use of certain methods or
> techniques, but it drops the assumption that seems to underly current work
> that at the end of the day there is an optimal design. Optimal should be
> indexed by stakeholder. Ideally, for each technique/method that we
> propose we should make clear which stakeholder can use it, or in which
> negotation it can play a role.
agree with what I think is the main point of it. That is, actors
offering (or are responsible for offering) services for consumption,
do so because they have something to gain from it. If they do not gain
then they will withdraw their service offerings.
(A) The underlying assumption here is then that the actors offering
services indeed are free to offer and withdraw their services from the
market. That would create a situation where a decentralized
configuration of the value web indeed occurs. All participants that
are in are in because they can and it's in their interest (for all
kinds of reasons that must be balanced), otherwise they leave.
I'd say that the context where services services are infinitely
available, and can be offered and withdrawn at will by all
participating actors creates a value web that is decentrally
configured and optimized for that context.
(B) In a situation where the option to offer and withdraw services
from a market is limited or non-existent by some actor (such as inside
an organization), I think there is a possibility to optimise the web
from that actors particular point of view. He can always coerce the
other providers to continue to offer their services, and he can limit
their possibility to start offering.
The point taken in Busital and other papers that we have written (as I
have understood it), is that we decide on one actor in the value web
and try to balance or maximise his gains from participating in the
web. We then assume that the same procedure is done in all the other
actors, but don't care much about that. It all works out since we are
in the context described in (A).
ba
other stuff. I will meet with Paul tomorrow (24/7) and hopefully also
with Maria to see how far in the work we have got. There's a lot of
information here in this google-group that should be digested. And the
XYZ case from SOAM should be properly analysed.
> not real choices, but let me throw in my contribution.
> * I agree with what you say about the composition of conversion events
> and the hierarchical structure. Only one point: when a conversion event is
> executed by another actor, there is also an exchange involved.
> * composition of exchange events, what you call grouping. This is not so
> clear to me, but it is interesting. I don't see why it necessarily has a
> flat structure (cf discussion on whether value interfaces should allow for
> decomposition). More important is the question what this "grouping" stands
> * design time/run time. I think it is useful to distinguish a work process
> that implements a process type and realizes a process - on design level.
> What this work process also takes into account are the business rules. At
> run-time, we have instances of this work process.
that there is but one transfer of resource between agents in an
exchange (disregarding dualities), but that the transfered resource
may be a composite -- composite in the sense that it is grouped or a
bundled.
But I suspect I was a bit too sloppy in the analysis. We'll see.
First I should say something about the relation between a service and
a process. As it stands we have two kinds of processes -- conversion/
exchange and work, both at type level. Why two? This was perhaps to
reflect two ontological aspects of a process; what it is and what it
does. It _is_ a set of events, it _does_ consume and produce
resources. The former is a design time concept, the latter a run-time.
The relation between a service and a conversion/exchange process is
that of abstraction. A service is an abstraction of a conversion/
exchange process. This is the design time aspect of a process. This is
what it is. At the same time a work process provides a realization of
a service and this is done through composition. This is the run time
aspect of a process. This is what it does.
Events are manifestations of consumed and produced resources. I think
of them as notations in a ledger. This, of course, applies to the
notion of service goal as well. The goal of a service is to have a
particular set of notations in a ledger. I.e., some consumption and
production of resources should occur.
I think it's OK to say that a service is an abstraction and that it
provides a realization of a process. Perhaps this can be reformulated
as " ... it gives access to a resource" since resources are produced
in processes. The consequence of this is that, strictly speaking, a
service is not a resource but the access it provides is. Maybe this is
nitpicking but there is a distinction: its abstractness cannot be
traded, but its ability to provide access to a resource can (that's
the litmus test). On the other hand, saying that a service is not a
resource is a bit worrisome and may indicate that there is a flaw in
the argument. Or it could be that the distinction has no practical
significance and one can go on saying that a service is a resource.
What one cannot say is that a service _is_ a realization of a process.
(A bit on naming; if a service is an abstraction of a exchange
process, then it can be called exchange service, if it's an
abstraction of a conversion process, then it can be called conversion
service).
The thinking then is that a work process that implements a conversion
process does this by choreographing the consumption and production of
resources. It does this by calling appropriate sub-processes (through
their service interfaces as we have discussed) thereby creating a tree-
like structure of calls. The result from this call structure is a
resource that is the composition of what has been done in the sub-
processes. Currently I think of the resulting resource as one (1). If
a work process produces several resources then there are as many call
trees as there are resources.
For example, what is produced in the famous hairdressing example is
the right to have the hair cut. This is done by calling services X and
Y (that in turn may call other services). If on the other hand the
result of the hairdressing is the right to have the hair cut and
cleaned, then services X and Y are called upon as before, but service
Z (with its subtree) is called upon for the cleaning. The subject of
the services is of course the same (the hair), but the resulting
resources (the right to have the hair cut and the right to have the
hair cleaned) are distinct. This brings us to the next issue, the
exchange. Should the resulting resources be given access to (be
offered) as a group or as distinct entities?
In the case of a exchange I thought differently about composition than
the call trees described above. What I wanted was to be able to
express bundlings or groups. That is, the right on one resource is
transferred together with another, or not at all. At the time I
thought about it, it made sense to make the distinction between the
composition as exhibited in a work process implementing a conversion
than that of an exchange. Now that I've written some about it, and
Hans asked, I'm not sure anymore. The similarity between a conversion
and an exchange is striking. The way by which they compose resource
should perhaps not be talked about at this level of abstraction.
This line of reasoning is not at all finished. I post this now and
will continue as soon as possible to finalize it. Feel free to
comment ...
> A work process describing a complex exchange (choreography) also may have
> to comply to certain business rules/policies.
> * I think it is good to have a generic service ontology, but at the same
> time, more specific things should be said about software services, and
> about how sofware services interface with non-software services. E.g the
> levels of Erl (see above), specific for software services. Recognition of
> the fact the the user of a software service is not always (often not) the
> customer [example: an online check-in service at KLM is used by the
> passenger, but the passenger is not the one who pays the KLM IT department
> for it] This is because a software service is usually a delegated task.
> * who is altering the resource? (3) I think both the REA process and the
> work process, at different levels of abstraction.
just to be a set of events. But I will think this through some some
more.
> * I don't get your point on right-changing resources
http://docs.google.com/View?docid=dm8b2qw_319cc7m5gfg that Paul posed
some time ago.
> * I don't get the point of your remarks on conversion and
> exchange process (6), although obviously I think the distinction is
> useful. What is confusing to me is the sentence "a work process
> implementing an exchange process realizes a grouped exchange service" -
> particularly because we have not identified a thing like "exchange
> service" yet. Who are provider and customer of such a service?
before they became public (I write in a text editor and copy the text
over to this document. This time a little too much was copied this
time. Sorry).
Hans Weigand
Birger,
thanks for sharing your thoughts. When I do not get all of it, it is
because we need some more alignment and explicating of assumptions. So let
me once again try to explicate my assumptions.
On the relationship between process and work process. You say the
difference is between what it is and what it does. To me, the difference
is more between what it does and how it does it. Or better: between a
certain composition of activities (work process) and the economic
abstraction of this composition (process), i.e. the consumption and
production of resources. As REA events are defined in terms of changes in
resources, I have difficulty in following you when you say that the
process is about events and the work process about resources and how they
change. REA (and e3value, in some way) abstract to the economic aspect,
and it abstracts from process details - the ordering of the events, and
how the events are performed (which specific activities create the
events).
I agree with your ledger example: the administrator only records the
economic events, being the essence of the process from an economic point
of view: resources are added or substracted.
On the relationship between process and service. In some sense, you can
say that a service is an abstraction from a process. In the sense that you
abstract from internal events and focus on the value change in the service
subject (customer resource, you being transported) and the use of an
enabling resource (you being transported by train rather than by bus e.g).
To call this an abstraction makes sense when you start from the process
(service provisioning view). From a customer point of view, the service is
not an abstraction of course. To him, the the service is what he gets and
the process is whatever the provider does (not of customer's concern) to
realize that. What he gets is not a product but some value
transformation. Getting a product means having ownership rights and
custody. Getting a value transformation/service means the transformation
actually having happened (perhaps after some iterations). If you pay in
advance, you create an obligation for the provider to realize the
transformation later.
>For example, what is produced in the famous hairdressing example is
>the right to have the hair cut.
I am not so sure. Products and services are not completely symmetric. For
a product one has to specify the rights, because just saying "book" is not
sufficient. But "hairdress" cannot be misunderstood: you got it or you did
not. For the product, the ownership right is crucial, because that
guarantees that no one can take the product away. For the service, once it
has been delivered, it cannot be retracted or taken at all.
When you pay in advance, the provider has an obligation, you have a right.
Ok, but what is produced in the service is not a right, I would say.
Maybe we can skype in the afternoon to discuss some issues?
I will start working out the XYZ example, hope to be able to share
something later.
Hans Weigand
A note on the service levels in order to get at clean terminology:
business level (cf. Dietz ontological or performative level)
information level (cf. Dietz/Langefors infological or informative level)
infrastructure level (cf. Dietz formative level, Langefors datalogical)
*business level
business services are identifiable services in the business that are
characterized by a certain economic autonomy. This means that in principle
it can be delivered in a cost-effective way by some actor, and that
managerial responsibility has been assigned to it.
A distinction can be made between core services and enhancing services.
Core services are part of the primary process, and produce value for
customers in some conversion process.
Enhancing services support other services
- as access service (information, contracting, ordering, fulfilment). The
function of an access service in relation to a core service is similar to
the function of a facade object in OO (Gamma patterns) and increases
loose coupling. Access services can be at the front (customer interface)
or at the back (procurement).
- as monitoring/management service
- as .. (other types?)
*information level
information services are software services that are characterized by a
certain autonomy. The direct value provided by the information service is
the recording, retrieval or exchange of information. (The indirect value
is that it supports coordination).
A distinction can be made between task-oriented information services and
entity-oriented information services (cf. Thomas Erl). Entity-oriented
information services maintain and provide information about entities
(busines objects) and typically have a CRUD-style web service interface.
Task-oriented services correspond to what Papazoglou calls business
*processes", whereas entity-oriented services are called business services
in this work. Task-oriented services are, by definition, composed of other
(composed or atomic) services (composition being constrained by business
logic). Entity-oriented services are usually atomic (on the informational
level - they do use infrastructural
services).
Alternative (better?) naming: composite vs discrete service
Information services can use other information services and use
infrastructural services as resources
Information services can be supported by management and monitoring
services whose aim is to maintain and improve the quality level of
the managed service over time.
*infrastructure level
infrastructural services are IT services that are characterized by a
certain economic autonomy (which makes them suitable candidates for
outsourcing) and usually support more than one information
service.
The value provided by the IT service is the storage of data or the
execution of programs.
The infrastructure level may include generic software services (e.g.
DBMS).
Infrastructural services use hardware as resource
Synonym: utility service (Erl), technology-oriented
Infrastructural services can directly support a business service in the
case of an IT-business (e.g. grid service business).
Also at this level we can have monitoring and managing services.
Informational services can support business (production) services in
the case of information industry. E.g a wheather forecasting.
In all industry branches, information services can support access
services, such as the order process.
Question:
- do we also need something like an exchange or communciation service
responsible for the communication via some channel or bus? For example,
between the customer and the company: internet or phone. Or do we see this
as part of the access service?
Hans
ba
> Question:
> - do we also need something like an exchange or communciation service
> responsible for the communication via some channel or bus? For example,
> between the customer and the company: internet or phone. Or do we see this
> as part of the access service?
>
> Hans
separation is that a core service e.g. 'Book sales' in order to be
offered always need to have some access service associated with it.
Access is always accomplished through some communication. Therefore,
the access and the communication might as well be collapsed into
one.
But I see the differences in the responsibilities of an access service
and an exchange service. The access service can be seen as a
differentiation factor of a core service offering and it is
responsible for this differentiation. This is the service that makes
the 'Book sales' convenient. The convenience of a "on-click"-shopping
scheme lies in the access to the sales. Not in the e.g. reliability of
the communication. The responsibility of the exchange service is, in
this case, merely to "haul bits". But the exchange service may also be
a differentiating factor. Using an analogy from common networking,
communication between parties is done on the terms of the slowest
communicating party. So, if this party offers a 'Convenient Book sale'
over a slow ftp link, then the exchange service really is
differentiating. From the buyer's perspective the offered service
becomes a 'Convenient but Slow' Book sales. As the two types of
services contribute to the differentiation of the core service in
different ways it makes sense to keep them separated.
I lean towards keeping them separate in theory, but collapsing them in
practice where possible.
/birger
--------------
Referring to the document caise09v0.doc there are some questions about
the outlined method:
The method is divided into four phases: (1) Business modeling and
innovation; (2) Service identification; (3) Informational service
identification, and (4) Infrastructure service support.
Q: Is the purpose of the phases to do a clear separations of method
concerns and that these concerns follow in a natural order? First
design of business model, then design of services.
Business modeling is done at three levels: (1A) transaction level;
(1B) knowledge level; (1C) intangible level.
Q: My assumption is that the design of a value model at the
transactional level amounts to stating who the participating actors
and what the values (in terms of goods and services) they exchange
are. This transaction level is what we have have focused on when doing
value modeling this far. Is this so?
Q: Design at the transactional level includes deliberations that were
explained in the c3-value paper: your own capabilities, your
customers, and your competition. Thus, what is included in the model
is dependent on a particular actor's (the focal or principal actor)
point of view. Is this so?
Q: In contrast to the design of a value model at the transaction
level, design at the knowledge level means modeling what is changed
or improved in an actor. That is, what capabilities may be added to or
subtracted from an actor as a result of a value exchange. Those
capabilities can be positives (like 'doing maths' added) or negatives
(like 'ignorance' subtracted) now. Is this the idea?
Q: Perhaps a repetition, but is the objective at the knowledge level
to state what a Book shop customer would gain from using a service
from a Book shop? This could, for example, include increased status
since he's now more knowledgeable in the eyes of his friends. Is this
the way to look at it?
Q: The knowledge level model becomes a model of what the offering
party's a) beliefs of what the motivating factors behind his customers
decisions to participate in a value exchange are, and b) own
motivations for participating. Is this how to think about the result
of knowledge level modeling?
Q: Design on the intangibles level involve adding to the model for
example agents or capabilities that are not directly involved in a
business case, but are/can be relevant for it. The intangibles are
(perhaps) implicit enablers or can provide alternatives. Do you want
to capture and make explicit the factors that makes a consumer more
likely to use/choose your service instead of the your competitor's? Is
this the idea behind intangibles?
Q: Finally (in phase 1), the intangibles captures the 'second order
values' that are included in a resource transfer. For example,
'convenience' is an intangible for Book provisioning at Amazon.com. I
can get hold of a book in a convenient way. 'Trust' is another example
of intangible. The level of trust has been built up over time as
successful transfers have been carried out. Is this how to think of
it?
Q: In phase 2 then, each core business service is identified. What
distinguishes a business service from a core business service? In the
case of Amazon.com, is 'Book sales', or 'User access to book catalog',
examples of core business services? Oops! I think this question is
addressed in one of Hans's comments (from the 28th) as "Core services
Amazons primary process, while 'User access to a catalog' doesn't.
Q: Another question is the distinction between a service and a
software service. A possible way to distinguish between them is to
say that what is identified in phases 1 and 2 are business
services. What is considered in phases 3 and 4 are software services
that can realize the business services. Can this way of separating the
two be useful?
Phase 3 is about design of the software services that can realize the
business services identified in phase 2. This can be done in two ways,
1) creation of a new design, or 2) adaption of some software services
already available.
Q: In case of adaption of something available, the info about that
should be accessible for the modeler. Where does this information
come from (from a method point of view)? Will it be provided through
the c3 analysis? That is, should ones own capabilities in terms of
current availability/capability of applications be explicitly stated
in the business model.
Phase 4 is about Support from infrastructure in order to realize
software services.
Q: The same question as the previous one can be made here; do we
design our software services independently of what infrastructure we
have available, or do we look at what we have and design after that?
In the latter case, also some note about what kind of infrastructure
we have should be in the starting value model. Is this so?
Hans Weigand
Birger,
hereby a new version of the paper. It is not that easy to work out the
design method - on the one hand because we do have limited information, on
the other hand because the value models are quickly growing large.
Thanks for your many questions. I have to address some of them in more
detail. But in general the answer to most questions is "yes", so we are on
the same line.
About the knowledge/identity level: the knowledge level, in Verna Lee's
analysis, has to to with capability, so it is not just any information.
For example, SAP benefited from IBX's knowledge on procurement, in their
alliance, as they did not have that knowledge before. The examples in her
papers are about knowledge gained not on instance level, but by the
collaboration as such, or by analyzing the transaction stream.
The intangible level: I propose to focus on "identity", to give
it some coherence. So not every second-order value belongs to this
level - mostly not, I would say (e.g. convenience of buying). I would like
to limit it to effects on the social identity of the actor.
For example, SAP provided IBX with a trustworthy image.
Or consider the value of a brand in consumer goods. The brand is a
resource, the value object is "provide an image", and it has an effect
on the popularity or status of the consumer.
Your example of a book. The book itself is a good (transaction level).
Incorporating knowledge, it is a bit special; it also provides
knowledge at the knowledge level (knowledge and book not being the
same thing). The identity value may be in that you associate with the book
and the writer, which may help you to on the social level.
I think these levels are very interesting to explore further, but perhaps
it should go to a separate paper.
ba
http://docs.google.com/Doc?docid=dg97c6s3_18c9mwc6fc&hl=sv
ba
phase. Although I don't completely understand them they yet, they
certainly seem to cover important aspects of business modeling. One
question; you refer to Verna Lee as the source of information about
intangibles. I'm not familiar with this person and his/her work. When
I do a search I get links to Verna Allee (e.g, http://en.wikipedia.org/wiki/Verna_Allee
and links on that page). Is this the same researcher? Another
researcher in the area of intangibles is Karl-Erik Sveiby (
http://www.sveiby.com/TheLibrary/tabid/68/Default.aspx ). I think that
there is some common ground between those two.
Now onto some reflections and questions about the method and its
relation to the proposed service ontology.
The service ontology was complemented with sub-types of the service
concept to reflect the idea that services can be thought of as being
at some level -- business level, infomation level, and infrastructure
level. This seems very natural. A service on a lower level support (in
some respect) a service at a higher level. To take advantage of this
in a method some ideas popped up.
Is it a good idea that in step 2 include the following deliberations
(given that a value model, such as e3value is present)?
1. Decide which ones of all possible services should be classed as
business services. The business services are those that are vital for
an agent to use or produce in order to conduct his business.
2. Decide which services provide information support for the business
services.
3. Decide which services provide infrstructure support for the
information service.
As I currently understands it all services in those levels can be
performed by humans, software, or perhaps combinations thereof.
* Is the work in the subsequent step (step 3) to determine which of
these business services, information services, and infrastructure
services should be realized in software?
* In the service ontology model presently at
http://docs.google.com/Doc?docid=dg97c6s3_18c9mwc6fc&hl=sv the service
has three sub-types. Service has also a recursive relation 'Enhances'
associated with it. Can the relations 'Infrastructure Support' and
'Information Support' be regarded as sub-types of 'Enhances' or are
they distinct?
* What about 'Complementary' as we have discussed earlier? A gift
wrapping is a complementary resource wrt to a gift. Should
'Complementary' be in much in the same way as 'Enhances' is?
* Does an 'Enhancing service' enhance service or a process? When we
say that this service is an 'Enhancing service' do we then mean that
the output of this service is used as an input resource (for a
process) that in some respect change a feature of a resource?
ba
sneaked into in the previous post. That the entire question may be
misguided is another type of error. So, I make some corrections and
also take the opportunity to add a few more.
/birger
>
> * What about 'Complementary' as we have discussed earlier? A gift
> wrapping is a complementary resource wrt to a gift. Should
> 'Complementary' be in much in the same way as 'Enhances' is?
service complements a gift service.
The meaning of complements is that a service A is complementary wrt a
service B, if A cannot exist without B also existing. A gift wrap
service is meaningless if there is nothing to wrap.
* Is the following a way to explain the distinction between 'enhances'
and 'complements' (-> means imply)?
** A service E enhances a service A => (A is consumed --> E is
consumed) and E changes a feature of A.
** A service C complements a service B => (B is consumed --> C is
consumed) --> resource F is produced.
In other words, enhancement means that there exist a dependency
between inputs to a process that results in a feature change of the
output resource. Complements means that there exists a dependency
between the inputs to a process, and the process output a new
resource. Perhaps one can call this new resource a bundle?
>
> * Does an 'Enhancing service' enhance service or a process? When we
> say that this service is an 'Enhancing service' do we then mean that
> the output of this service is used as an input resource (for a
> process) that in some respect change a feature of a resource?
'Enhancing service', do we then mean that it is used as an input
resource (for a process) that changes a feature of another resource?
As we have modeled it today enhances is a recursive relation on
Service.
* If enhance means 'change of feature', then can a process _ever_ be
enhanced by a service? If it can, one must assume that there is some
feature of the process that is changed. But only resources have
features. Ergo, a process is a resource. This relation, if there is
one, is currently missing in the model.
ba
sneaked into in the previous post. That the entire question may be
misguided is another type of error. So, I make some corrections and
also take the opportunity to add a few more.
/birger
>
> wrapping is a complementary resource wrt to a gift. Should
> 'Complementary' be in much in the same way as 'Enhances' is?
service complements a gift service.
The meaning of complements is that a service A is complementary wrt a
service B, if A cannot exist without B also existing. A gift wrap
service is meaningless if there is nothing to wrap.
* Is the following a way to explain the distinction between 'enhances'
and 'complements' (-> means imply)?
** A service E enhances a service A => (A is consumed --> E is
consumed) and E changes a feature of A.
** A service C complements a service B => (B is consumed --> C is
consumed) --> resource F is produced.
In other words, enhancement means that there exist a dependency
between inputs to a process that results in a feature change of the
output resource. Complements means that there exists a dependency
between the inputs to a process, and the process output a new
resource. Perhaps one can call this new resource a bundle?
>
> say that this service is an 'Enhancing service' do we then mean that
> the output of this service is used as an input resource (for a
> process) that in some respect change a feature of a resource?
Hans Weigand
Birger,
I wanted to do more yesterday, but I started to integrate your part in the
current version of the article. However, a major issue is now the
definition of enhancing service, access service, etc.
Ontologically, we can distinguish the following cases (exhaustive?):
- "subservice" A is subservice of B iff
Service A is consumed in process X that realizes service B
note: this is not the same as: service A produces a resource R that is
consumed in process X that realizes service B. In this case, there is only
an indirect relationship between service A and B
-"complement" (symmetric) A and B complement iff
Service B affects resource R and service A affects resouce R and A and B
are included in the same exchange process
where affect is synonymous to the "subject" relationship, defined as
follows:
A affects R iff A has a goal event E and E converts R
-"complementary service (asymmetric). Assuming that in an exchange
process, some services are considered "core", then B is a complementary
service if B complements A, A is core, and B is not core.
note: in this case, there is a certain existence-dependence between A and
B, in the sense that if A is removed from the exchange process, so is B.
This follows from the definition of "core" (to be stated yet).
However, the existence-dependence is not ontological. An ontological
existence-dependence exists when A not only affects R but either produces
R or exchanges R.
Example 1: hair washing as related to hairdressing is
existence-dependent in the first, but not in the ontological sense.
Example 2: a gift wrapping service is existence--dependent in the
ontological sense (be careful: the gift paper itself does exist
independently, but the wrapping not)
-"enhance" service A enhances service B iff
service A has a goal event E and E converts B
Note the ontological difference with complementary service. In this case,
service B itself is the goal of A. What does this mean? It is only
meaningful when we assume that services have features/quality attributes,
because then it can be "converted". This assumption is not odd, as
services are resources. The crucial question is what attributes of
services we distinguish. Here we may refer back to our previous work on
service qualities: security, availability, performance, ..
Note: if A enhances B, A is existence-dependent on B.
-"access service" A is an access service to service/resource B (for agent
C) iff there is an exchange process exchanging service/resource B to
agent C and service A is used in this exchange process
note: access services can apply equally well to services as other
resources (cars, books).
note: there may be a recursion (B being an access service), in principle
note: there is an existence-dependence
note: we assume here the existence of exchange processes. Is it possible
to define access service also without this notion?
Now the 1 million dollar question: what about a negotiation or
information (advertising) service?
It is an access service, as it is part of the exchange process
It is an enhancing service if we assume that availability is a quality
attribute.
Does it mean that access services are kind of enhancing service?
Perhaps the notion of access service is derivative. Why is a certain
access service included in the exchange process? Because it has an
enhancing function.
Note that we can also say that management services are enhancing services,
so it is not the case that every enhancing service is an access service.
There is also an alternative definition of access service; to avoid
confusion, I use the term interface service:
A is an interface service to service B if
the invocation of service A causes the invocation of B - or:
the goal of service A is that service B is realized or:
the exchange of service A causes the exchange of service B
to be continued..
ba
excellent points, comments, and questions. Much appreciated as I have
struggled a bit with precise definitions and to make sure that they
are consistent. We have been at the PoEM-conference for the last two
days (they are wrapping up now) and will continue working on this
later today.
Paul Johannesson
First, we would need to state what is a core service. One idea was
that an organisation just stipulates what it views as its core
services, so it could potentially be any service. Another idea was
that core services were about what an organisation offers to its
enivronment, which could be stated as: A core service is about
transferring (rights on) a resource to another actor, i.e. a core
service corresponds to a value transfer in an e3 model.
We then continued by considering what kinds of services that exist,
the idea being that given a core service we can start identifying
additional services that are required or may improve the core service.
If we choose the definition above, the core services are easy to
identify from the e3value model.
Given a (core) service, it is possible to identify a number of
services around it. These services can be classified into four(?)
groups:
* Value adding services - services that increase the value of the
service for customers
* Coordination services - openEDI stuff
* Managerial services - services that manage the processes
realizing the service
* Support services - services that are used in processes that
produce the service (a special case of support processes are
information and infrastructure services)
We then need to define the above categories and include them in the
description of the ontology, a sketch is given below. The text is to a
large extent based on Hans's earlier mail.
Value adding services
A service complements another service if they both have goals that
affect the same resource.
Example: A gift wrapping service complements a book sales service, as
they both have as goals to affect a book.
A service A enhances a service B if A has a goal that improves some
feature of B.
Example:
An access service provides access to another service. This implies a
constraint as below:
If WP is a work process that realises a process P that realises a
service S and there are access services for S, then there must exist a
work process WP1 that occurs before or in parallell with WP that
produces one of these access services.
Maybe this is rather interface service as defined in one of Hans's
mails.
Managerial services
Management is typically about a set of processes (process instances).
For example, you monitor a set of processes to identify bottlenecks.
This may help you to improve the process set, but not necessarily a
single process instance. (In the collapsed case, there is only one
process instance in the set.) If we view a set of processes as a
resource, then we could say that a management service has as goal to
improve some feature of that resource (process set).
Could we say that we manage services?
A tricky thing about management services is that we, so to say, move
one level up - the management services govern lower level processes/
services.
Coordination services
These are services needed to coordinate the exchanges of resources.
The services can be enumerated: identification, negotiation,
actualisation, and post-actualisation.
This answers the million dollar question by saying that these services
are neither enhancing nor access nor complementary services, as they
do not increase the value of the core service. These are just services
needed to coordinate the exchange.
Support services
These are services that are used in processes that produce the service
(a special case of support processes are information and
infrastructure services).
/Paul
Hans Weigand
Paul, Birger,
thanks. I agree with core service being identifiable as value object,
although in a value bundle some may be more core than others.
You deviate from my proposal with the notion of coordination service, but
perhaps not that much. The definition of coordination is fine with me. But
the question remains, from a service ontology point of view, what the
subject of the coordination service is. It is a service, but what does it
convert?
If the answer is that it does not convert anything, the questions becomes
whether it is a service.
If the answer is that it transfers a resource economically (like a
transport service transfers some goods physically), then that resource is
the "subject" of the service. The resource being either a good or a
service. But then it is not too different from an enhancing service. The
difference being that it does apply to services AND goods; and that it
focuses on the economic transfer, rather than some other (quality) aspect.
But does this apply to information and negotiation service as well? Or
should we say that the information service transfers information about the
resource, and the negotiation service transfers commitments about the
resource?
Or related to that: is the "exchange of resources" a REA event type, or a
process (that uses services like information service), or a service (with
a process behind it) that aims at exchanging a resource economically.
Although I have some questions I like the idea of defining the
coordination services more in terms of what they actually do rather than
the abstract notion of adding value to a service. I started this morning
to update the methodology section in the paper, but if we follow this
line, I have to adapt it again. Which is not a problem.
ba
type. We are working on explanations of the other service types and
will update the service ontology later today.
/birger
* Core service.
* Non-core service. A non-core service is of one of four types:
** Value adding service.
*** Complementary service.
*** Enhancing service.
*** Access service.
** Coordination service. A service coordinates a relation (i.e. an
exchange) between actors if it changes a feature of the relation. The
feature can be called 'phase' and it can take one of four possible
values -- identification, negotiation, actualisation, and
post-actualisation. Furthermore, the ordering of the phases is
significant. The phases should come in the order as stated above. An
intuitive reformulation of coordination is that an agent is
transformed according to the phases. For example, an agent is
transformed from 'Market segment' via 'Lead' via 'Customer' to
'Satisfied customer'.
** Support service.
** Managerial service.
Hans Weigand
Hello
I will update the paper (section 2, section 4) tomorrow morning. It is a
hectic time, next week I am at a conference (but with internet
connection) for three days. The Friday is reserved for the paper anyway. I
hope we can manage. If any of you wants to be first author, that is fine
with me. Anyway, I will do my best.
Greetings
Hans
Hans Weigand
Hello
hereby a new version. I added the XFS description and improved something
in section 4. However, I kept the term enhanced service for the time
being.
I think that not only the service ontology, but also the kinds of services
we distinguish and their relationships are innovative.
Important, I think, is not only the identification of these kinds of
services, but also that they are well-grouned/defined in the REA
service ontology.
Can you work on section 3? If I can do something on this section, then let
me know.
Hans
ba
We are working on section 3 right now ( http://docs.google.com/Doc?docid=dg97c6s3_18c9mwc6fc&hl=sv
). What's in section 3 is readable all the way down to the heading
"Scratch notes". One should be a bit cautious when reading the Scratch
notes section. The name is quite descriptive.
One of the main problems this far has been to understand the
information and infrastructure service part of the service model and
the value-adding service part. They seem to orthogonal in a sense, but
not unrelated. I have updated the Service ontology graph to capture
the orthogonality.
I think the "value-adding dimension" of a service is fairly well
understood after our discussions. Likewise is the "supporting
dimension" (although I have an alternate idea of this at the bottom of
the scratch notes. This is an attempt to explain how the dimensions
are related. It disturbs me that I cannot still explain why an
information service is not an enhancing service, for example).
The coordination and managerial dimensions are different from the
other two. The hypothesis is that the main characteristic of this
difference is that a service from those dimensions is used to alter a
process. A managing or coordinating service is instrumental when
changing a (feature of) a process. This is also in the scratch notes
but is yet to be worked out properly.
/birger
Paul Johannesson
We have continued on Sections 2 and 3. The ontology in Section 3 is
mostly stable though there are a few issues and a lot of polishing is
needed. I think most of what we have in the ontology is consistent
with the method in Section 4, but not completely. Hans, feel free to
make changes as you see fit. We will today have a closer look at the
method and try to come up with some suggestions. The text is here:
https://docs.google.com/Doc?id=dg97c6s3_18c9mwc6fc&hl=en_GB
Best regards,
Paul
ba
the text of section 3 is stabilizing (there are a few remarks here and
there but nothing dramatic) and is fairly complete. There is also a
nicer presentation of REA that should go into section 2. All of it in
http://docs.google.com/Doc?docid=dg97c6s3_18c9mwc6fc&hl=sv
/birger
---
On the method in caise09v3.doc, Section 4:
The introduction/classification of services in the beginning of
Section 4 does not directly relate to the service model in Section 3.
We should try to make use of the service model. We attempted that in
the present version of Section 3, but not everything in the beginning
of Section 4 is covered.
Step 1 in Section 4.1 is an interesting read but it does not really
feel as a part of a method but more like a number of observations and
discussion points. A problem might be that the reader at this point
believes that a strict method is to be presented but this is not
delivered here. This can be addressed in two ways:
- cut down on the section and make it look more like a method
description
- lower the expectations of the reader by saying that we provide a set
of guidelines or something similarly soft, rather than a method
- or a combination of the two above, first we state input and output
for a step, and then we give guidelines for how to carry out the
transformation of input to output
Step 3 and 4 are also quite vague, it does not feel like a method.
Step 3 and 4 do not use the service model very much. This is
unaviodable as the service model is not able to give a deep analysis
of information and infrastructure services.
In Section 4.3, the division into steps needs to be in synch with
Section 4.2.