By John Fitch, for Project Performance International (PPI) [Fitch, John. “Extending the Lifecycle Modeling Language (LML) to Enable Decision Patterns and Traceability.” PPI Systems Engineering Newsjournal (SyEN), no. 125, June 2023, pp. 22–35.]
This article is the fourth in a series that introduces readers to a novel pattern-based Decision Management methodology. The author hopes to stimulate engineering practitioners to exploit the principles and practices described in this series to deliver more value to stakeholders, in less time and with fewer resources.
The first article, Introduction to Decision Patterns (PPI SyEN edition #107), recounted the author’s 30+ year journey concerning the discovery, use, and refinement of decision patterns, the conceptual basis behind this construct, and the extensive variety of use cases in which decision patterns have been applied. The article introduced simplified examples of decision patterns for Enterprise Strategy, System/Product Design, Process Capability Design, Service Design, and Curriculum/Courseware Design. The message: Decision patterns are real and have created value.
Building on that foundation, the second article, Decision Patterns – So What? (PPI SyEN edition #111), dove more deeply into the potential value created by eight different aspects of a decision-centric information architecture (aka information metamodel) which, taken together, comprise a novel form of the Digital Thread. Each construct, e.g., the Decision Breakdown Structure (DBS) or Requirement-to-Decision (R-D) traceability, was explored in terms of its representation as class-based entities, attributes, and relationships, how this connected thread of knowledge creates new or improved systems engineering capability, and the practical challenges that have been observed when applying this model to the engineering of diverse types of systems. The message: A Digital Thread that overlooks decision traceability is incomplete.
The third article, Reverse Engineering Stakeholder Decisions from Their Requirements (PPI SyEN edition #113), focused on how to apply decision patterns and decision-to-everything traceability to a specific front-end use case common to any project or strategic initiative. The Decision Blitz process was explained, i.e., how to use a decision pattern to quickly capture your stakeholders’ decisions and to explicitly trace how these decisions have created the boundary conditions for your project. This process provides the engine for a set of project jump-start services that PPI offers our clients. The message: An explicit, context-aware decision model is a great way to jump-start requirements analysis, requirements validation, and solution design.
The principles and practices shared in the first three articles can be used on solution development projects of any type, supported by only the most rudimentary tooling. However, the ability to fully exploit pattern-based Decision Management at enterprise scale and applied to complex systems demands better software solutions. The foundation for such tooling is a well-documented, sufficiently complete, and rigorous modeling language that supports the capture of the essential data required to identify decisions, plan their analysis, inform decision-making, and capture and communicate decision rationale and the downstream consequences of the solution (alternative) that has been chosen for implementation. The message: Houston, we have a problem!
No widely accepted system modeling language or out-of-the-box software toolset fully supports the Decision Management methods, information metamodel, and viewpoints that are advocated in these articles. PPI wants to change this fact by helping standards organizations and engineering tool vendors to fully incorporate the power of decision-centric systems engineering into their offerings.
The content of this article explores an in-progress effort to infuse the Lifecycle Modeling Language (LML) standard [1, 2] with a more comprehensive, yet lean decision-centric information metamodel, and to support the implementation of that metamodel is the Innoslate MBSE software [3] from SPEC Innovations.
At PPI, we pride ourselves on “walking the talk” i.e., we use the principles and practices that we teach our clients when we develop our products and services. Therefore, we chose the design of our Project Decision Jump-Start Services as the demonstration example that would:
We used the Service Design decision pattern [4] and conducted a quick Decision Blitz [5] to frame the decisions that have been made (reflecting our desire for a Decision Management services portfolio) and are yet to be made (the design of the service flows and service delivery platform).
Figure 1: Service Design decision pattern; our starting point
Before conducting the Decision Blitz, an initial set of schema extensions were added to Innoslate, including:
The Service Design decision pattern was imported into Innoslate from Excel and used as the
questioning framework for conducting the Decision Blitz. The Decision Blitz yielded a Decision Breakdown Structure (DBS). The DBS was captured in an Innoslate database query, i.e., a saved/named/retrievable viewpoint, and exported to Excel to share with PPI team members for validation and refinement.
Figure 2: Decision Blitz Results (partial) exported from Innoslate
Because the Design Decision class was created as a subclass of Action, the DBS is not limited to a hierarchical decomposition of thinking tasks. Connecting design decisions with LML’s control flow constructs (Sequential, Parallel/SYNC, Selection/OR, and LOOP) transforms the DBS into a network of serial or parallel thinking tasks and branching logic that can be visualized as an Action Diagram. When coupled with the Task subclass, another subclass of Action, this model can support the assignment of resources and dates/durations to create a comprehensive Trade Study (Decision Analysis) Plan for the project.
Figure 3: Decision Breakdown Structure – Trade Study Plan as an Action Diagram
The Decision Blitz identified two services as central to PPI’s Decision Management services portfolio; therefore worthy of designing/modeling in more detail:
The PPI team originally worked through the Requirements Validation service engagement flow as a simple N-Squared Diagram captured in Excel.
Figure 4a: Requirements Validation Service – Original N-squared Diagram
Mapping the service steps as Actions and the items (work products) flowing between the steps as the LML Input/Output class was a good fit for modeling the engagement flow of each service. Figure 4b shows how a portion of the engagement flow model appears within an Innoslate Action Diagram. Green trapezoids represent required inputs/outputs; gray trapezoids are optional items that provide as-needed feedback to earlier steps.
Figure 4b: Requirements Validation Service – Action Diagram
Although it takes more time and user interface actions to populate and lay out the Action Diagram when compared with the equivalent Excel N-Squared Diagram, the Action Diagram provides additional value by:
Figure 4c illustrates a manually generated definition of both service flows combined in a single diagram. It is included to illustrate the fact that views generated from system models within MBSE tools will likely never fully replace hand-drawn customized art used for communication purposes. However, the graphical richness and flexibility of MBSE tools continue to improve such that they may be an effective 80% - 20% solution and reduce the need for many costly and hard-to-maintain hand-drawn artifacts.
Figure 4c: Combined Engagement Flows – Hand-drawn graphics [6]
The alignment of the information metamodel with desired stakeholder viewpoints has been an iterative process; one filled with tradeoffs in which current tool limitations in visualizing knowledge influence the selection of classes, subclasses, relationships, and attributes. For example, Innoslate enables the definition of database queries that generate tabular views of entities based on their class and relationships; however, filtering out entities in traceability “columns” by their attribute values is not supported at present. This creates the need for more relationships than might be desired. For example, three relationships (analyzes, chooses, rejects) are required between a design decision and an alternative to capture the evolution of thinking that occurs during the Decision Analysis process. It would be simpler if the value of an enumerated Preference attribute (Legacy, Committed, Recommended, Current favorite, Worth considering, Consider but rejected, Just an idea) on each alternative provided the ability to filter unwanted alternatives from various decision-focused views.
Filtering traceability (tabular) views and hierarchical decompositions are also limited to “left-to-right” relationship logic. This limits the ability to view the Requirement-to-Decision-to-Requirement (R-D-R) traceability [7] in which the “decision-in-the-middle” is the starting point and where stakeholders want to see in one view how many requirements/goals influence a single decision, which then creates multiple derived requirements. This points to the need for a many-to-one-to-many diagramming topology (fan-in/fan-out), instead of a long serial thread or simple expanding hierarchy.
Figure 5: Requirement-Decision-Requirement (R-D-R) Traceability Model
Figure 6 illustrates the iterative process of information metamodeling and viewpoint definition, using the data model for decision analysis and typical methods for visualizing decision analysis logic. LML and Innoslate support the ability to visualize Radar Diagrams that show the performance (effectiveness) of alternatives against a set of evaluation criteria. Risks may be represented in a colorized matrix form. However, there is no convenient out-of-the-box ability to define richly structured tables that place Performance information in “cells” defined by relationships with Criterion (the rows) and Alternatives (the columns). This prevents the auto-generation of a typical Evaluation Matrix with an associated Risk Table for the leading alternatives.
Figure 6: Iteration between Information Metamodel and Viewpoints
The author’s experience in defining and extending the schema of other software tools enabled a first cut at mapping the prior art to the LML. The information metamodel shown in Figure 7 is the result of multiple iterations and schema-vs-viewpoint tradeoffs and represents an initial proposal to the LML Steering Committee.
Figure 7: Proposed LML Extensions to Support Decision Management
A brief overview of the proposed LML extensions follows.
LML includes a Decision class, but a review of its attributes, relationships, and uses indicate that this class was suitable for operational decisions, i.e., conditional branching points in an operational process flow. It was not designed to represent a system design or strategy decision, which is defined in the pattern-based Decision Management methodology as “A fundamental question or issue that demands an answer or solution. A subset of the overall problem to be solved”.
As noted earlier, the Design Decision class was created as a subclass of LML’s Action class; as a result it inherited useful decision planning attributes such as Start (date), Duration, and Percent Complete and relationships such as:
It was relatively simple to add attributes and relationships (that have proven useful in past Decision Management engagements) to the Design Decision class. Figure 8 illustrates how those extensions appear within the Innoslate Schema Editor.
Figure 8: Design Decision class attributes and relationships
A Criterion is a subclass of Requirements used to evaluate (screen and score) the value delivered by an alternative in a design decision. A Criterion clarifies the intent of a system requirement (and its associated goal value) in the context of a specific decision. Beyond the attributes inherited from the Requirement class, a Criterion includes:
These attributes support the screening and weighted scoring processes that are central to multicriteria decision-making.
A Criterion has several unique relationships that support decision analysis:
The Alternative class, a subclass of Asset, represents a possible solution to the question posed by a design decision. Alternative attributes include:
Alternative relationships include:
Performance, a subclass of Measure (a subclass of Characteristic), represents the estimated or measured effectiveness of an alternative in a design decision, as evaluated against the threshold and goal values for a specific criterion. Performance may be expressed as qualitative text or as quantitative real number estimates (with units). Performance attributes include:
As stated earlier, Performance entities populate the cells in an Evaluation Matrix at the “intersection” formed by two relationships:
The Evaluation Matrix for a design decision with ten criteria and five alternatives would, if fully populated, have fifty Performance entities. In practice, some alternatives may be eliminated from further evaluation when they fail to meet the Threshold value specified in a Criterion; therefore, not every Alternative-Criterion pair must have a Performance entity. Some decisions may have more than one Performance entity for each Alternative-Criterion pair if multiple estimates are made by different methods (extrapolation from expert experience, back-of-the-envelope calculation, math model, simulation, prototype testing, or system testing).
LML’s Risk class was well matched with the common usage of risk as the expression of uncertainty, i.e., a potential tie-breaker between alternatives in decision-making. Because Alternative was defined as a subclass of Asset (which possesses an Asset -> causes -> Risk relationship), no additional schema changes were required to associate risks with alternatives. Three additional attributes were proposed for a risk to provide the ability to describe a general strategy on how risk might be mitigated:
The existing relationship, i.e., Risk -> mitigated by -> Action, Asset, or Characteristic, may then be leveraged as a method to detail the risk mitigation strategy in terms of process steps, new components, or mitigation requirements.
Though less often considered in decision analysis, an Opportunity class (subclass of Risk) which expresses how an alternative might perform better than expected, would be a useful addition to LML. Opportunity attributes that express how to improve the odds (probability) and positive impact (consequence) might include:
The LML standard defines a set of Mandatory diagrams including:
Additional useful diagrams that commonly support full lifecycle engineering and are relevant to Decision Management include:
Innoslate supports the rendering of the content of most of the diagrams mentioned above in tabular form, both within the application canvas and as Excel file reports.
Beyond the visualizations defined in the LML standard, Innoslate supports a Radar Diagram that may be used to represent the relative effectiveness of an alternative against the criteria in a design decision. This is possible “out-of-the-box” because:
Figure 9: Radar Diagram of Effectiveness of Innoslate as a Service Delivery Platform Alternative
From the “chosen” alternatives in the Decision Jump-Start Services decision model, the PPI team captured a set of derived requirements and design goals for a proposed Service Delivery Platform. To date, ~40 requirements have been identified, mostly functional and performance. An example of these requirements, associated with Step DS.9 in the Requirements Validation service flow, is shown in Figure 10, below. These requirements address the two ways that a decision (through the alternative chosen) creates new “derived” requirements that constrain the design of the system of interest, i.e., the Decision-to-Requirement traceability aspect of the Digital Thread.
Figure 10: Functional and Performance Requirements (with Rationale) associated with an Action.
Note that significant communication value can be provided by populating the Rationale attribute for each requirement. This illustrates how a lean, Entity-Relationship-Attribute (ERA) information metamodel can improve communication and alignment between stakeholders and solution developers.
The following is an initial wish list of LML extensions and Innoslate enhancements that would most significantly improve our ability to support a rich set of Decision Management services on this platform:
Numerous other language and tool extensions may be discovered through ongoing engagement between the PPI and LML/SPEC Innovations teams.
Approximately 50 hours of effort has been invested by PPI in:
Next steps include:
The process used in this language/software extension project can be generalized to other language standards and MBSE tools. Plans are underway to begin engagement with the SysML community so that future SysML tools will fully support advanced pattern-based Decision Management capabilities in their native form.
[1] Lifecycle Modeling Organization, 2022. Lifecycle Modeling Language (LML) Specification, Version 1.3, http://www.lifecyclemodeling.org/spec/1.3, 16 June 2022.
[2] Vaneman, W., Sellers, J. and Dam, Steven, 2018. Essential LML – Lifecycle Modeling Language (LML): A Thinking Tool for Capturing, Connecting and Communicating Complex Systems. https://specinnovations.com/download-essential-lml-ebook. SPEC Innovations. Manassas, Virginia, USA, 2018.
[3] SPEC Innovations, 2023. Innoslate Product Overview. https://specinnovations.com/innoslate.
[4] Fitch, J.A., 2021. Introduction to Decision Patterns, Project Performance International Systems Engineering Newsjournal, PPI SyEN 107, December 2021.
[5] Fitch, J.A., 2022. Reverse Engineering Stakeholder Decisions from Their Requirements, Project Performance International Systems Engineering Newsjournal, PPI SyEN 113, June 2022.
[6] Project Performance International, 2023. Project Decision Jump-Start Services, https://www.ppiint.com/corporate-services/project-decision-jump-start-services/.
[7] Fitch, J.A., 2022. Decision Patterns – So What?, Project Performance International Systems Engineering Newsjournal, PPI SyEN 111, April 2022.
John Fitch is a Principal Consultant and Course Presenter for Project Performance International. John brings over four decades of systems engineering, engineering management, consulting, and training experience to the PPI team. In 2012, John was certified by INCOSE as an Expert Systems Engineering Professional (ESEP). Within the field of systems engineering, John’s career has focused on decision management, requirements management, risk management, systems design &
architecture, product/technology road mapping, and innovation. In addition to defense/aerospace, John has guided initiatives in domains such as communications systems, software, energy, nanotechnology, medical devices, manufacturing systems, knowledge management, and business process improvement.
.svg){kind=small}
SPEC Innovations Team : 4/16/24 11:50 AM
By John Fitch, for Project Performance International (PPI) [Fitch, John. “Rethinking Requirements Derivation: Part 2.” PPI Systems Engineering...
SPEC Innovations Team : 4/8/24 3:35 PM
By John Fitch, for Project Performance International (PPI) [Fitch, John. “Rethinking Requirements Derivation: Part 1.” PPI Systems Engineering...
.svg){kind=small}
Steven Dam : 12/4/23 5:46 PM
Don't feel up to reading? Watch the recording! What is Verification & Validation (V&V)? The common definitions for V&V are: verification is “the...
