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 Technical Process Model therefore defines all of the activities of the system at the Technical 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 Logical Process Model and are abstractions of all the system's activities, with the next (technical) 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 Technical Entity Model a switch from layering to deal with complexity, to using partitioning will be needed at the lowest levels of detail in the Technical Process Model.

Technical Aspects

In Guideline: Logical Process Model 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 logical-level considerations. Now we need to add more detail to the activities, and introduce specific technical aspects important to workflow processes and tasks, namely:

• Storage Technology - storage service solution technology standards are defined; 
• Server Technology - server technology standards are defined, and how the tasks are to be structured into applications/services and logically deployed to servers;
• Presentation Technology - presentation level service standards and patterns are defined in support of role interactions with the tasks, processes and sub-processes. Optionally how presentation level service solution support user interactions (namely, a possible collection of roles), the execution of an end-to-end business scenario;
• Messaging Technology - specification of the workflow technology and standards that bring it all together.

The Technical Process Model is used, within the enterprise architecture context, to either specify technical patterns for the enterprise, or (if the scope, scale and resources are appropriate for the system being architected) to document an implementation level view of the system. Both may be described, if desired and appropriate, as well. These patterns may be generic, such as 'n-tier' or 'client server'. They may also be specific in terms of technologies and where and how to use them, such as 'IBM SAA ImagePlus IBM FlowMark' with configuration 'xyz'. These standards may be shown in this model, however they must be documented in Architectural Decisions.

Complexity is dealt with through partitioning of the model, based upon either location considerations or technology solutions. A combination may work as well.

Key to the technical view is the deployment locations model, which is used to show how processes and the required supporting infrastructure are organized and deployed throughout the enterprise. In other words, some process model aspects may be shown to best advantage in the locations model. Technical choices, the enterprise technical standards, and how they are used/deployed are also shown. Add links to these locations diagrams from the technical process model diagrams.

Technical Processes

The example below shows the set of Technical 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 Technical 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.

Technical 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 business 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 technical modeling effort, decisions made are:

• A role binding to activities;
• Roles are re-factored in order to simplify and address RBAC requirements; 
• 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 Technical Process Model

There are three main reasons for structuring the Technical 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 very 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 Technical 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 Technical level?

An activity at the Technical 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 Technical Process Model must encapsulate the functionality of the system being architected. Layering is important for hiding complexity as more detail is required at the Technical level than at the Business and Logical levels.  

What is a task at the Technical level?

A task is typically performed by a single person or a single system and has a single purpose (i.e., it is an atomic activity). 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 Technical 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 Technical 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 Technical level

The set of modeling elements for the process aspect, and all other Technical level viewpoints, are defined in the Technical 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 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 (see: Concept: Complex IT Architectures).
  • 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 the use case describes 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.

References 

Many references exist for doing 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