Difference between revisions of "Editor's Corner"

From SEBoK
Jump to navigation Jump to search
m
Tag: visualeditor
 
(125 intermediate revisions by 4 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. As BKCASE Editor in Chief (EIC) I have overall responsibility for the continuing review and update of 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 during my first year in the job. 
+
[[File:Hutchison,Nicole Profile.jpeg|right|200px]]
  
SEBoK v. 1.3.1 and v. 1.3.2 are micro releases which continues our commitment to regular review of the information referenced in our''Guide to the Systems Engineering Body of Knowledge''
+
{|
 +
|-
 +
|<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>
 +
|}
  
Some of the updates planned for a minor update to create SEBoK v. 1.4 have been delayed by external factors. In particular updates to key external sources such as[[ISO/IEC/IEEE 15288|ISO/IEC/IEEE. Systems and Software Engineering -- System Life Cycle Processes]]<nowiki/>and the[[INCOSE Systems Engineering Handbook]]<nowiki/>v. 4.0 will have a significant knock on effect for the SEBoK. Other activities within our sponsoring organizations on key topics such as model based systems engineering (MBSE), systems of systems, systems engineering leadership, etc. must also be carefully considered before they are incorporated into our guide. Work has already begun on new and revised material to reflect these changes within the wider knowledge base from which the SEBoK is drawn. As these updates are completed and reviewed you will begin to see them included from SEBoK in v. 1.4, now planned for Spring 2015. 
+
<div style="text-align:right">'''06 May 2024'''</div>
  
=== SEBoK v. 1.3.1 ===
+
'''What's the holdup with Digital Engineering?'''
SEBoK v.1.3.1 is a micro update to v.1.3. It responds to comments raised by our ongoing activity of lower level review and engagement with the community. From this we have identified a number of smaller updates to references, terminology and organization of knowledge.
 
  
=== SEBoK v. 1.3.2 ===
+
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.  
SEBoK v.1.3.2 is a second micro update to v.1.3.  It fixes a number of broken links caused by the re-launching of the INCOSE website.
 
  
Where possible the link has been updated to point at the same material in its new home on the INCOSE.org website.  If that was not possible the direct link has been removed and replaced with a reference giving title, author and date.  We will review all of these links for SEBoK v. 1.4 to ensure the linked material is still available and relevant.  If you have any problems finding particular linked material in the mean time please contact the Editorial Board for assistance.  
+
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?
  
For details of content affected by these updates go to [[Acknowledgements and Release History]].  
+
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.
  
===Future Direction for SEBoK===
+
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.
  
In the foreword to SEBoK v. 1.3 I described the "core group of dedicated and knowledgeable [[Development of SEBoK v. 1.0|contributing authors and reviewers]]" who make up the BKCASE community.  It has been my privilege over the last 12 months to continue working with and grow this community and to expand our relationships with key organizations and groups both within systems engineering and outside of it.
+
Why is it, then, that digital engineering is not moving as quickly as we'd like?
  
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 develop plans for its maintenance and evolution. Our overall goals in evolving the SEBoK remain broadly the same as those outlined in the previous SEBoK updatesI have restated and slightly modified those goals below:
+
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.   
  
*Improve the ways in which [[SEBoK Introduction|Part 1 (SEBoK Introduction)]] provides a starting point for different SEBoK users to find and navigate knowledge relevant to them. This will include consideration of some of the [[SEBoK Users and Uses|SEBoK Use Cases]] which were not expanded in previous releases.
+
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.
*Review of [[Systems|Part 2 (Systems)]] with help from the International Society for the Systems Sciences (ISSS) to better understand the relationships between [[Systems Science (glossary)]] and [[Systems Thinking (glossary)]] as applied to [[Engineered System (glossary)|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 the alignment and co-evolution of [[Systems Engineering and Management|Part 3 (Systems Engineering and Management)]] with other systems engineering life cycle documentation, in particular the planned new release of [[ISO/IEC/IEEE 15288|ISO/IEC/IEEE. Systems and Software Engineering -- System Life Cycle Processes]] and the [[INCOSE Systems Engineering Handbook]] v. 4.0.
 
*Assess our coverage of knowledge on systems engineering application and practices. This may include expansion of the [[Service Systems Engineering|Service]] and [[Enterprise Systems Engineering|Enterprise]] knowledge areas in [[Applications of Systems Engineering|Part 4 (Applications of Systems Engineering)]]. It will also consider how systems engineering practices such as architecting, life cycle tailoring and model based systems engineering are addressed across the SEBoK.
 
*Identify the other groups, both within the systems engineering community and beyond, with interest in the topics of [[Enabling Systems Engineering|Part 5 (Enabling Systems Engineering)]] and [[Related Disciplines|Part 6 Related Disciplines]] and form stronger relationships with them.
 
  
We continue to work towards ensuring 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]]. If you are interested in any of the activity discussed above or if you have other topics which we should be considering please contact me or the appropriate member of the [[BKCASE Governance and Editorial Board|Editorial Board]] directly or use one of the available feedback mechanisms.
+
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.
  
We have made a good start on gathering review comments and content suggestions from as wide a variety of individuals as possible to make the SEBoK a truly community-led product. Thank you to all those who have already joined this effort and I continue to look forward to working with many of you on future SEBoK releases.
+
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:
  
Thank you,
+
*'''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.
[[File:RickSignature_Full.png|left|200px]]
+
*'''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