FuSE Agility as a

FEATURE
SPECIAL

Foundation for Sound

MBSE Lifecycle
JUNE 2O23
VOLUME 26/ ISSUE 2

Management
Barry Papke, barry.papke@3ds.com; Matthew Hause, matthew.hause@hotmail.com; and David Hetherington;
david_hetherington@ieee.org
Copyright © 2023 by Barry Papke, Matthew Hause, and David Hetherington. Permission granted to INCOSE to publish and use.

 ABSTRACT
Over the past several years, numerous industries have increased their adoption of the systems modeling language (SysML®) and
model-based systems engineering (MBSE) as a core practice within their engineering lifecycles. However, the introduction of
SysML and MBSE methodologies has not yet yielded many of the originally envisioned benefits. System models are becoming
larger and more complex and many large MBSE projects continue to experience problems with model integration, repository
performance, and model lifecycle management. The root cause is the failure to recognize the MBSE digital environment as a
complex engineering information processing system that requires the same rigor and development processes as the system-of-
interest (SoI) it is designing. This article describes how three future of systems engineering (FuSE) agility foundation concepts
(system of innovation, effective stakeholder engagement, and continuous integration) directly address some of the problems seen
in adoption, deployment, and sustainment of the MBSE digital environment as an SoI.

MBSE ADOPTION, DEPLOYMENT, AND SUSTAINMENT

F
IS NOT WITHOUT IT’S CHALLENGES
uSE agility is one of the initiatives ■■ Model integration issues between
intended to shape the future of sys-
tems engineering and contribute to-
ward the practical realization of the
Systems Engineering Vision 2035 published
by INCOSE. FuSE agility includes nine
foundational concepts to advance thinking
and practice in “agile-systems engineering”
(development of agile systems) and “agile
systems-engineering” (an agile systems
engineering process). Creating an agile
system requires an agile organization using
an agile process.
While the challenges of realizing the
Systems Engineering Vision 2035 are before
us, there are a number of urgent challenges
biting at our heels, specifically in the area
of MBSE deployment and MBSE lifecycle
management (Noguchi 2022 and Papke
2022). Many large MBSE projects have
not fully realized the envisioned benefits.
Common pain points include:
government-reference models, prime
contractor models, and supplier models
and across disconnected networks.
■■ Integration issues between descriptive
models and computational/analytical
models.
■■ Insufficient representation of their
systems of interest, leading to stake-
holder confusion, increased backlog of
rework, and system architecture and
design flaws
■■ Dramatic slowdown of modeling tool
performance as the number of models
users grew, model size grew, and during
model delivery activities for major
reviews.
■■ Insufficient verification and validation
of model simulations and outputs.
■■ Lack of configuration control and lack
of quality control in model content.
Industry is beginning to realize that the
digital engineering environment is its own
system of interest with requirements for
what it must provide, functions it must
perform, interfaces and data exchanges it
must support, and performance parameters
it must achieve. As a system it must also be
based on a sound architecture (both the
tool environment and the models it con-
tains) that provides key architectural proper-
ties such as loose coupling, proper cohesion,
modularity, maintainability, extensibility, etc.
This article focuses primarily on “agile
systems-engineering” (an agile systems
engineering process) and three specific
FuSE agile concepts: system of innovation,
effective stakeholder engagement, and
continuous integration (Willette, et al.
2021) to provide actionable guidance in the
context definition, deployment, operation,
and sustainment of the MBSE digital
engineering environment.

34
 21564868, 2023, 2, Downloaded from https://incose.onlinelibrary.wiley.com/doi/10.1002/inst.12443 by libffg rrtyu - Beijing Normal University , Wiley Online Library on [09/08/2023]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
3. System of Innnovation (SOI) Validation – does the model fulfill its ob-

FEATURE
SPECIAL
Learning & Knowledge 2. Target System (and Component) Life Cycle Domain System jectives as a digital engineering artifact
Manager for LC Managers
of Target System Life Cycle Manager in the digital engineering environment
of LC Managers
(is the model useful to all applicable
Learning & Knowledge
Manager for Target Systems
stakeholders throughout the engineering
LC Manager of lifecycle.)
Target System
1. Target System
In the document-based world for De-
partment of Defense projects, there was

JUNE 2O23
VOLUME 26/ ISSUE 2
little, or no thought given to the docu-
ment format and content specified as the
“contract deliverable.” Document based de-
(Substantially all the ISO15288 processes are included in all four Manager roles) Target liverables were defined by a system of data
Environment
items descriptions (DIDs) and DD Form
Figure 1.  Agile systems engineering life cycle model pattern (Schindel and Dove 2016) 1423 “Contract Data Requirements List.”
In the commercial domain, most organiza-
tions had similar pre-defined templates and
SYSTEM OF INNOVATION contract statements of work. There has been formats.
The system of innovation was described little innovation to the document-based
in the paper “Introduction to the Agile Sys- systems engineering process since its first SYSTEM OF INNOVATION ENABLER FOR
tems Engineering Life Cycle MBSE Pattern” inception. Project planning is based on past SUCCESSFUL MBSE ADOPTION
(Schindel and Dove 2016). It consists of metrics and standard processes. Most large MBSE projects today are still
three (3) systems: Many of the project challenges and “first attempts” to deliver systems using
• System 1:  the target system under execution problems seen in large MBSE this methodology. Projects are attempting
development. projects can be traced directly to the to do many more things with models as
• System 2:  the system that produces, inability of System 3 to recognize and the “authoritative source of truth” such as
supports, and learns about the target adapt to the impact of MBSE. The largely implementation of the “digital thread” than
system. This is the logical system manual, document-based systems were attempted with documents (DoD
within which the target system will engineering process has been replaced by 2018)]. The growth in size and complexity
exist during its lifecycle. a highly complex, engineering information of models during the engineering lifecycle
• System 3:  the process improve- processing system that has interfaces and continues to present new problems and
ment system, called the system of information exchanges with other systems challenges to model lifecycle management,
innovation that learns, configures, in the digital engineering system-of- model integration, and digital infrastruc-
and matures system 2. System 3 is systems (Maier 1996). ture performance. Projects can no longer
responsible for situational awareness, Unlike documents, models are living depend on the predictability of their legacy
evolution, and knowledge manage- entities that are also systems with an document-based processes. They require an
ment – the provider of operational architecture, functions, interfaces, and agile approach to address these challenges.
agility. performance requirements. While projects The system of innovation provides this
are still adapting to perform design reviews agility through three basic principles:
In the context of the MBSE digital en- and associated quality assurance processes sensing, responding, and evolving.
vironment, the target system (System 1) is which focus on the verification and valida- ■■ Sensing – MBSE projects must monitor
the actual physical system. One of the key tion (V&V) of the system design, the need and measure key indicators of both
features of the agile systems engineering life for such activity is clearly understood, in project progress (a measure of System
cycle model (ASELCM) is that the target the context of System 1 (the system under 2 performance) as well as data from
system provides feedback through the development), V&V asks: System 1. This requires more than
physical environment to the lifecycle man- Verification – does the system satisfy the assigning budget, scope, and schedule
ager. This feedback could be sensor data, specified requirement within cost, sched- to the MBSE deployment activity. It
user complaints, feature requests, or other ule, and acceptable technical risk (did we means recognizing that many assump-
feedback based on the deployed operation build the thing right.) tions made about the MBSE workflows,
of the physical system. The lifecycle domain MBSE model architecture, and network
system (System 2) is the digital engineering Validation – does the system achieve architecture may be incorrect and are
environment that consists of tools, process- its mission and business objectives and yet to reveal themselves. As we used to
es, and people that develop and maintain intended use in the operational environ- say — Inside every small problem is a
System 1. System 3 is the functional engi- ment (did we build the right thing.) large problem struggling to get out!
neering and project management organiza- ■■ Respond – MBSE projects must make
tions that plan the definition, deployment, In MBSE, there is another system of in- decisions about what they see and be
and sustainment of System 2 and also terest (SoI) that must be considered, System prepared to react to address the actual
control its funding and resources. 2 which is the model itself as an engineer- performance of their MBSE deploy-
In terms of the system that learns, ing artifact in the engineering lifecycle: ment. Detailed planning and compli-
configures, and matures System 2, System ance are not sufficient. Initial plans
3 has been in hibernation for decades. The Verification – is the system model will need to evolve as new information
people, processes, and tools for execution syntactically and semantically correct comes to light.
of the systems engineering lifecycle have and does it contain all required ■■ Evolve – MBSE projects must embrace
been codified in standards, documented in engineering content (is it a good model- the fact that their process will evolve,
engineering procedures, and specified in based representation of the design.) and this evolution must be supported

35
 21564868, 2023, 2, Downloaded from https://incose.onlinelibrary.wiley.com/doi/10.1002/inst.12443 by libffg rrtyu - Beijing Normal University , Wiley Online Library on [09/08/2023]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
uc [Model] Model [MBSE Environment Stakeholders]
FEATURE
SPECIAL

« system context »
MBSE Models and Digital Environment
Develop System
Architecture
Install and Configure
« stakeholder » Access Reuse Servers and Repository « stakeholder »
System Engineer Libraries Applications IT Installer

Run and Mantain

Generate Model-
JUNE 2O23
VOLUME 26/ ISSUE 2

Periodic Backups « stakeholder »

Obtain Component Based Deliverables IT Log and
List and R&M Data Monitor Server Backup Manager
« stakeholder » and Network
R&M Engineer Performance
Execute Low
Push R&M Performance Fidelity Simulation Manage Databases
Estimates Back to System
Model « stakeholder »
Generate Log Files to Library Curator
Receive Model Based Investigate Problems
SWAP Data for Execute High Fidelity
« stakeholder » Installation Design Physics-Based
Mechanical Engineer Simulation
Push Design Update Reuse
Constraints Back to Libraries
the System Model
Subcontractor
Receive Model Based Prime
Review Model- Integrator Reference Models
« stakeholder » Based Deliverables and Requirements
Customer Review for Model Quality
and Modeling Standards Develop
Analyze Existing Architecture for
System Models Merge Subcontractor Assigned Subsystems
for Reuse Models with Prime
Integrator Models

Quality Assurance Engineer

Figure 2.  MBSE model and digital environment stakeholders have diverse needs and concerns

with a culture of experimentation, little “backend” management or support. definition, deployment, and operation of
re-evaluation, and new institutional Little has changed in document and data the MBSE modeling environment. The
memories. management technology. stakeholder analysis for the MBSE models
In MBSE projects, engineering infor- and digital environment (System 2) is just
EFFECTIVE STAKEHOLDER ENGAGEMENT mation is managed at the model element/ as important as that for the SoI (System 1)
Effective stakeholder engagement is property level. The model repositories are itself. This is at the core of the second di-
another key FuSE agility concept that is complex server applications that require mension of V&V as described earlier. If we
well understood and generally applied significant back-end IT support. Models are don’t understand stakeholder needs correct-
correctly with respect to the SoI being living entities that access data and integrate ly, how can we know whether the models
developed, but is neglected in the context of with other models. Model re-use is a major and their digital environment is producing
deployment, operation, and sustainment of benefit of MBSE and is typically imple- models that fulfill their objectives as a
the MBSE digital engineering environment. mented using reuse libraries, which require digital engineering artifacts (validation)?
As with the system of innovation, stake­ a library manager or curator. Projects must understand the needs and
holder engagement within document-based The backend repository IT support and concerns of both new and legacy stakehold-
systems engineering processes is largely library curators are new stakeholders. ers with respect to the models, tools, and
dormant. Stakeholder concerns are codified Legacy stakeholders including customers, processes of MBSE (Flyvbjerg 2023).
in the standards, DIDs, and statements subcontractors, and other engineering dis-
of work. In MBSE projects, there are ciplines have new and different stakeholder CONTINUAL INTEGRATION AS AN ENABLER
many new and significant activities and needs with respect to the MBSE models and FOR SUCCESSFUL MBSE ADOPTION
processes, that each have new stakeholders digital environment. Continuous integration is yet another
and new concerns. Those new concerns key FuSE agility concept that is well
must be identified and addressed as part EFFECTIVE STAKEHOLDER ENGAGEMENT understood and generally applied correctly
of the MBSE definition, deployment, and AS AN ENABLER FOR SUCCESSFUL MBSE with respect to the SoI being developed
execution activities. ADOPTION (particularly in software intensive
For example, in document-based proj- As a symptom of new MBSE projects projects), but is neglected in the context of
ects, deliverables are managed through failure to apply the system of innovation deployment, operation, and sustainment of
defined data management processes and concept and to perform their three key the MBSE digital engineering environment.
organizations. The engineering information functions (sense, respond, and evolve), The concept of continuous integration
is controlled at the document level. The many MBSE projects fail to recognize how (that is, continuous delivery) is at the
tools to create documents are “commodity the technology, tools, and processes of core of agile. The key principle of agile
office applications” that require minimum MBSE have created the need to perform development is to deliver products
information technology (IT) resources and new stakeholder engagement analysis for iteratively and incrementally, maximizing

36

Feedback
se
on
Detects and
measures the
Continuous Re
sp
performance Integration
of the SOI.
The MBSE
Digital
Environment SOI
Effective
Stakeholder
Engagement
What to Identifies the needs and
Measure performance objectives
of the SOI.
Figure 3.  FuSE agility foundation concepts depend on each other
opportunities for feedback. Incremental
deliveries of ‘done’ products to ensure
a potentially useful version of working
product is always available” (Schwaber
and Sutherland 2013). This concept is
about enabling integration as early and as
often as possible revealing issues caused
by incompatible or insufficient interfaces
and information exchange specifications
(Willette et al. 2021).
As mentioned previously, the MBSE
digital engineering environment is a com-
plex engineering information management
system within a larger system-of-systems
digital engineering environment. Within
a given systems engineering department,
the interfaces and engineering workflows
between networks and tools may be well
defined and mature. However, most of
these interfaces and workflows are specific
to the project and may be new or poorly
defined and largely or entirely untested. In
addition, as part of a system-of-systems,
the tools and networks in customer and
supplier environments and in other engi-
neering disciplines evolve independently
which may affect these interfaces. Contin-
ual integration provides the opportunity
to begin exercising the interfaces and
workflows between engineering depart-
ments, customers, and suppliers early, when
the model content is relatively small and to
establish performance baselines for critical
MBSE processes such as model download
and commit time, simulation execu-
tion, and other server/network resource
demands. This does not mean propagating
model changes instantly across the project.
It refers to planned, incremental model
integrations that coincide with incremental
Senses the needs and
System of performance of the SOI.
Innovation Responds with decisions,
actions and evaluations.
Evolves and improves with
learned knowledge and
capability.
Feedback
on Needs
delivery of the System 1 design, as part of
an agile project workflow.
In their application of agile systems
engineering, projects must ensure that the
output of each “sprint” is both a useful
version of the design description, but also a
useful version of the system-of-models that
fulfill their intended role in the engineering
lifecycle. The sprint objectives should also
include model data exchanges between
contractor/supplier/customer environment,
branch merges and model integration and
any end-to-end simulations, queries or
other “digital thread” related workflows.
SUMMARY AND CONCLUSION
Once projects commit to adoption of
MBSE in their engineering projects, they
take on new challenges related to the
deployment, operation, and sustainment of
the complex digital engineering envi-
ronment consisting of the models, tools,
network, processes, and people involved.
Because projects have operated so long
with the mature and much simpler docu-
ment-based systems engineering approach,
they failed to realize the impact of such a
transformational change in their engineer-
ing lifecycle. This article highlighted three
of the FuSE agility foundation concepts
(system of innovation, effective stakeholder
engagement, and continuous integration)
and described how each concept can help
address the challenges that large projects are
experience in their initial MBSE journey.
Several other concepts are also key enablers
such as technical oversight for agile projects,
agility across the value stream, and orches-
trating agile operations, but were beyond
the scope of this article.
21564868, 2023, 2, Downloaded from https://incose.onlinelibrary.wiley.com/doi/10.1002/inst.12443 by libffg rrtyu - Beijing Normal University , Wiley Online Library on [09/08/2023]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
The article also highlights the depen-
FEATURE
SPECIAL
dencies between each of the FuSE agility
foundation concepts. In this context, the
system-of-interest is the set of models
and the model based digital engineering
environment that consists of the tools, IT
infrastructure, processes, and people.
The system of innovation operational-
izes agility by sensing, responding, and
JUNE 2O23
VOLUME 26/ ISSUE 2
evolving. One of the key elements to sense
is the stakeholder needs. If these are not
understood, the response will be ineffective.
Continuous integration provides feedback
in how well the stakeholder needs are being
met. If this feedback is not provided, there
is no learned knowledge to drive the neces-
sary evolution of the SoI.  ¡
REFERENCES
■■ Department of Defense. 2018. Depart-
ment of Defense Digital Engineering
Strategy. Office of the Deputy Assistant
Secretary of Defense for Systems Engi-
neering. 09 May. www.acq.osd.mil/se .
■■ Willett, K., R. Dove, A. Chudnow,
R. Eckman, L. Rosser, J. Stevens, R.
Yeman R and M. Yokell. 2021. “Agility
in the Future of Systems Engineering
(FuSE) – A Roadmap of Foundational
Concepts.” INCOSE International
Symposium, 31: 158-174.
■■ Maier, M. W. 1996. “Architecting Prin-
ciples for Systems-of-Systems.” INCOSE
International Symposium, 6(1), 565-573.
■■ Noguchi, R. 2022. “Converging MBSE
Methodology” NDIA Systems and
Mission Engineering Conference.
November. NDIA Proceedings (dtic.
mil) .
■■ Papke, B., M. Haus, D. Hetherington,
and S. McGervey. 2022. “MBSE Model
Management Pain Points – Wait, this
looks familiar!” NDIA Systems and
Mission Engineering Conference.
November. NDIA Proceedings (dtic.
mil) .
■■ Flyvbjerg, B. and D. Gardner. 2023.
“How Frank Gehry Delivers On Time
and On Budget.” Harvard Business
Review. January-February. Accessed 03
March 2023, https://hbr.org/2023/01/
how-frank-gehry-delivers-on-time-and-on-
budget .
■■ Schwaber, K., and J. Sutherland. 2013.
“The Scrum Guide.” Scrum.Org, 13
March. https://www.scrum.org/resourc-
es/scrum-guide .
■■ Schindel, W., and R. Dove. 2016.
“Introduction to the Agile Systems
Engineering Life Cycle MBSE Pattern.”
Proceedings International Symposium.
International Council on Systems
Engineering. Edinburgh, Scotland, 18-
21 July.
37
 21564868, 2023, 2, Downloaded from https://incose.onlinelibrary.wiley.com/doi/10.1002/inst.12443 by libffg rrtyu - Beijing Normal University , Wiley Online Library on [09/08/2023]. See the Terms and Conditions (https://onlinelibrary.wiley.com/terms-and-conditions) on Wiley Online Library for rules of use; OA articles are governed by the applicable Creative Commons License
ABOUT THE AUTHORS
FEATURE
SPECIAL

Barry Papke is the manager for the cyber system

industry process success team for CATIA/No Magic.
He has thirty-five years of systems engineering and
operations analysis experience in the aerospace
and defense industry across the entire systems The INCOSE Handbook
engineering lifecycle from concept development
through integration, test, and post-delivery support.
Throughout his career, he has been actively involved
5th Edition has published
JUNE 2O23
VOLUME 26/ ISSUE 2

in application of model-based methods including

requirements management, enterprise architecture,
cost estimation, system design, and operations analysis.
Barry has a BS in mechanical engineering from Texas
A&M University and a MS in systems engineering
from Steven’s Institute of Technology. He is a member
of the INCOSE Agile and Security Working Groups
and the MBSE initiative. SYSTEMS ENGINEERING HANDBOOK
David Hetherington is a principal systems engineer A GUIDE FOR SYSTEM LIFE CYCLE PROCESSES AND ACTIVITIES

with System Strategy, Inc. He serves multiple defense

and commercial industry sectors. He has extensive
personal experience in designing and leading design
teams for both software and hardware covering an
unusually broad range of system types. These complex
systems have varied from real-time control to software
internationalization, to offshore oil drill ships, to
enterprise software applications, to automotive radar
chipsets, to electronic publishing, and more. In
addition to MBSE, he has a strong concentration of
domain knowledge in safety, reliability, maintainability,
and diagnostics.
Matthew Hause is an SSI principal and MBSE FIFTH EDITION

technical specialist, a former PTC fellow, a co-chair of

the unified architecture framework (UAF®) group, and
a member of the OMG SysML specification team. He
International Council on Systems Engineering
®

has been developing multi-national complex systems

for over 45 years as a systems and software engineer. He
started out working in the power systems industry and
has been involved in military command and control

INCOSE Members get a

systems, process control, manufacturing, factory
automation, communications, supervisory control
and data acquisition (SCADA), distributed control,
office automation, and many other areas of technical 55% discount.
and real-time systems. His roles have varied from
project manager to developer. His role at SSI includes
mentoring, sales presentations, standards development,
presentations at conferences, specification of the Visit incose.org/wiley to get
UAF profile, and developing and presenting training
courses. He has written over 100 technical papers on your discount code.
architectural modeling, project management, systems
engineering, model-based engineering, and many other
subjects. If you are having any issues
ordering the book please contact
info@incose.net

www.incose.org/sehandbook

38