Do Systems Engineers Need to Know SysML? Webinar

Rather watch than read? Check out the recording!

Do systems engineers need to know SysML? The question opens a broader conversation about what systems engineers need to understand, how they develop judgment, and where modeling languages fit into their work.

In the final part of our Engineering the Future webinar series, Courtney Wright, SPEC Innovations Director of Solution Engineering, spoke with David Long, President of Blue Holon, Inc., past INCOSE president, and longtime systems engineering practitioner, about SysML, model-based systems engineering, and the future of the profession.

Long’s answer to the title question was direct: a person can be a systems engineer without knowing SysML. He also made clear that he remains a strong advocate for MBSE. Throughout the conversation, the focus returned to understanding the engineering problem and using technology to support better outcomes.

Below are highlights from their conversation.

Do systems engineers need to know SysML?

Courtney Wright:

David, let’s dive right in. Do systems engineers need to know SysML? What’s your reaction?

david long:

This may be a controversial take with some, but I would argue, no, they do not. What is SysML? SysML is a modeling language. It is part of our ability to take advantage of computing power.

That’s a subset of systems engineering, one. And two, SysML is one of many languages. There is OPM, Object Process Modeling. There is LML, Lifecycle Modeling Language, and many, many others.

While SysML has a lot going for it, it is not the end-all, be-all of systems engineering. You can be a systems engineer without knowing SysML.

Takeaway

Long distinguished systems engineering competency from knowledge of a particular modeling language. SysML can be valuable, but it represents one way to support the broader work of understanding and engineering a system.

For someone developing their career, the question becomes which methods and modeling skills their role requires, alongside the systems engineering principles they need to apply.

Can someone do systems engineering without the job title?

Courtney Wright:

You think there might be people who are doing systems engineering who don’t claim it, maybe don’t know it?

david long:

Absolutely don’t claim it. Absolutely don’t know it.

As INCOSE reached beyond aerospace and military and reached into many of the commercial domains, one of the things that we saw very strongly at that point is that there were many people who were doing what we would call systems engineering practices under different brands.

They were attempting to address modern complexity, modern scale, transdisciplinary issues with some tools that we recognize, some tools that we don’t, but they didn’t call it that way.

Courtney Wright:

When I was working at INCOSE as certification program manager, I was seeing people apply for the expert level, in particular, who were submitting documentation saying, “I’ve been doing systems engineering for 25 years,” but they would very frequently pull me aside and say, “I didn’t know it. I didn’t call it that. My job title wasn’t systems engineer.”

Takeaway

Job titles and terminology do not always reveal the work someone performs. Both speakers described people who had applied systems engineering practices for years before recognizing those practices by that name.

Looking at responsibilities, methods, and the complexity of the problems someone addresses can provide a fuller picture of their experience.

What should employers look for at different career stages?

Courtney Wright:

If you’re looking to hire someone for a systems engineering role, what is a green flag you might see on their resume, something that gives you greater confidence about this person being able to perform as a systems engineer?

david long:

We’d like some junior practitioners who may be more up on some modern technologies. They could be domain-specific technologies, or they could be AI, they could be MBSE, they could be digital.

When I’m looking at mid-level, I want to see somebody who has appreciation of the lifecycle.

The systems engineering V is mislabeled. It’s actually the engineering V, of which systems engineering plays a connective role.

Can a systems engineer move from aerospace to medical? Absolutely. They can bring a lot of value. But knowing the domains, the physics, the contributing disciplines, they’re different for medical than for aerospace.

If I’m looking for somebody who’s going to be a hands-on lead, senior lead, principal systems engineer, I need them to know that actual application domain.

Takeaway

Long’s priorities varied by role. Junior practitioners can contribute familiarity with newer technologies, while mid-career engineers need to understand how decisions connect across the lifecycle.

For a senior technical lead, he emphasized knowledge of the application domain. Experience that helps improve an organization’s engineering practices may differ from the expertise needed to lead the engineering of a particular system.

How can engineers demonstrate more than tool proficiency?

Courtney Wright:

What would you see on a resume for someone who was applying for a systems engineering job that would scare you off?

david long:

One of the things would be somebody who only lists a set of systems engineering tools. “I know tool X, I know tool Y, I know tool Z.” That’s great, and that’s useful, but that might make you a modern-day data clerk as opposed to a systems engineer.

For systems engineering, we need to understand the fundamental principles and some of the greater methods, not just the languages and tooling.

Wright then asked how someone with years of tool experience could demonstrate that broader understanding.

david long:

I would start talking with them about what the greater methods and processes are, and the "whys" behind them.

For a requirements engineer, it would be more than just requirements management. It would be some of the requirements engineering aspects. As we’re going through decomposition, are we going through more than just restatement?

For somebody who’s doing systems engineering, certainly we would look towards an understanding of requirements, an understanding of architecting principles, an understanding of interface management.

It could turn out that the person who’s been playing that role for seven years has those things. I just want to know it.

Takeaway

Tool experience becomes more meaningful when an engineer can explain the methods behind the work and why particular decisions were made. Long was asking candidates to demonstrate their understanding, including knowledge they may already have developed through years of practice.

Examples involving requirements decomposition, architecture, or interfaces can help connect a list of software skills to the engineering work those skills supported.

What makes MBSE valuable?

Courtney Wright:

You are a huge champion of model-based systems engineering. Let’s give a pep talk for MBSE. What have been the successes that you have seen achieved through MBSE?

david long:

Fundamentally, what is model-based systems engineering? It is the application of modern computational power, both computing and storage, for enhancing the systems engineering process.

Why? Because artifacts may be wonderful communication tools, but they are terrible analysis tools, terrible data representation and data storage tools. So we can just do so much more in 2026 than we could in 1956.

Long described a space company that had used modeling techniques and tools tailored to its needs, developing them as the system matured.

david long:

Were they using a tool that we would label with the MBSE term? No, but they were using the power of digital to handle computation, to handle information complexity, et cetera.

Takeaway

Long framed MBSE around the engineering capabilities that digital models enable. His example showed an organization using modeling to address its needs even though its tools did not carry the familiar MBSE label.

That perspective keeps attention on what a team can analyze, understand, and communicate through its models, and how those capabilities improve the engineering process.

How much of a model should leaders understand?

david long:

You cannot separate an engineer, or for that matter a practitioner, from their data. If you do, then what is that individual doing?

If I’m working at a system level, there may be some high-fidelity models that I am aware of, but I’m not touching. I certainly have to have an understanding of the architecture of the system. That’s what my job is.

One of the traps of digital, one of the traps of model-based, is that we’ve confused accuracy and precision. Digital baits us into premature precision. I always need to be accurate. I should only be as precise as I need to be. I always have to have the big-picture understanding of the system.

courtney wright:

What’s the risk of a leader, chief systems engineer, program manager, not understanding the models that their team is using?

david long:

In a modern transdisciplinary system, none of us can be experts in all of the technologies, all the disciplines required to bring that system into being.

We have to know just enough to know whom to ask and whom to trust in each given area.

A leader has to be able to say, “That’s an order of magnitude out. There’s something not right there. Dig deeper.”

Takeaway

The appropriate depth of model knowledge depends on someone’s responsibilities. Leaders may not need to build or manipulate every detailed model, but they need enough understanding to ask useful questions and recognize results that deserve investigation.

Long’s distinction between accuracy and precision also challenges teams to consider whether added detail is useful. A highly detailed model still needs to represent the right problem and support sound decisions.

How can AI support the development of engineering judgment?

Courtney Wright:

As you’re saying that, AI is coming to mind for me. As you were talking about the precision and accuracy, I was having the same concerns.

david long:

With AI, we should segregate a little bit, much as you did with senior, mid, and junior. How can we be using AI thoughtfully today, and how should we be looking at it tomorrow?

When you have AI complementing a senior practitioner, regardless of the domain, but certainly in systems engineering, it’s a very valuable tool. The senior practitioner has that built-up basis of engineering judgment to say, “This does not feel right.”

An early-career practitioner does not have that basis of engineering judgment. They have to default more to what the model is telling them or what the AI is telling them. And that’s very dangerous.

In the early career, we should be thinking about how we can make it a partner, not only in our engineering efforts, but in our developmental efforts. How can we accelerate our learning curve as a systems engineer?

If we were to augment that with AI learning cycles, we could perhaps take engineering judgment to a level we haven’t seen before. But we’ve got to be very thoughtful in that so that we don’t abdicate trust to digital, trust to model-based, or trust to AI.

Takeaway

Long saw potential for AI to support learning as well as engineering work. He also emphasized that experience affects someone’s ability to question an answer that looks convincing.

His proposal was an opportunity to explore carefully: use AI to help engineers develop judgment while keeping them actively involved in evaluating the results.

What experiences help engineers build judgment?

Courtney Wright:

Whatever you’re doing, your judgment is improving, because that’s the skill that you need for the future. Any other tips on how people can improve their judgment?

david long:

It’s breadth of the systems engineering lifecycle, or engineering lifecycle. And I’m going to say it’s a little bit of diversity of roles.

Through my career, one of the things that I’ve observed is that some of the best systems engineers come out of test and evaluation. The reason they come out of test and evaluation is that they understand how things break and some of the real-world consequences of early-phase decisions.

Therefore, they have that built-up judgment base to perhaps factor in some considerations that others don’t.

Wright also raised the value of experiences outside work, including volunteering, sports, family responsibilities, and trying a car repair.

david long:

Oftentimes, we view systems engineering way too narrowly. We view it in a product-centric mentality. We don’t view it through the broader systems-thinking and interactive lens.

My belief is that all systems engineers are leaders. They have to lead from the middle of the pack, oftentimes without positions of power, without positions of authority.

We can take a lot of these professional competency insights, learnings, and lessons out of volunteer societies, out of church, out of family and bring them into our day job to augment our judgment base.

Takeaway

Exposure to different lifecycle stages helps engineers see the consequences of decisions. Long highlighted test and evaluation as a particularly valuable source of that experience.

Both speakers also recognized learning beyond the workplace. Experiences involving coordination, leadership, and the effects of decisions can contribute to the professional judgment engineers bring to a team.

How should organizations decide what to invest in MBSE?

Courtney Wright:

If you were advising a team on investment in MBSE tools and they’re trying to decide, “Do we buy something new? Do we just use Excel and PowerPoint? What should we do?” What are some of the criteria that you would suggest they consider?

david long:

One of the things I would ask them to consider is, honestly, what is their level of systems engineering maturity to begin with? Because it is very easy for your tooling aspirations in a model-based way to fundamentally outstrip where you are.

Before you assess your digital aspirations, before you assess your digital competencies, let’s talk about your systems competencies, your systems engineering aspirations, and then obviously what your real business need is.

Are you trying to solve a knowledge management problem? Are you trying to solve a high-fidelity modeling problem? Are you trying to solve a product line problem? Those are different challenges that will point you to different levels of investment.

If you want to change your systems engineering outcomes, you have to change your investment in systems engineering. That’s going to be training. It’s going to be tools. It’s going to be the way that you work.

You really have to focus: what is the business outcome that we’re after? Because the purpose of engineering is not to produce a better model. The purpose of engineering is to advance a business or societal outcome.

Takeaway

Long recommended starting with the organization’s engineering maturity and the problem it needs to solve. Those considerations help define the capabilities, training, and changes in working practices that an investment should support.

He also cautioned that changing how a team works can slow its first attempt. Establishing the desired outcome beforehand gives the team a clearer basis for judging the value of the change across the lifecycle.

How can systems engineers make training stick?

Courtney Wright:

What’s the other way that people can be educating themselves outside the job on what’s next and what they should know in systems engineering?

david long:

I am a big fan of really just-in-time, fit-for-purpose training. The half-life of systems engineering knowledge is pretty short, so you need to put it into practice. If you have a framework, then using targeted training, whether it is organization-provided, outside-provided, et cetera, is very valuable.

Courtney Wright:

You said that the half-life of systems engineering knowledge is short. Let me clarify that a little bit. I think of unapplied, right? If you learn it and then you don’t apply it, it withers away. If you learn it and you do apply it, it will stick with you and continue to be valuable.

david long:

Thank you for the clarification, because you’re spot on. If I study it and I don’t put it into practice for two years, then a lot of it fades away. If I study it and I apply it in my program, it’s sticky; it anchors.

Takeaway

The clarification matters: the speakers were discussing the difficulty of retaining unused learning. Connecting training to a current project or near-term assignment gives engineers a chance to apply and strengthen what they have learned.

Targeted training can therefore complement a broader educational foundation throughout a career.

How might shared models change technical communication?

Wright asked Long to compare traditional design reviews with collaboration around shared models.

david long:

I think shared collaboration around digital models across a holistic team is accelerating and is more in favor with early careers.

We tend to frame things in an either/or. Here’s an “and” world. The reality is, I think through agile mentalities, continuous verification, et cetera, that we will see a lot more collaboration around models with very thin, very focused gate reviews.

Courtney Wright:

I have also been pleasantly surprised to see the transition away from design reviews as we realized those were necessary because of communications. When we have Zoom, when we have ways for people to look at a shared model together, we don’t all have to be in the same room.

Takeaway

Long envisioned ongoing collaboration around models paired with focused reviews at decision points. The discussion preserved a role for reviews while questioning whether large meetings are the most effective way to share and assess engineering information.

A shared model can give people a common basis for that discussion, with the form of communication adapted to the team’s needs.

When is SysML an appropriate choice for sharing models?

During the audience Q&A, an attendee asked about approaches for sharing models and digital twins between government and contractors.

david long:

There is no singular best.

If that is your use case, and if it is the design of that kind of system, if the people that you’re communicating with are using SysML, there’s absolutely nothing wrong with it.

The point is that not everything fits in that camp. If I were going to engineer an organizational system, I don’t think I would go towards SysML. If I were going to work with a lot of non-technical stakeholders, actually what I did behind the scenes would be tailored to my engineering method, and then I would develop fit-for-purpose visualizations for others.

For the scenario that you’ve laid out, assuming your customers are using SysML, it’s absolutely great. The challenge is when we default and say, “SysML is the answer, what’s the question?”

Takeaway

Long’s answer returned to the purpose of the work and the people who need to understand it. SysML can be a strong choice when it fits the engineering method and the communication needs of the customer and team.

His opening answer was therefore compatible with a positive view of SysML: systems engineers can select it for a reason, while recognizing that other methods and representations may serve different situations.

The future of systems engineering starts with the engineering

Across the conversation, Wright and Long returned to the importance of lifecycle understanding, engineering judgment, and clear communication. Modeling languages and digital tools support those capabilities, and engineers need opportunities to apply them to real problems.

The same perspective shaped Long’s advice to an audience member considering a move into MBSE. He encouraged building a systems engineering foundation and putting that knowledge into practice in a modeling tool.

david long:

It should be about being a systems evangelist who does their work in a model-based manner.

For teams planning their next step, the conversation offers a useful starting question: what engineering outcome are we trying to improve, and what knowledge, methods, and tools will help us get there?

Continue the Conversation

This webinar concluded SPEC Innovations’ three-part Engineering the Future series.

Explore the full webinar series for conversations about the careers, education, and technologies shaping the profession.

You can also join Ask a Systems Engineer, our weekly live Q&A, to bring your questions about systems engineering, MBSE, digital engineering, and professional development.