BPMN Diagrams – Digging Artifacts

Artifacts are more than business detritus. Documents are created in business processes that represent actionable information. See how to represent these useful artifacts in business process modeling notation.

Background

We presented an introduction to BPMN diagrams two weeks ago. Business analysts are often required to document as-is processes and to-be processes. These diagrams help identify the scope of a software project. The diagrams can also help uncover requirements that might be overlooked without diagramming the processes.

The BPMN specification is designed to establish a common language and convention for creating process diagrams. This common convention allows people who are familiar with modeling, but new to a project to avoid learning a new diagramming language on each project or for each client. We have a link to the official version of the spec in our introductory post (we will update that link if and when the spec changes).

More Than A Flow

Most of business process modeling is modeling the flow of events, and the messages between organizations. Artifacts allow us to express more than just a flow. Artifacts allow us to show information or objects that are passed along through the process with the flow. Artifacts are also referred to as data objects in the BPMN official spec, but since they can represent physical objects as well as electronic documents, it is easier to just refer to them as artifacts.

An artifact is drawn as a document as shown above. The name of the artifact is included below the document icon, and the status is shown in square brackets.

Note that artifacts are not required for BPMN diagrams. They can make the diagrams much easier to read, however, and should be included whenever it improves the clarity of the diagram.

Sequence Flow Artifact Example

Artifacts can be passed through a process, changing state along the way. We can show this by attaching an artifact to a sequence flow between activities.

In this BPMN example, the artifact (an Application) is passed along the sequence flow between three tasks. This application shows a simple hiring process for an employer. Someone screens applicants, then passes the applications along for approval. Once the application has been approved, the applicant is hired. In this business process, the application is passed along as an “attachment” to the sequence flow between each task.

This approach to attaching artifacts to flows makes for a very clean diagram. It is very easy to see that the application is “passed” as data from task to task.

Message Flow Artifact Example

Messages between activities also represent a type of process flow. The BPMN spec uses the term message flow to differentiate messages from sequences (referred to as sequence flows). We can expand our example to include the process from the perspective of the applicant as well as the employer.

In this business process modeling example, we show two pools that represent the worker and the employer. The employer’s process is identical to the previous example, and the artifacts are attached exactly as before (to the sequence flows). The messages sent between the worker and the employer now have artifacts associated with them. The first is a submitted (but not yet screened) application. The second is a submitted job offer.

Attaching artifacts to message flow provides clarity in the diagram much like the sequence flow attachment.

A Supported Alternative

There is an alternative way to represent artifacts – attaching them to activities. In our previous examples, the application artifact “changes state” within the “Approve Application” task. This was demonstrated by the change in state of the artifact between the sequence flows that enter and exit the task. This could also be shown by attaching artifacts to the task itself.

When we attach the artifacts directly to tasks, we have to include the directional arrows that indicate if the artifact is being sent “into” the task, or coming “out of” the task. As this diagram shows, the application enters the task in a “Screened” state, and exits in an “Approved” state.

This approach is valid for the BPMN spec, but we don’t reccommend it, because it is limited. What if the task were “Evaluate Application” instead of “Approve Application?” We could have the application as an artifact output of the task in either of two states – Approved or Rejected. How would we draw it? It would be easier to understand the process if a gateway were used to direct the process flow after the evaluation, with artifacts attached to the output flows of the gateway.

One thing that is important – whichever approach you choose, be consistent. We believe that attaching artifacts to flows is the better approach, because it handles more situations with clarity.

Summary

Artifacts are important to business processes. Including them in BPMN diagrams can improve the communication process by putting the needed artifacts in center stage. When we include artifacts, we have choices about how to include them. We should be consistent in using the same approach in all of our diagramming. Attaching artifacts to flows provides more clarity than attaching them to tasks.