Difference between revisions of "Editor's Corner"

From SEBoK
Jump to navigation Jump to search
m (Minor rewrites before final release.)
Tag: visualeditor
 
(23 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
[[File:Rob_cloutier_bio_photo.jpg|right|200px]]
+
[[File:Hutchison,Nicole Profile.jpeg|right|200px]]
  
 
{|
 
{|
 
|-
 
|-
−
|<center>''The “Editor’s Corner” provides perspective from the Editor in Chief on critical topics for systems engineering, either through their own words or by inviting a guest writer.''</center>
+
|<center>''The ''Editor’s Corner'' provides perspective from the Editor in Chief on critical topics for systems engineering, either through their own words or by inviting a guest writer.''</center>
 
|}
 
|}
  
 +
<div style="text-align:right">'''06 May 2024'''</div>
  
−
<div style="text-align:right">'''30 October 2022'''</div>
+
'''What's the holdup with Digital Engineering?'''
  
 +
In 2008, I attended my first International Symposium of the International Council on Systems Engineering (INCOSE). I was near completing my master's in systems engineering and was excited to learn more from the broader community. At that Symposium, I attended a number of talks about something called "model-based systems engineering" (MBSE). I was dazzled by the vision presented: a hyper-networked set of tools that would allow information to flow seamlessly throughout the lifecycle. The tenor of the presentations - and all of the conversations - was that this evolutionary way of working was just around the corner.
  
−
<div style="text-align:justify">Let me point out before you begin reading, the purpose of this missive is not to point fingers, but rather to muse about whether we as a systems engineering community go back and reflect on previous prognostications. I feel it is important for individuals and organizations to reflect on the past, and see if we can learn anything to help us move forward as professionals. So, here goes …
+
Today, I have had the privilege of working in the Digital Engineering space for the last five years. And what I am constantly hearing is that we need digital engineering, but that there is frustration about the benefits not being realized quickly. So why is this?
  
−
Have we developed a "resistance to change" – have we as a systems engineering community become slow and lethargic in responding to advances in tools and methodologies? A quick scan of the Internet shows that INCOSE has produced three vision documents since 2007. These vision documents represented the systems engineering vision for the years 2020, 2025, and the latest, for 2035. So let me ask – as a community, do we go back and look at those projections, determine what was correct, and what missed the mark? Do companies that support professional societies, or government agencies, go back and review these?
+
Historically, Wymore laid the foundations for MBSE in his 1993 book. From this foundation, it took 10 years for Systems Modeling Language (SysML) to be established. It took a further four years before INCOSE established an MBSE initiative. So by the time I was first hearing about MBSE in 2008, the concept had actually been percolating through the field for 15 years. As I learned more about it, I began to understand just how far the reality of systems engineering practice was from the vision of MBSE.
  
−
It is interesting that in 2007, INCOSE published a document titled Systems Engineering Vision 2020 (INCOSE-TP-2004-004-02). In the Executive Summary, it was stated that “In many respects, the future of systems engineering can be said to be model-based.”
+
The term "digital engineering" gained traction in the mid-2010s, with a firm anchor established in 2018 with the US Department of Defense's ''Digital Engineering Strategy''. The term digital engineering is used in a variety of ways, but I generally like this definition: an integrated digital approach that uses authoritative sources of systems' data and models as a continuum across disciplines to support lifecycle activities from concept through disposal. (DAU 2023) In other words, it's using trusted data and models to engineer systems in a digital way. This is similar to the promise of MBSE that I was first introduced to in 2008.
  
−
As I write this in September 2022, that original vision document was published 15 years ago. Yet, as the program director of a medium-sized systems engineering graduate program, I am approached regularly by companies, government agencies, and others looking for systems engineering talent. The number one skill these representatives are seeking is experience with model-based systems engineering (MBSE). The second ask is some exposure to modeling and simulation at the systems level.
+
Why is it, then, that digital engineering is not moving as quickly as we'd like?
  
−
In the INCOSE ''Vision 2025'', released in 2014, one of the imperatives was cited as “Advancing the '''tools''' and '''methods''' to address complexity.” (Emphasis added.) Today we are only 2+ years away from 2025. If I look at that vision document, and cherry-pick some of the statements from that 2025 vision around modeling, the authors of that document believed that by 2025:
+
I would propose that the term "digital engineering" in and of itself is a challenge. I have heard for years at community events that "MBSE" is really just systems engineering using models. Many have expressed concerns that by calling it something separate, we've created artificial silos between MBSE and "other systems engineering". The same seems to be true for digital engineering. Adding to this challenge is the distinction - or lack thereof - between digital engineering and MBSE. At conferences in the last few years, I've seen tracks for MBSE and digital engineering completely separated in our programs. While most of the community knows there is a close relationship between the two, we send conflicting signals in the way that we communicate them. 
  
−
<blockquote>
+
True "digital engineering" really goes beyond just engineering activities. While I would define digital engineering as "doing systems engineering in a digital way", this requires a fully integrated digital environment - a complex technical challenge in and of itself. Organizations that put forth the time and energy to establish such an environment should, therefore, not limit itself in scope to only data and tools that support systems engineering. It would be extremely inefficient, for example, to not also include tools that support project lifecycle management activities, even if much of this data falls under "project management" rather than systems engineering. If we as systems engineers truly see the world in systems, we need to treat the creation of digital environments systemically as well. We have to acknowledge that our digital environments should support all of our team members, not just systems engineers. What we are really talking about is broad digital transformation. By continually communicating this as an "engineering" problem, we make it more difficult to help our leaders, decision-makers, managers, and other critical team members to buy into our vision. The language may also create some tension with other engineering disciplines that have been utilizing data and digital models for decades.
−
*"Modeling and simulation is widely used to support integrated planning for a better representation of real-world constraints and solutions"
 
−
*"Systems engineering tools will facilitate systems engineering practices as part of a fully integrated engineering environment. Systems engineering tools will support high fidelity simulation, immersive technologies to support data visualization, semantic web technologies to support data integration, search, and reasoning, and communication technologies to support collaboration."
 
−
*"Model-based approaches will move engineering and management from paper documentation as a communications medium to a paperless environment, by permitting the capture and review of systems design and performance in digital form."</blockquote>
 
  
−
Last week, the University hosted a job fair. As I walked around talking to DoD and industry talent managers, every company hiring systems engineers was begging for graduates that are familiar with MBSE, SysML, modeling, and simulation. It is obvious there is an overwhelming need that we, as academics, may not be satisfying. One student, a mechanical engineer, that took my Fundamentals of SE course, and then applied SysML in his Aerospace Engineering Master's thesis, was hired within 20 minutes of talking to a DoD agency. So, the prognostication was correct, but it seems there are still not enough individuals with the necessary skills. There seems to be an opportunity here - our systems engineering graduate programs need to redouble the efforts in these areas. Additionally, have our companies and agencies fall short of providing the requisite training? Is it realistic to believe systems engineers will learn these skills on their own?
+
Digital engineering is also resource-intensive. The intention and hope are that once digital environments and approaches are well-established, they will decrease cycle times, make systems more financially effective, and improve our ability to build the systems that the world needs. However, until those things are established, there is a lot of work to be done and time and money invested to get there. Digital engineering can and will cost more and take more time upfront. That is a difficult pill to swallow when one of the foremost selling points for digital engineering is increased efficiency.
  
−
Another interesting prediction in that vision document stated that, “Use of technologies such as simulation, visualization, and gaming will lead to innovations in systems engineering education.” This is consistent with the [[Acknowledgements and Release History|Editor’s Corner musing from the last two releases]] of the SEBoK that addressed a/the metaverse.
+
All of these are challenges to full digital transformation, but there is hope. Based on observations over the last several years, there are pockets of excellence, where organizations are pushing the boundaries of what we can do in the digital space and more and more, people are buying into the value proposition. Now we have to deliver on that value by coming together as a community. Humbly, I share a few thoughts for this:
  
−
As I look forward to retirement, allow me to reflect on my time as a young engineer working on the V-22 Osprey in the mid 80’s. The Boeing Corporation had decided to move from paper drawings to CADCAM. They tried to convince the aerospace engineers to give up their drafting board and tools and move to the computer based modeling tool called CATIA. The response from those aero engineers was “you can have my drafting tools when you pull them from my cold, dead fingers”. So, Boeing hired a large number of college graduate engineers and trained them in CATIA. Drawings would come off the senior design engineers drafting boards, and these new CADCAM engineers would recreate the drawings in CATIA. Those digital models were then available to the numerical control machines on the factory floor. They were "resistance to change". Fast forward to today – the only place you will find a drafting board in Boeing is in the Boeing Museum in Seattle. All of the senior engineers use CATIA (because they were the junior engineers in the 1980’s. It took a generation or two to transition from paper-based to computer driven modeling.
+
*'''As a community, we need to create a clear framework for how all of the pieces fit together.''' Is MBSE a part of digital engineering? Is digital engineering a part of systems engineering or is systems engineering a subset of digital engineering? There is a proliferation of opinions on this and until we as a community find some consistency in the way we discuss these things together, it will be almost impossible for us to build a consistent vision with our colleagues in other disciplines.
 +
*'''We need to share our challenges more openly.''' I hear the same issues and concerns from people throughout the community, but we are not always willing to share our failings. True digital engineering is too complex for any one organization to fully solve in isolation. We need to be willing to share more specifics about what isn't working so that we can learn from one another's failures, rather than repeating them.
 +
*'''We need to share success stories.''' Just like with our failures, examples of something that worked - and some insight into the context in which it worked - will provide energy and momentum for us all to build upon.
 +
*'''We need to set more reasonable expectations about the digital transformation we're living through.''' If MBSE was still "fairly new" 15 years in, it is wholly unreasonable to believe that digital engineering will propagate throughout the discipline in a few years. True digital transformation will require shifts in our processes and approaches, organizational cultures, and expectations. These changes are slow. A roadmap that would help set expectations for when certain benefits may be realized would go a long way to building buy-in from our colleagues and organizations.
  
−
Many of you reading this witnessed a similar  story relative to the software engineering community. Even into the 90’s, mainframe and Unix programming was performed using Vi and EMACS, or even using command line. Then, Borland introduced Turbo Pascal and their IDE (Integrated Development Environment) in 1983. Using this new IDE, programmers could program, compile, link, and execute a program all in one environment. For a decade or more, these IDE’s were considered toys or crutches, and “real programmers” used Vi (or EMACS or command line, you get the idea). Again, an example of "resistance to change" by both the software engineering community, and the companies that would not pay for these new tools. Today, most software is written using IDE’s… again, it took a generation or two.
+
These are a few thoughts from the last several years of observing the community. ''What have you seen in your experiences with digital engineering?'' I encourage you to share your thoughts and views in the comments below. We look forward to learning from each of you and continuing the conversation.
  
−
I began this article stating that maybe the systems engineering community has become too lethargic and resistant to change – much like the aero engineers and software engineer were in the 80’s/90’s. Let’s reflect on that claim. In 2007 it was identified by the INCOSE TechOps community that by 2020 our discipline would be “model-based”. Yet, today, industry cannot find enough systems engineers with experience in model-based systems engineering. We had 15 years to prepare. Let’s reflect on the other projection from that 2007 vision document that was identified earlier- “Use of technologies such as simulation, visualization, and gaming will lead to innovations in systems engineering education.” This brings me back to the previous two Editor Corners – the metaverse. Has anyone in systems engineering taken this seriously and identified the requirements for such a system?
+
Sincerely,
 +
[[File:Hutchison_Signature.png|200px|left]]
  
−
I feel that maybe this article has seemed like a random walk. So, what is really my destination? How do I wrap this up? If we are to look at the current systems engineering graduate education, I have been told that there are very few graduate SE programs right now that have integrated MBSE, digital engineering, and/or digital twin concepts woven into their curriculum. I am not talking about courses dedicated to these topics, but these topics simply integrated into the curriculum. In those programs that have done this, their students are being swept up months before they graduate with near six figure offers because they have used MBSE in several classes and maybe on a research project, not to mention their thesis or dissertation.
 
  
−
Many hundreds of hours went into the creation of these Vision documents by leaders in our field from all over the world. It is my opinion that we should take more time to consider, reflect, and act on those vision documents. We should also take a look at them retrospectively and determine where they were right, and where they missed the mark. Then, we need to ask ourselves as a community, what do we need to do moving forward.</div>
+
==Citations==
 +
Wymore, W. 1993. ''Model-Based Systems Engineering.'' CRC Press.
  
−
[[File:RobSignature2.jpeg|200px|left]]
+
DoD. 2018. ''Digital Engineering Strategy.'' Arlington, VA: US Department of Defense.
 +
 
 +
DAU. 2023. "DAU Glossary." Fort Belvoir, VA: Defense Acquisition University (DAU). https://www.dau.edu/glossary/digital-engineering

Latest revision as of 03:06, 6 May 2024

Error creating thumbnail: File missing
The Editor’s Corner provides perspective from the Editor in Chief on critical topics for systems engineering, either through their own words or by inviting a guest writer.
06 May 2024

What's the holdup with Digital Engineering?

In 2008, I attended my first International Symposium of the International Council on Systems Engineering (INCOSE). I was near completing my master's in systems engineering and was excited to learn more from the broader community. At that Symposium, I attended a number of talks about something called "model-based systems engineering" (MBSE). I was dazzled by the vision presented: a hyper-networked set of tools that would allow information to flow seamlessly throughout the lifecycle. The tenor of the presentations - and all of the conversations - was that this evolutionary way of working was just around the corner.

Today, I have had the privilege of working in the Digital Engineering space for the last five years. And what I am constantly hearing is that we need digital engineering, but that there is frustration about the benefits not being realized quickly. So why is this?

Historically, Wymore laid the foundations for MBSE in his 1993 book. From this foundation, it took 10 years for Systems Modeling Language (SysML) to be established. It took a further four years before INCOSE established an MBSE initiative. So by the time I was first hearing about MBSE in 2008, the concept had actually been percolating through the field for 15 years. As I learned more about it, I began to understand just how far the reality of systems engineering practice was from the vision of MBSE.

The term "digital engineering" gained traction in the mid-2010s, with a firm anchor established in 2018 with the US Department of Defense's Digital Engineering Strategy. The term digital engineering is used in a variety of ways, but I generally like this definition: an integrated digital approach that uses authoritative sources of systems' data and models as a continuum across disciplines to support lifecycle activities from concept through disposal. (DAU 2023) In other words, it's using trusted data and models to engineer systems in a digital way. This is similar to the promise of MBSE that I was first introduced to in 2008.

Why is it, then, that digital engineering is not moving as quickly as we'd like?

I would propose that the term "digital engineering" in and of itself is a challenge. I have heard for years at community events that "MBSE" is really just systems engineering using models. Many have expressed concerns that by calling it something separate, we've created artificial silos between MBSE and "other systems engineering". The same seems to be true for digital engineering. Adding to this challenge is the distinction - or lack thereof - between digital engineering and MBSE. At conferences in the last few years, I've seen tracks for MBSE and digital engineering completely separated in our programs. While most of the community knows there is a close relationship between the two, we send conflicting signals in the way that we communicate them.

True "digital engineering" really goes beyond just engineering activities. While I would define digital engineering as "doing systems engineering in a digital way", this requires a fully integrated digital environment - a complex technical challenge in and of itself. Organizations that put forth the time and energy to establish such an environment should, therefore, not limit itself in scope to only data and tools that support systems engineering. It would be extremely inefficient, for example, to not also include tools that support project lifecycle management activities, even if much of this data falls under "project management" rather than systems engineering. If we as systems engineers truly see the world in systems, we need to treat the creation of digital environments systemically as well. We have to acknowledge that our digital environments should support all of our team members, not just systems engineers. What we are really talking about is broad digital transformation. By continually communicating this as an "engineering" problem, we make it more difficult to help our leaders, decision-makers, managers, and other critical team members to buy into our vision. The language may also create some tension with other engineering disciplines that have been utilizing data and digital models for decades.

Digital engineering is also resource-intensive. The intention and hope are that once digital environments and approaches are well-established, they will decrease cycle times, make systems more financially effective, and improve our ability to build the systems that the world needs. However, until those things are established, there is a lot of work to be done and time and money invested to get there. Digital engineering can and will cost more and take more time upfront. That is a difficult pill to swallow when one of the foremost selling points for digital engineering is increased efficiency.

All of these are challenges to full digital transformation, but there is hope. Based on observations over the last several years, there are pockets of excellence, where organizations are pushing the boundaries of what we can do in the digital space and more and more, people are buying into the value proposition. Now we have to deliver on that value by coming together as a community. Humbly, I share a few thoughts for this:

  • As a community, we need to create a clear framework for how all of the pieces fit together. Is MBSE a part of digital engineering? Is digital engineering a part of systems engineering or is systems engineering a subset of digital engineering? There is a proliferation of opinions on this and until we as a community find some consistency in the way we discuss these things together, it will be almost impossible for us to build a consistent vision with our colleagues in other disciplines.
  • We need to share our challenges more openly. I hear the same issues and concerns from people throughout the community, but we are not always willing to share our failings. True digital engineering is too complex for any one organization to fully solve in isolation. We need to be willing to share more specifics about what isn't working so that we can learn from one another's failures, rather than repeating them.
  • We need to share success stories. Just like with our failures, examples of something that worked - and some insight into the context in which it worked - will provide energy and momentum for us all to build upon.
  • We need to set more reasonable expectations about the digital transformation we're living through. If MBSE was still "fairly new" 15 years in, it is wholly unreasonable to believe that digital engineering will propagate throughout the discipline in a few years. True digital transformation will require shifts in our processes and approaches, organizational cultures, and expectations. These changes are slow. A roadmap that would help set expectations for when certain benefits may be realized would go a long way to building buy-in from our colleagues and organizations.

These are a few thoughts from the last several years of observing the community. What have you seen in your experiences with digital engineering? I encourage you to share your thoughts and views in the comments below. We look forward to learning from each of you and continuing the conversation.

Sincerely,

Error creating thumbnail: File missing


Citations

Wymore, W. 1993. Model-Based Systems Engineering. CRC Press.

DoD. 2018. Digital Engineering Strategy. Arlington, VA: US Department of Defense.

DAU. 2023. "DAU Glossary." Fort Belvoir, VA: Defense Acquisition University (DAU). https://www.dau.edu/glossary/digital-engineering

Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Editor%27s_Corner&oldid=72024"