Introduction

In the Unified Architecture Method (UAM), the Business Process Model defines all of the business activities of the system under study. Activities may represent complete business lines, complete businesses (at the highest level of abstraction) or smaller portions of business activities within a business. Activities may also represent business processes, which are composed of sub-processes, tasks, events and decision points. See: Whitepaper: BPMN - an Introductory Tutorial.

Activities, in the UAM context, are used to partition and understand the structure of the system under study, from a process perspective, resulting in manageable chunks, in much the same way that an enterprise is typically partitioned into inter-dependent business lines and business units. However, the role and purpose of different parts of an organization are not always clear to other parts of it, which results in less-than-optimal interactions when executing a business process.

In the UAM, activities start at the abstract level of the BPMN concept. Activities are abstracted and related to other activities or sub-activities (and possibly roles and resources), and they also explicitly define interfaces, and the set of processes and tasks (services or responsibilities) they provide. This use of an abstraction of business activity often goes hand-in-hand with using business models at different levels of abstraction as in the UAM (see Concept: Complex IT Architectures).

Note: Since UAM may be used at any level within the enterprise, the level of detail to be included in this model is a judgment call of the architect, based upon:

• The objective of the architecture effort
• The size of the enterprise or (business line)
• Time and resource constraints

Layering the Business Process Model is a convenient way to deal with complexity. Start with a top layer of activities that are abstractions of all the 'activities' of the system under study, with the next layer of detail showing more details of these activities. More layers can be used as well if the size and complexity warrants it.

Business Activities as Components

In this "Internet Era" and "Internet Speed", businesses need to be more dynamic; meaning that they need to change, update, add or modify their business activities and processes much more quickly than in the past. Defining structure and independent business activities as components provides the independence and flexibility required. At the design and implementation level, this may equate to a Service Oriented Architecture, but not necessarily. The objective is to have independent activities (namely, sub-processes and tasks) that are easily reconfigured, or even dynamically re-configured as dictated by business desires and business drivers.

Business activities have well-defined boundaries with predefined interfaces supporting interactions between business activities. These interfaces (possibly formalized service-level agreements) become the hinges that support the organization and also permit easier reconfiguration because activities are decoupled from each other. Dependencies are defined in terms of interfaces and responsibilities, not on how these responsibilities are carried out.

This approach very much equates to similar concepts in the past (but applied here to enterprise and system modeling), such as modular programming, structured programming, and structured design just to name a few.

Using business events and messaging to abstract and define interactions between activities can reduce direct dependencies even further. Because business events make time and space transparent, business activities can interact indirectly (see Guideline: Business Event) through messages.

If encapsulation is not considered important or required for a given business activity (due to its level of abstraction or for other reasons), then the business activity boundary may be defined as notional and will not exist during business operation. You can indicate this in the model by saying that the business activity (which is a kind of UML component) is not directly instantiate-able—it comes into being only through the instantiation of its parts.

Business Processes

Business services are provided to customers/users through or by business activities or processes. We are concerned with encapsulation here, and can indicate that business services have more than notional boundaries by making them directly instantiate-able. This defines the business service provided by the process (i.e. a collection of activities) such that, in operation, the boundary will be somehow made real and visible to customers/users.

Business activities explicitly define the responsibilities that they can be asked to perform. This specification of behavior is essential because it allows the decoupling mentioned in the previous section. A business activity that does not define its services is without meaning. There is no way that another business activity can know what services it provides, other than inferring them from its name. At the business level these services may not be very explicit or clear, but they need to be made clear at the Logical and Technical levels.

The services provided define the means of interaction with the business activities/process and are essentially specified as operations of the interface(s) to the service. These interfaces are collections of related activities and as such describe the sub-process that the business activities play in providing the service. At this business level however, these interfaces may not be clearly understood and therefore not clearly defined.

The example below shows the set of business activities (i.e. process) of the research lab within the ThuNorTech fictitious enterprise used in the UAM example architecture (See: UAM Examples). This process provides the "Perform Lab Study" service to customers.  The diagram shows how the defined activities interact to perform a lab study. From this diagram, it becomes apparent that the responsibilities can be reassigned by allocating an interface to another business activity—to re-direct the workflow to modify or augment the process. This reallocation of responsibility would conceptually have no effect on other business activities that make use of them.

Figure 1 - A simple Business Process Model with collaborating activities

This UAM process description, part of the Business Process Model, in no way defines the solution approach. SOA, Client-Server or any other approach may be used to implement these activities and processes—decisions that are made at the Logical and Technical levels.

Business Activities Contain Actors and Resources

A business activity is an abstraction of a collection of people, hardware, and software and other resources that work together to perform the responsibilities of the business process. They are an "abstraction" because we describe models of the processes in terms of activities, roles and resources. A business activity contains actors, and may contain business roles and business entities. A business task is an activity that cannot be decomposed any further in the business modeling effort. A business entity is a piece of information created or manipulated by business activities or business systems. 

We do not, during our business modeling effort, decide that:

• A role is bound to a particular activity, this is defined at the Logical level;
• A human (or humans) is bound to a particular business actor. Actors are defined but not their relationship to humans, this is defined at the Logical level;
• The activity and associated actor or role will be fulfilled by software (and associated computational hardware); again, this is defined at the Logical level.

Activities may capture a very complex system, with associated Actors, and possibly roles and resources. In some cases this high-level of abstraction is required and desired in order to hide complexity. These business activities can eventually be mapped to human resources, or to specific hardware or software systems. This abstraction helps us focus on the actors and interfaces of the business activities and determine the necessary responsibilities without having to consider the (usually imperfect) real situation of a specific person or system, which is left to the Logical level of analysis.

Note that at the business level, computational notions are absent, including the bindings of business activities to systems, and the binding of associated actors to humans.

A Business Has Many Business Activities

Instances of several different business activities, as well as several instances of a single business activity, normally execute in parallel. There might be an almost unlimited number of paths an activity instance can follow. These different paths represent the choices open to the activity instance in the workflow description. Depending on specific events or facts, a activity instance can proceed along one of several possible paths, directed, for example by:

• Input from an actor;
• A business rule;
• A business event.

In modeling business activities, you can assume that activity instances can be active concurrently without conflict. At this stage of business development, you should focus on what the business should do. These potential conflicts are solved later, when modeling the Logical or even Technical level, at which stage you try to understand how things should work in the business. Or you might solve these problems during the implementation, for example, by increasing the number of employees who can perform the critical task.

Are Business Activities Always Related to Business Actors?

Every business activity does not necessarily have a relationship to or from a business actor. Actors interact with the system to get services --- but services are provided through a process, a collection of activities. Some of these activities therefore may be automated or otherwise do not have associated actors. The level of the modeling effort also has an impact upon the need for actors, for example in a high-level enterprise architecture most of the activities should have associated actors.  

Business Processes & Activities vs. Business Functions

Business activity are not be simply allocated to a business processes. Often processes are the customer-facing and require the collaboration of a number of business process and activities in order to fulfill the service request of the customer. Business activities (and even processes) collaborate, similar to Figure 1, to perform business processes. The diagram in Figure 2 below clarifies the relationship between business services (processes) provided to customers versus how the enterprise is organized along functional lines — along generic business functions such as financial management or customer relations. 

Figure 2 - Business processes vs. business functions 

This clarifies the difference between a business process and a business function. This distinction is important when defining architectures and specifically the process models. A business function provides functionality that is useful for one or more business processes — it is the vertical view of the business (e.g. Customer Relations or Financial Services). A business process on the other hand is a horizontal view of the business that at a high-level equate to business services offered to customers (e.g. Order Processing or Travel Booking). This distinction is not always clear, especially at lower levels within an enterprise, but when modeling at the Business level it is important. These concepts are illustrated in the Figure 2, which is well understood by Business Analysis’s and definitely needs to be understood by IT architects.

Structuring the Business Process Model

There are three main reasons for structuring the Business Process Model:

• Make the business activities easier to understand;
• Reuse parts of workflows that are shared among many business processes;
• Make the Business Process Model easier to maintain.

Layering may be done in any perspective and aspect (see: Concept: Architecture Perspectives and Viewpoints). In addition to the partitioning approach where multiple activities are formed into processes, one may also layer activities. High-level layers provide general viewpoints of the enterprise or the "system" at a high conceptual level, with lower layers adding detail. This fits nicely with the audience for these different viewpoints and layers. For example, a company's executive management, as well as its process owners, are interested in their company's business models — management work with overall views and objectives, whereas the process owners and leaders need a more detailed picture of how their process should be performed.

If the enterprise (i.e. the "system" being architected) is large and complex, or if differences between the executives' and the process owners' views of the organization are great, this can be dealt with by developing two (or more yet related) layers. One model, for the executives, would contain a set of high-level business activities that show the intent and purpose of the organization. The other model, for the process owners, would contain a detailed set of activities that help clarify how the organization needs to function internally. For each high-level business activity, you could define one, or several, detailed business activities representing the same thing within the organization. For example, you could start with the primary business actor, detail the results and services he or she is interested in, then develop a separate business activity for each detailed area.

If you want to engineer your organization one business activity at a time, you can apply this technique incrementally. First make a high-level activities model of the entire business and then "drill-down" into one of the activities of interest to provide a more detailed model for the process owner. There is a one-to-one relationship between a high-level business activities and its set of more detailed business activities — with the detail encapsulated within the activity. The figure below illustrates this concept. The "Sales & Marketing" activity (Contained within a Customer Relationship Management (CRM) high-level activity) is drilled-down to expose more details.

Figure 3 - Layering of IT Architectures to deal with complexity

Note the  decorator on the "Sales & Marketing" activity, indicating that the next layer of detail of this "collapsed sub-process" has been defined. 

The options for dealing with complexity are described in Concept: Complex IT Architectures. For more information also see: Guideline: Business Perspective Views. 

Practical Advice

What is an activity at the business level?

At the business level, an activity represents a clustering of work that delivers a meaningful output. Often an activity at this level encapsulates a sub-process that may be re-used or encapsulates further detail. At the Business level, activities can be structured to hide complexity and to layer a business process for ease of understanding. There is usually functional cohesiveness involved in choosing activities at this level. An activity may or may not be constrained by automation assumptions. Generally the automation decisions are left to the architects and are defined and represented at the Logical level. The choice of activities at this level and their sequence must be representative of the business vision. 

What is a task at the business level?

A task is the most granular level of activity representation, a cohesive (atomic) unit of work. Tasks can be further broken down into steps but this is done in the task description and not in the diagram. A task is a type of activity. There is no need to distinguish between the types of activities or tasks at the business level unless the business wishes to impose a constraint on the architecture (e.g., they want a particular unit of work to be automated or not).

How do business rules fit in?

Business rules, at this level, should represent only the rules that apply to the business regardless of where they would be positioned in the activity sequence.  These are the ‘true’ rules that constrain business practices due to policy or legal limitations. It is important to isolate these at this level. They are best not associated with specific activities. This will encourage the statement of these rules in a process and technology independent way. References: Ronald Ross books. 

How does the present organization fit in?

It need not, should not. It is best to associate activities with business functions as opposed to existing organizational structures. The organization may change considerably during the lifetime of the architecture documents so to keep the models stable; handle organizational structure separately. Also, the redesign of the organizational structure is an activity that would be owned by the architecture team. The architecture models, the roles model in particular, provide valuable input into that effort which should be carried out with HR representatives from the business. Ideally, HR representatives (or appropriate managers) are involved in various aspects of the architecture so that they can acquire the knowledge they need first hand. On the other hand, interaction with outside agencies or customers is important to have clearly represented in the business process models. 

Stay Organized

It is very easy for the modeling effort to slip away from any kind of overall order. Constant tweaking at the lower levels can lead to inconsistencies in the overall consistency of the models. Avoid too many layers. Two to three layers are ideal. More than three is very difficult for users of the models to understand and manage. Always keep the top level diagrams and the context diagram up to date and available to all modelers. 

BPMN usage

It is very important to go light on the notation at the Business level.  Ease of comprehension is more important than expressing all of the details.  The Business Perspective Language defines a simple set of modeling elements to be used. Portray what is important to the vision and at a level of detail that can provide context to business constraints / requirements. 

How do business requirements fit in?

The business process model provides the ideal context for a set of business requirements. Since the business process model reflects the business vision, the specific business needs statements can fit within the description of the activities. There are also supporting activities that may not have a place in the models that need to be addressed, as well as non-functional requirements that need to be placed within a separate context. Keep in mind that the business rules must be documented separately at this level. If business functions have been shown in the business process model then these can provide a good context for the business rules. The requirements at this level are statements of a business needs and do not necessarily describe the functionality of a system as the automation decisions are not made until the logical architecture is being modeled.

Characteristics of a Good Business Process Model

• Business activities are aligned with the business strategy, as described by concrete business goals.
• Activities conform to the business they describe.
• All activities are found. Taken together, activities perform all tasks within the business.
• Every activity within the business should be included in at least one process.
• There should be a balance between the number of activities and the size of the activities:
  • Few activities make the model easier to understand.
  • Many activities may make the model difficult to understand.
  • Large activities may be complex and difficult to understand.
  • Small activities are often easy to understand. However, make sure that they describe a complete workflow that produces something of value for a customer.
• Each activity must be unique. If the workflow is the same as or similar to another activity or process, it will be difficult to keep them synchronized later. Consider merging them into a single activity.
• The description of the Business Process Model should give a good, comprehensive picture of the organization.

Examples

Airport

An airline provides services to passengers. Because an airline is a very large and complex business to model, it makes sense to divide it into a number of independent business activities/processes. Each business activity can then be modeled independently as a business in its own right. Shown below is the "Check-in" business activity, but there are many other activities within an airline company.