Difference between revisions of "Editor's Corner"

From SEBoK
Jump to navigation Jump to search
 
(305 intermediate revisions by 11 users not shown)
Line 1: Line 1:
'''Please note that in order to provide review comments, you will use the DISQUS feature at the bottom of each article. You may login to DISQUS using existing accounts (e.g. Google, Yahoo, Twitter, or Facebook) or you may create a DISQUS account.  Please look for the BKCASE posts under the discussion for each article, which provide specific guidance for reviewers.'''
+
[[File:Hutchison,Nicole Profile.jpeg|right|200px]]
  
==Overview==
+
{|
BKCASE (pronounced "Bookcase") is the acronym for the Body of Knowledge and Curriculum to Advance Systems Engineering project.  The BKCASE team is developing two products, a Guide to the Systems Engineering Body of Knowledge (SEBoK) and a Graduate Reference Curriculum for Systems Engineering (GRCSE).  
+
|-
 +
|<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>
 +
|}
  
The current content of [[Guide to the Systems Engineering Body of Knowledge (SEBoK) v. 0.75|www.sebokwiki075.org]] represents version 0.75 of the SEBoK. To be clear:
+
<div style="text-align:right">'''06 May 2024'''</div>
* The SEBoK is not the compendium of all systems engineering knowledge; instead, in its final form it is intended to be the definitive guide to systems engineering (SE) knowledge. To this end, each article has been intentionally limited to about 2000 words (not including references or tables).
 
* The materials in version 0.75 should ''not'' be considered final. 
 
*With 0.75, the authors have attempted to improve the consistency in terms of scope and level of detail for each article.  However, where reviewers note inconsistency, comments would be extremely helpful.
 
*Only some of the articles were updated for 0.75 (see "Articles Updated for SEBoK 0.75") below.  All other articles in the wiki are essentially the same as version 0.5 (with minor updates to reflect changes elsewhere).
 
  
Version 0.75 offers the public SE community a view into the state of the SEBoK as its authors evolve it towards the September 2012 Version 1.0 release. Most importantly, the authors are soliciting comments from the community to improve the content for version 1.0. The ideal outcome is that the SEBoK will be supported worldwide by the SE community as the authoritative BoK for the SE discipline.
+
'''What's the holdup with Digital Engineering?'''
  
==State of the SEBoK==
+
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.
Summarizing the current state of the SEBoK at this point, the SEBoK team believes the following:
 
  
#The SEBoK is more mature than version 0.5.  The quality of the writing, the choice of topics, the architecture of the SEBoK, and the completeness of the writing have been improved over version 0.5.  The author team is quite proud of how far the SEBoK has come.  Yet, the choice of version "0.75" does reflect the fact that much more work remains before the SEBoK will be fully ready for broad use and adoption.
+
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?
#The architecture of the SEBoK into ''parts'', ''knowledge areas'', and ''topics'' is fundamentally correct and will persist in version 1.0, although there may be some minor adjustments.
 
#The choice of ''primary references'' - considered the most important readings in the field for a given topic - is immature.  Reviewer feedback to help mature those choices is especially vital.
 
#Integration among articles is better than in version 0.5, but much remains to be done.
 
#Even though the articles in the wiki have been edited, there are still shortcomings in the writing.  Nevertheless, version 0.75 captures extremely valuable information about the field, and provides a solid foundation for the final version.
 
#Moving to a wiki environment for the development and delivery of the SEBoK has been a huge step for the authors, but well worth it. 
 
  
Reviewers will provide an external check on these beliefs.
+
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.
  
===Articles Updated for SEBoK 0.75===
+
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.
The following is the list of articles that have been heavily revised in the transition from SEBoK 0.5 to SEBoK 0.75 or are new articles entirely.  Many of these updates were done in response to the SEBok 0.5 reviews (please see the [http://www.sebokwiki.org/075/images/c/cf/Adjudication_report_for_0_75_Final.pdf Adjudication Report] for additional information).  Reviewers are welcome to comment on all articles, not only the ones updated for SEBok 0.75.
 
 
 
{|
 
|-
 
|
 
*[[SEBoK 0.5 Introduction|Part 1: SEBoK 0.5 Introduction]]
 
**[[Scope and Context of the SEBoK]]
 
**[[Structure of the SEBoK]]
 
**[[Economic Value of Systems Engineering]]
 
**[[Systems Engineering: Historic and Future Challenges]]
 
**[[Systems Engineering and Other Disciplines]]
 
***[[Use Case 1: Practicing Systems Engineers]]
 
*[[Systems|Part 2: Systems]]
 
**Knowledge Area: [[Systems Thinking]]
 
***Topic: [[What is a System?]]
 
***Topic: [[Types of Systems]]
 
***Topic: [[What is Systems Thinking?]]
 
**Knowledge Area: [[System Science]]
 
***Topic: [[History of System Science]]
 
***Topic: [[System Methodology]]
 
***Topic: [[Groupings of Systems]]
 
**Knowledge Area: [[Systems Approach]]
 
***Topic: [[Overview of the Systems Approach]]
 
***Topic: [[Engineered System Context]]
 
***Topic: [[Identifying and Understanding Problems and Opportunities]]
 
***Topic: [[Synthesizing Possible Solutions]]
 
***Topic: [[Analysis and Selection between Alternative Solutions]]
 
***Topic: [[Implementing and Proving a Solution]]
 
***Topic: [[Deploying, Using, and Sustaining Systems to Solve Problems]]
 
***Topic: [[Acquirer/Supplier Responsibility]]
 
***Topic: [[Applying the Systems Approach]]
 
*[[Systems Engineering and Management|Part 3: Systems Engineering and Management]]
 
***Topic: [[System Life Cycle Process Models: Vee]]
 
***Topic: [[System Life Cycle Process Models: Iterative]]
 
**Knowledge Area: [[Concept Definition]]
 
***Topic: [[Mission Analysis]]
 
***Topic: [[Stakeholder Needs and Requirements]]
 
**Knowledge Area: [[System Definition]]
 
***Topic: [[Architectural Design: Logical]]
 
***Topic: [[Architectural Design: Physical]]
 
**Knowledge Area: [[System Realization]]
 
***Topic: [[System Verification]]
 
***Topic: [[System Validation]]
 
**Knowledge Area: [[System Deployment and Use]]
 
***Topic: [[Operation of the System]]
 
***Topic: [[System Maintenance]]
 
***Topic: [[Logistics]]
 
**Knowledge  Area: Systems Engineering Management
 
***Topic: [[Planning]]
 
|
 
*[[Applications of Systems Engineering|Part 4: Applications of Systems Engineering]]
 
**Knowledge Area: [[Product Systems Engineering]]
 
***Topic: [[Product Systems Engineering Background]]
 
***Topic: [[Product as a System Fundamentals]]
 
***Topic: [[Business Activities Related to Product Systems Engineering]]
 
***Topic: [[Product Systems Engineering Key Aspects]]
 
***Topic: [[Product Systems Engineering Special Activities]]
 
*[[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]]
 
***Topic: [[Systems Engineering Governance]]
 
**Knowledge Area: [[Enabling Businesses and Enterprises to Perform Systems Engineering]]
 
***Topic: [[Deciding on Desired Systems Engineering Capabilities within Businesses and Enterprises]]
 
***Topic: [[Organizing Business and Enterprises to Perform Systems Engineering]]
 
***Topic: [[Assessing Systems Engineering Performance of Business and Enterprises]]
 
***Topic: [[Developing Systems Engineering Capabilities within Businesses and Enterprises]]
 
***Topic: [[Culture]]
 
*[[Related Disciplines |Part 6: Related Disciplines]]
 
**Knowledge Area: [[Systems Engineering and Software Engineering]]
 
***Topic: [[The Nature of Software]]
 
***Topic: [[An Overview of the SWEBOK Guide]]
 
***Topic: [[Ten Things a Systems Engineer Needs to Know about Software Engineering]]
 
***Topic: [[Ten Things a Systems Engineer Needs to Know about Managing a Software Team]]
 
**Knowledge Area: [[Systems Engineering and Project Management]]
 
***Topic: [[The Nature of Project Management]]
 
***Topic: [[An Overview of the PMI Guide to the Project Management Body of Knowledge (PMBOK(TM))]]
 
***Topic: [[Relationships between Systems Engineering and Project Management]]
 
***Topic: [[The Influence of Project Structure and Governance on Systems Engineering and Project Management Relationships]]
 
**Knowledge Area: [[Systems Engineering and Industrial Engineering]]
 
** Knowledge Area: [[Systems Engineering and Specialty Engineering]]
 
***Topic: [[Security Engineering]]
 
***Topic: [[System Assurance]]
 
***Topic: [[Affordability]]
 
***Topic: [[Environmental Engineering]]
 
***Topic: [[Lean Engineering]]
 
|}
 
  
==About the SEBok 0.75 Review==
+
Why is it, then, that digital engineering is not moving as quickly as we'd like?
This is the third phase of SEBoK reviews.  The first review of version 0.25 was completed with a [[Acknowledgements|limited audience]] of reviewers in Fall 2010.  The report on the 0.25 comments can be found [http://www.bkcase.org/fileadmin/bkcase/files/Review_Documents/SEBOKVersion0.25AdjudicationReportFINAL1.pdf here].
 
  
The second review of version 0.5 was open worldwide in Fall 2011; an additional review was conducted by INCOSE working groups (WGs) in association with the INCOSE International Workshop. For comments received in the 0.5 wiki, the comments and any author actions to date can be viewed on each page under the heading "Comments from 0.5 Wiki."  For comments received outside the wiki, please view the adjudication report [http://www.sebokwiki.org/075/images/c/cf/Adjudication_report_for_0_75_Final.pdf here].
+
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.
  
The third review, of version 0.75, is open to the public; the deadline for reviewer comments is April 15, 2012.
+
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.
  
In version 0.25, the guide was presented as a PDF document with sixteen chapters.   Version 0.5 was presented in a wiki.  Version 0.75 is also presented in a wiki with seven major parts, [http://www.www.sebokwiki.org/05/index.php/Category:Knowledge_Area 28 knowledge areas], and about [[SEBoK Table of Contents|160 total articles]] with hyperlinks between articles and to a set of [http://www.www.sebokwiki.org/05/index.php/Category:Primary_Reference primary references], a [http://www.www.sebokwiki.org/05/index.php/Category:Glossary_of_Terms glossary], and a list of [[Acronyms|acronyms]].  (Please see [[How to Read the SEBoK|Reading the SEBoK]] for a detailed explanation of the different article types.) The review of version 0.75 will use embedded discussion functionality for each article.
+
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.
  
===Review Process===
+
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:
The SEBoK version 0.75 review process is intended to provide the SE community an opportunity to comment on the approach, provide feedback on current draft content, provide feedback on the wiki format, and make recommendations about future content and wiki features. The author team recommends that all reviewers read [[SEBoK 0.75 Introduction|Part 1: SEBoK 0.75 Introduction]] including the complete set of Part 1 articles, which provide the context for the rest of the materials.  In addition, reviewers are encouraged to review the materials most relevant to their current roles or interests.  
 
  
'''Please note that in order to provide review comments, you will use the DISQUS feature at the bottom of each article. You may login to DISQUS using existing accounts (e.g. Google, Yahoo, Twitter, or Facebook) or you may create a DISQUS account. Please look for the BKCASE posts under the discussion for each article, which provide specific prompts for reviewers to consider.'''
+
*'''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.
  
==Two types of input requested==
+
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.
There are two forms of reviewer feedback: 
 
#Each of the articles has a set of discussion prompts in the embedded discussion at the bottom of the page. Reviewers are asked to consider these prompts as they conduct their reviews. 
 
#The word document [http://www.sebokwiki.org/075/images/7/72/SEBoK075_ReviewForm_Final.pdf SEBoK 0.75 Review Form] is provided to collect specific comments on the overall SEBoK and the wiki. Please provide responses by question number and return the document to [mailto:bkcase@stevens.edu bkcase@stevens.edu].
 
  
Please note that reviewers may download a PDF of SEBoK 0.75 [http://www.sebokwiki.org/075/images/2/28/SEBoK075_Final.pdf click here] or may download a specific Part for review by going to [[Download SEBoK PDF]].
+
Sincerely,
 +
[[File:Hutchison_Signature.png|200px|left]]
  
==Thank you==
 
The opinions and constructive criticism the BKCASE author team receives from you, the reviewer, plays an extremely valuable and important role in the worldwide success and acceptance of SEBoK.  If you would like to obtain further project information, please visit the project’s website at [http://www.bkcase.org/ bkcase.org] and if you have any questions during your review, please contact us at [mailto:bkcase@stevens.edu bkcase@stevens.edu].
 
  
The BKCASE author team sincerely thanks you for volunteering your time to help us with this important effort.
+
==Citations==
 +
Wymore, W. 1993. ''Model-Based Systems Engineering.'' CRC Press.
  
~The BKCASE Team
+
DoD. 2018. ''Digital Engineering Strategy.'' Arlington, VA: US Department of Defense.
  
[mailto:bkcase@stevens.edu bkcase@stevens.edu]
+
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