Introduction
The Unified Architecture Method (UAM) uses the concepts and terminology as defined by the OMG's Business Process
Modeling Notation definition to describe business activities, processes and tasks. See: Whitepaper: BPMN - the standard and Whitepaper: BPMN - an Introductory Tutorial. BPMN defines business activities as
work to be performed as part of a business process. Activities in turn represent either a Task (an atomic activity) or
a Sub-Process (a compound activity).
The processes of a business are therefore defined as a number of different activities, each of which represents a
specific task or sub-process in the business. An activity defines what happens within the business when an event start
up the activity; it describes a sequence of actions (Tasks and Sub-Processes) that produces a valuable result for a
particular actor. At the technical level the focus is on making technical decisions, even if the complete workflow
(activities, processes, sub-processes and tasks) are not all defined. Decisions regarding technical solutions, solution
patterns, and other technical details are documented in Architectural Decisions, see Task: Define an Architectural Decision.
Depending upon the size and scope of the enterprise, and the objectives of the architecture effort, it may be desirable
to define the full details of the workflows, as illustrated below.
Figure 1 - Task details for "expense reimbursement".
Technical activities specify the interactions between the subject system and its actors/roles, and the effect that
they have on the business—the performance of an activity may change the state of the business (and thus may change
the way the business responds to future events or interactions), and the activities must specify and capture these
state changes.
A services view of the system is also possible, since what the business directly and explicitly provides to its
environment are services, and the interaction between the actor and the business, as described in the
(high-level) activity, will take place through the invocation of one or more of those services. The collected set
of activities constitutes all the possible ways of using the business and how they are supported, and all the
possible actions (events) and actors that the business deals with. See: Guideline: Technical Process Model.
Name
The name of the technical activity should express what happens when an instance of the activity is performed. The form
of the name should therefore be active, typically described by the gerund form of the verb (Checking-in) or a verb and
a noun together.
The names can either describe the tasks in the activity, for instance placing an order. Although an activity
describes what happens within the business, it is often most natural (and recommended) to name the activity from
its primary actor's point of view.
Goals
The goal of a logical activity should be specified from at least two perspectives:
-
For the actors the process interacts with, specify the value those actors expect from the business (expected
result).
-
From the perspective of the organization performing the process, define what the objectives are of having this
process in place and what you hope to achieve by performing it (business goals).
Performance Goals
Some common metrics categories are:
-
Time - an approximation of the time it should take to execute the workflow, or part of the
workflow.
-
Cost - an approximation of the cost of executing the workflow, or part of the workflow.
-
Quality - for example, "no more than 2% of products should be defective when they come off the
production line".
A major challenge is to understand what scenarios (activity instances) are relevant to measure. Criteria to use are
frequency of the scenario, or business relevance of the scenario. If you can determine that a particular part of the
workflow has importance, you may save yourself some effort by only measuring the cost or time of that subflow.
Workflow - Structure
Most activities may be thought of as several sub-processes, which together yield the total workflow. Sometimes several
activities in the system have common sub-processes or tasks, or the same sub-process (or task) appears in
different parts of one activity. If this common behavior has any substantial volume, it should be performed by the same
actors/roles. This is the key value added for the technical process model, deciding upon the structure and
relationships between activities, tasks and process, which are defined as the details of each activity and process are
defined. See: Guideline: Technical Perspective Views.
Characteristics of a Good Technical Activity
-
Its name and brief description are clear and easy to understand, even to people outside the modeling team.
-
Each activity is complete from an outside (actor's) perspective. For example, the activity Expense
Reimbursement in a company starts when an employee files a travel claim. The Expense
Reimbursement activity is not complete unless it includes a notification about the decision from the
company to the employee and (if appropriate) a compensatory payment.
-
Each activity normally is involved with at least one actor. Activities are initiated by actors and business
events, interact with actors to perform the tasks, and deliver results.
-
It is possible, but unusual, for a supporting activity not to interact with an actor. This is true if an
activity is initiated by an internal event and does not have to interact with an actor to perform its tasks.
-
It is substantial. Remember, a concrete activity must be easy to read. Therefore, an abstract activity should
not be too small. If an abstract activity is not substantial, it should be eliminated and its tasks should be
described in the affected concrete activity.
-
It contains logically related tasks.
-
It exists for a specific reason. An abstract activity should contain any of three kinds of tasks: those that
are common across several activities; those that are optional; or those that are important enough that you want
to emphasize them in the model.
Characteristics of a Good Process Description
-
It must be clear and easy to understand, even for people outside the modeling team.
-
It describes the workflow, not just the purpose of the activity.
-
It describes only those tasks that are inside the business.
-
It describes all possible tasks in the activity. For example, what happens if a condition is met, as well as
what happens if it is not.
-
It does not mention actors who do not communicate with it. If it did mention other actors, it would make the
description difficult to understand and maintain.
-
It describes only those tasks that belong to it, not what is going on in other activities that work parallel to
it.
-
It does not mention other activities with which it does not have relationships. If the activity requires that
some results exist in the business before it can start, this should be described as a precondition. The
precondition should not have any references to the activity in which the result was created.
-
It indicates if the order of any tasks described for the activity is not fixed.
-
It is structured so that it is easy to read and understand.
-
The description clearly describes the start and end of the workflow.
-
Each extend-relationship is described clearly so that it is obvious how and when to insert the business
activity.
|