Introduction

The Unified architecture Method (UAM) uses the concepts and terminology as defined by the OMG's Business Process Model and Notation definition to describe business activities, processes and tasks. See: Whitepaper: BPMN - an Introductory Tutorial

BPMN defines business activities, which denote 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). 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. The Logical Process Model therefore defines all of the activities of the system at the logical level. 

Some UAM activities are slight abstractions the BPMN concept. Activities are abstracted and related to roles and resources (and possibly other activities or sub-activities), and they also explicitly define interfaces, and the set of processes and tasks (services or responsibilities) they provide. This use of an abstraction of activity goes hand-in-hand with using 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 process model is a convenient way to deal with complexity. Start with a top-level of activities, which are typically the leaf activities of the Business Process Model and are abstractions of all the system's activities, with the next (logical) layer of detail shown using more detailed diagrams. More diagrams can be used as well if the size and complexity warrants more layers. As with the Logical Entity Model a switch from layering to deal with complexity, to using partitioning will be needed at the lowest levels of detail in the Logical Process Model.

Computational Aspects

In Guideline: Business Process Model business activities were described, including a view of them as components along with other aspects such as their relationship to roles and actors and how structuring helps—all very much focused on business-level considerations. Now we need to add more detail to the activities, and introduce computational aspects important to processes and tasks, namely:

• Storage - how storage services are used to support the activities
• Servers - how the tasks are to be structured into applications/services and logically deployed to servers
• Presentation - how presentation level services are structured to support various role interactions with the tasks, processes and sub-processes, and optionally how presentation level services are structured to support user interactions (namely, a (possible collection of) role performing an end-to-end business scenario)
• Messaging - inter-task and inter-application communications services (and associated management and control) that ties together individual tasks into a process or sub-process.

Note that even though computational aspects are added to the model, specific solutions are not specified at this point; technologies, such as the workflow middleware solution or database vendor, are specified in the Artifact: Technical Perspective.

Logical Processes

The example below shows the set of logical 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 Logical 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 but more likely at the Technical level.

Logical Activities Contain Actors and Resources

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

During the logical modeling effort, decisions made are:

• A role binding to activities;
• A human (or humans) is bound to a particular business actor;
• The activity and associated actor or role will be fulfilled by software and associated computational hardware (i.e. manual vs. automation decisions).

A single activity or small set of 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 activities can eventually be mapped to human resources, or to specific hardware or software systems. This abstraction helps keep the focus on the actors and interfaces of the activities and determine the necessary responsibilities without having to consider the (usually imperfect) real situation of a specific person or system.  

Structuring the Logical Process Model

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

• Make the activities and processes easier to understand;
• Reuse parts of workflows that are shared among many processes;
• Make the the 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 "system" being architected is a large and complex enterprise, 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 activity, you could define one, or several, detailed activities representing the same thing within the organization. For example, you could start with the primary actor, detail the results and services he or she is interested in, then develop a separate activity for each detailed area.

If you want to engineer your organization one 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 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

Understanding the fundamental capabilities of the COTS technologies that apply.

The role of the IT architect is important at this stage. They must share their knowledge of the generic capabilities of the technologies that could add value to the delivery of business services. The elaboration of an architectural vision provides a context and means for sharing this information. This vision must provide a common understanding of the role that each major technology component plays including any legacy systems, custom applications, and generic commercial technology products.  The vision must also address the generic means of communicating between these components (i.e., messaging, file drop, database level interface, etc.). With these general principles established and decided, the team preparing the Logical Process Models are then in a position to decide on the details of what components will be doing what as well as the dialogue needed between them and / or the data stores they need to share. 

What to automate?

Where there is a choice provided by the generic technology selections made, deciding whether to automate the delivery of a business service or task comes down to volumes. Automating the delivery of a business service that only has a handful of requests per year does not make any financial sense if you have to develop some custom application in order to do so. Similarly, if a rare exception in the business process requires the execution of a rarely performed task then consider simple options for the performance of this task. Often, rare exceptions can have complex rules that go with them; and therefore, automating them is not cost-effective.  These tasks can be put to a user for exception handling. For example, on most call center systems there are automated options that address 90% of the things that a customer will want to do and there is an option to speak to a clerk for the remaining requests. 

Redesigning the business to mesh with the new technology

Understanding the cost and impact of adapting the business is critical and this is where the as-is logical model and a mathematical representation of it comes into play. If there are various high-level architectural options being considered, then these tools will provide the means for measuring the overall business operational impact in terms of staffing, throughput, and service times. Obtaining an understanding of the demand for services under the new model is also important in this exercise. Group sessions with clients, client interviews, client surveys, and extrapolation from historical data are techniques that can be used to gather this kind of information. 

Once technology decisions are made, the original business process model may require changes. However, typically the business vision is based on some fundamental aspects of modern technology and if the business process modeling was based on a sound and stable vision without getting into too much detail then the business process model and business requirements could remain stable throughout a number of architectural tweaks. 

What is an activity at the Logical level?

An activity at the Logical level has a specific types (i.e., call activity, collapsed subprocess, task, transaction) and tasks have specific types (i.e., user, manual, service, business rule task, etc.).  A Logical Process Model must encapsulate the functionality of the system being architected. Layering is important for hiding complexity as more detail is required at the Logical level than at the Business level.  

What is a task at the Logical level?

A task is typically performed by a single person or a single system and has a single purpose. If performed by a person, then the task represents a single multi-functional user interface. The task may encapsulate many steps taken by the user on the user interface. A "service task" is functionally cohesive, fully automated and is performed by a single system component. 

How do business rules fit in?

At the Logical level, the business rules must be expressed in a more structured format to ensure completeness, accuracy and ease of maintenance. Other types of rules will come into play, but the ‘true’ business rules should continue to be expressed and managed independently. Decision tables are recommended at this level for business rules, gateway logic, and other processing rules. This will ease maintenance of the system considerably. At this level, all of the rules must be attached to an activity by reference to the decision table in the activity description. Isolating the business rules in separate activities (multiple rules invoked in one activity is fine) can assist in their visibility for those maintaining a process model. In addition, expressing other kinds of processing logic in decision tables can aid in the maintainability. Often processing rules are the outcome of business rules. For example, suppose that a company has a business rule that only service agreement holders are offered certain promotions. As a consequence of this business rule they might be directed to a specific type of agent when they call, a processing rule that occurs at a specific point in time. Once in place, executable decision tables should be maintainable by business analysts and need not require programmer intervention. References:  Ronald Ross books.

How do functional requirements fit it?

The functional requirements can be placed within the context of the activities and tasks within the Logical Process Model, bearing in mind that the complete description of functionality of the system is not necessarily an architecture effort. Details of message formats, user interface functionality, report contents and formats, etc. are left to detailed design. 

BPMN usage at the Logical level

The set of modeling elements for the process aspect, and all other Logical level viewpoints, are defined in the Logical Perspective Language. Even at this level do not get carried away with the notation. The important elements are the task types and the judicious use of lanes and pools. If lanes make it too complicated to portray the model clearly, then avoid them and include the ‘component name’ in the activity description template. If there is messaging between components, then place the components in separate pools to portray the messages going back and forth. If the components are integrated through a database, then lanes can be used to represent the components. 

Characteristics of a Good Logical Process Model

• Activities are all defined, including end-to-end business scenarios.
• The activity structure is defined and agreed, with the architecture of the process, sub-process and tasks supporting flexibility and adaptability (to changing business needs and priorities).
• The relationship to and usage of logical entities by processes and tasks is defined. 
• The inevitable complexity of processes and tasks at the enterprise level is managed by:
  • Defining a few high-level activities, with drill-down to lower level detail;
  • Limiting process detail to 3 or 4 levels of drill-down; 
  • Use visual models and visual cues (color, etc.) to organize the model and make it comprehensible;
  • Small use cases are often easy to understand. However, make sure that they describe a complete workflow that produces something of value for a customer.
• Each activity, process, sub-process and task must be unique. If there are similarities, consider merging them.
• Security aspects have been identified and solutions modeled.
• Important computation aspects have been included (i.e. storage).

References 

Many references exist for doing logical process modeling. Included here is a tutorial and reference for OMG's BPMN standard, which this method subscribes to:

• Whitepaper: BPMN - an Introductory Tutorial
• Whitepaper: BPMN - the standard