The Business Architecture Core Metamodel – BACM uses the term “outcome” to label and name a concept in business architecture. Our purpose in this article is to explain the concept labelled “outcome” in two ways: (1) what outcomes have to say about the state of properties of business objects and (2) how outcomes can act as conditions that control entry to and exit from value stream stages, capabilities and processes. To create this explanation, we show how a value stream stage and its unpacking as a network of outcomes, capabilities and touchpoints can be interpreted as a finite state machine – FSM.

The term “outcome” is also commonly used in business to mean a final result of a coordinated web of activities, sometimes including the value or benefit the recipient of the outcome experiences. In the BACM, the concept labelled “outcome” has a narrow and technical meaning. I am not going to try to explain why the BACM authors decided to use the term “outcome” to label this concept. But, if you are trying to model a concept that is like the common business usage of “outcome, here are several other BACM concepts that are better suited for modeling business outcomes:

• “Ends” represent the desired results of a strategy
• “Change” represents the desired results of an initiative
• “Offering” represents a potential or actual contract establishing the terms and conditions of a product or service
• “ValueProposition” represents the value of an offering to a customer segment as seen by the business
• “Segment” represents the value of an offering as perceived by the customer

The example

Consider the following example, which was introduced in another post:

This figure shows a simplified model of the outcomes, information items, capabilities and touchpoints that describe what happens when a traveler interacts with a transportation company to plan a trip. The outcomes are represented as green ovals, the information items are represented as blue rectangles and the object relationships are represented as blue round-capped rectangles. A grey rectangle is a capability and a grey trapezoid is a touchpoint.

Outcomes describe the information item states

The outcome labels hint at the states of the linked information items, but the business architect needs to describe the states of the information items in detail. The descriptions should be prose statements that refer to information items by label and the statements should be able to be verified with respect to information its objects. For example, suppose there is an outcome object “st1” linked to a traveler object “tv1” with a “stateOf” typed link. If “st1” is a valid member of the outcome “travel need”, it should be true of “tv1” that “tv1 has a need to take a trip”.

The following table provides descriptions of information item state associated with each of the outcomes in the preceding diagram.

Outcome	State Description
travel need	There exists a traveler with a need to take a trip
travel inquired	The traveler who needs to take a trip has made an inquiry to an existing travel company
trip inquired	The travel company has received and recorded the inquiry as a trip inquiry record and linked that record to a record that identifies the traveler who made the inquiry.
travel offered	The travel company has assembled a collection of offers that it believes meet the needs of the traveler as expressed in the inquiry. It has communicated that collection to the traveler and has recorded the offers linked to the inquiry record.
travel chosen	The traveler has chosen a trip route from among the offers. The chosen route is linked to a newly created trip record that represents an agreement between the traveler and the travel company.
travel planned	The exit criteria for the PlanATrip stage. It is the conjunction of the “travel chosen” outcome and potentially other outcomes such as seat and meal choice or travel insurance.
travel abandoned	The traveler has abandoned the dialog with the travel company.

Outcome defined information item states

How outcomes function as entry and exit criteria

Outcomes and the other entities of the BACM are abstractions, not individual things. The “Traveler” entity is an abstraction that defines a collection of people who need to travel. In technical terms, the “Traveler” entity is a class (or classifier) whose description should allow someone to determine, for a given individual object, whether that object is a member of the class. Consequently, we have to explain the function of the BACM entity description as a set of rules that are applied to hypothetical (or actual) objects. These objects are either given a state by the business architect as described in the section “Simulating the FSM to display history” or their state can be inferred from what the entity description says must be the case.

The state description of each outcome is interpreted as a collection of tests on the state of business object objects, information item objects and object relationship objects. This role of an outcome state description is called a “validation test“. To pass this test, the object state must satisfy the statements of the state description, For example, if “Traveler:tv1” is a traveler object, it must have state represented by “Traveler:tv1 needs to take a trip” to satisfy the entry criteria “travel need” state description. Another traveler object “Traveler:tv2” with state “Traveler:tv2 writes a blog post” would not satisfy the entry criteria.

When an outcome is used as an entry condition and this validation test fails for a traveler object, the value stream stage cannot be entered by the traveler object. When an outcome is used as an exit condition and the outcome object validation fails for its information item objects, the outcome object is invalid and cannot enable a subsequent stage. However, a stage may have multiple exit criteria, and an outcome object should validate exactly one of the exit criteria. When designing a value stream stage, the business architect should account for the most likely exit criteria and entry criteria. Unlikely criteria should be included only if handling those situations requires substantial effort or raises significant risk.

In a previous post that included the above diagram, we explained how an outcome used as an entry criteria can also be used as a needed outcome for a capability or an experienced outcome for a touchpoint. The same validation process is applied to each outcome object needed by a capability or experienced by a touchpoint. And the same validation process is applied to outcome objects produced by capabilities and triggered by touchpoints.

When a stage is unpacked as a graph of outcomes, capabilities and touchpoints, each entry criteria outcome should also be needed by at least one capability or experienced by at least one touchpoint. Each exit criteria outcome object should be produced by at least one capability or triggered by at least one touchpoint. Ideally, there is a connected path via intermediate outcomes, capabilities and touchpoints from each entry criteria to at least one exit criteria and from each exit criteria to at least one entry criteria. You will see the reason for this requirement in the next section.

The outcome, capability, touchpoint graph as a finite state machine

The graph of outcomes, touchpoints and capabilities can be interpreted as a state transition diagram for a finite state machine. The outcomes are the states and the touchpoints and capabilities represent the actions taken by the traveler and the transportation company respectively to change from the incoming state to the outgoing state. We can make this more explicit by providing a state transition table.

In outcome	Capability/Touchpoint	Out outcome
travel need	traveler inquires	traveler inquired
traveler inquired	inquiry establishment	trip inquired
trip inquired	trip/route matching	travel offered
travel offered	traveler chooses	travel chosen
travel offered	traveler chooses	travel inquired
travel offered	traveler chooses	travel abandoned

FSM state transition table

Simulating the FSM to display history

We can create another table from this state transition table to demonstrate how an individual traveler, “tv1” might transition through a sequence of states to book a trip. We also want to show how each state can create changes in the state of the objects of the information items.

To do this, we create a hypothetical traveler object labelled “tv1” with a state “tv1 needs to take a trip” and we create an outcome object “st1.1”¹ that is linked to the traveler object and we apply the validation test of the “travel need” outcome to see if the outcome object “st1.1” passes the validation test, which it does. The two consequences of passing the validation test: (1) the “traveler inquires” touchpoint is enabled and the transition to the next state can occur; (2) the “st1.1” object is established as a member of the “travel need” outcome class.

The following table describes the history of the operation of the FSM for this example and the effect on the information item objects of each state in the history. The outcome object is identified by the outcome class it is a member of (e.g. “travel need”) and the object identifier (e.g. “st1.1”). As the FSM transitions, new outcome objects are created with a new state identifier (e.g. “travel inquired:st1.2”.

The information item objects are identified by the information item class they belong to (e.g. “Traveler”) and an object identifier (e.g. “tv1”).

State	Current Information Items
travel need:st1.1	Traveler:tv1 needs to take a trip
travel inquired:st1.2	Traveler:tv1 has made an inquiry
trip inquired:st1.3	Traveler:tv1->makes:mk1->trip inquiry:ti1
travel offered:st-1.4	Traveler:tv1->makes:mk1->trip inquiry:ti1->responds:rs1->trip offers:to1->trip route:rt1.1-n
travel inquired:st1.5	Traveler:tv1 has made an inquiry
trip inquired:st1.6	Traveler:tv1->makes:mk2->trip inquiry:ti2
travel offered:st1.7	Traveler:tv1->makes:mk2 ->trip inquiry:ti2->responds:rs2->trip offers:to2->trip route:rt2.1-n
travel chosen:st1.8	Traveler:tv1->makes:mk2->trip inquiry:ti2->responds:rs2->trip offers:to2->trip route:rt2.1-n[3]->assign:.as1->trip record:rc1

State machine history

At “travel inquired:st1.2”, the traveler has made an inquiry, but it has not yet been established as an inquiry by the travel company. This change of state is produced by the traveler at the “traveler inquires” touchpoint.

At “trip inquired:st1.3”, the travel company has received the inquiry and established a “trip inquiry” information item object to record the inquiry and linked it to the identified Traveler object “tv1”.

At “travel offered:st1.4” the travel company has responded with a trip offer object “trip offers:to1” that is a collection of “trip route”. A trip route is a collection of trip segments, each representing an unbroken journey from a starting point to an ending point.

At “travel inquired:st1.5” the Traveler at the “traveler chooses” touchpoint has made a new inquiry. This is a new state, not a resumption of “trip inquired:st1.3”. Consequently there will be a new inquiry. When the FSM transition table indicates that an output outcome is the same as an input outcome of another transition, a new state is created and it must satisfy the validation test of the output outcome (which is also the input outcome for the next transition).

At “trip inquired:st1.6” the travel company has received and established a new trip inquiry object that is linked to the Traveler object. The “traveler inquired” outcome assumed that the traveler was already known and the existing Traveler object “tv1” is reused as was the case in “trip inquired:st1.3”. This new trip inquiry object is “trip inquiry:ti2” and a new link of “makes:mk2” is created from the traveler object to the trip inquiry object.

Eventually the traveler chooses a trip route from the offers and the history ends in “travel chosen:st1.8”. That is the end of the stage, but not the end of the value stream. The history can be extended to show what happens in a particular hypothetical scenario for the rest of the value stream.

What is the value of using FSMs to model value stream behavior?

FSM histories demonstrate model correctness

A scenario for a FSM is like a test program for a software module – it shows that the software model executes correctly for a set of cases. The history that is produced by a scenario should connect a hypothetical entry outcome object to a hypothetical exit outcome object. If the history stops (i.e. there is no possible next transition) at an outcome object that is not a valid exit criteria outcome, the business architecture model is incomplete or incorrect.

It is possible to semi-automate the creation of histories if the outcome validation rules are expressed in a more rigorous way. The business architect will need to provide ways of e.g. choosing the different triggers of a touchpoint that represent different actions by the traveler. For most cases, tracing the transitions by hand (or aided by software) and annotating the states with information from the outcome validation descriptions will produce a document that can be reviewed by subject matter experts.

The example scenario and history explains how the FSM is constructed and how to simulate its behavior

The definition of a FSM to model behavior leads the business architect to focus on outcomes instead of focusing on describing how a capability, touchpoint of process works. Once outcomes are chosen, the business architect and analyst can explore different ways of achieving these outcomes.

In a previous post, we saw how a value stream stage can be unpacked to reveal parallel behavior. We will explain how to represent parallel behavior in a FSM in a subsequent post. But, there is no defined order between states in parallel behavior except in certain cases. So care must be taken when simulating parallel behavior to avoid attempting to establish an ordering of states in behaviors that can occur in parallel.

The history reveals when objects change state

The history shows when objects should be created and destroyed and when their state should change. By collecting the outcomes that describe the state of objects of a given type, the business architect sees all of the possible states of the object type. For example, in this value stream stage, a “trip inquiry” object can have the states: not existing, “trip inquired”, “travel offered”. The “trip inquiry” information item is a class but it only has members if an outcome description states that an object of the class has been created. The “trip inquired” outcome description states that a “trip inquiry” object has been created. This “trip inquiry” object can have the state “travel offered” because that state adds a link of type “responds” to the “trip inquiry” object. The state of an object includes all of the links it participates in. This leads to an information view that is one of the primary views of business architecture.

The history adds possible sequences of these states, revealing for example that the “trip inquiry” object is created and linked to the “Traveler” object before the “trip offers” object is created and linked to the “trip inquiry” object. If one assumes that the time taken to carry out the actions of a capability or touchpoint is nonzero, then the output outcome object will happen strictly later than the input outcome object according to a “clock” that is associated with the history. However, prior to choosing a specific way to implement a capability or a touchpoint, it would be difficult to realistically estimate the time taken. So, the business architect should not be tempted to make such estimates prior to completing the model of value streams, capabilities, outcomes and touchpoints and moving to the next phase of designing an implementation for the business.

Summary

In this blog post, we demonstrated:

• how to document outcomes so they can be used as entry and exit criteria for a value stream stage;
• how to interpret outcome->capability/touchpoint->outcome sequences as transitions in a finite state machine;
• how to define hypothetical state objects to follow the transitions of the finite state machine to create a history;
• how to view the outcomes providing descriptions for the state of business object and information item objects to create entries in the business architecture information map;
• ways to use the history to determine if the business architecture model is correct.

This is just the beginning of the story about the symbiosis of business architecture and finite state machine modeling. Future blog posts will explain and demonstrate how this symbiosis attaches semantic behaviors to value streams, capability networks and process networks, and allows the business architect to work with subject matter experts and decision makers to validate the business architecture model.

ICYMI

Previous posts in this series:

• 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 labeling of “st1.1” shows that it is a composite state of a hierarchical finite state machine. The top level state “st1” identifies the value stream stage and the substate “.1” identifies the “travel need” outcome state object. Composite states allow the business architect to represent entity states at different levels of detail. For some analyses, describing a composite state by a prefix such as “st1” may be sufficient, while other analyses may require the full composite state identifier. A future post will explain composite states and their uses. ↩︎