I had the privilege of giving a lecture at the INCOSE Webinar put on every third Wednesday of the month by the INCOSE CAB organization. I was originally scheduled for August but through some interesting circumstances I was moved up to February. And given only few days to prepare. Fortunately I had the basis from a lecture I do at the end of the UMBC Graduate Course ENEE 663: System Implementation, Integration, and Test.
I've put the abstract, a pdf of the slides, My responses to the Q&A, a record of the chat and more. Let's talk more. Use the comment section below.
It’s not hard to see that our society is being overrun by technology. And yet there is an expectation that we will solve our biggest problems by using technology. But these world spanning societal problems are becoming increasing complex and more difficult to solve because of the very technology that is embedded in the world already. Systems Engineering is a profession dedicated to finding holistic solutions that takes into account every eventuality. But trying to understand the emergent properties of the complex systems needed to solve complex problems is especially difficult. The future of Systems Engineering must address these issues in a compressive manner so that the next generation of Systems Engineers can face these challenges and find successful solutions. Paul Martin will be reviewing the 2007 INCOSE Systems Engineering Vision 2020 document in light of our present day dilemmas. Is INCOSE Vision 2020 still pertinent? Has Systems Engineering made the strides it needs so it can be part of making a better tomorrow for all of us?
If you are an INCOSE Member you can see the video in Connect at the Webinar Archives.
The INCOSE Webinar Host, Andy Pickard observed, “We had very good attendance and the most active chat line that I have seen in a webinar to date!” I was thinking we could continue our conversation in the comments section below.
To following questions are from the Q&A portion of the webinar. My answers are italicized.
Question 1: You stated that you viewed systems engineering as problem solving. The implication is as an 'after the fact' fire-fighter. I think that the real value of SE is at the beginning to middle of a project, not after the damage has been done. Care to comment?
So true, but unfortunately we live in a world where we are called in “after the fact” and forced to solve the mistakes of others. Sad but true.
Question 2: Why not add the recent failures with the government website for signing up for Obamacare as a failure in meeting its schedule, protecting data, etc. and having to be rescued with a new group of problem solvers?
Great suggestion and will add those failures to my slides the next time I give this lecture to my UMBC class.
Question 3: You said that we live in a 'man-made world.' Do you think that nature will remind us more in the near future of how little she respects that view?
Respecting the environment is very important to System Engineers and “Mother Nature” is as much a stakeholder as any other entity.
Question 4: Not so much a question as a point: I would argue that we have NO means of dealing with complexity OTHER than breaking it up into parts and interfaces among it. Reductionism is not bad. What is bad is selecting one view as 'the only' view, and then only breaking things up that way and not also describing the ways that those pieces interact along many dimensions. Those dimensions include power, signal, mechanical interfaces, data, protocols, timing, effect on user, change in environment, development cost, sustainment cost, etc.
Well said Dr. Sarah Sheard. However we do have a means to deal with the issue of “emergence” and complexity, and that is to build a high fidelity model (or build a prototype) and try out the integrated system in the virtual (or real) world. I can’t but think about how the Wright brothers used a methodical experimentation of full-size prototypes to discover the science behind aeronautical engineering. The science came after the modeling.
Question 5: Can you distinguish more clearly the difference between our current 'management realm' vs. the desired 'holistic solutions realm?' Particularly, what is meant by 'management realm?'
I believe that the “science” of Program Management is very mature. The PMs should be providing the services to the SE in the areas of Information Management, Configuration Management, Resource Management, etc. PMs should Manage and SEs should Solve. We want our customers to look at System Engineering as a “problem solving” discipline. Not just a Technical Management or Process Oriented discipline.
Question 6: What do you see as the impact of SE in the energy industry? Please address SE in oil & gas industry...thank you !
Energy is not my domain but my local INCOSE Chapter (Chesapeake) has a Working Group called: The Future of Energy (FoE) Initiative. Check out their website. They want to develop sustainable concepts for clean energy systems. Alex Pavlak <email@example.com> is the Group lead.
Question 8: We have a working group for Agile Systems and Systems Engineering (ASSE) that is defining both the need for modular architecture for an agile system and the need for some practice/process definition for the system engineer to flow to help work in an iterative fashion. Would you agree that we have our eye of the future to address your bad and ugly points?
Yes. I can see a future where there is a convergence of Agile and Model Based SE. A future where Design Reviews will be Model Based and our stakeholders will expect and understand the models we show them. A bright future with less bad and ugly points.
Question 9: Paul, Do you have any ideas on how information could be collected to actually quantify SE Success/Progress? Thanks.
If you think about it, the best place where SE Organizations hang out and gather is INCOSE! In the past I believe they have survey members for this type of information. Maybe it’s time to try again.
Question 10: Thank you for your thoughts - I can really see and understand the need for 'Lean Systems Engineering' - ie. to stop people seeing Systems Engineering as being expensive and cumbersome. QUESTION - what one thing would make the biggest difference and would help to start that journey?
We need to get SEs to see the value of the processes they use to “realize a system.” If there is no value then they need to have the courage to eliminate it.
Question 11: Which of the following two items currently limits our ability to produce complex system products predictably: a) limits to capabilities of the human systems engineers or b) the current limitations of tools, info handling, integration of info across disciplines, underlying systems science, lack of comprehensive modelling?
It is a) that leads to b). In other words, it’s our own human limitations that are reflected in the tools we make. These limitations will become less with time but how much time?
Question 12: How does SE in the future overcome the obstacles imposed by politicians making decisions in defining a problem and how to solve it which causes failures that the SE s knew how to prevent
See Question 2 to a real world example. Can we elect politicians that are system thinkers??
Question 13: Re: Complexity / Emergence -- while reductionist approaches are useful, we must also consider an approach to utility / requirements that is less focused on system-level specification compliance and more focused on characterizing capability (i.e., SoS) level performance to include degraded modes of operation and sensitivities to off-nominal operating conditions. (if we can't 'test' it, we don't know what we're delivering to the user).
Please use the comment section for more observations. Let the discussions begin.