Information Technology Reference
In-Depth Information
Secondly, the enterprise language accommodates the expression of business
services. A business service is a particular description of behaviour that
focuses on the functionality or capability provided by one party to the others
who can then use the service to satisfy their own business needs, resulting in
some added value to them. A business service can be provided by a single
role in a community or it may involve several roles; for example, the phone
repair service of the Phone Repair community is provided by the Phone Repair
Provider role (encompassing HQ system and Branch staff roles of the Detailed
Phone Repair community jointly), which both interact with the service users.
This business service is the central part of the Phone Repair community and
can be used by other members in the Phone Repair community, such as the
Customer and the User.
Business services can be made public by a community; that is to say, they
can be used not only by the objects filling other roles in the same community
but may also be accessed by the behaviour of different communities. Note
that a business service can be supported by one or more technical services,
described in the computational viewpoint, and that these different uses of the
concept of service are in line with the current SOA frameworks, such as the
OASIS Reference Architecture [46].
A process is a specific form of behaviour expressed in terms of sequential
or concurrent ordering between steps. Each business step may consume and
produce information. A process will thus involve one or more community roles,
which perform actions associated with business steps. Each process is aimed
at satisfying an objective, and many processes can be defined in a community,
each of which contributes to the overall objective of the community. This
abstract definition of the process can be further refined to give more detailed
process definitions represented in notations such as BPMN, or UML activity
diagrams (as in UML4ODP).
Interactions are the basic elements of the community behaviour. Each
interaction indicates which roles it involves, and what part they each play in
it. For example, in a message exchange requesting a repair, the community
roles of User and Branch staff may be involved, with the user acting as initiator
and the branch as responder (where initiator and responder are interaction
roles, not community roles). Multiple interactions can then be composed
into sequences or concurrent activities, forming extended pieces of behaviour,
building up first steps and then complete processes. Thus, simple interactions
can be used to build up control flows, yielding a style of behaviour familiar
from process modelling.
The complete behaviour of a community can generally be decomposed into
a number of distinct processes. In the PhoneMob (see figure 2.7), we have,
for example, the repair process, concerned with dealing with a faulty phone,
and two separate administrative processes, one dealing with the negotiation
of service levels with a logistics provider and the other providing assessment
and reporting of key performance indicators. Finally, we have a management
process concerned with the maintenance of the phone loan policy.
