Extending LML to Enable Decision Patterns and Traceability

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.]

Introduction

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.

Our Approach

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:

• Highlight the decision-focused extensions (classes, attributes, and relationships) needed in the LML.
• Communicate the characteristics (requirements and goals) that PPI desires in a Service Delivery Platform (SDP) for our evolving portfolio of Decision Management services.
• Prototype multiple high-value decision-centric digital threads by capturing requirements,
  decisions, solutions, etc. in Innoslate.
• Create viewpoints to visualize these digital threads, leveraging the existing capabilities of Innoslate.
• Iterate the proposed information metamodel and viewpoints to maximize the value that can be delivered without significant modifications to LML and Innoslate.
• Define the requirements and goals that would fill key language and tool gaps in support of our vision of a pattern-based Decision Management capability with decision-to-everything traceability.

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:

• Creation of a new Design Decision class, a subclass of LML’s Action class.
• Creation of a new Alternative class, a subclass of LML’s Asset class.
• Various Design Decisions and Alternative attributes and relationships.

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:

• Requirements Validation
• Project Decision Planning

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:

• Modeling the control flow (branching logic) of the Action Diagram by defining serial and parallel (or conditional, iterative, or looping) actions.
• Providing the ability to hide (by filtering) or to abstract (by roll-up) details that are important to one audience, but not another.
• Supporting capture of additional attributes associated with the Action or Input/Output entities.
• Creating entities that may participate in other views based on relationships not shown in the N-Squared Diagram.
• Supporting model consistency checking, e.g., detecting dangling actions, inputs, or outputs.

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

Proposed Metamodel/Schema Extensions

A brief overview of the proposed LML extensions follows.

Design Decision

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:

• generates or receives -> Input/Output
• depends on -> Action
• consumes -> Resource
• performed by -> Asset

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

Criterion

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:

• Threshold
• Goal
• Weight

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:

• constrains -> Design Decision
• evaluates -> Performance
• refines -> Requirement

Alternative

The Alternative class, a subclass of Asset, represents a possible solution to the question posed by a design decision. Alternative attributes include:

• Preference
• Selection Rationale
• Start Date
• End Date
• Total Weighted Score
• Normalized Weighted Score

Alternative relationships include:

• analyzed by, chosen by, or rejected by -> Design Decision
• exhibits -> Performance
• derives -> Requirement
• implemented by -> Task
  
  

Performance

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:

• Basis of Estimate
• GO-NO GO
• Score

As stated earlier, Performance entities populate the cells in an Evaluation Matrix at the “intersection” formed by two relationships:

• exhibited -> Alternative
• evaluated by -> Criterion

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).

Risk (and Opportunity)

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:

• Mitigation – Preventive
• Mitigation – Contingent
• Mitigation – Monitoring

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:

• Growth – Promoting
• Growth – Exploiting
• Growth – Monitoring
  
  

Thoughts on Data Visualization (Viewpoints)

The LML standard defines a set of Mandatory diagrams including:

• Action Diagram (Mandatory for Action entities with children)
• Asset Diagram (Mandatory for Asset entities with children)
• Spider Diagram (Mandatory for traceability across classes)

Additional useful diagrams that commonly support full lifecycle engineering and are relevant to Decision Management include:

• Class and Entity Relationship Diagrams (to model information architecture alternatives)
• Timelines (to model the Trade Study plan that sequences decision analysis and associated modeling, simulation, prototyping, and testing tasks that inform decision-making)
• Hierarchy Diagram (to model any decomposition structure)
• Risk Matrix (to map risks to a probability and consequence grid)

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:

• The Radar Diagram is implemented to display Characteristics associated with Assets
• Characteristic is the parent class of Measure, the parent class of Performance.
• Asset is the parent class of Alternative.

Figure 9: Radar Diagram of Effectiveness of Innoslate as a Service Delivery Platform Alternative

Gaps to Fill

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:

• General purpose entity -> instantiates -> entity relationship with one-to-multiple and branch entity instantiation tools to accelerate the creation of a DBS from a decision/criteria pattern. Distinguish pattern instantiation from other traceability relationships.
• Requirement-Decision-Requirements (R-D-R) traceability viewpoints (graphical and tabular) with a decision-in-the-middle (many-to-one-to-many topology) built on a general fan-in/fanout traceability engine.
• Configurable multiple-panel “boxes” for displaying user-selectable attributes, relationships, and relationship targets for any class of entity. Supports visualization of a Decision Breakdown Structure in two or three-panel box format (Decision, Alternatives analyzed or chosen, Decision Status, or the performed by relationship).
• Evaluation Matrix viewpoint that supports direct input of Performance entities and
  associated attributes in the cells formed by rows (Criterion) and columns (Alternatives).
  Ability to generate and display weighted scores and total weighted scores.
• Ability to overlay and selectively compare the Radar Diagrams of multiple Alternatives (Assets).

Numerous other language and tool extensions may be discovered through ongoing engagement between the PPI and LML/SPEC Innovations teams.

Conclusions

Approximately 50 hours of effort has been invested by PPI in:

• From-scratch learning of LML and the Innoslate MBSE software.
• Extending the LML information metamodel and Innoslate schema by 5 classes and
  associated attributes and relationships.
• Using the extensions to create an Innoslate Decision Pattern Services project with ~700
  entities – decisions, requirements, actions, etc. with ~20 views and reports.
• Summarizing an initial set of proposed requirements for supporting pattern-based Decision Management in the language and software.

Next steps include:

• Completing the definition of proposed requirements for full support of the Decision
  Analysis process to enable a Decision Coaching service that will follow the Decision JumpStart services.
• Continuing engagement with the Lifecycle Modeling Organization and SPEC Innovations to negotiate the best implementation of extensions to the standard and enhancements to the software.
  
  

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.

References

[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.

About the Author

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.