Difference between revisions of "Editor's Corner"

From SEBoK
Jump to navigation Jump to search
 
(188 intermediate revisions by 8 users not shown)
Line 1: Line 1:
__NOTOC__
+
[[File:Hutchison,Nicole Profile.jpeg|right|200px]]
==History, Motivation, and Value==
 
The Body of Knowledge and Curriculum to Advance Systems Engineering Project (BKCASE) began to create a community-based ''Guide to the Systems Engineering Body of Knowledge (SEBoK)'' and a ''Graduate Reference Curriculum for Systems Engineering (GRCSE)'' in fall of 2009 (Pyster and Olwell et al. 2012) (Please see http://www.bkcase.org for more information).  The SEBoK came into being out of a recognition that the systems engineering (SE) discipline could benefit greatly by having a living authoritative guide that discusses what is included in the discipline, how the discipline should be structured to facilitate understanding, and what documents are the most important to the discipline. A key principle of the BKCASE project is that the SEBoK and GRCSE will always be available free worldwide – including the revisions to those products.  
 
  
Through the end of 2012, BKCASE was led by Stevens Institute of Technology and the Naval Postgraduate School in coordination with several professional societies and sponsored by the U.S. Department of Defense (DoD), which provided generous funding. Volunteers from dozens of companies, universities, and professional societies across 10 countries contributed many thousands of hours writing the SEBoK articles; their organizations provided significant other contributions in-kind. For additional information on the BKCASE authors, please see the [[Acknowledgements]] article.
+
{|
 
+
|-
The scale and complexity of BKCASE emerged over the first few months of the project.  Systems engineering is large and relatively immature when compared to more classic engineering disciplines, such as electrical and mechanical engineering.  We are extremely pleased with how the community rose to the challenge.  New authors continually stepped up when gaps in the writing team were identified and we routinely assembled 25 to 30 authors every three months in a multi-day workshop to iron out issues and make key decisions.
+
|<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>
 +
|}
  
One of the most critical decisions occurred in January 2011, when the team confirmed a switch to a wiki-based presentation for the body of knowledge. This added much complexity to the effort, but offered great advantages in terms of the modularity for update, access to interim material by the authors, easy review and suggestions for improvements, and flexible navigation.  In hindsight, the impact of choosing a wiki was much greater than we understood, but we are very happy we went down that path.  We believe this format to present the body of knowledge will serve the SE community much better than if we had produced a traditional PDF or Word document.
+
<div style="text-align:right">'''06 May 2024'''</div>
  
To help ensure both the quality of the SEBoK and its acceptance by the community, it was vital that the SEBoK be created with an open collaborative process. Specifically, each version had public review and each review comment was adjudicated. The adjudication results can be found at [[SEBoK Review and Adjudication]].
+
'''What's the holdup with Digital Engineering?'''
  
The earliest value of the SEBoK has simply been the greater sense of community that has developed among the authors, which include many fellows of professional societies and other leaders in the field. For example, the relationship between Systems Science and Systems Engineering is now more clearly understood than in the past. This relationship is captured in Parts 2 and 3 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.  
  
The greater value of the SEBoK, of course, comes from use by the community. As of the end of October 2013, SEBoK articles have been accessed more than 200,000 times and early usage reports are quite encouraging.  We hope the SEBoK will regularly be used by thousands of systems engineers around the world as they undertake such activities as creating systems architectures, developing career paths for systems engineers, and deciding new curricula for systems engineering university programs.
+
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 SEBoK is intended to evolve and morph with use and with changes in the field. The wiki structure is particularly well-suited for promoting that purpose. Users are asked to comment about what they like and dislike, what is missing and what should be removed.  New articles will be added and existing articles updated regularly.
+
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.
  
At the beginning of 2013, with version 1.0 of both SEBoK and GRCSE released, BKCASE transitioned to a new governance model with shared stewardship between the Systems Engineering Research Center (SERC) (see http://www.sercuarc.org), the International Council on Systems Engineering (INCOSE) (see http://www.incose.org), and the Institute of Electrical and Electronics Engineers Computer Society (IEEE-CS) (see http://www.computer.org). This new governance structure was formalized in an agreement between the three stewards that was finalized in spring of 2013. The stewards have reconfirmed their commitment to the key principle that SEBoK and GRCSE will be available at no cost to the users.
+
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.
  
==SEBoK Philosophy==
+
Why is it, then, that digital engineering is not moving as quickly as we'd like?
The SEBoK is sometimes compared to Wikipedia. The SEBoK is like Wikipedia in its most fundamental structure, as it is a collection of wiki articles built on MediaWiki technology. However, the SEBoK is unlike Wikipedia in that its content is carefully controlled. Anyone in the community can suggest changes be made to SEBoK articles, but no one except the SEBoK Editors can actually implement those changes in the SEBoK wiki. Wikipedia is a much more open wiki, allowing virtually anyone to change any article, while reserving the right to undo changes that are offensive or otherwise violate Wikipedia's rules. Tight control over SEBoK content is a tradeoff.  Such control ensures a stable baseline whose quality and integrity are assured by its editors.  On the other hand, such control discourages some members of the community from contributing improvements to the SEBoK.
 
  
To satisfy both the need for a stable baseline and the desire for broader community involvement, we have implemented a new collaborative space. The ''SEBoK Sandbox'' is a copy of the SEBoK that is separate from the baseline version where anyone in the community can edit articles, recommend new content, or provide comments on existing articles. It is important to note that while anyone in the community can gain access to the Sandbox, all submissions must still be approved by the Editorial Board before they will be folded into a new baseline version of the SEBoK. For more information on how this works, please '''[http://www.sebokwiki.org/sandbox visit the Sandbox]'''.
+
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.
  
==Version 1.2==
+
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.
This version of the SEBoK was released 15 November 2013. This is a minor release of the SEBoK which includes two new articles, a rewrite of one article, updates to existing articles, and new primary references. The Editorial Board plans to release the next version of the Sandbox in late November 2013.
 
  
Changes between versions 1.1.2 and version 1.2 include:
+
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.
*Two new articles: [[Integrating Supporting Aspects into System Models]] and [[Technical Leadership in Systems Engineering]]
 
*Heavy revision to [[Decision Management]]
 
*Minor edits to articles in Parts 1, 2, 3, 4, 5, and 6 and
 
*Two new primary references.
 
  
==Version 1.1.2==
+
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:
Version 1.1.2 was released 1 August 2013 as a micro release that corrected some errors and added some wiki functionality. The biggest change in the release of v. 1.1.2 was the co-release of the companion SEBoK Sandbox, a collaborative space for the systems engineering community.  
 
  
Changes between versions 1.1.1 and 1.1.2 included:
+
*'''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.
* Version numbers were removed from page titles to improve maintenance of links
+
*'''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.
* Reflection of the governance of the SEBoK and oversight through the Editorial Board, including a page called [[Meet the Editors]].
+
*'''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.
* A few references were updated, notably in the [[Safety Engineering]] article.
+
*'''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.
  
No comments were adjudicated for this micro release.
+
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.
  
==Version 1.1.1 ==
+
Sincerely,
 +
[[File:Hutchison_Signature.png|200px|left]]
  
This version was released 14 June 2013 as a micro release that corrected some errors and added some wiki functionality.
 
 
Changes between versions 1.1 and 1.1.1 included:
 
* Version numbers were removed from page titles to improve maintenance of links
 
* Spelling errors in contributor names were corrected.
 
* 'Cite This Page' was revised and improved.
 
* A few references were updated, notably in the [[Safety Engineering]] article.
 
* Meta-tags were improved to increase visibility to search engines
 
* Wiki navigational features --- especially breadcrumbs --- were improved. 
 
* A counter was added to record PDF downloads.
 
 
No comments were adjudicated for this micro release.
 
 
==Version 1.1==
 
This version, released 26 April 2013, was a minor release which updates many topic articles and glossary articles.
 
 
Changes that were made include:
 
* Fourteen topic articles were updated in Parts 1, 2, 3, and 6, for the purpose of expanding or improving the explanation of the topic, or in some cases to add new references.
 
* Sixteen glossary terms were updated and two new glossary terms were added.
 
* The [[Acknowledgements]] page was updated to reflect the significantly revised governance structure for the SEBoK, which added many new contributors in varying roles.
 
* The [[Main Page]] and other Quicklinks pages were modified to reflect the new version.
 
* The SEBoK Evolution article formerly in SEBoK v. 1.1 Introduction was deleted, being replaced by an updated version – this Editor's Note article.
 
 
There were no changes to wiki navigation and operation.  Comments from version 1.0.1 that were adjudicated were deleted from DISQUS, while comments still to be adjudicated remain in the wiki.
 
 
==Upcoming Releases==
 
 
We will regularly update the SEBoK to correct errors, improve existing articles, add new articles, and respond to specific comments from the user community.  The current plan is to issue occasional micro updates and two minor updates a year for the first two years, and then decide whether a larger more major revision is needed in the third year or whether additional micro and minor revisions are adequate. Micro updates correct spelling errors and sentence grammar and make other very modest changes and occur as needed. They are identified by three digits - Version 1.x.y.  Version 1.0.1 was the first micro release. Minor updates will correct errors, continue to add content to existing articles, including any new references published recently, and perhaps add articles to existing knowledge areas.  Minor updates will not change the basic organization of the SEBoK.  The editors may not respond to all comments posted in DISQUS for the minor updates. This release, Version 1.2, is the second minor update.  Major updates will be unconstrained.  All accumulated comments and suggestions will be adjudicated for the major updates, and the adjudication results will be posted for the community.
 
 
New releases are under the control of a Governing Board appointed by the stewards, who oversee the SEBoK Editor-in-Chief, Co-Editor-in-Chief, and an Editorial Board.  The stewards contribute resources to manage the SEBoK wiki, support new releases, and encourage SEBoK adoption.  Volunteer authors from the world-wide SE community continue to propose and create new content and other volunteers review that new content.
 
 
The next minor release will be Version 1.3, currently scheduled for publication in the first half of 2014.  The editors have several new articles and article updates already in the pipeline for v. 1.3.  We expect the community will contribute many more new changes during that timeframe.
 
 
 
[[File:EditorsinChiefSignatures.png||center|400px]]
 
 
 
 
<center>
 
{|
 
|-
 
|style="background-color: #ffffff"|[[File: Stevens.jpg|300px|center|Stevens Institute of Technology]] |
 
|style="background-color: #ffffff"|[[File:Systems_Engineering_Logo_r3.JPG|552px|center|Naval Postgraduate School's Systems Engineering Department]]
 
|}
 
</center>
 
  
==Works Cited==
+
==Citations==
 +
Wymore, W. 1993. ''Model-Based Systems Engineering.'' CRC Press.
  
Pyster, A., D.H. Olwell, T.L.J. Ferris, N. Hutchison, S. Enck, J.F. Anthony, D. Henry, and A. Squires (eds). 2012. ''Graduate Reference Curriculum for Systems Engineering (GRCSE™),'' version 1.0. Hoboken, NJ, USA: The Trustees of the Stevens Institute of Technology ©2012. Available at: http://www.bkcase.org/grcse-10/.
+
DoD. 2018. ''Digital Engineering Strategy.'' Arlington, VA: US Department of Defense.
  
{{DISQUS}}
+
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