Configuration Management Guide for Data-Driven Systems Engineering

Data-Driven Systems Engineering (DDSE) poses distinct challenges in Configuration Management. This guide aims to outline strategies for implementing Configuration Management in an Innoslate-powered Digital Engineering Environment (DEE). Innoslate, a comprehensive model-based systems engineering and requirements management solution, offers a rich feature set that establishes an authoritative source of truth in an integrated DEE.

1. Configuration Management

Configuration Management (CM) refers to the methods used for maintaining control of a system’s requirements, architecture, state, and supporting processes throughout its lifecycle. It is typically described, to varying levels of detail, within a program’s Systems Engineering Plan (SEP) and Configuration Management Plan (CMP).

NIST SP 800-53 CM-2¹ defines baseline configurations as “documented, formally reviewed, and agreed-upon specifications” that “serve as a basis for future builds, releases, or changes.” Configuration change controls formalize how changes to a baseline configuration are made. NIST SP 800-53 CM-3² states that configuration change control includes:

• Determining and documenting the types of changes that are configuration-controlled
• Reviewing and approving/disapproving configuration-controlled changes
• Documenting configuration-controlled change decisions
• Implementing approved configuration-controlled changes
• Monitoring and reviewing configuration-controlled changes
• Retaining records of configuration-controlled changes

Two additional aspects of configuration management are:

• Identifying proposed configuration-controlled changes
• Implementing change control mechanisms

Figure 1‑1 shows the CM actions that will be discussed within this guide. These actions fall within three major categories: Configuration Baselining, Change Management, and Configuration Control.

Figure 1‑1. CM Actions

2. Managing Change

2.1 Configuration Baselining

An Innoslate baseline consists of any approved configuration, such as a specification functional architecture, or physical architecture. It includes specified Innoslate entities along with designated relationships.

2.1.1 Baselining Documents

Innoslate Documents include specifications and plans. They consist of hierarchically sequenced Statements and Requirements entities. Innoslate Documents can be baselined by using Innoslate’s Document Baseline feature. The Document Baseline feature leverages entity history to capture and store document baselines (i.e., snapshots in time). Document baselining prevents modifications to the baseline, but not the current state of the entities comprising the document. Document baselining does not prohibit document deletion, which must be addressed through other configuration controls.

Baselined Innoslate Documents should be retained in the organization’s CM system. For CM purposes retain:

• Externally viewable document - generate from within Documents View by selecting ‘Report’ then ‘Basic Document Output (DOCX)’
• Products necessary to reconstruct document within Innoslate - generate from within Documents View by selecting ‘Report’ then:
   
  • Document ZIP Output (INNO) backup file with the ‘Include Baselines’ option
  • Basic Tabular Output (CSV) file with ‘Global ID’ and ‘Relationships’ selected

2.1.2 Baselining Architectures

Architectures include any set of related Innoslate entities. Typically, this will include entities supporting physical, functional, or hierarchical models. These entities may align to DoDAF or UAF Viewpoints. Architectures are baselined through management declaration. This declaration should be supported by CM policies, clearly state what constitutes the baseline, and institute baseline configuration controls. For example, a physical architecture baseline may include component level Asset entities with ‘decomposes’, ‘connected to’, and ‘performs’ relationships while specifically excluding ‘decomposed by’ relationships.

Baselined architectures should be retained in the organization’s CM system. For CM purposes retain:

• Products necessary to reconstruct document within Innoslate - generate from within Database View by selecting ‘Report’ then:
   
  • Innoslate ZIP Output (INNO) backup file with the ‘Include Baselines’ option
  • Basic Tabular Output (CSV) file with ‘Global ID’ and ‘Relationships’ selected
• Key portions of architecture as an externally viewable document – generate by navigating to the architecture’s root entity, opening in Entity View, selecting ‘Report’, and ‘Hierarchical Report (DOCX)’ with desired diagram types

2.2 Change Management

Change Management is the process of managing changes to configuration baselines. It consists of seven CM actions: Define, Identify, Review, Decide, Implement, Verify, and Retain.

2.2.1 Define

Policies should be established which define the types of changes that are configuration-controlled at a given point in time. A notional configuration-controlled change policy is shown in Table 2‑1. Configuration-controlled changes require formal approval before implementation.

Table 2‑1. Notional Configuration-Controlled Change Policy

2.2.2 Identify

Proposed changes to configuration-controlled items within Innoslate should be identified in a Change Request (CR) or Engineering Change Proposal (ECP). A CR establishes the impact of proposed baseline changes and documents the Innoslate implementation steps. CR formats may vary, but should include the following key elements:

• Information – provides administrative information on the CR including number, title, submission date, originator, urgency (e.g., Routine, Emergency), and type (e.g., Editorial, Technical)
• Description – provides a high-level description of what the change will accomplish
• Rationale – describes why it is necessary to implement the change
• Proposed Solution Table – provides detailed steps for implementing the CR in Innoslate
• Status – describes the location within the CR workflow

The Proposed Solution Table consists of sequentially executed steps to be followed in Innoslate by the implementer. It should minimally include the following columns:

• Entity Information – contains the entity’s number and/or name
• Location – contains the entity’s URL
• Change Description – contains a description of the change to the entity
• Change Type – specifies the type of change, to include: Add, Modify, or Delete
• Change Category – specifies the entity attribute name, label, or relationship to be changed (e.g., Name, Description, Label, Relationship)
• Current Value – contains the current value associated with the Change Category, if applicable
• Proposed Value – contains the proposed value associated with the Change Category
• Notes – contains any additional explanatory notes to clarify the proposed change

2.2.3 Review

CRs are reviewed by a Change Control Board (CCB). The CCB should be comprised of management, CM personnel, and technical experts. CCB meetings held to review CRs should include both the CR originators and implementers in attendance.

2.2.4 Decide

The CCB will approve or disapprove proposed baseline changes detailed in CRs. CCB decisions must be formally documented and retained. This can occur within the CR form or through the use of related Decision entities (i.e., Decision ‘enabled by’ Artifact).

2.2.5 Implement

Approved CRs are implemented by a designated implementer with the appropriate Innoslate project permissions. The CR’s Proposed Solution Table steps should be implemented in the sequence provided. Failure to adhere to the CR’s step execution sequence may result in broken dependencies (e.g., a link to an entity that has not yet been created) or confusion as to which parts of the table remain to be implemented. For large tables, the implementer should consider marking the individual steps as complete.

2.2.6 Verify

CM personnel should monitor and verify changes to configuration-controlled data. Erroneous or unauthorized changes should be backed out and logged.

For Innoslate Documents, CM personnel should review Post Baseline Change Reports (PBCRs). PBCRs provide a detailed log of all changes occurring to a document’s entities following each baseline. PBCRs should be compared against the approved CR’s Proposed Solution Table.

For architectures, CM personnel should review CR project modifications by comparing individual entities against the approved CR’s Proposed Solution Table.

2.2.7 Retain

Retain records of all configuration-controlled changes. If CRs are implemented as Innoslate Documents, retain them for CM purposes as externally viewable documents. To generate an externally viewable document from within Documents View, select ‘Report’ then ‘Basic Document Output (DOCX).’

2.3 Configuration Control

Innoslate employs multiple data control mechanisms that can be used to prevent unauthorized data modifications as shown in Figure 2‑1.

Figure 2‑1. Data Controls

2.3.1 Project Access Permissions

Project access permissions control the privileges that users have within a project. Segregation of data across projects allows different users and user groups to have permissions appropriate to the program phase. For example, as shown in Table 2‑2, all developer users may initially have Collaborator access to a system-level project. Following PDR, non-SE users may be downgraded to Reviewer access.

Table 2‑2. Notional Project Access Permissions

Optimal use of project access permissions requires upfront planning in conjunction with the development of a Conceptual Data Model (CDM).

2.3.2 Document Baselining

Document baselining prevents modifications to the baseline, but not the current state of the entities comprising the document. Document baselining does not prohibit document deletion, which must be addressed through other configuration controls.

2.3.3 Entity Locking

Entity locking prevents changes to entity attributes, labels, and relationships. Entities can only be unlocked by the locking collaborator or project owners. Entity locking is frequently used to provide protection from inadvertent or unauthorized changes being made by project Collaborators.

3. Implementing Change Management

3.1 Change Requests (CRs)

There are two primary options for implementing CRs within Innoslate. Option 1 consists of an Innoslate-based CR form implemented within Documents View. This CR form can contain either a textual (Option 1a) or dynamically constructed (Option 1b) Proposed Solution Table. Option 2 consists of storing Excel CR forms as Artifact entity attachments. The benefits and required effort for the CR implementation options are shown in Figure 3‑1.

Figure 3‑1. CR Implementation Option Benefits and Effort

3.1.1 Option 1a: Innoslate-based CR with Textual Proposed Solution Table

CR Implementation Option 1a consists of creating and saving a CR template within Documents View.

First, use the Schema Editor to create a “CR Document” label for class Artifact. Then, create a blank document of type ‘CR Document’ and add content sections as specified in 2.2.2 Identify. The Proposed Solution Table should be inserted with the ‘Table…’ insert option. Back up your document by running a ‘Document ZIP Export (INNO)’ report.

Add the CR template to the project from Documents View by selecting ‘More’, selecting, ‘Template,’ entering, “Change Request,” for the template name, and selecting, ‘Create.’ This will result in a new Artifact named, ‘Change Request,’ being created. It is recommended to lock that entity to prevent inadvertent deletion.

New CRs are created by selecting document type ‘CR Document’, template ‘Custom Template’, and custom template ‘Change Request’.

3.1.2 Option 1b: Innoslate-based CR with Dynamically Constructed Proposed Solution Table

CR Implementation Option 1b is implemented in the same way as Option 1a with the exception of the Proposed Solution Table. Option 1b’s Proposed Solution Table is dynamically created by querying the project database for the associated solution steps.

Use the Schema Editor to create a “CR Solution Step” class. “CR Solution Step” should be a subclass of Statement and minimally contain the attributes shown in Table 3‑1.

Table 3‑1. CR Solution Step Attributes

Create new CR Solution Step entities from the database view. CR Solution Steps should be numbered sequentially using their corresponding CR number prefix.

Add the Proposed Solution Table to the CR template by inserting it with the ‘Table Notation…’ insert option. Within the ‘Insert Table Notation’ pop-up as shown in Table 3‑2, enter the solution step query, select the ‘CR Solution Step’ attributes, and enter a query limit high enough to retrieve all of the CR’s solution steps.

Table 3‑2. CR Solution Step Insert Table Notation Pop-Up

When new CRs are created from the CR template, the table notation query will need to be updated by the user to retrieve CR Solution Steps corresponding to the new CR number.

A CR’s Proposed Solution Table can be exported as an Excel spreadsheet for the implementer. From Database View, query and sort for the CR’s solution steps (e.g., order:number class:”CR Solution Step” number:CR.###.% where ### is the CR number). Then, generate an Entity Table Report with the CR Solution Step attributes from Table 3‑1.

3.1.3 Option 2: Attach Excel CR to Artifact

CR Implementation Option 2 consists of creating an Artifact entity for each Excel CR. This Artifact should be numbered to match the CR number contained within the Excel CR form. The Excel CR is added to the Artifact as an attachment.

3.2 CR Workflow

CR workflow can be modeled in Innoslate as a State Machine Diagram (SMD) as shown in Figure 3‑2.

Figure 3‑2. CR Workflow State Machine Diagram

The CR workflow SMD can be implemented in a project’s schema by:

• Creating a ‘Change Request’ class with an enumerated status field representing CR states.
• Creating a ‘Change Request Status’ workflow to implement CR state transitions.
  
  

3.2.1 Implementing CR Workflow States

Use the Schema Editor to create a “Change Request” class. “Change Request” should be a subclass of Artifact and minimally contain an enumerated attribute named “Status”. “Status” should have values matching the states shown in Figure 3‑2: ‘Proposed’, ‘Approved’, ‘Rejected’, ‘Implemented’, and ‘Closed’. Set the default value for “Status” to ‘Proposed’.

If CRs are implemented as Innoslate Documents (Options 1a and 1b), then:

• Use the Schema Editor to update the ‘CR Document’ label to add the class ‘Change Request.’
• Create a CR template based on the ‘Change Request’ class
  • If a CR template does not exist, then:
    • Create the document as described in Section 3.1.1
    • Before adding it as a template, navigate to Database or Entity View and transform the source Artifact to the ‘Change Request’ class
    • Reopen the document in Documents View and add it as a template
  • If a CR template already exists, then:
    • Create a new unpopulated document from the CR template
    • Navigate to Database or Entity View and transform the source Artifact for this new document to the ‘Change Request’ class
    • Reopen the new document in Documents View and add it as a template
    • Lock the new template’s Change Request entity in Database or Entity View
    • Delete the old templates Artifact entity
  • If desired, navigate to Database or Entity View and transform the source Artifacts for any legacy CRs to the ‘Change Request’ class

If CRs are implemented as Artifacts with Excel CR attachments (Option 2), simply create new ‘Change Request’ class entities for all future CRs. Existing CRs can be transformed from Artifact to the ‘Change Request’ class.

3.2.2 Implementing CR Workflow State Transitions

To implement the CR workflow state transitions, select, ‘Workflow,’ from within the Schema Editor. Select, ‘Add Workflow Class,’ and the ‘Change Request’ class. If necessary, select the ‘Status’ enumerated property. Define the workflow transitions for each ‘Status’ state by selecting ‘Add Transition’, the name of the target transition state, users/teams with permission to transition the state, and users/teams notified of the state transition.

For example, in Figure 3‑2 the ‘Proposed’ state has two transitions. When defining the workflow, ‘Add Transition’ will be used to select ‘Approved’ creating the ‘Proposed to Approved’ transition, and to select ‘Rejected’ creating the ‘Proposed to Rejected’ transition as shown in Figure 3‑3.

Figure 3‑3. ‘Proposed’ Status Transitions

The Innoslate CR workflow should be used in conjunction with CR procedures defined in the organization’s CMP. From within Database View, CR status reports can be generated using the Entity Table Report with ‘Status’ selected as a column attribute.

4. Conclusion

Innoslate allows an organization to maintain control of a system’s requirements, architecture, state, and supporting processes throughout its lifecycle. It provides versatile features for controlling and tracking change at different levels of granularity. Innoslate provides the capability to implement and supplement and processes within an organization’s CMP.

References

[1]U.S. Department of Commerce, NIST SP 800-53, Rev. 5 Security and Privacy Controls for Information Systems and Organizations § (2020).

[2] U.S. Department of Commerce, NIST SP 800-53, Rev. 5 Security and Privacy Controls for Information Systems and Organizations § (2020).