This is the first of a series of posts on building advanced business architecture models with the Business Architecture Core Metamodel – BACM. These posts are intended for business architects. They will use models of a fictional transportation company, displayed as diagrams, to exemplify and explain the the concepts in the BACM metamodel.
Before diving in …
A metamodel is essentially a palette of predefined concepts that can be specialized to create a model of something. Models help us understand and reason abstractly about real-world entities and behaviors. Models usually focus on a part or behavior of interest. Business architecture models represent interesting parts and behaviors of a business making use of concepts like capabilities, value streams and business objects. The concepts of the BACM metamodel are closely aligned with the concepts described and exemplified in the Guide to the Business Architecture Body of Knowledge – BIZBOK® Guide, a publication of the Business Architecture Guild®. Many of these concepts are also defined in the glossary section of the Business Architecture Guild website https://businessarchitectureguild.org. Familiarity with these concepts is essential to understanding this series of posts.
Models based on OMG metamodels are typically visualized and edited as “box/line diagrams”; for example, UML model classes are presented as rectangles and model associations are presented as lines that connect boxes. The model diagrams presented in these posts will use a variety of shapes and colors to visualize the non-relational concepts of the BACM (e.g. capabilities, value stream stages, outcomes). The shapes and colors will indicate the metamodel concept, e.g. capabilities are visualized as grey rectangles. Relational concepts will be represented as lines of various widths and colors. The metamodel concept from which a model relation/line is derived can usually be determined by looking at the shapes and colors of the shapes that are connected by the line. The BACM specification does not dictate a visualization of the metamodel concepts and the visualizations presented in these posts are only intended to aid the reader’s understanding about the concepts and how they work together to model a type of business. They do not represent a standard or approved way to represent business architecture concepts.
This series of posts will not illustrate or try to explain the metamodel itself. Anyone familiar with the UML modeling language and the concept of metamodeling can download the specification document from the OMG website and learn the exact details of the metamodel.
What is a “dynamic” value stream?
Value streams are a key concept in business architecture. They represent the stages of work done to generate value for a stakeholder and they produce components of the value proposition made to the stakeholder of the value stream. An airline company promises its travelers a safe, comfortable, on-time travel experience at a competitive cost. The value stream generates the components of the value proposition in a sequence of interactions with the traveler called “stages”. This sequence of interactions gives the value stream its dynamic nature.
The BIZBOK® provides a description of dynamic behavior: “Value stream entrance and exit criteria control and determine flow based on events that occur that are triggered in part by business object state changes.” It does not define entrance and exit criteria or explain what is meant by “flow”, creating a mystery for business architects who want to model dynamic behavior.
The most recent version of the BACM specification, BACM 1.2 – currently in the final approval stage at the OMG, provides metamodeling concepts that can be used to model dynamic value streams. These concepts are borrowed from behavior modeling with finite state machines, a paradigm widely used in technical disciplines such as software engineering and systems engineering, but not so widely used in business modeling. Hopefully, these posts will convince you of the value of using this approach to model the behavior of businesses, following the concepts and principles of business architecture.
Sequencing the “Make a Trip” value stream
The “Make a Trip” value stream represents the stages of value experienced by a traveler interacting with a transportation business such as an airline company. In our example, it has six stages:
Plan a Trip – a traveler has examined possible trips and has chosen a trip
Ensure Permission – the traveler has booked a trip and has a ticket
Depart – a segment of the trip is preparing for departure and departing
Enroute – the segment of the trip is enroute
Arrive at Destination – the segment of the trip has arrived and the next segment may begin
Terminate Trip – the traveler arrives at the final destination
Each of these stages sums up the experiences the traveler has while interacting with the transportation company. For example, at the end of the “Plan a Trip” stage, the traveler will have valued the trip options presented, along with the experience of use the transportation company’s website. The “Depart” stage will be valued positively if the gate was comfortable, the boarding process was smooth and the travel was begun on time.
We can create a model from the BACM template and display it as a node/arc graph below. The shapes and colors indicate the BACM type of the model element and the label identifies it in the model. Relationships between shapes are often represented by a line, sometimes with a distinguishing arrowhead on one end. The legend below the diagram explains the shapes.
Orange fat arrow
Value stream
Red fat arrow
Value stream stage
Black filled diamond arrowhead line
Composition (lifecycle dependency)
Legend
What are entry and exit criteria?
The BIZBOK® says that entrance and exit criteria are based on business object states. A “criterion” is “a principle or standard by which something may be judged or decided” (Google English Dictionary). So a “criteria” is a collection of rules that when applied to a group of business objects’ states should produce a decision (e.g. true, false, or undecided).
An outcome describes a possible state of the business and its stakeholders. An outcome’s description can be used as a test against a business scenario to see whether the scenario matches the outcome description. For example, if the outcome description is “The traveler has chosen a trip from the selection of trips offered by the travel company.” and the traveler in a scenario has not chosen a trip, the outcome would not match the scenario. If this outcome description is used as an entry criterion for the “Ensure Permission” value stream stage, the entry criterion test would fail and the “ensure Permission” value stream stage would not be entered.
Exit Criteria (Business States) from “Plan A Trip”
When offered a selection of trips, the traveler can: (a) choose a trip from the selection; (b) request a new selection of trips; (c) abandon the search for a trip. These possible states are the exit criteria of the “Plan a Trip” value stream stage. We can represent them as three outcomes in BACM as shown in the following table:
Outcome label
Outcome definition
travel planned
The traveler has chosen a trip from the selection offered by the transportation company in response to the inquiry.
travel need
The traveler has set parameters of the inquiry and requests a selection of travel offers from the transportation company.
inquiry abandoned
The traveler will not continue to seek a travel offer (timeout or sign out of website, disconnect of phone call, …)
The value stream diagram can be extended to include these outcomes as entry criteria and exit criteria as shown below.
green oval
outcome
black line (entry criteria)
links an outcome playing the role of an entry criteria to a value stream stage
black line (exit criteria)
links an outcome playing the role of an exit criteria to a value stream stage
legend
In this diagram, “Travel Need” is both an exit criterion and an entry criterion of the “Plan a Trip” stage. As an exit criterion, it means that the details of the traveler’s desired travel have changed as a result of viewing the offers received. As an entry criterion, these changed details will provoke a new set of travel offers from the transportation company. For example, the cost of the travel departing as originally requested is too high, and the traveler wants to change the departure date in hopes of lowering the fare. In a later post, the “Plan a Trip” stage will be unpacked to see how this repeating behavior can be modeled in more detail.
An Exit Criteria of a Stage is the Entry Criteria for later Stage
An outcome can be either an entry criterion or an exit criterion; the outcome’s role in the value stream stage is determined by a labelled arc connecting the outcome to the value stream stage. As this example shows, an outcome can be both an entry criterion and an exit criterion. If an actual traveler was not satisfied with any of the travel offers received, the traveler might change some parameters of the inquiry and receive a new selection of offers. In effect, the traveler has exited and reentered the “Plan a Trip” stage because the exit criterion and the entry criterion are the same.
On the other hand, a traveler may choose a trip from the selection offered. This state of affairs, represented by the “travel planned” outcome, would allow the “Ensure Permission” stage to be entered.
Connecting All of the Stages
In the preceding diagram, the “travel planned” outcome is the exit criterion of the “Plan a Trip” stage and the entry criterion of the “Ensure Permission” stage. If we make the reasonable assumption that whatever work happens in the “Plan a Trip” stage, that work takes time, we can conclude that the “travel planned” outcome must occur after the “travel need” outcome. Since “travel planned” is an entry criterion for “Ensure Permission”, the stage cannot be entered until the “Plan a Trip” stage is complete. So, the use of outcomes as entry and exit criteria can allow an analysis of the model to establish a time-ordering of the value stream stages. There is no requirement that an exit criterion be an entry criterion for the next stage; an exit criterion outcome may be the entry criterion for a stage several stages to the right or several stages to the left. Look at the following diagram.
The previous diagram has been extended to add entry and exit criteria for the rest of the value stream and handle the case of a multi-segment trip. The “Arrive at Destination” stage has two exit criteria: “trip complete” and “ready depart”. The “trip complete” outcome describes the situation where the traveler has arrived at the final destination; the “ready depart” outcome describes the situation where there is another travel segment to be taken.
The model represented by the preceding diagram tells us that “Depart” occurs before “Enroute” and “Enroute” occurs before “Arrive at Destination”. It also tells us that “Terminate Trip” occurs after all occurrences of “Arrive at Destination”, because the diagram contains no loops after the “trip complete” outcome occurs. Such models can be analyzed for “reachability”, i.e. what paths through sequences of the pattern [outcome, entry criteria, stage, exit criteria, outcome] will connect any two outcomes.
There is more to be explained
This diagram is easy to understand because the exit criteria outcome is often the entry criteria for a subsequent stage. The model that produced this diagram is more complicated as will be revealed in the next posts. The simple outcomes in the diagram have conceptual validity because we are accustomed to dealing with concepts at different levels of detail, often within a single conversation. We understand an outcome concept such as “ready depart” and know that it also represents a number of more specific outcomes such as the arrival of the conveyor, the arrival of the conveyor crew, etc., and we would expect to be able to look at the next level of detail in the model to verify our understanding. The BACM provides the ability to model concepts at multiple levels of detail; it is the responsibility of the business architect to use this ability wisely.
Note that there is no exit criterion/entry criterion connection between the “Ensure Permission” and the “Depart” stages. The value stream through the “Ensure Permission” stage, has involved a dialog between the traveler and the travel company. The “Depart” stage involves a number of coordinated activities, one of which, the boarding of passengers, depends on the “travel confirmed” outcome. The entry criterion, “ready depart” describes a situation where the departure time has arrived, the conveyor is ready to depart, the ticketed passengers are ready to board and the crew is ready to control the conveyor. All of these criteria must be met, not just that the travelers have tickets. We will show how to model this in a later post.
Though not shown in this diagram, a transportation company may be unable to completely fulfill its responsibilities, resulting in a delay for the traveler or possible cancellation of the remaining travel. Though these situations are infrequent, the business must have policies and procedure to deal with them, and the traveler must have the opportunity to know what these policies and procedure are. If a transportation company is losing business or incurring unnecessary costs because of such situations, the value stream should represent them. In later posts, we will show how to model these situations in the BACM.
Summary
Outcomes are a critical concept for describing behavior in business architecture models. They are a partial description of the expected state of a business on entry to a value stream stage and also on exit. They are partial because they describe the state of a particular set of business objects and not the state of the business as a whole, an intractable result that is the consequence of parts of the business that behave largely independently of each other.
By using outcomes to act as entry and exit criteria, the BACM is able to connect value stream stages together and establish time dependencies between the stages of a value stream. Using these connections, it is possible to analyze the paths through the value stream stages leading to a particular outcome. These paths are important to the task of root cause analysis and to the task of predicting the consequence of changes to a business’s operating model.
In addition, these outcomes can be linked to the value items produced by the value stream stages and to the capabilities that need and produce the outcomes. Consequently, outcomes have an important role in facilitating the analysis of the parts of the business operating model that contribute to the value delivered to the stakeholder. Proper outcome design will yield more useful business architecture models.
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/
About the Author
Jim Rhyne, the author and a partner at Thematix, has chaired the work at OMG (https://www.omg.org) on the BACM specification since 2018. Jim is also a co-founder and director of the Business Architecture Guild whose members, particularly Hermann Schlamann and Lloyd Dugan, have participated in the BACM specification work along with other members of the OMG. The OMG is a standards development organization that is now a part of the EDM Association (https://edmcouncil.org/). Some of the more well known OMG specifications are: CORBA, UML, BPMN, SysML.
Modeling Dynamic Value Streams
This is the first of a series of posts on building advanced business architecture models with the Business Architecture Core Metamodel – BACM. These posts are intended for business architects. They will use models of a fictional transportation company, displayed as diagrams, to exemplify and explain the the concepts in the BACM metamodel.
Before diving in …
A metamodel is essentially a palette of predefined concepts that can be specialized to create a model of something. Models help us understand and reason abstractly about real-world entities and behaviors. Models usually focus on a part or behavior of interest. Business architecture models represent interesting parts and behaviors of a business making use of concepts like capabilities, value streams and business objects. The concepts of the BACM metamodel are closely aligned with the concepts described and exemplified in the Guide to the Business Architecture Body of Knowledge – BIZBOK® Guide, a publication of the Business Architecture Guild®. Many of these concepts are also defined in the glossary section of the Business Architecture Guild website https://businessarchitectureguild.org. Familiarity with these concepts is essential to understanding this series of posts.
Models based on OMG metamodels are typically visualized and edited as “box/line diagrams”; for example, UML model classes are presented as rectangles and model associations are presented as lines that connect boxes. The model diagrams presented in these posts will use a variety of shapes and colors to visualize the non-relational concepts of the BACM (e.g. capabilities, value stream stages, outcomes). The shapes and colors will indicate the metamodel concept, e.g. capabilities are visualized as grey rectangles. Relational concepts will be represented as lines of various widths and colors. The metamodel concept from which a model relation/line is derived can usually be determined by looking at the shapes and colors of the shapes that are connected by the line. The BACM specification does not dictate a visualization of the metamodel concepts and the visualizations presented in these posts are only intended to aid the reader’s understanding about the concepts and how they work together to model a type of business. They do not represent a standard or approved way to represent business architecture concepts.
This series of posts will not illustrate or try to explain the metamodel itself. Anyone familiar with the UML modeling language and the concept of metamodeling can download the specification document from the OMG website and learn the exact details of the metamodel.
What is a “dynamic” value stream?
Value streams are a key concept in business architecture. They represent the stages of work done to generate value for a stakeholder and they produce components of the value proposition made to the stakeholder of the value stream. An airline company promises its travelers a safe, comfortable, on-time travel experience at a competitive cost. The value stream generates the components of the value proposition in a sequence of interactions with the traveler called “stages”. This sequence of interactions gives the value stream its dynamic nature.
The BIZBOK® provides a description of dynamic behavior: “Value stream entrance and exit criteria control and determine flow based on events that occur that are triggered in part by business object state changes.” It does not define entrance and exit criteria or explain what is meant by “flow”, creating a mystery for business architects who want to model dynamic behavior.
The most recent version of the BACM specification, BACM 1.2 – currently in the final approval stage at the OMG, provides metamodeling concepts that can be used to model dynamic value streams. These concepts are borrowed from behavior modeling with finite state machines, a paradigm widely used in technical disciplines such as software engineering and systems engineering, but not so widely used in business modeling. Hopefully, these posts will convince you of the value of using this approach to model the behavior of businesses, following the concepts and principles of business architecture.
Sequencing the “Make a Trip” value stream
The “Make a Trip” value stream represents the stages of value experienced by a traveler interacting with a transportation business such as an airline company. In our example, it has six stages:
Each of these stages sums up the experiences the traveler has while interacting with the transportation company. For example, at the end of the “Plan a Trip” stage, the traveler will have valued the trip options presented, along with the experience of use the transportation company’s website. The “Depart” stage will be valued positively if the gate was comfortable, the boarding process was smooth and the travel was begun on time.
We can create a model from the BACM template and display it as a node/arc graph below. The shapes and colors indicate the BACM type of the model element and the label identifies it in the model. Relationships between shapes are often represented by a line, sometimes with a distinguishing arrowhead on one end. The legend below the diagram explains the shapes.
What are entry and exit criteria?
The BIZBOK® says that entrance and exit criteria are based on business object states. A “criterion” is “a principle or standard by which something may be judged or decided” (Google English Dictionary). So a “criteria” is a collection of rules that when applied to a group of business objects’ states should produce a decision (e.g. true, false, or undecided).
An outcome describes a possible state of the business and its stakeholders. An outcome’s description can be used as a test against a business scenario to see whether the scenario matches the outcome description. For example, if the outcome description is “The traveler has chosen a trip from the selection of trips offered by the travel company.” and the traveler in a scenario has not chosen a trip, the outcome would not match the scenario. If this outcome description is used as an entry criterion for the “Ensure Permission” value stream stage, the entry criterion test would fail and the “ensure Permission” value stream stage would not be entered.
Exit Criteria (Business States) from “Plan A Trip”
When offered a selection of trips, the traveler can: (a) choose a trip from the selection; (b) request a new selection of trips; (c) abandon the search for a trip. These possible states are the exit criteria of the “Plan a Trip” value stream stage. We can represent them as three outcomes in BACM as shown in the following table:
The value stream diagram can be extended to include these outcomes as entry criteria and exit criteria as shown below.
In this diagram, “Travel Need” is both an exit criterion and an entry criterion of the “Plan a Trip” stage. As an exit criterion, it means that the details of the traveler’s desired travel have changed as a result of viewing the offers received. As an entry criterion, these changed details will provoke a new set of travel offers from the transportation company. For example, the cost of the travel departing as originally requested is too high, and the traveler wants to change the departure date in hopes of lowering the fare. In a later post, the “Plan a Trip” stage will be unpacked to see how this repeating behavior can be modeled in more detail.
An Exit Criteria of a Stage is the Entry Criteria for later Stage
An outcome can be either an entry criterion or an exit criterion; the outcome’s role in the value stream stage is determined by a labelled arc connecting the outcome to the value stream stage. As this example shows, an outcome can be both an entry criterion and an exit criterion. If an actual traveler was not satisfied with any of the travel offers received, the traveler might change some parameters of the inquiry and receive a new selection of offers. In effect, the traveler has exited and reentered the “Plan a Trip” stage because the exit criterion and the entry criterion are the same.
On the other hand, a traveler may choose a trip from the selection offered. This state of affairs, represented by the “travel planned” outcome, would allow the “Ensure Permission” stage to be entered.
Connecting All of the Stages
In the preceding diagram, the “travel planned” outcome is the exit criterion of the “Plan a Trip” stage and the entry criterion of the “Ensure Permission” stage. If we make the reasonable assumption that whatever work happens in the “Plan a Trip” stage, that work takes time, we can conclude that the “travel planned” outcome must occur after the “travel need” outcome. Since “travel planned” is an entry criterion for “Ensure Permission”, the stage cannot be entered until the “Plan a Trip” stage is complete. So, the use of outcomes as entry and exit criteria can allow an analysis of the model to establish a time-ordering of the value stream stages. There is no requirement that an exit criterion be an entry criterion for the next stage; an exit criterion outcome may be the entry criterion for a stage several stages to the right or several stages to the left. Look at the following diagram.
The previous diagram has been extended to add entry and exit criteria for the rest of the value stream and handle the case of a multi-segment trip. The “Arrive at Destination” stage has two exit criteria: “trip complete” and “ready depart”. The “trip complete” outcome describes the situation where the traveler has arrived at the final destination; the “ready depart” outcome describes the situation where there is another travel segment to be taken.
The model represented by the preceding diagram tells us that “Depart” occurs before “Enroute” and “Enroute” occurs before “Arrive at Destination”. It also tells us that “Terminate Trip” occurs after all occurrences of “Arrive at Destination”, because the diagram contains no loops after the “trip complete” outcome occurs. Such models can be analyzed for “reachability”, i.e. what paths through sequences of the pattern [outcome, entry criteria, stage, exit criteria, outcome] will connect any two outcomes.
There is more to be explained
This diagram is easy to understand because the exit criteria outcome is often the entry criteria for a subsequent stage. The model that produced this diagram is more complicated as will be revealed in the next posts. The simple outcomes in the diagram have conceptual validity because we are accustomed to dealing with concepts at different levels of detail, often within a single conversation. We understand an outcome concept such as “ready depart” and know that it also represents a number of more specific outcomes such as the arrival of the conveyor, the arrival of the conveyor crew, etc., and we would expect to be able to look at the next level of detail in the model to verify our understanding. The BACM provides the ability to model concepts at multiple levels of detail; it is the responsibility of the business architect to use this ability wisely.
Note that there is no exit criterion/entry criterion connection between the “Ensure Permission” and the “Depart” stages. The value stream through the “Ensure Permission” stage, has involved a dialog between the traveler and the travel company. The “Depart” stage involves a number of coordinated activities, one of which, the boarding of passengers, depends on the “travel confirmed” outcome. The entry criterion, “ready depart” describes a situation where the departure time has arrived, the conveyor is ready to depart, the ticketed passengers are ready to board and the crew is ready to control the conveyor. All of these criteria must be met, not just that the travelers have tickets. We will show how to model this in a later post.
Though not shown in this diagram, a transportation company may be unable to completely fulfill its responsibilities, resulting in a delay for the traveler or possible cancellation of the remaining travel. Though these situations are infrequent, the business must have policies and procedure to deal with them, and the traveler must have the opportunity to know what these policies and procedure are. If a transportation company is losing business or incurring unnecessary costs because of such situations, the value stream should represent them. In later posts, we will show how to model these situations in the BACM.
Summary
Outcomes are a critical concept for describing behavior in business architecture models. They are a partial description of the expected state of a business on entry to a value stream stage and also on exit. They are partial because they describe the state of a particular set of business objects and not the state of the business as a whole, an intractable result that is the consequence of parts of the business that behave largely independently of each other.
By using outcomes to act as entry and exit criteria, the BACM is able to connect value stream stages together and establish time dependencies between the stages of a value stream. Using these connections, it is possible to analyze the paths through the value stream stages leading to a particular outcome. These paths are important to the task of root cause analysis and to the task of predicting the consequence of changes to a business’s operating model.
In addition, these outcomes can be linked to the value items produced by the value stream stages and to the capabilities that need and produce the outcomes. Consequently, outcomes have an important role in facilitating the analysis of the parts of the business operating model that contribute to the value delivered to the stakeholder. Proper outcome design will yield more useful business architecture models.
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/
About the Author
Jim Rhyne, the author and a partner at Thematix, has chaired the work at OMG (https://www.omg.org) on the BACM specification since 2018. Jim is also a co-founder and director of the Business Architecture Guild whose members, particularly Hermann Schlamann and Lloyd Dugan, have participated in the BACM specification work along with other members of the OMG. The OMG is a standards development organization that is now a part of the EDM Association (https://edmcouncil.org/). Some of the more well known OMG specifications are: CORBA, UML, BPMN, SysML.
Tags: