Objective
Business process modeling may be first and foremost about business context and opportunities, yet half of the benefits still depend on mapping with supporting systems; that can be better achieved through enterprise architecture.
On that account, modeling languages like BPMN suffer from their lack of abstraction, which entails:
- A flat level of description within which a hotchpotch of information has to be squeezed, with every extension inducing exponential increase of complexity and ambiguities.
- No conceptual distinction between the semantics of business domains and enterprise architecture.
Hence the ill-defined overlaps between business models, systems functional architectures, domain specific processes, and supporting applications.
These flaws can be mended by factoring out a semantic backbone anchoring business processes to enterprise architecture, leaving the details of business processes to be described with BPMN specifics. The focus here is on the semantics of architecture concepts, not be confused with (yet possibly complemented by) attempts to build bridges between modeling languages (see e.g Y.Wautelet and S.Poelmans).
Business Processes & Enterprise Architecture
Contrary to requirements capture directed at supporting systems, business processes modeling is meant to be driven, at least in their inception, by business objectives. Business Process Model Notation (BPMN), if not being universally adopted, can be used as representative of the approach and challenges:
- On the business side the difficulty is to specify activities and rules without coercing business analysts into the complexity of a pseudo programming language. That is to be difficult without a clear distinction between architecture concepts and business logic.
- With regard to supporting systems, the mix of enterprise architecture and business concerns hampers the distinction between shared business functions (ideally supported through service oriented architectures), and domain specific applications (typically developed from users’ stories).
Most of these difficulties could be tackled by introducing an enterprise architecture level in BPMN focused on the modeling of organization and shared objects and processes on one side, architecture capabilities on the other side.
The question is then to decide what is relevant at architecture level and what can be relegated to applications or designs levels.
Anchoring Processes to Architectures
Business process modeling comes with some conflicting aims as it tries to shadow changing business opportunities while making the most of steady enterprise organization and systems (aka enterprise architecture). That dilemma can only be solved through a steadfast anchoring of business concerns to supporting systems; for that purpose one needs to define a core of stable yet versatile categories relevant at architecture level:
- Actual containers represent address spaces or time frames; symbolic ones represent authorities governing symbolic representations. System are actual realizations of symbolic containers managing symbolic artifacts.
- Actual objects (passive or active) have physical identities; symbolic objects have social identities; messages are symbolic objects identified within communications. Power-types (²) are used to partition objects.
- Roles (aka actors) are parts played by active entities (people, devices, or other systems) in activities (BPM), or, if it’s the case, when interacting with systems (UML’s actors). Not to be confounded with agents meant to be identified independently of their behavior.
- Events are changes in the state of business objects, processes, or expectations.
- Activities are symbolic descriptions of operations and flows (data and control) independently of supporting systems; execution states (aka modes) are operational descriptions of activities with regard to processes’ control and execution. Power-types (²) are used to partition execution paths.
Some of these categories are not explicitly defined by BPMN:
- Containers for physical (locations) and logical (domains) objects.
- Objects, with the ensuing confusion with regard to active objects and physical flows.
Given their clarity of purpose and semantics, adding these concepts should be straightforward. Others are already defined, if with blurred or too detailed semantics.
Blurred Semantics
Since BPMN is meant to describe the different aspects of processes, analysts have to be clear about their intentions.
To begin with connectors, there are four and only four possibilities: references to objects, communication channels, state transitions, or flows (data or control) between activities. With anchors unambiguously defined, built-in consistency checks could be employed to clarify meanings (e.g preventing references between activities instead of flows).
The same policy could be generalized:
- Events are detailed but BPMN obfuscates the critical (with regard to systems architecture) distinction between external (actual, business) and internal (symbolic, system) events.
- Swimlanes and pool tally with organization and roles (aka actors), but with confusing (with regard to enterprise architecture) overlaps.
- Tasks, transactions, and sub-processes should be refined as to separate business logic from processes execution.
- Gateways’ definition mix semantics (event-based or not) and syntax (parallel, inclusive, exclusive, etc.)
- Data stores tally with symbolic entities but overlook the distinction between transient (process space and time-frame) and persistent (system space and time-frame) representations.
Assuming that models semantics differ for business analysis (extensional, descriptive) and software design (intensional, prescriptive), the objective is to set apart some commons to be shared at enterprise architecture level, leaving specifics hided under business and system hoods to be managed with whatever tool as befits (e.g BPMN for processes or UML for systems). A basic standard syntax could also be introduced to ease the frictions between enterprise architecture and the specifics of business applications and systems designs, as well as between both kinds of specifics.
Under the Hood: Architecture Semantics & Designs Syntax
Anchors shared at enterprise architecture level are to be fleshed out with specific details. That will depend on methods and tools, some specific (e.g BPMN or Petri nets), others directly targeting systems with domain specific language (DSL). In any case a standardized syntax may serve as a glue between EA, business, and systems semantics:
- Anchors (#): instances (objects or activities) directly and consistently identified across businesses and system.
- Collections (*): set of individuals with shared features.
- Features: attributes or operations without identity of their own.
- Structures (diamond): composition (black) for individual components (objects or activities) whose life-cycle is bound to their owner, i.e they have no identity of their own; aggregation (white) for components identified independently but used in the context of their owner.
- Connectors: associate individuals; their semantics is set by context: communication channel, reference, data or control flow, transition. They can bear identification (#).
- Power-types (2): define subsets of individuals objects or activities. Depending on context and modeling language, power-types correspond to classifications, extension points, gateways, branches, joins, etc.
- Inheritance (triangle): contrary to structure and functional connectors that deal with instances, inheritance connectors are used to describe relationships between descriptors. Strong inheritance (black) is the counterpart of composition and points to structural features, weak inheritance (white) the counterpart of aggregation and points to functional features.
On that basis the objective is to refine and consolidate the semantics of BPMN concepts relevant at enterprise architecture level.
Activities
BPMN defines task as a “single unit of work not to be broken down to a further level of detail”, without further detail; given the dearth of specifics there is room for some principled distinction between the logical definition of tasks and the way they are to be carried out by business processes. For that purpose one can reformulate Aristotle’s rule for three unities:
Unity of action: execution units should have one main action triggered by a single event initiated by a single primary actor. Subplots, if any, may summon the collaboration of secondary actors but they must return to the main plot after completion. Otherwise system architects would be kept in ignorance regarding possible execution dependencies.
Unity of place: execution units should be located into a single physical space where all resources can be obtained directly, and should not depend on activities from other locations. That is a necessity if functional architectures are to be managed independently of technical ones.
Unity of time: execution units should be timed by a single clock under which accesses to all resources can be synchronized, i.e it should not depend on events timed by other clocks. That is a necessity if innards and synchronization of business processes are to be managed independently of choreography and orchestrations supported by communication architectures.
Not surprisingly, these formal criteria can be mapped to functional (unity of action) and execution (unity of place and time) dependencies, which together constitute the basic architecture bearings.
Along that EA perspective, activities should be stereotyped depending on execution constraints (center red or white) and footprint (context):
Refining tasks’ action semantics should not affect notation for multiple instances.
Organization
BPMN Pools are best understood as logical containers for roles (aka actors in UML parlance), with lanes representing participants in collaborations; as such they epitomize the logical fence between enterprise architecture and supporting systems.
Yet to fully serve that purpose the semantics of pool and lane have to be exclusive, the former applied to organizations, the latter to roles; the reason being that organizations cannot fulfill roles like agents, in particular they cannot generate events directly: actual responsibilities must pass through individuals. That principle should govern the definition of interfaces between organizations and supporting systems, more so with the crumbling of traditional fences between enterprises and their business environment under the spreading of smart systems and digital flows.
Considering the pivotal position of organization and roles between business processes and systems, lanes should be stereotyped along the same EA perspective and so be aligned with stereotyped activities:
Flows represent exchanges between tasks (and therefore lanes) and as such are associated to contents (with regard to tasks) and communication channels (with regard to lanes). They are used to define how activities are to be performed taking into account functional and execution dependencies:
- BPMN message flows correspond to functional dependencies; they stem from business logic and the contents to be processed and can therefore be defined independently of processes’ execution context. they may (a) or may not (b) be bounded to identified entities.
- BPMN sequence flows correspond to execution dependencies; they may (d) or may not (c) be bounded to a time-frame.
It must be reminded that BPMN flows mix explicit flows with implicit events, as can be seen when translated into UML activity and state diagrams:
- Message (a,b) and sequence (c,d) flows correspond respectively to UML data and control flows.
- Events corresponding to asynchronous (a,c) and synchronous (d) communications appear on UML transitions, possibly with attached messages.
Insofar as architecture is concerned these distinctions are critical if business logic is to be managed independently of business channels and operational environments. Moreover, the focus put on flows’ action semantics facilitates consistency checks on one hand (e.g flows from devices combine control and data), and feasibility checks on systems capabilities (e.g communication channel between CCTV and operator).
Lanes and flows can then be combined or refined using standard logic operators for composition, aggregation, and specialization used for events.
Collaborations
BPMN uses conversations and choreographies to model collaborations. Simple conversations can be associated to duplex flows and stereotyped like messages (d), with multiples ones (aka forums) best understood as passive communication choreographies. Choreographies, being collaborative tasks involving multiple participants, are best defined in dedicated lanes using logical operators:
- Composite lane: a collection of devices and a controlling system (a).
- Collective lane: a set of users with identical roles (b).
- Aggregate lane: a set of agents with specific roles (c).
Whereas the details of collaborations are meant to be hided at EA level, applying standard logic operators for composition, aggregation, and specialization is to enhance transparency and enable direct consistency checks, e.g:
- Differentiated actors for differentiated tasks (c/e).
- Shared execution context (f) for strong collaboration (a), compared to interchangeable actors (b).
And as already noted, collaborations should make explicit the distinction between tasks’ logic (white center) and execution (red center).
Events & Time
BPMN defines events as something that happens, compared with an activity, which is something that is done. That’s much too vague and even inconsistent because activities carried out instantly can legitimately be modeled as events. As a corollary, adding complexity to balance vagueness, a medley of stereotypes is introduced to rally events’ differences.
Insofar as architectures are concerned, in particular with networked and digital business environments, events are what hold architectures together. So, if systems’ behaviors are to be properly modeled, events must be understood as changes in the state of agents (people, systems, devices) or activities identified at architecture level and characterized by:
- Nature of change: state of devices, systems, activities, or actors’ expectations.
- Action semantics: start, end, or interruption of tasks, send or receive of messages, timing, etc.
On that basis events can be stereotyped providing the semantics remain congruent with the distinction between logic and execution, which entails that a clear distinction is to be maintained between events as observed changes and the associated information, e.g.
- Messages (including from timers): information only, entail no change or synchronization.
- Signals: no information, initiate some synchronization, defined independently of diffusion mechanisms.
- Errors: cannot be defined independently of associated information. Exceptions could be used instead.
- Conditional: can be understood as a request or the induced operation.
Like stereotyped roles and the static view of EA, stereotyped events could facilitate the mapping of processes to dynamic EA capabilities.
Moreover, when combined with roles, activities, and gateways , these stereotypes will enhance processes’ semantic traceability and consistency.
Decision-making: Gateways
Since gateways define how activities are governed, their visibility at architecture level should focus on the ways decisions are made. On that account, decision-making being a key function of enterprise architecture, gateways must clearly separate what belongs to governance from the specifics of computation or execution.
As rules, gateways are best defined by their domains (left side) and co-domains (right side); and since the objective is to factor out decision-making concerns, the corresponding semantics should refer respectively to decisions’ footprint and purpose:
- Footprints refer to gateways’ drive: functional ones are driven by the contents of data flows (IF data THEN _), execution ones by events (WHEN event DO _).
- Purposes refer to gateways’ impact: logical (aka computational) gateways define sequencing constraints on activities (whit center) independently of their actual execution (red center).
While actual execution is usually set across footprints and purposes, there are clear architecture benefits in managing business logic independently, which means factoring out data-driven gateways whenever possible. These “pure” computation rules are meant to be neutral with regard to architecture and therefore hided from EA.
That’s not the case for gateways also conditioned by execution circumstances involving events or lanes, which may or may not entail architecture footprints:
- Events: architecture capabilities may affect execution constraints, e.g for communications.
- Lanes: organization may affect execution depending on the actors executing the tasks, e.g for authorizations and responsibilities.
For gateways mixing criteria the challenge would be to maintain a semantic consistency between activities, events, and gateways; hence the benefits of stereotypes and standard operators:
- Event-driven gateways have to be fed by actual task execution (a).
- Interruptions have to follow event-driven gateways (b).
- Data-driven gateways have to be fed by symbolic descriptions (c) .
- Decisions have to follow tasks involving people, in descriptions (d) or execution (b).
Traceability and consistency of decision-making at EA level may become a central issue as the ubiquity of digital flows and smart systems blurs responsibilities and curtails processes’ transparency.
Data, Information, Knowledge
Strictly speaking, BPMN only considers the information flowing through processes, overlooking the problem of business entities shared across processes, i.e information architecture.
At process level sequence and data flows are to be explicitly associated to, respectively, control and data objects. Distinctions should be added for data values (data non directly bound to identified entity) and real time control objects.
Conclusion
Factoring out enterprise architecture backbone of processes and stereotyping concepts accordingly would position BPMN at a modeling crossroad between business, organization and systems.
Moreover, stereotyped BPMN models could also be distilled as to coincide with UML’s activity and state diagrams, which would significantly enhance their traceability with software engineering
Further Reading
- Modeling Paradigm
- Capabilities & Feasibility
- Focus: Business Processes & Abstraction
- Focus: Business Cases for Use Cases
- Modeling Languages: Differences Matter
- How to choose Frameworks & Methods
- Languages and Models
- EA: Maps & Territories
- EA: Work Units & Workflows
- Focus: Business Analyst Booklet
- Focus: Enterprise Architect Booklet
- Ontologies & Enterprise Architecture
External Links
- BPMN Process Model – Descriptive, Analytic (Operational) to Executable
- Yves Wautelet and Stephan Poelmans, “An Integrated Enterprise Modeling Framework Using the RUP/UML Business Use-Case Model and BPMN”
- Russell N., Workflow Patterns: The Definitive Guide”, MIT Press (2016)