Patrick Forgione, MSE’s Post

View profile for Patrick Forgione, MSE, graphic

Senior Principal Systems Engineer at Raytheon | MBSE Lead

Put the SE back in MBSE In the engineering community, the mention of MBSE is usually tied to keywords like SysML, Cameo, MagicDraw, and other mentions to the numerous other platforms. Don't get me wrong, I have been a Cameo/MagicDraw user for over 10 years and will continue to champion those platforms (maybe a bit of bias)...but MBSE is not the tool, it is not the platform, and it not the language. MBSE is Systems Engineering that caught on to using digital tools much like Mechanical Engineering (CAD) and Electrical Engineering (ETAP)...however it got caught up in itself by becoming encompassed by the tools they use. This isn't a shaming post; far from it. What I am striving to do is bring back what it means to be a Systems Engineer back into our modeling practices. Bring back the importance of systems thinking and critical thinking, bring back asking "why"...especially before we open the modeling tool to get to work, and...with absolute emphasis on this...bring back communication. Our jobs as Systems Engineers isn't necessarily to know everything, but to know everyone. We need to understand our stakeholders and understand all of their requirements...not just the system requirements. We must be asking these questions and doing our due diligence first before we even start thinking of what kinds of SysML elements we might be using. I can tell you that I have an Excel file, almost 20mb in size (and growing), on brainstorming and organizing my thoughts on my current program before I even open Cameo. Consider it a whiteboard session for myself but I truly advise you all to get your thoughts in order and to speak to people before you go and model. The biggest battle we face in MBSE is getting that buy-in from leadership/management on how effective we are and the value that modeling brings. Though, if we lack those communication skills and don't network within our stakeholders, we will continue to face that resistance. We must grow that trust, form the necessary bonds between your teams, and, with those "soft skills" you'll find that your MBSE approaches are more welcomed. I leave with a quote from the #incose SEBoK - "Systems thinking is concerned with understanding or intervening in problem situations, based on the principles and concepts of the systems paradigm (https://lnkd.in/e9NsQs2M)". The keyword I want to highlight there is "problem". If we don't understand the problem, if we don't care to ask qualifying questions, and if we don't organize these thoughts effectively then the model is just another collection of pretty pictures.

Systems Thinking

Systems Thinking

sebokwiki.org

Sarah Sheard, Ph.D.

Researcher and Consultant, Software Engineering Institute (Retired)

1mo

I agree! Some people find great pleasure in getting every detail right, to the point that they extremely uncomfortable with making any general statements until the details have been worked out. Tools allow them to dive right in. Others have more difficulty determining which details to start looking into without an overall “big picture” tied to need and strategy. In my mind at least these tend to be systems engineers and architects. I have settled on a strategy over the years of layering. Come up with a big picture and develop the details one layer down for anything not suspected to be a problem, two layers if it seems there might be an issue. Then you have enough to do the first set of feasibility studies. Continue making decisions layer by layer However I will say that I get the biggest pushback on this approach from software people, probably rightly so. One missing bit can break software. When I wrote in an article while I worked at a Software organization that systems engineers don’t focus on details, the CTO said that was incredibly insulting to systems engineers. (Nothing could be more important than details! Not doing them was tantamount to saying systems engineers are careless and slipshod!)

Patrick Hillberg Ph.D.

Adjunct Professor @ Oakland University | Product Lifecycle Management (PLM) | Speaker, Consultant, Expert Witness | Advocate for Workforce Development | Ex-Siemens PLM

1mo

IMO… I tell my students “your model is incomplete until it shows the impacts of culture, economics, and feedback loops”. Senge’s “The Fifth Discipline” posits four disciplines as a basis for Systems Thinking: - Personal Mastery - Mental Models - Shared Vision - Collective Learning - Systems Thinking Your comments on tools have analogies to Senge, in particular Shifting the Burden: - Products are complex, so we need models. - Models are hard, so we need tools. - The tools are hard, so we develop expertise and arcane languages - Only Shamans understand the SE language. - The culture divides between SE Shaman and those required to implement what the Shaman command. 🙄 (And I have an MS, PhD, and faculty position in SE.) INCOSE seems to be prisoners of their own mental models. In the SEBoK, or on their website they seem determined to define Systems Thinking within the constructs of Engineering. But Engineering is a Subsystem.

Samuel Boutin

Chairman, Knowledge Inside

1mo

It is easy for a tool to become so complex that staying expert user is a full time job. When this happens, there is a gap between people who think what to do and people building the model. Then organizational interface and a new silo is getting birth. Especially in upfront design, when you need to be fast and investigate a lot of solutions with limited resources, that does not fit at all. But downstream, when one main solution detailed, big companies can play this game if they have money for it.

Markus Götz Junginger

car guy, engineer, founder

1mo

Gentlemen, forgive my bias. Many of our thoughts and perspectives get cluttered through the inherent complexity of our tools and concepts. Clarity of thought drives our ability to communicate and invite stakeholders to be lead through our work. I still consider ISO 19450, the OPM methodology the superior concept in modeling. The works of Prof. Dori demonstrate the purity of reason. Modelling without the unnecessary chaff. Tradespace optimization on architectural or design level requires this simple technical truths.

Completely agree. I feel like “SE” gets overlooked during implementation of MBSE because it has been pushed so hard as a requirement for government contracts. So, to no fault of their own, individuals are given MBSE tasks without understanding SE fundamentals. During my training courses I try and stress the importance of systems thinking and the exercises that should occur prior to modeling. But the reality is - there is a pressure to appease the government and meet the contract requirement (on schedule and under budget). SE simply cannot be taught in a week in addition to an MBSE tool, language, and approach. Your thoughts?

Robert Hämisch

Simplify Systems Engineering - Easier Assessments. More innovation. Happier teams | Automotive Developer & Systems Engineering Revolutionary | Wrote code for the world's first SAE-L3 vehicle - and got it 'street legal'

1mo

Agree. Interesting observation, summarizing your thoughts provocativelly: Once SE started using tools, communication took a hit. Do the tools have anything to do with that? Time for new ones? 😄

Robin Kennea

Lead Systems Engineer | Aerospace | Electric Propulsion

1mo

There's no MBSE without SE. (And good SE at that....). As an ex-aero/mech design engineer it really frustrates me when, on receiving a brief, young designers fire up their CAD system immediately and start modelling. It's as if using pencil and paper to sketch ideas is anathema. Same goes for sys engineers & MBSE; you're notebook is your best friend. Ditto on the giant personal spreadsheet thought dump! This is the new notebook.

Henk-Jan Scholman

Engineering Process Improvement @ IDECI | Smart Customization, Change Management

1mo

Working as a lecturer mechatronics it is what i tell my students: as mechatronics engineer your communication skills is what should set you apart from the specialists: you'll need them to solve cross- or inter-disciplinary problems. SysML and similar tools are needed to map the design and discuss its problems in a common language (not CAD, ECAD or software code) so all stakeholders can understand.

Raymond Wolfgang

I help people in Systems & Requirements succeed at their jobs quickly. To explore if or how I can help your engineering project or career with my courses or trainings, grab a spot on my Calendly below.

1mo

Great post! And, I always think links to the SEBoK are value-added. And I agree, the barriers to MBSE implementation are not technical. #mbse #sebok

Mike Delaney, PE

Instrumentation Technical Expert at United States Air Force

1mo

"Systems Practices as Common Sense" is my favorite overall book on SE.   It's too easy to focus on the wrong thing.  I forgot the source but at the start of a SysML class the instructor said before you make a model, you need to understand why, who the intended viewer is, and what they should get out of it (unless I'm paraphrasing or mixing multiple bits of advice).  I've been saying that out loud in meetings a lot these days.  

See more comments

To view or add a comment, sign in

Explore topics