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 in a business are therefore defined as a number of connected different business 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 starts it up; it describes a sequence of actions (Tasks and Sub-Processes) that produces a valuable result for the business.  In the very simple example below there are a number of business activities defined that support an airline and passengers checking in to a flight with luggage.:

Figure 1 - A passenger can travel individually or with a group. When traveling with a group, a passenger is accompanied by a tour guide.

From an individual actor's perspective, a business activity defines the complete workflow that produces the desired results. This is similar to what is generally called a "business process", but "a business activity" in the context of the UAM (and BPMN) has a much more precise definition.

The definition of the business activity concept, as do all of the models defined within the UAM, differentiates between instances and classes. This, and other important concepts, which aid in understanding and identifying business activities are:

• Business Activity - to make the business activity model more comprehensible, similar processes are grouped together into a business activity. In reality, there are a great number of possible processes for any given business activity, many of them very similar with the main differences being conditional aspects of the workflow (for example, the type of product that the customer would like to purchase). Thus a business activity (class) will define decision points and alternative flows; which path is taken will depend on the state of the business, business events, and input from the business actor.
• Actors and Roles - The actor is probably the real key to finding the correct business activities. Starting with individual actors — or really instances of actors — helps in finding business activities. At the enterprise level, the actors and the activities are going to be, initially, covering a large portion of the business through abstraction. This layering is the only way to deal with this complexity. See: Guideline: Users, Actors and Roles. Note: Only actors are defined at the Business level, roles imply that the activity is interactive; a decision that is made only at the Logical level.
• A result of observable value - helps in determining the correct extent of a business activity, which should be neither too small nor too big (but this is hard to avoid at the enterprise level). Requiring that the business activity give a result of observable value, that is, both perceived and measurable, helps in finding a complete flow, and in avoiding business activities that are too small (i.e. a single Task is likely not a complete business activity).  
• In a business - The words "in a business", means both that the business provides the business activity to the actor, and that the business activity only covers what is actually done within the business. Supporting work done elsewhere is not included.
• Action - The actions are invoked either on request from an actor to the business, or through some other business event. Actions include internal tasks and decisions, as well as requests to either the invoked actor or other actors.

Business activities specify the interactions between the subject business and its business actors, and the effect that they have on the business — the performance of a business activity may change the state of the business (and thus may change the way the business responds to future events or interactions), and the business activities must specify and capture these state changes.

A services view of the business is also possible, since what the business directly and explicitly provides to its environment are services, and the interaction between the Business Actor and the business, as described in the Business Activity, will take place through the invocation of one or more of those services. Note that for new business development (the creation of a new business or business line for example), or when changing the business, Business Activities are one way of identifying services that the business provides. It is easy enough to equate Business Activities to Business Services in the business view, since at this level there should be no notion of how these activities or services will be implemented, in other words, they are just labels on the (possible collection of) activities that the system provides/uses.

The collected set of Business Activities constitutes all the possible ways of accessing/using the business, and all the possible actions (events) and actors that the business deals with. See: Guideline: Business Process Model. 

Extent of Business Activities

It is sometimes hard to decide if a service is one, or several business activities. Apply the definition of a business activity to the airport check-in process. A passenger hands his ticket and baggage to the check-in agent, who finds a seat for the passenger, prints a boarding pass and starts baggage-handling. If the passenger has normal baggage, the check-in agent prints baggage tag and customer claim check, and terminates the business activity by applying the tag to the baggage, and giving the customer claim check, together with the boarding pass, to the passenger. If the baggage is oversize so that it cannot be transported normally, the passenger must take it to a special baggage counter. 

Do you need one "business activity" at the check-in counter, another at the special baggage counter? Similarly, what if a passenger checks-in at a self-service kiosk, is this a different "business activity"? Or are all of these part of a single business activity? These transactions involve several slightly different types of actions. But the question is, will any of them be of value to a passenger carrying special baggage if he does not do the other (i.e. self-serve check-in without baggage handling)? Not really, it is only a complete procedure (from check-in until he is ready to board) that has value and makes sense to the passenger. Thus, the complete procedure involving the self-serve kiosk and possibly (zero to) two different baggage counters is all part of the same business activity (that may be decomposed into more detailed activities).

In addition to this "cohesive and complete" criteria, it is practical to keep descriptions of closely related services together, so that you can review them at the same time, modify them together, test them together, write manuals for them, and in general manage them as a unit. Note also that two independent business activities can have similar beginnings.

Example:

In an insurance company, the business activities Handle Claim and Handle Request both start when someone (an actor) makes contact with a claim handler. The claim handler and the actor exchange some information to make it clear whether the actor is filing a claim or requesting some information. Then, and only then, is it possible to decide which business activity is underway. Although the two business activities have similar beginnings, they are not connected.

Name

The name of the business activity should express what happens when an instance of the business 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 (Check-in Individual).

The names can either describe the tasks in the business activity, for instance placing an order. Although a business activity describes what happens within the business, it is often most natural (and recommended)  to name the business activity from its primary actor's point of view. 

Goals

The goal of a business activity should be specified from at least two perspectives:

• For the business actors the business process interacts with, specify the value those business actors expect from the business (expected result). 
• From the perspective of the organization performing the business processes, define what the objectives are of having this business process in place and what you hope to achieve by performing it (business outcomes). 

Performance Goals

Some common metrics categories to note when describing the activity are: 

• Time - an approximation of the time it should take to execute the activity, or part of the activity. 
• Cost - an approximation of the cost of executing the activity, or part of the activity.
• 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 (business 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 business activities may be thought of as one or more sub-processes, which together yield the total workflow. Sometimes several business activities in the business have common sub-processes or tasks, or the same sub-process (or task) appears in different parts of one business activity. If this common behavior has any substantial volume, it should be performed by the same business actors.

If a subflow is substantial, common to several business activities, and also forms an independent and naturally delimited part, the model might be clearer if this behavior is partitioned out to a separate business activity (i.e. a BPMN Call Activity). This new business activity is then included in the business activity using normal BPMN workflow concepts and structures.

Example:

At the airport check-in counter, the two business activities, Check-in Individual and Check-in Group both use the same procedure to handle an individual passenger's baggage. Because the subflow is independent of the ticket handling, and is logically connected, it is modeled separately in the business activity as Handle Baggage . See: Guideline: Business Perspective Views.

Characteristics of a Good Business Activity

• Its name and brief description are clear and easy to understand, even to people outside the IT architecture team.
• Each business activity is complete from an outside (actor's) perspective. For example, the business activity Handle Claim in an insurance company starts when a customer files a claim. The Handle Claim business activity is not complete unless it includes a notification about the decision from the insurance company to the customer and (if appropriate) a compensatory payment.
• Each business activity normally is involved with at least one actor, especially high-level activities defined at the Enterprise Architecture level. Business activities are often (but not always) initiated by actors, interact with actors to perform the tasks, and deliver results.
• It is possible for a supporting activity or call activity not to interact with an actor. This is true if a business activity is initiated by an internal event and does not have to interact with an actor to perform its tasks (i.e. it is a service activity).

Characteristics of a Good Process Description

• It must be clear and easy to understand, even for people outside the business modeling team.
• It describes the workflow, not just the purpose of the business activity.
• It describes only those tasks that are inside the business.
• It describes all possible tasks in the business activity. For example, what happens if a condition is met, as well as what happens if it is not.
• It does not mention roles who do not communicate with it. If it did mention other roles, 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 business activities that work parallel to it.
• It does not mention other business activities with which it does not have relationships. If the business 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 business activity in which the result was created.
• It indicates if the order of any tasks described for the business 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.

Characteristics of a Good Abstract Business Activity

• It is substantial. Remember, a concrete business activity must be easy to read, together with its abstract business activity. Therefore, an abstract business activity should not be too small. If an abstract business activity is not substantial, it should be eliminated and its tasks should be described in the affected concrete business activity.
• It contains logically related tasks.
• It exists for a specific reason. An abstract business activity should contain any of three kinds of tasks: those that are common across several business activities; those that are optional; or those that are important enough that you want to emphasize them in the model.