Difference between revisions of "Editor's Corner"

From SEBoK
Jump to navigation Jump to search
 
(169 intermediate revisions by 6 users not shown)
Line 1: Line 1:
A very warm welcome to you if you are a returning SEBoK user, and in particular to anyone new to the SEBoK.  
+
[[File:Hutchison,Nicole Profile.jpeg|right|200px]]
  
I have recently taken the post of Editor in Chief for BKCASE, which includes responsibility for the SEBoK. Many thanks to the [[BKCASE Governance and Editorial Board|BKCASE Governors]] and the current members of the [[BKCASE Governance and Editorial Board#Editorial Board|Editorial Board]] for their support.  Special thanks to the outgoing Editor in Chief Art Pyster and Co-Editor in Chief Dave Olwell, who led the BKCASE efforts from 2009 through the beginning of 2014, and to all the members of the [[Development of SEBoK v. 1.0|original BKCASE Core Team]].
+
{|
 +
|-
 +
|<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>
 +
|}
  
==SEBoK v. 1.3'''==
+
<div style="text-align:right">'''06 May 2024'''</div>
  
SEBoK v. 1.3 is a minor release which continues our commitment to regular review of the information referenced in our guide to the systems engineering body of knowledge.  The primary focus of the Editorial Board for this release was review of references to ensure that they continue to represent the most current information and resources from the systems engineering community. In addition, we have generated a number of new case studies. The primary changes from SEBoK v. 1.2 are:
+
'''What's the holdup with Digital Engineering?'''
  
*A new [[Use Case 0: Systems Engineering Novices|use case]] intended to help individuals who are unfamiliar with systems engineering understand key concepts and navigate the SEBoK to get acquainted with the discipline;
+
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.  
*Three new case studies on [[Successful Business Transformation within a Russian Information Technology Company|Business Transformation]], [[Federal Aviation Administration Next Generation Air Transportation System|Next Generation Air Traffic Control]], and [[How Lack of Information Sharing Jeopardized the NASA/ESA Cassini/Huygens Mission to Saturn|NASA's Mission to Saturn]];
 
*Updates to the [[Hubble Space Telescope Case Study]]; and
 
*Updates to references and content to reflect the publication of the newest version of the Project Management Body of Knowledge (PMBoK).
 
  
==Future Direction for SEBoK'''==
+
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?
  
As I take on my new role in BKCASE I have inherited a coree group of deicated and knowledgable [[Development of SEBoK v. 1.0|contributing authors and reviewers]]. Some of whom have taken roles on the editorial board while many more remain actively involved in the continuing maintenance and evolution of the SEBoK. Alongside this group we have started the process of expanding our relationships with key organizations and groups both within systems engineering and outside of it.  
+
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 role of the Editorial Board is to work with this community of interest on an ongoing review of the current SEBoK content and structure and to develope plans for its maintenance and evolution. Some of the areas under consideration for revision over the next 18 months include:
+
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.
  
*General exploration of ways in which we can better cover cross cutting application issues such as model based SE and agile life cycle approaches.
+
Why is it, then, that digital engineering is not moving as quickly as we'd like?
*Review of Part 2 (Systems) with International Society for the Systems Sciences (ISSS) to better understand the relationships amonst Systems Thinking, Systems Science and the Systems Approach as applied to Engineered Systems.  We hope this will lead to an improved integration of systems principles, concepts, patterns and models into the other systems engineering focused knowledge areas across the SEBoK.
 
*Continue with the alignment and co-evolution of Part 3 (Systems Engineering and Management) with other systems engineering life cycle documentation, in particular ISO/IEC/IEEE 15288 and the INCOSE ''Systems Engineering Handbook'', v. 4.0.
 
*Assess our approach to knowledge on the ways in which systems engineering is applied.  This may include expansion of the [[Service Systems Engineering|Service]] and [[Enterprise Systems Engineering|Enterprise]] knowledge areas in Part 4 (Applications of Systems Engineering).  It will also consider how systems engineering practices such as architecting, life cycle management and model based systems engineering are adressed across the SEBoK.
 
*Identify the other groups, both within the systems engineering community and beyond, with interest in the topics of Parts 5 and 6 and form stronger relationships with them, e.g. INCOSE Systems Safety working group.
 
  
We aim to ensure that our coverage of existing systems engineering knowledge is complete and to push the boundaries of that knowledge into new approaches and domains. I also want to strengthen further our links to all members of the systems engineering community through things like the [[Sandbox|SEBoK Sandbox]]. I hope that we can gather review comments and content suggestions from as wide a variety of individuals as possible to make the SEBoK a truly community-led product.
+
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.
  
I very much look forward to working with many of you on future SEBoK releases in the future.
+
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.
  
Thank you,
+
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.
[[File:RickSignature_Full.png|left|200px]]
+
 
 +
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,
 +
[[File:Hutchison_Signature.png|200px|left]]
 +
 
 +
 
 +
==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

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