Thursday, October 22, 2009

Business Process Management (Part-2 Business Process Modelling[Chapter V Process Choreographies ] ) Sec B -- By Mathias Weske

Development Phases

This section introduces the development of process choreographies, guided by
phases. The main goal of this section is to provide an understanding of the
concepts and artefacts involved in the design of process choreographies, rather
than on providing a reference methodology for choreography design These phases are organized into design phases and
implementation phases, shown in the upper and lower part of that figure,
respectively. There are three associated roles that represent the stakeholders
involved in choreography design and implementation. Based on the discussion
of these roles in Section 1.2, their specific responsibilities in the context of
process choreographies are highlighted.
Business engineers are mainly involved in the choreography design phases,
including scenario modelling, domain scoping, milestone definition, and participant
identification. Business engineers are responsible for business-related
aspects of the process choreography; they need to make sure that the collaboration
contributes to the goals of the enterprise, similarly to organizational
business processes.
System architects are responsible for the architectural aspects of the implemented
process choreography. This means that they are
involved in the design of process choreographies as well as in their implementation.
In particular, they are involved in the specification of the behavioural
interfaces, discussed later in this chapter.
Once the process choreography design is completed, developers are responsible
for realizing the process orchestrations in a way that the overall
business-to-business collaboration as specified in the process choreography is
realized. Behavioural interfaces are important artefacts for designing the individual
process orchestrations.
Based on this discussion of the stakeholders in process choreography design
and implementation, the phases are sketched.
Scenario modelling is at the heart of choreography design: scenarios describe
the overall setting and goals of the process choreography. They are also
useful for integrating the results of the other design phases. To model a particular
scenario, a domain in which the cooperation will take place needs to
be specified. This is performed during the domain scoping phase by business
engineers.
Formal notations are not required in scenario modelling and domain scoping,
so that the scenario and the domain can be described in a language that
allows expressing the relevant concepts. Depending on the specific setting of
the project, plain English text enriched with informally specified graphical
diagrams can be used.
The participant identification phase is devoted to defining different roles
of choreography participants. There are two options for doing this. These
roles are specified in a way that allows for the selecting of concrete process
participants on the basis of their properties as laid out in the participant roles.
In the context of process choreographies, the term process participant
refers to an organization, rather than to an individual. For instance, the role shipper can be played by multiple shipping companies, all of which are appropriate
for participation in the process choreography.
In the milestone definition phase, the participants define certain states of
the choreography in which the cooperation has achieved certain results, typically
characterized by intermediate products. These states are called milestones.
Milestones and their ordering describe behavioural aspects of the
choreography from a high level of abstraction.
In the message identification phase, the interactions in the scenario are
used to identify and design messages that realize the various interactions. This
phase has business aspects as well as technical aspects; it is therefore located
on the border of the design and implementation of process choreographies.
The design aspects include the business content of the messages, while the
implementation aspects include the technical realization of these messages
and concrete message formats.
Finally, the choreography definition phase combines the message identification
and the milestone definition phases of the modelled scenario. The
result of this phase is a detailed specification of the interactions between the
participants, the messages to realize the interactions, and the milestones that
are reached during the resulting conversation in the instance layer.
The choreography definition phase, just like the message identification
phase, includes business aspects as well as technical aspects. Unsuccessful
interaction behaviour would arise if, for instance, message formats were used
that one or more participants would not understand. To avoid this problem,
it is assumed that message formats as well as the semantics of the messages
are agreed upon by the participants.
Domain standards, like the ones mentioned above, are in place to provide
a common terminology, and, thereby, an understanding of the concepts
used. These standards are enhanced with technical information, so that data
structures and message formats are available. Business engineers, system architects,
and developers participate in choreography definition and message
identification.
In the lower part of Figure 5.4, the phases during implementation of
process choreographies are shown. Based on the choreography definition, behavioural
interfaces of all roles in the process choreography are defined. Behavioural
interfaces serve as blueprints for the design of the individual process
orchestrations realized by the participants of the process choreography.

No comments:

Post a Comment