The Simulation Summit

At 8,848 m (29,029 ft), Mount Everest is the highest point on earth. Once simply knownas "Peak 15", the mountain was named after Sir George Everest in 1865 ,the onceBritish surveyor-general of India. In 1953, the New Zealander Edmund Hillary and TenzigNorgay of Nepal became the first to ascent to the top of the world. Since then, therehave been 4,102 ascents, and Everest has claimed 216 lives.

Mount Everest also sits on the border between China and Nepal. Most people climbingEverest follow the southeast ridge from Nepal. It is technically easier, and is in fact theroute that was used by Hillary and Norgay. However, this route was dictated more bypolitics than by design as the Chinese border was closed to the western world in the1950's. It turns out that Everest can also be climbed along the northeast ridge fromChina. In fact, since there has been access to the Chinese side, many ascents start fromthere.

This provides a decent metaphor for business process simulation. The ascent to thiscapability has typically been made by business process management suite (BPMS)vendors wishing to satisfy the criteria of Gartner's "Magic Quadrant" for BPM suiteswhich includes the following requirement:

Process simulation and optimization using real-time, historical and estimateddata values.1

A Fake FeatureIn attempting to provide simulation functionality, it would appear that most BPMS andBPMN process modeling tool vendors have taken the apparently logical (or perhapstechnically convenient) route of starting from an existing BPMN process model editor andadding on simulation features. The result is often a simulation capability of limited value,to the point where BPM commentator Bruce Silver describes simulation provided by BPMvendors as a fake feature2.

Bruce goes on to articulate some of the criteria under which simulation could beconsidered a real feature of BPMN process modeling software. According to Bruce, BPMNtools with simulation capabilities support the following to varying degrees, but noneappear to support a critical mass of what I will call the Silver Criteria3:

Activity Duration

Actual activity duration consists of the actual time spent processing an item of work atan activity (the "active time") and the time an item of work waits (the "lag time") at anactivity before being processed due to a queue of waiting work, limited processing

1. Magic Quadrant for Business Process Management Suite, 2007. Gartner CoreResearch.2. See Is Simulation Fake? by Bruce Silver, BPMS Watch (http://www.brsilver.com/wordpress/2007/03/08/is-simulation-fake/)3. This list has been compiled based on various posts in Bruce Silver's BPMS Watch. Forexample, see http://www.brsilver.com/wordpress/2007/03/08/is-simulation-fake/ and http://www.brsilver.com/wordpress/2009/02/15/making-simulation-useful/

capacity at an activity (e.g. a physical constraint) or the required processing resourcesbeing unavailable. The ability to both model and report on both of these components ofthe activity's total duration is a real world requirement, often ignored by manysimulation tools.

Events

Simulation needs to model event probability and time of occurrence. In BPMN, eventsprovide a visual representation for describing the exceptions that occur in real lifeprocesses. Such exceptions are often the root of performance issues in existingprocesses. To accurately model what-if scenarios, the ability to assign a probability andmean time of occurrence for events defined in the process model is a requirement. Mostsimulation tools simply ignore events.

Iterative Activities

BPMN supports two types of repeating activities: looping and multi-instance thatrepresent feedback based on a condition or size/components of the item of work.Simulation must model the number of iterations based on a parameter or property of thework being processed.

Instance Attributes

In most simulation tools, probabilities assigned at various nodes (e.g. activities orgateways) are uncorrelated. In actuality, these probabilities are usually highly correlatedin real world business processes. Specifically, the duration of a particular activity, theprobability of a particular gateway output, and/or the probability of some eventoccurring are often related to each other. For example, the longer an activity takes (e.g.scanning documents), the more likely an exceptional event might occur (e.g. a jam).One needs to be able to specify simulation parameters as an expression of one or more

instance attributes, such as "size" or "claim value", which could take specific valuesrather than simple numbers like an absolute value or a mean and standard deviation.While this makes defining a scenario to simulation more complex, it stands to providemore realistic output.

Schedules & Resource Contention

In business processes, an activity will only be executed when work and resources areavailable for the activity in question. The availability of specific resources, whetherhuman, machine or otherwise, is driven by their schedules and contention for equivalentresources by other activities. Simulation software should accurately model resourcecontention and allow detailed schedules to be defined for all resources which show whenthey are available to work in specific roles, or specific sets of activities.

Contingent Resource Assignment

Most simulation tools let you assign roles to activities. However, business processes areoften characterized by contingent resource assignment. For example, an activity mayassign Role A as the primary resource, but if no member of Role A is available, theactivity may pull a resource from Role B.

Priorities

It should be possible to base resource acquisition at various steps in a process based onpriorities, or some kind of priority logic. For example, oldest item in the pipeline getsworked on first, of items get worked on based on an attribute of the work items. Prioritycould be based on activity or an attribute of the items to be processed.

Pre-Population of Work in Progress

Simulation models generally start empty, reflecting no work present initially in thesystem. This causes a distortion in the simulation results at the beginning of thesimulation period. Continuous processes are always in a state where resources arealready constrained by the work in progress. One method to address this situation iswith a warm up period where results are not collected until the system is "loaded" withwork. However, populating the simulation model with work in progress at the variousactivities at the beginning of the simulation period best reflects reality.

Detailed Reporting & Data Access

Simulation results should provide breakdown of metrics at the process, activity, resourceand potentially work attribute level. Resource utilization and excess capacity should bereported for any given period. There should also be access to the raw simulation output.Pre-built metrics and charts provided by simulation tools are convenient but they rarelyprovide the detail you need for real analysis. One should be able to access records foreach process instance, and for each activity or event instance. It should be possible toimport this data into a spreadsheet or a database.

Serious Simulation

Just like climbing Everest from the northeast ridge, there is another approach tobusiness process simulation. One starts on the other side: from the domain of serious,robust simulation software that satisfies the "Silver" criteria a priori and then build insupport for authoring these simulations using BPMN process models.

This approach is similar to what Meta Software did in 1989. Meta developed a capabilityto generate simulation models for their pre-existing industrial simulation software fromIDEF0/SADT process models4. IDEF0 is a graphical modeling notation that provides thesyntax and semantics to diagram the decisions, actions, and activities of an organizationor system. A common application of IDEF0 was to document business processes, in thesame way that BPMN is used today. In 1989 IDEF0 was a promising emerging standardfor drawing business process diagrams. Perhaps, if this work had been done today, Metawould have chosen BPMN as the process modeling methodology.

We can look to Meta's experience in developing IDEF0/SADT support for authoringsimulation models to understand how robust BPMN based simulation models that satisfythe Silver Criteria can be made possible. The lessons learned in providing a way togenerate business process simulations from IDEF0 business process models can easily beapplied to BPMN5. There are two significant considerations that have to be made whenexposing simulation through a process model diagram:

• There must be a generalized mapping of process diagram work flow patterns tothe underlying simulation code.

• Process models must be extended to include the specific assumptions that definea scenario.

4. See: Modeling an NORAD Command Post Using SADT and Colored Petri Nets byValerio Pinci and Robert Shapiro.5. In fact, this has been done. Meta Software's METAFORE supports simulation ofprocess models defined in BPMN via an XPDL interface.

Process Definition

Process model diagrams will support varying numbers of work flow patterns such assequential flows, exclusive gates, parallel processing, matching, etc. The work flowpatterns supported by the diagramming methodology have to be mapped to simulationcode in a generalized way. This usually results in code that is parameterized to reflectthe basic work flow pattern, yet support variation and correlation amongst the variousprocess instances (e.g. tokens of work) which will be populated into the simulationmodel.

Scenario Definition

Secondly, the parameters and placeholders in the resulting simulation code have tospecified for each specific process instance. Common resources used to performactivities in the process model need to be specified so that semaphores in the simulationcode constrain the availability of these resources to reflect schedules and resourcecontention. These constitute a set of business process assumptions built into a givenscenario, and these parameters have a definite business sense, representing items thatwould not be foreign to the average business user.

For example, we need to know when and where items of work will enter or "arrive" inthe process. To specify this, we need to capture the following types of data:

• The process the work item will arrive in.• The destination activity. This is usually the model start or input point, but may

be any process activity when we are trying to simulate work in progress at thebeginning of the simulation period.

• Arrival times.• Quantity if more than one unit of work item is arriving at this particular time with

the same attributes.• Data field values. These represent the properties of the work item (process

instance) arriving into the process.

A Standards Based API for Simulation

Assuming that a mapping between process diagram work flow patterns and simulationcode exists, what we find is that a simulation model can be defined by a process diagramand a complete set of scenario parameters. Critically, if the process diagram and thescenario parameters are both specified using a standard, we have a vendor neutral,standards based API for simulation.

While there has been considerable effort in standardizing process diagrams (e.g. BPMN),there has been little to no effort in standardizing the scenario parameters describedabove. The Scenario Definition Language is an attempt to standardize scenarioparameters. For example, the Scenario Definition Language describes the followingformat for process instances:

SchemaItem

Representation(XPath) Notes

Arrival ID //arrivals/arrival/@id A unique identifier for the arrival.

ProcessName

//arrivals/arrival/process

The work flow process name or id (e.g.as defined in the process model).

Data Source //arrivals/arrival/datasource

Specifies the source system or scenariofor the arrivals.

DestinationActivity //arrivals/arrival/activity

The activity in the process where thearrival takes place. Arrivals may occur atactivities other than the start of aprocess to represent the work inprogress at the start date/time of thescenario. In general, this is a referenceto an activity in the process model.

Arrival Time //arrivals/arrival/arrivalTime

The date and time at which the arrivalinto the process takes place.

Occurrences //arrivals/arrival/occurrences

How many times the arrival occurs. Thiscould be a statistical distribution.

Frequency //arrivals/arrival/frequency

The time between occurrences. Thiscould be a statistical distribution.

Quantity //arrivals/arrival/quantity

Allows multiple arrivals of entities withthe same attributes to occur at thearrival time. This could be a statisticaldistribution.

Field Values //arrivals/arrival/fieldValues Data field values for the arrival

See the complete Scenario Definition Language specification for a complete descriptionof this business process scenario schema. Given support for a standards based API,exposing the API via web services makes vendor neutral simulation as a service possible.Simply imagine http://www.mysimulationservice.com/myscenario/arrivals.xmlreturning a list of arrivals defined according to the Scenario Definition Languagedescribed above.

BPMN Necessarily But Not Necessarily BPMN

One last item worth discussion is the loose coupling between the process modelingstandard and the proposed Scenario Definition Language (SDL). While elements in theSDL schema will reference items in the BPMN diagram, SDL remains separate fromBPMN. The path of not extending BPMN to support simulation directly is chosen onpurpose. BPMN is used for many applications besides simulation, and benefits from aprocess centric purity. By only loosely coupling SDL to BPMN, the two standards used forsimulation can evolve separately. SDL can survive a change to a new modeling notationstandard and vice versa for BPMN.

Secondly, there are other consumers of the scenario parameters defined in SDL thatmay not require a process model, or even use simulation for that matter. For example,activity based costing, and workforce management for simple processes.