BPSS and Business Process
Role
Current
Shortcomings
Role information currently provides type or classification information
about the relata in a business process. In other words, given a relation such
as “buys” or “sells,” the things in the relation have a type of “buyer” or
“seller.” Other ebXML
specifications, such as CPPA and Messaging, tie in to the BPSS instance and
use the BPSS values for Role both in CPPs and CPAs as well as within the
actual ebXML Message header. The To, From, Service, Action and Role values
provide basic metainformation descriptions for relating events concerning the
documents being exchanged in ebXML messages to the states entered by the
concrete business process session.
The UMM has used role as a label for a navigation link and in a concept
of AuthorizedRole. Previously
there has been some discussion how or whether the BPSS role concept adheres to
or deviates from UMM usage. That discussion has, in my opinion, been largely
fruitless. Therefore, the shortcomings that I wish to discuss do not derive
from prior discussions of BPSS and UMM “semantics”. Thus I here assume that
the semantics of Role values derives from being a type/classification of
relata in business processes, which is the widespread and ordinary business
language usage, and which I described in the first paragraph.
There are several sources of inadequacy in the current approach to
capturing Role information which I will discuss under separate headings:
polyadicity, cardinality, and compositionality.
Polyadicity
Polyadicity is the property of how many relata are in a relation. The
current treatment of business process deals with only abstracted business
relations. For example, in a concrete selling relation such as “selling,”
there are typically more kinds of things being related than just a buyer and a
seller. There is a product or service being purchased and there is some
arrangement made for something to be received in exchange for the product or
service (a payment, for example). [Otherwise we might have a hard time
distinguishing “selling” from “giving”.]
UMM inspired business process models so far do not capture cleanly
these richer business process relational descriptions, but that is not
necessarily a shortcoming. We can regard the four place selling relation
(buyer, seller, product, payment) as the basis for a two place selling
relation (buyer, seller) with the product and payment assumed to exist, but
remaining unidentified.[In logic this would be done by existentially
quantifying over the product and payment relata.] In other words, expressive
incompleteness of our current model need not always be a shortcoming but may
merely be an indication of a certain “level of abstraction.”
However, for some time it has been thought that there needs to be a
distinction between multiparty (greater than two) and binary (two) business
relations (the relations being viewed as things in their own right, called
collaborations). For example, an escrow business process might exist between
three parties, a seller, buyer, and the escrow agent. A buyer might arrange with an escrow
service to hold its payment until the delivery of a product, and the seller
might wait to ship until the escrow service notified it of having received the
payment. There might therefore be a more complicated selling relation
involving three relata, each with a distinctive business role. It is then the
number of types of business agents
involved that motivates introducing multitparty relations with greater than
two roles.
There is a theorem of logic (more accurately, model-based
representation theory) that shows that any n-place relation can be defined in
terms of 2-place relations. This theorem (deriving from Quine) is unquestioned
extensionally speaking, but is a perennial philosophical favorite for endless
debates over whether “something” is lost “intensionally viewed.” Though I
personally would be happy to restrict BPSS to binary collaborations, I could
agree that multiparty collaborations might be cognitively more natural for
some analysts describing a process. If these multiparty collaborations then
“expand” into collaborations involving at most 2 parties, the connections with
CPPA and Messaging remain as they now are. However, for multiparty
collaborations that are not, in some sense, composed from (or based upon) 2
party collaborations, there will be currently be no ebXML implementation for
the underlying message and document exchanges that implement them. ebXML
Messaging and CPPAs are currently 2-party restricted, and will remain so, probably well past the version 3
level.
At any rate, if we are to “expand” multiparty collaborations into
binary ones, we need to be able to indicate connections between subsets of the
roles in a multiparty collaboration and the roles in the underlying binary
collaborations. I think one shortcoming of current BPSS is that expressing the
connections between Roles in one “segment” of a business process and Roles in
another segment is basically absent, or at least not powerful enough to keep
track of what needs tracking.
Compositionality
The crux of the shortcoming over Role that we currently have is that
our working models identify the role of a Business process segment (for
example, a CollaborationActivity or a BusinessTransactionActivity) but does
not represent the occupant of the role. Therefore, there is no clear way of
indicating the connection that the occupant of Role1 in Segment1 is the
occupant of Role5 in Segment5.
Roles are currently captured technically just as attributes (toRole,
fromRole) on the BP segment, and while we can reference Roles by nameIds,
it is not clear how we track
the association of occupants with Roles through a collaboration.
Bob Haugen and others
have previously shown this limitation by considering the case where occupants
reverse roles. If we want to compose a distributorship collaborative business
process from a pair of buyer-seller relations, logically we need to keep track
that the distributor is a seller to the retailer, but a buyer from the
manufacturer. That is, the occupant of the initial seller role can be the
occupant of the buyer role later on.
Therefore, the current notation is insufficiently expressive to
indicate that the occupant of a role in one BP segment is the same as the occupant of (the same or different) role in
another BP segment. I think that
if we can agree upon what we need to do, we can then work out a suitable XML
way to capture this expressive requirement.
I am going to wait to see first if there is agreement on at least
needing to augment the expressive apparatus of BPSS before getting into XML
syntax matters. However, I would note that the abstract Performs constuct that
was deprecated in version 1.1 does part of what is needed to increase the
expressive power. I think I would agree that the current notation (where
something called a BusinessPartnerRole has a Performs EII) is
confusing.
However, I would prefer to introduce more globally the cast of
participants in the BP, and then reference them as needed to tie them to Roles
within a given BP segment. So we would have an Association within a
BusinessTransactionActivity or within a CollaborationActivity that abstractly
connected one of the participant player with a Role
So in other words we would have something like
Cast: a, b, c (as needed).
RetailerOrdersfrom Distributer:
RoleAssociation(a-ref, roleid-to-buyer)
RoleAssociation(b-ref, roleid-to-seller)
DistributerOrdersfromManufacturer:
RoleAssociation(b-ref, role-idref-to-buyer)
RoleAssociation(c-ref, role-idref-to-seller)
Cardinality
Finally, and less critically, there is at present no indication of how
many occupants there are for a role, or that occupants are entering or
exiting.
For example, in a request-for-quote business process, we can imagine
that there is the role of shopper
(quote-seeker)and the role of bidder (quote-offerer). However, it might be useful to be able to
annotate somehow to indicate that initially there are say up to 100 bidders,
but that later on, one (or five)
of those bidders gets the PO. It is not that there are new roles involved or
that the role association connections are not expressible, but rather that the
numbers of players in a role goes from some large number in one role to a
smaller number in a connected role later.
There are several other possible use cases where we might want to
express cardinality restrictions on role occupants. I propose that this also be an area
investigated as we make changes to the Role schema apparatus.