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.