Developing A Systems Engineering Capability That Meets the Needs of Your Organization

This is part 5 of the blog series “Integrated Data as the Foundation of Systems Engineering.

In part 4, Practicing SE from a data-Centric Perspective, I went into more detail concerning what it means to practice SE from a data-centric perspective providing guidance that can be used to understand and successfully create and manage the integrated dataset within an organization.   In the first section, I discussed the need for enterprise and business management buy in and support needed to transition the organization from their present state to practicing SE from a data-centric perspective.  In the second section, I introduced key concepts from big data including: data governance, information technology, and data management.  In the third section, I discussed the current state of most organizations concerning practicing SE from a data-centric perspective and the path needed to move from the current state to a future state where the projects within an organization practice SE from a data-centric perspective using a common, integrated dataset.

In this part 5, I focus on topics to help organizations develop a systems engineering capability that meets the needs of their organization.

In the first section of part 5, I present the concept of SE capability levels (SCLs) to help organizations assess what their current SE capability is from an integrated dataset perspective and provide a roadmap to get to their desired level of SE capability based on their organization’s specific needs.  This section also includes a link to another blog on the selection of an SE toolset that is needed to implement the chosen SCL is discussed.

In the second section of part 5, I provide advice to help sell the idea of moving toward a data-centric practice of SE to management and then implementing the chosen SCL..

Levels of SE Capability

It is important for the enterprise to first decide how, and to what extent, they are going to provide the capability for projects to implement SE from a data-centric perspective.  This decision must be based on the needs of the enterprise while being scaled to the level of rigor that allows the system lifecycle process activities to be performed by the projects with an acceptable level of risk.  The INCOSE SE HB (INCOSE 2015), Chapter 8, Tailoring Process and Application of Systems Engineering, provides excellent guidance in tailoring the SE lifecycle processes to meet the needs of the project.

Once this is decided, the individual projects need to determine what level of SE capabilities they need to successfully manage the development of their system of interest.  Once they have decided on the level of SE capabilities needed, they can then take the necessary actions needed to provide those capabilities.  These actions include:

*  developing organizational policies, processes, and procedures needed to implement SE from a data-centric perspective;

*  providing requirements to the IT department concerning the IT infrastructure needed, so these capabilities can be realized;

*  selecting and procuring an SE toolset that supports the level of SE decided on; and

* training their mangers and systems engineers in the use of the SE toolset and processes.

It is important to realize that this journey towards an integrated dataset can be made in a series of small steps.  The enterprise doesn’t have to jump to a completely integrated dataset at the beginning of their journey.

Some organizations may want to start with an electronic (vs. hard copy documents) requirement management capability with the ability to support allocation and traceability.  Later, they can add the capability to manage the requirements and other work products over the lifecycle of the project, linking requirements to design, and linking requirements to verification and validation planning work products.  The project can identify measures to track system development activities and identify and manage risks.  They can then add the capability to use non-language-based diagrams as single entities without the underlying data, e.g., functional flow diagrams or context diagrams, and link the requirements to those diagrams.  From there, the capability for analytical modeling can be added where the various diagrams, requirements, and other work products are visualizations of an underlying dataset (only if there is some benefit to be gained from doing so.)  Taking this path can be a slow journey and it will be some time before the benefits of practicing SE from a data-centric perspective discussed earlier can be realized.

An alternate approach some organizations may want to implement (and may need to based on the complexity of their systems) is to start with an analytical modeling capability from the beginning. This will allow them to incrementally integrate requirements development and management with other work products and their underlying data and information into a common, integrated dataset as well and link work products from all lifecycle process activities together.  This path to achieving a common, integrated dataset will be shorter, speeding up the journey resulting in the organization being able to realize the benefits of practicing SE from a data-centric perspective much sooner than the previous approach.

No matter which approach your organization takes, each step in the journey adds capabilities that will lead towards establishing an integrated dataset as the foundation of all project lifecycle process activities, enabling the project to meet the challenges of increasingly complex systems and realizing the benefits of practicing SE from a data-centric perspective.

From an IT infrastructure requirements perspective, it is best for the projects to communicate the end state envisioned, so the IT department can provide the IT infrastructure and SE toolset that is scalable to be able to handle the needs of the organization for the envisioned end state.

To help in this journey to implement SE from a data-centric perspective, it is useful to define different levels of SE “capability”.   What specific SE capabilities a project needs depends on their product line, its complexity, issues they are having and want to address, workforce knowledge and experience, the SE toolset being used, and the organization’s processes, standard operating procedures, and work instructions.

Below are proposed SE Capability Levels (SCLs).  Each level assumes the previous level has been experienced and surpassed.  As the organization progresses through the levels, their SE capability level increases. As the SCL increases, the organization is getting closer to realizing the intent of the MBSE Initiative and will be moving closer to realizing INCOSE’s Vision 2025.  The journey ends when the organization has reached the SCL that meets the needs of the organization.

(Note: While conceptually, the SCLs defined herein are similar to other capability maturity models defined by other institutions, the SCL concept is not the same.  Other capability maturity models focus on an organization’s processes, their definition, their execution, and their enforcement.  The SCLs defined herein focus on the capability of an organization to practice SE from the data-centric perspective discussed in this document, with the end state where all projects in the enterprise establish a common, integrated dataset consistent with the enterprise’s documented ontology and master schema.)

SCL 0: The various SE lifecycle process are divided across organizational units operating in stovepipes.  The enterprise has no documented data and information governance policy. There is no defined master ontology for the enterprise nor project. The primary toolset used by the project is common office applications: word-processing, spreadsheets, presentations, and basic drawing and diagraming tools.  The primary focus of the project is on hardcopy, printed documents, design description documents, ICDs, CAD drawings, etc.

While the files representing these work products are stored electronically, they exist as independent files (vs. in a database containing underlying data) making it difficult to share information contained within the files. Often there are inconsistencies between work products, it is difficult to assess completeness, configuration management is a nightmare, few, if any, work products are linked together across lifecycle processes, and it is difficult to identify and manage dependencies between work products. The project baselines and configuration manages the printed documents or electronic versions of the printed documents (e.g., pdf files).

Unfortunately, this level represents many legacy system development processes and associated shortcomings seen in today’s world of more complex systems.  These organizations are not equipped to deal with the ever increasingly complex systems and cannot realize any of the benefits of practicing SE from a data-centric perspective listed earlier.

SCL 1: The various SE lifecycle process are divided across organizational units operating in stovepipes. The enterprise has not documented nor implemented a data and information governance policy. There is no master ontology defined for the enterprise nor project.  The project has not included data management concepts in their PMP nor SEMP.  The project has no IMP and have not developed a master schema for the databases representing the project’s work products. There is no common, integrated project dataset.

Some parts of the enterprise may be using diagraming or modeling tools, requirement management tools (RMTs), CAD tools, etc. other than standard office tools, but in isolation from other parts of the system lifecycle process and organizations responsible for those processes.  Legacy PM tools are used to develop and manage PM work products and their underlying data and information (e.g., budgets, schedules). The PM and SE tools store the data and information representing the various work products either as electronic files or in their own proprietary database using a proprietary schema.  Because there is no project master schema, the data and information in these individual databases and files are not compatible – making it difficult to share data between tools and organizations.

Some work products may be linked within the lifecycle stovepipe, but not necessarily across lifecycle stages.  For example, allocation, traceability, parent/child, and interface requirement relationships are managed within the RMT, but the requirements are not linked to diagrams, models, design, systems verification, nor system validation work products.  Models developed by the project focus on functionality, performance, and interfaces, but do not reflect quality, design and construction standards, nor physical attributes of the system.

A minimum of work product attributes and associated measures are defined, but the measures (and reports based on the measures) are not consistent across organizational units and lifecycle process activities and are often out of date. The project has a reliance on common office applications and paper based documentation.  Printed or electronic file versions of the work products are what is baselined and configuration managed by the organization.

A diagram of the various work products datasets for organizations at SCL 1 closely resembles that shown in Figure 6.

SCL 2:    Stovepipes are mostly gone, but some still exist. The enterprise has not yet documented and implemented a data and information governance policy.  However, a master ontology for project has been defined.   The project has included data management concepts in their PMP and SEMP and has an IMP. The project has started to establish a common, integrated dataset with a master schema defined and uses this integrated dataset to manage work products and their underlying data across all lifecycle processes.

Most of the work products are being developed using SE tools vs office applications.  However, a variety of legacy PM and SE tools (e.g., budgets, schedules, requirements) are still used to develop and manage some work products and their underlying data independent from other tools.  While the project has developed a master schema for their integrated dataset, many of the SE tools store the data either as electronic files or in their own proprietary database using a proprietary schema.  Because of the use of SE tools with proprietary schema, the data and information in these individual databases is not compatible – making it difficult to share data between tools and organizations.

To share the data and information, Extract, Transform, Load (ETL) tools are developed or procured and used to input the data from the external databases into the project’s integrated dataset. Any changes to the external SE tool databases must go through the ETL process before the changes are included in the integrated dataset.  This makes it difficult to keep the data and information in the integrated dataset current and consistent across all lifecycle process activities and with the external databases.  Anyone doing analysis, modifying work products and their underlying data and information, or generating reports based on the data in the integrated dataset, must make sure the data from the external databases is current and has went through the ETL process before being brought into the integrated dataset before using that data.

Many, but not all, of the PM and SE work products and underlying data and information are linked not only within lifecycle stovepipes, but also across lifecycle stages.  For example, requirements are linked to the stakeholder needs and higher level requirements allocated to the system, requirements are linked to models, design is linked to requirements, system verification and system validation is linked to design and requirements.  There is traceability between requirements, analysis, models, design, verification, validation.  The PMP and SEMP define work product attributes to be used to manage the overall SE effort across all lifecycle stages.  The PMP and SEMP define measures like MOSs, MOEs, MOPs, KPPs, TPMs, LIs to be included in the integrated dataset. Project data and information are linked with the SE process data and information.  The data representing measures and work product attributes is accessible and is used to generate reports, dashboards, etc. which are used to better manage the project and system engineering processes.

There may still be some use of common office applications, however the master, ground-truth, work products, underlying data and information are managed electronically with any paper-based documentation considered as “reports” that only represent the electronic data and information at the time of printing. However, these reports are what is still baselined and configuration managed by the organization vs. the database that contains the underlying data.  The project manages the various SE lifecycle process activities from the common, integrated dataset.

For less-complex systems, many of the benefits of SE from a data-centric perspective listed earlier can be realized.  A diagram of the various lifecycle process activity datasets closely resembles that shown in Figure 7.

SCL 3:    Stovepipes within the project do not exist. The enterprise has documented and implemented a data and information governance policy.  A master ontology for the enterprise and project has been documented.   The project has included data management concepts in their PMP and SEMP and have a IMP. Most, but not all, of the underlying data representing the SE lifecycle work products are included in the project’s integrated dataset. The project has transformed their SE process such that most of the PM and SE work products are being developed using PM and SE tools that conform to interoperability standards.

There is a master schema defined for the project’s integrated dataset. The project manages the various SE lifecycle process activities and work products and their underlying data and information from the project’s integrated dataset. Most of the PM and SE tools adhere to interoperability standards and store the data and information either as electronic files or in a database whose schema is consistent with the project master schema allowing the SE tool databases to be included directly as part of the project’s integrated dataset.  Because of the Project’s SE Tools adhere to interoperability standards and consistent schemas, the data and information in these individual databases is compatible – enabling the SE tools to share data and data to be shared with other organizations.

All the data and information representing the SE lifecycle work products are included in the project’s integrated dataset. All the work products and underlying data and information are linked not only within a lifecycle stage, but also across lifecycle stages.

There is only one “ground truth” for the project – the data and information in the integrated dataset.  The project’s data and information in the integrated dataset is under strict configuration control and therefore represents the baseline state of the project at any given time. The work products and underlying data and information are developed, analyzed, and managed holistically as an integrated system made possible because of the existence of a common, integrated dataset. Any “visualizations” of the data and information in the integrated dataset represent the current state of the project.

Note: Even though most of the SE tools have compatible databases included in the integrated dataset, the enterprise may require the project to continue to use some legacy systems, such as budgeting and scheduling applications, whose schema is not compatible with the integrated dataset. In this case, this data must go through a ETL process before the data can be included in the integrated dataset and be accessible by other tools.

There may still be some use of common office applications, however the master, ground-truth, data and information are managed electronically with any paper-based documentation visualizations of the data and information considered as “reports” that only represent the electronic data and information at the time of printing.  However, these reports are what is still baselined and configuration managed by the organization (as contrasted with baselining the dataset(s) that represent those work products).

Most the benefits of SE from a data-centric perspective listed earlier can be realized for more complex systems.  A diagram of the various lifecycle process activity datasets closely resembles that shown in Figure 8.

SCL 4:    The enterprise has documented and implemented a data and information governance policy.  A master ontology for the enterprise and project has been documented.   The project has included data management concepts in their PMP and SEMP and have a IMP. There is a master schema defined for the project’s integrated dataset.  All the underlying data representing the SE lifecycle work products is included in the project’s common, integrated dataset. All PM and SE work products and underlying data and information are developed using SE tools that conform to interoperability standards and store the data and information in a database whose schema is consistent with the project’s master schema. This allows all SE tool databases to be included directly as part of the project’s integrated dataset, enabling all SE tools to share data and data to be shared with other organizations. All the work products are linked not only within a lifecycle stage, but also across lifecycle stages.

There is only one “ground truth” for the project, the data and information in the project’s common, integrated dataset.  This data is under strict configuration control and therefore represents the baseline state of the project at any given time. The work products and underlying data and information are developed, analyzed, and managed holistically as an integrated system made possible because of the existence of a common, integrated dataset. Any “visualizations” of the data represent the current state of the project.

Common office applications are used to document reports that only represent the electronic data and information in the integrated dataset at the time of printing. Rather than baselining these reports, the datasets from which the reports are generated are baselined and configuration managed.  The project manages the various SE lifecycle process activities from this common, integrated dataset. This integrated dataset represents not only an integrated architectural model of the system under development but also represents a model of all the SE lifecycle process activities and resulting work products and their underlying data and information.

All the benefits of SE from a data-centric perspective listed earlier can be realized.  A diagram of the various work products datasets closely resembles that shown in Figure 9.

SCL 5:    The enterprise has an enterprise level ontology defined and documented. The enterprise has defined and documented an enterprise level data and information governance policy and plans. The enterprise has developed an enterprise level IMP. Two or more projects within the enterprise are operating at SCL 4.

Not every enterprise needs to be at SCL 5.  Not every project needs to be at SCL 4.  Most projects should strive to be at least at SCL 2 but are encouraged to get to SCL 3 or higher, that is, IF there is an ROI to the enterprise/project for doing so.  Take baby steps.  The enterprise may set a goal of being at level 4 or 5, but first assessing their current level, identifying the SCL appropriate for the organization, and then developing a roadmap for getting there.

Note: A project may be currently using analytical models as part of their SE lifecycle process activities, but unless they are managing the models and all other SE work products and their underlying data and information in a common, integrated dataset, they have not yet reached SCL 4.  Depending on the degree of data and information integration, these projects may be at SCL 1, 2, or 3.

Choosing an Appropriate SE Toolset

To attain a capability, the organization needs to address their people, processes, and tools.  All three work together to be able to practice SE at the chosen SCL.

A detailed discussion concerning choosing an appropriate SE toolset is included in the following blog: Features an SE Toolset Should Have.

In the second section of part 5 of this blog series, I provide advice to help sell the idea of moving toward a data-centric practice of SE to management.

Comments to this blog are welcome

If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.