This post extends a previous post that introduced viewing a business architecture capability/outcome graph as a finite state machine – FSM, and it demonstrates how to view such graphs as parallel finite state machines. A parallel finite state machine is a collection of finite state machines that work independently of each other but define special states representing synchronization between subcollections of machines. In addition, the post demonstrates how the unpacking of a value stream stage can be viewed as a hierarchical finite state machine and explains the value to the business of composite states of the hierarchical finite state machine.

The Example Business Architecture Diagram

This complicated diagram models the check-in and boarding of passengers of a conveyor segment, the cleaning and provisioning of the conveyor and the inspection and assumption of control of the conveyor by the conveyor crew. These activities are a mixture of sequential and parallel activities.

An outcome/capability dependency diagram

To begin the process of defining transition tables, we simplify Figure 1 by eliminating the information items and information item relationships and the relationships between outcomes and information items. Then we layout the resulting diagram so that sequential dependencies between outcomes are shown in order from left to right. Here’s what that looks like:

Figure 2 cannot be taken as a timeline diagram where the capabilities and states happen according to their horizontal position; the X axis of the diagram is not a clock. Though travel confirmed and conveyor arrived are shown at the same horizontal position, it does not mean that they occur at the same time. What the diagram does say is that boarding ready and conveyor ready board must overlap in time in order to satisfy the boarding conveyor ready synchronizing outcome. It also tells us that conveyor arrived happens before conveyor ready board and before conveyor inspection OK. It does not tell us whether conveyor ready board happens before conveyor inspection OK or vice-versa.

The FSM transition tables for Figure 2

Ignoring the Depart stage and the entry and exit criteria outcomes for the moment, Figure 2 shows three layers of activities that are each sequential but behave independently from each other. To view this diagram as a parallel finite state machine, look at each layer as an independent finite state machine defined by the transition tables below. We do not start the BoardingFSM with the travel confirmed to boarding ready transition because that transition happens prior satisfying the entry condition of the Depart stage.

Table 1 – BoardingFSM

In Outcome	Capability/Touchpoint	Out Outcome
boarding ready	synchronization 1	boarding conveyor ready
boarding conveyor ready	boarding activation	boarding done

Table 2 – CleanProvFSM

In Outcome	Capability/Touchpoint	Out Outcome
conveyor arrived	clean-provision activation	conveyor ready board
conveyor ready board	synchronization 1	boarding conveyor ready

Table 3 – CrewFSM

In Outcome	Capability/Touchpoint	Out Outcome
conveyor arrived	conveyor inspection	conveyor inspection OK
conveyor inspection OK	conveyor operation	conveyor enroute

Synchronizing outcomes

The elements and relationships in Figure 2 are abstract – in logic they would be called classifiers. They describe an allowed pattern of behavior and not a specific behavior. To describe a specific behavior, we need to talk about the instances¹ of these abstractions. An instance of an abstract element is typically a data element representing some real world entity. So, conveyor is the abstraction, an instance is a data element that represents a specific airplane, bus, taxi, … . The conveyor instance has a type, which is the conveyor abstraction. Likewise, hasConveyor is an abstraction of a relationship; an instance of the relationship is a typically implemented as a data element (e.g. in a join table) that represents a link between a particular conveyor segment data element and a particular conveyor data element.

The outcomes in Figure 2 with dashed boundary lines are synchronizing states, which permit a transition only when the synchronization conditions are met. What this means for boarding conveyor ready is that an outcome instance of type boarding ready and an outcome instance of type conveyor ready board must both be valid through some interval of time. Assuming that the corresponding data schema is representative of the real world, the actual passengers for a conveyor segment are ready to board and the actual conveyor is ready to be boarded. As soon as the synchronizing conditions are met, the boarding conveyor ready outcome instance becomes valid and performance of boarding activation is allowed.

Outcome instances have a specific time of validity. If the actual passengers are ready to board at 10:42EST on 4 June 2026 and boarding is done at 11:31EST on 4 June 2026, the boarding ready outcome instance would be valid during that interval. In order for synchronization to occur, the conveyor ready board outcome instance would need to happen during that same time interval.

In addition, the conveyor instance must be linked to a conveyor segment instance that is also linked to a passengers instance. This insures that the passengers that are ready to board are boarding the same conveyor that has been cleaned and provisioned. In practice, this is achieved by linking the outcome instances to the information item instances whose state they define. A data schema for the information item instances might include an enumerated value that encodes the outcome instance state, e.g. “3” means boarding ready in the “state” field of the schema for passengers.

We have chosen to represent the transitions into the boarding conveyor ready synchronizing state with a transition label synchronization 1 indicating that this transition cannot occur until it is ready to occur in each state transition table that contains it. The “out” outcomes of all transitions with the same synchronization activity must be the same also. This synchronization activity only occurs in the first two transition tables, so the transition from boarding ready to boarding conveyor ready (row 2 of the first transition table) cannot occur until the transition from conveyor ready board to boarding conveyor ready (row 2 of the second transition table) is also allowed to transition, and vice versa. In other words, the transition to boarding conveyor ready in both transition tables happens as soon as the FSMs defined by the first two transition tables enter the predecessor states boarding ready and conveyor ready board.

Common “in” outcomes

The conveyor arrived outcome is needed by two capabilities: clean-provision activation and conveyor inspection. These capabilities can be performed independently of each other. In transition tables 2 and 3, the initial transitions both have conveyor arrived as the “in” outcome, meaning that as soon as there is an instance of conveyor arrived, the two FSMs defined by tables 2 and 3 are allowed to begin executing their respective capabilities.

Finite state machine creation and termination

Generally, a FSM associated with a transition table will be created each time instances of outcomes that are “initial in” outcomes are created. In a simulation, as soon as an instance, e.g. “conveyor 1234 arrives at port 6789” of type conveyor arrived is created, an FSM (e.g. “cp-3579”) is created as defined by table 2 and an FSM (e.g. “ci-2468”) is created as defined by table 3.

An “initial in” outcome is an outcome that appears in the “in outcome” column of a transition table but not in the “out outcome” column. A “final out” outcome is an outcome that appears in the “out outcome” column of a transition table, but not in the “in outcome” column. A FSM terminates when it enters a state whose type is a “final out” outcome. The FSM terminates, but its final outcomes remain as they may trigger another FSM.

In the terminology of finite state machines, an “initial in” outcome is a initial state and a “final out” outcome is a terminate state. These are both called pseudo-states and are usually associated with real states that are defined as external to the FSM model or are real states in some other FSM definition. The synchronizing state is another type of pseudo-state typically called a join or junction state. We have simplified the definition of finite state machines and eliminated much technical detail because the finite state machines we use in business architecture and meant to describe behavior, but not to be executed or simulated.

The hierarchical state machine and composite states

A hierarchical finite state machine contains subordinate FSMs that define the behavior of an activity element, such as a capability or value stream stage, in additional detail. This hierarchy can be created to any depth the business architect needs to describe the behavior of the business. In Figure 2, we can construct a 2 layer hierarchy, where the top layer is an FSM that defines the chain of entry and exit criteria as states of the top level FSM. The value stream stages are the actions that cause the transitions between the entry and exit criteria of each stage. One or more subordinate FSMs will define the behavior of each stage.

In our rendering of Figure 2, we defined three FSMs that operate in parallel to clean and provision the conveyor, to board the passengers and to inspect and take control of the conveyor for the travel segment. These are subordinate FSMs to the value stream FSM. We can describe the state of this hierarchical FSM as a composite of the value stream stage and the state of each of the subordinate FSMs. For example, the state:

• MakeATrip:Depart.
  • BoardingFSM:boarding_ready,
  • Clean-ProvFSM:conveyor_ready_board,
  • CrewFSM:conveyor_inspection_OK

describes a legal composite state of the hierarchical FSM. The state:

• MakeATrip:Depart.
  • BoardingFSM:boarding_done,
  • Clean-ProvFSM:conveyor_arrived,
  • CrewFSM:conveyor_inspection_OK

describes a composite state, but it is not a possible state because the passengers have boarded before the conveyor is cleaned and provisioned.

Hierarchical state sequencing

The initial state of the top level FSM of the hierarchical FSM is MakeATrip:TravelNeed (the entry condition to the first stage of the MakeATrip value stream – see the prior post “Modeling Dynamic Value Streams” and look at the final diagram). When that criteria is satisfied by an outcome instance typed by TravelNeed, the PlanATrip stage is entered. Eventually, the hierarchical FSM reaches the MakeATrip:depart_ready state which enables MakeATrip:Depart to be entered. MakeATrip:Depart is technically a value stream stage, not an outcome or a state, but since it is defined by subordinate FSMs, we will treat it like a state in the hierarchical FSM².

Once MakeATrip:Depart is entered, the following composite state will be valid because of the conjunction of the depart ready outcome that is the entry criteria of the stage:

• MakeATrip:Depart.
  • MakeATrip:boarding_ready,
  • MakeATrip:conveyor_arrived

This state causes instances of the three subordinate FSMs to be created, which immediately causes a transition to:

• MakeATrip:Depart.
  • BoardingFSM:boarding_ready,
  • CleanProvFSM:clean-provision_activation,
  • CrewFSM:conveyor_inspection

Once the clean-provision activation capability completes and produces conveyor ready board, the composite state looks like:

• MakeATrip:Depart.
  • BoardingFSM:boarding_activation,
  • CleanProvFSM:terminated,
  • CrewFSM:???

The ??? means that we do not know the state of the CrewFSM because the completion of the conveyor inspection capability was not stated. The ??? notation allows us to reduce the number of composite state representations; to enumerate all of the discrete composite states, we would have to list all the possible combinations of parallel states, subject to the synchronization constraints. For a realistic model of a business, this would be a very large number of discrete states. The key for analysis of the behavior is to focus on a small number of subordinate FSMs and to look for the possibility of problematic composite states, e.g. where there are travel restrictions but the conveyor left anyway.

Composite states have business value

Composite states can have business value if they are designed for that purpose. Frequent flyers sometimes want to know information about the status of the airplane assigned to their flight segment; if it was late departing on its prior flight segment, it may be arriving late and causing a late departure for the flight segment the frequent flyer will be taking. Today, this information is supplied by airplane tracking applications, not the airline, but the airline could supply it and a wealth of other information of interest to the flyer. Better examples of the business value of tracking composite states and making them visible within the travel company will be found in stakeholder and employee value streams.

Since a composite state is associated with an outcome, the business architect can create an information item that represents a record that the outcome happened. The information item represents the knowledge that the outcome occurred and it can be used to inform operational decisions or collected to satisfy a regulatory requirement, on in the case of an outcome that is a financial transaction, the knowledge that the event occurred can be published to interested parties. Using this technique, the business architect can record the importance of an outcome (and its implied composite state) to the business.

Since value streams represent abstractly how a business creates value for selected stakeholders, the collection of statistics based on selected composite states of the value streams can provide the business managers with a real-time and historical dashboard of operations.

Warning

The business architecture model and FSM interpretation shown in this post are not unique ways of representing the business architecture and the associated behavior of a passenger travel business. In particular, the arrangement into 3 parallel FSMs shown in Figure 2 is strongly biased by the organizational structures one typically finds in passenger travel businesses. These organizational structures include:

• Terminal operations – which staff and resource checkin activation and boarding activation capabilities;
• Cleaning and provisioning operations – typically contracted to external businesses with those specialties;
• Conveyor operations – which maintain and operate the conveyors.

Other organizational structures are possible; one might combine the two FSMs triggered by conveyor arrived into a single FSM that becomes a sub-machine to the value stream FSM. This would represent a case where the conveyor operators also perform the cleaning and provisioning. Business architects need to be aware that such biases can and do influence both how a value stream stage is unpacked and how behavior may be applied to it with the definition of composite, parallel finite state machines. After creating even a partial unpacking of a value stream stage, it is good practice to think about alternative ways the stage could be unpacked. If one or more capabilities in the unpacking are found to be deficient, it is useful to investigate if an alternative unpacking or a different organizational structure or even a different capability decomposition would help to remedy the deficiency.

Summary

In this blog post, we demonstrated:

• how an unpacking of a value stream stage can lead to the definition of multiple state machine transition tables;
• how the creation, synchronization and termination of FSMs can be explained by examining the transition tables;
• how composite states are defined by hierarchical FSMs derived from the unpacking of value stream stages;
• how carefully designed hierarchical FSMs and their composite states can provide business value;
• how organizational and other biases can affect the unpacking of value stream stages and the creation of transition tables.

ICYMI

Previous posts in this series:

• What is an Outcome
• Unlock Business Analyses with Dynamic Value Streams
• Dynamic Value Streams – Parallel Flows
• Modeling Dynamic Value Streams – Unpacking Stages
• Modeling Dynamic Value Streams

Next Steps

Thematix offers training and consulting on advanced topics in business architecture modeling and applications to strategy management. To schedule an initial web meeting to see if our offerings will benefit your business, please use this link: https://calendly.com/jrhyne-thematix/30min

If you have questions about the content in these posts or want to discuss the BACM specification, please connect with me on LinkedIn https://www.linkedin.com/in/jrhyne/

Footnotes

1. The BACM specification does not model instances, but the metamodel can be translated into a logic language like OWL that does model instances. The business architecture model can also guide an implementation in software and data that explicitly represents instances. Instances are used in these narratives to describe how a model would behave if implemented as software and data. ↩︎
2. To explain this, we would need to dive into the BACM specification, where we would see that a value stream stage is associated with one or more “regions” and regions are a type of outcome. To be technically correct, we will have three regions associated with the Depart stage, one for each of the FSMs we defined. ↩︎