In the previous posts, we illustrated how business architects can model dynamic value streams using outcomes as entry and exit criteria for value stream stages. We demonstrated using capabilities and touchpoints to unpack value stream stages to reveal the important states of the business that happen within each value stream stage. To accomplish this, we extended the notion of preconditions and postconditions to capabilities (“needs” and “produces”) and touchpoints (“experiences” and “triggers”). These extensions, provided by the BACM metamodel, allow the business architect to create flow models that describe sequential flows, branches and loops.

In this post, we tackle the representation of parallel flows and synchronization. But first, we want to resolve an issue leftover from the first post – how to connect the “Ensure Permission” stage to the “Depart” stage.

Individual and Group Activities

In the previous post, the “Plan a Trip” and “Ensure Permission” stages were unpacked to show activities (capabilities and touchpoints) and intermediate states (outcomes) that describe what happens in these two stages. In the transition from “Ensure Permission” to “Depart” – a stage that covers the preparation of the conveyor, the boarding of passengers, and the assumption of control of the conveyor by the conveyor crew – the traveler becomes part of a group (“passengers”) that have some identical experiences (e.g. being transported from an origin to a destination) and have some individual experiences (e.g. having a comfortable or uncomfortable seat). For this example, we model this aggregation of travelers as occurring at the check-in activity where the traveler presents a valid ticket and indicates that he or she is present and prepared to travel¹. A potential model for this is shown below:

The “checkin activation” capability accepts each traveler’s ticket and signal of intent to travel and updates a passenger list for each segment of travel. At a certain time prior to the segment’s departure, these updates are deemed complete and the “boarding ready” outcome is produced by the capability. This outcome describes the state of the “passengers” as a group that contains the traveler.

The “boarding ready” outcome alone is not sufficient to enter the “Depart” stage as the conveyor must also be present at the departure terminal. The “depart ready” outcome that is the entry criteria for “Depart” requires the conjunction of “boarding ready” and “conveyor arrived”. Conjunction means that for some period of time, all outcomes in the conjunction must be valid conditions on the states of the associated business objects. In the real world, several other conditions would need to be met: conveyor crew present and prepared for duty, gate crew present and prepared for duty, conveyor provisioning prepared for duty, … . In the interest of clarity, we have omitted such details from the example.

Business objects whose state is affected

Adding the relevant business objects to the previous diagram yields the following:

In this diagram of added business objects, an “in” relation (whose type is “ObjectRelation”) links the traveler to the “passengers”, and the “of”² (ObjectRelation) links “passengers” to the “conveyor segment” (ObjectRelation). The “conveyor segment” is defined by an origin and a destination “travel port” so it is an ordered relationship from origin to destination. The “conveyor segment” is also a business object with an assigned conveyor (“has conveyor” object relation) and a group of passengers. The “passengers” of the “conveyor segment” are defined as the set of travelers whose “trip route” includes this “conveyor segment”.

The diagram does not show an outcome that establishes the “in” relation between the “Traveler” and the “passengers”. This outcome is produced by a sub-capability of “checkin activation” that is repeated for each traveler that checks in. We can model this internal behavior and will discuss modeling the behavior of capabilities in a later post. The “boarding ready” outcome represents the culmination of this repeated behavior when some subset of the booked passengers will have checked in.

Business object relationships can have state represented by outcomes

Note that a binary relationship in these diagrams is typically represented by a line between the source and the target. When a relationship is also the source or target of another relationship (e.g. “of”, “state of” and “has conveyor”) it is presented as a rounded capped rectangle (a node) whose label consists of the meta-relation name, two colons and the model relation name. The source and target of such a relationship can be identified by lines (arcs) whose labels contain the strings “from”, “to”, “src”, or “tgt”. If such a relationship is the source or target of another relationship represented as a rounded capped rectangle, it can be challenging to determine the sources and targets of each relationship visually, so the descriptions of each relationship should make it clear about the source and target of that relationship. This presentation configuration does not often occur.

The outcomes “boarding ready” and “conveyor arrived” both describe the state of “conveyor segment”, but they describe independent aspects of “conveyor segment”; “boarding ready” describes the state of the “passengers” of the “conveyor segment” and “conveyor arrived” describes the state of the conveyor associated with the “conveyor segment”, so there is no reason why these outcomes cannot simultaneously exist. This reasoning also applies to “boarding done” and “conveyor enroute”, ignoring for the moment whether “boarding done” must be valid prior to “conveyor enroute”.

However, “boarding ready” and “boarding done” are clearly contradictory, as is the case with “conveyor arrived” and “conveyor enroute”. Next, we will establish how “boarding ready” is flow related to “boarding done” and how “conveyor arrived is flow related to “conveyor enroute”. This will also illustrate how the “Depart” stage can be unpacked into parallel activities.

Parallel Activities

There are multiple activities triggered by the arrival of the conveyor: cargo and luggage must be offloaded and delivered to its next destination, the conveyor must be cleaned and provisioned, the conveyor must be inspected for safety and functionality prior to departure, the passengers must be checked against the manifest and be boarded. These activities are mostly independent of each other. The following diagram unpacks two of these activities: (1) cleaning and provisioning, followed by boarding; (2) conveyor inspection and control assumption.

Cleaning, provisioning and boarding the conveyor

The upper flow begins with the “conveyor arrived” outcome and produces the “conveyor ready board” outcome, meaning that the conveyor has been cleaned and provisioned (an action represented by the “clean-provision activation” capability). The boarding activity (“boarding activation” capability) begins when both “boarding ready” and “conveyor ready board” outcomes are valid, meaning that the passengers have all checked in (or the window for check-in has elapsed) and the conveyor has been cleaned and provisioned³.

Inspecting and taking control of the conveyor

The lower flow also begins with “conveyor arrived” and produces “conveyor inspection OK” (by way of the “conveyor inspection” capability). This capability may also produce an outcome that the conveyor is not OK to use, but that alternative is not shown in this diagram. Following “conveyor inspectionOK”, the conveyor crew takes operational control of the conveyor (“conveyor operation” capability). The resulting “conveyor enroute” outcome, in conjunction with the “boarding done” outcome satisfies the composite outcome “departed terminal” which is the exit criteria for the “Depart stage.

Synchronizing activities via outcome conjunction

An outcome may be needed by different capabilities to initiate parallel flows, these capabilities are assumed to be activated sometime during the period of validity of the outcome. Each of these capabilities may also need other outcomes, so it is not safe to assume that the capabilities all start at the same time. At the end of parallel flows, the outcomes must be explicitly synchronized by placing them in conjunction in a composite outcome like the “departed terminal” outcome that requires the conjunction of “boarding done” and “conveyor enroute”.

Unpacking Justifies Capability Decomposition

If you are making use of a capability reference model, such as the Transportation Reference Model of the Business Architecture Guild, you will go looking for candidates for the capabilities to fill out these flows. You will likely find a capability that is general (e.g. “conveyor control”). You could use that capability twice in the lower flow (for both the inspection activity and the control assumption activity) without creating an ambiguity. You would be implicitly assuming that the capability has different sub-capabilities, one needing the “conveyor arrived” outcome and the other needing the “conveyor inspection OK” outcome. We have made this assumption explicit and decomposed “conveyor control” to create the explicit sub-capabilities “conveyor inspection” and “conveyor operation”.

Capability decomposition may be needed to match needed and produced outcomes

However, a more serious problem occurs if a capability has multiple needed outcomes and multiple produced outcomes. The BACM metamodel does not have a way to pair a needed outcome and the produced outcome without decomposing the capability (and defining flows within the capability – this will be the subject of a subsequent post). Consequently, making these decompositions explicit is highly recommended.

The Guild Transformation Reference Model, from which some of these concepts are taken, does not have a transportation specific capability that fits the need for check-in, cleaning, provisioning and boarding activities, so we elected to decompose the “operation activation” capability to provide these sub-capabilities.

Summary

It is not necessary for the exit criteria of a value stream stage to also be the entry criteria for a subsequent stage. This example shows how the “checkin activation” capability takes the “travel confirmed” outcomes associated with individual travelers and groups them into an outcome representing the state of all passengers ticketed for the segment. Such capabilities are neither part of the “Ensure Permission” stage nor part of the “Depart” stage in this example, creating a problem for a value stream stage to capability cross-map as “checkin activation” would be omitted. A possible resolution would be to include in the cross-map any capabilities producing outcomes that are part of an entry criteria as capabilities supporting the stage whose entry criteria they satisfy in whole or in part.

The group transportation value stream presents a challenge to the business architecture modeler – how to combine the individual value experience of the traveler with the group travel value experience that may include delays and cancellations. The answer that was presented in the first section of this post is that both may need to be modeled. For example, the cleaning and provisioning of the conveyor may be completed, but an individual traveler may find their seat area was not properly cleaned. This could cause a delay affecting all passengers if the cleaning crew has to return, or the individual traveler becomes dissatisfied and the transportation company suffers some reputational damage. The business architect and sponsor must decide if the issue is significant enough to warrant detailed modeling.

An example of unpacking a value stream stage into parallel flows was presented. Parallel flows start with a single outcome or a conjunction of outcomes and must end with a conjunction of outcomes. In this example, the parallel flows end in a successful outcome “departed terminal”. In a later post, you will see examples when the desired outcomes does not happen. If synchronization must occur within parallel flows, it should be represented as a conjunctive outcome that includes outcomes from each flow.

This example reveals the importance of the ability to combine outcomes into conjunctions and use these conjunctions to condition the initiation of a capability or value stream stage. Conjunctions also serve to synchronize the outcomes created by capabilities in parallel flows

Also in this example, we saw the need to decompose capabilities that are too general to accurately describe the activity they represent in a flow. This is a recommended practice. But, it can lead to capability maps that a nicely hierarchical until level 4 or 5, but become quite flat at lower levels. This can be an issue because the capability hierarchy is used to roll-up assessments and other analytic results and it may be desirable to introduce additional levels in the capability hierarchy that result in more meaningful heat maps.

Footnotes:

1. This aggregation takes several forms at different places in the scenario: the traveler is aggregated with other booked passengers when the trip is booked, aggregated with checked-in passengers when check-in is complete, and added to boarded passengers when the traveler boards the conveyor. ↩︎
2. The BACM does not provide a syntax for the concept of a “restriction class” such as in Owl 2 or first order predicate logic. A “restriction class” is a class whose members must appear in a relationship with members of another class. In this example, “passengers” is intended as a class whose members are all passengers related by “of” to a particular member of the “conveyor segment” class. In other words, the group of passengers who are traveling in this conveyor segment. If a computational ontology model is desired as an adjunct to a BACM model, a translation of a BACM model into a computational ontology can be done and such formal logic rules added to the computational ontology. ↩︎
3. Since “boarding ready” is a requirement to enter the Depart stage, it could be argued that “boarding conveyor ready” as a conjunction of “boarding ready” and “conveyor ready board” is not necessary. A human may or may not make that inference and the BACM does not support that kind of inference, so it is a good practice to make the dependence of “boarding activation” on both “conveyor ready board” and “boarding ready” explicit as we have done here. ↩︎