Aerospace Systems Engineer


Tools are worthless

Ultimately any analysis technique, tool set, etc will work. But just spending thousands on a tool set won’t fix a philosophical problem, either. What matters is commitment that SE is valuable and must be done. Its “pay me now or pay me later”. 

Systems Engineering - Where’d we go wrong?

We haven’t expected Systems Engineers to do Systems Engineering in quite a while.
  1. We don’t derive the system, we assemble it.
  2. artificial work partitions have developed within Systems Engineering: We don’t document the system, we write disconnected specs, ICDs (and, maybe, conops)
  3. tools – DOORS, or modeling tools have become the ends not the means
We have lost the understanding that Systems Engineering is the process of deriving a viable system design, and the production of products communicating the design.
We focus on symptoms rather than the problem
  1. we see an integration problem when we really have a design problem
  2. we see requirement problems when we really have a lack of an operations concept
  3. we see a verification problem when we really have a requirement problem
We have abdicated Systems Engineering to others; Architects, Product Engineers, SW Engineers and “Ivory towers” experts.
  1. SEs just develop isolated documentation devoid of responsibility for, or understanding of, the system
  2. SW by its nature must integrate and be functional – the best SEs are currently found in SW engineering
  3. Esoteric discussions of architectural frameworks (yes, there is more than DoDAF) and modeling techniques and tools are interesting but impractical to the program manager, especially when asked to be implemented by a staff that doesn’t understand the Systems Engineering problem space.
  4. Good program managers justifiably resist expensive new tools, techniques or methods especially when wielded by, or foisted on, a staff ill-equipped to evaluate their efficacy or apply them productively.
We have lost technical management
  • We manage schedules and people, but we don’t manage the technical process. Technical management (usually the CSE) and program management need to work hand in glove.

A Practical Recovery Approach
A practical way forward is needed in the short term. Ultimately we need a more comprehensive reintroduction of, and appreciation for, Systems Engineering practices.
Two key things are needed, and competency in them both is readily achievable.
Write requirements well!

  • The 80% solution: “Upon x, the system shall do y, within z.”
  • If this were the only improvement implemented – we would be greatly improved. And it’s easy.
Consciously, deliberately, knowingly - derive the system design
  • This is a team effort! Commitment to this Systems Engineering responsibility would have tremendous rewards.
  • We have talented young engineers they will figure out (or reinvent) how to do it – but first they have to know it’s our responsibility. Deriving the System means, starting from the system’s objectives, develop the necessary architecture and behavior – which are the requirements to fulfill the objectives.
  • I suggest employing Use Case elaboration, to derive and document Requirements (specifications), Architecture (ICDs) and Behavior (OCDs) - holistically. But, don’t go overboard on cutting edge (bloated) tools and techniques.

That Process Problem

Engineers, I believe, tend to create and follow "process" just because it's our nature.  We like to organize and pigeonhole things.  It makes us feel productive.  But we seldom ask the hard question "Why".  Where is the cost benefit trade.  Where is the 80% solution, the "good enough".  Begin with the end in mind.  These are programmatic issues that are supposed to be part of the decision equation.

DOORS is a relational database.  We use it as a CM/DM tool and a word processor.  And, I think, just because we can.

DOORS is appropriate for managing the relationships between objects.  Requirements and possibly their relationships through ICDs and CONOPS documents might be a possible a candidate for incorporation into DOORS.  But then the Pandora's box is opened,…  We will ask (or have asked) ourselves,…Why not link the documents through DOORS.  This means the documents must be entered/ingested into DOORS.  And the links established.  And validated (mistakes are very possible/probable).  Which creates another mindless audit opportunity for the bureaucrats; "how many orphans?", "What's your 'burndown' rate?" 

It's hard for me to argue against "process" and "tools"; but somebody has got to ask the hard questions and do the trades;  Where is the "value added"?, Where is "good enough"?  These are programmatic questions.  Engineers don't like to address them because we can't calculate the "right" answer.  They aren't quantitative and there is risk.  We don't like that.  

I think the commercial world may "work" because of the Dilbert "pointy haired" boss, who we "Dilberts" like to make sport of.  Maybe there is method in his madness?  Maybe we actually need more programmatic management?  Maybe those aren't "stoopid" questions?

I had the good fortune (I think) of growing up as a Systems Engineer in an environment with a very strong Chief Engineer and a very strong Program Manager and hearing these two very strong women argue (cooperatively and respectfully); "It's not always about the technical, cost and schedule matter", "Sometimes it is about the technical".  These are not easy decisions but they are extremely important to a program's viability.

Systems Engineering was supposed to help Program Management by performing the technical management but we have abandoned that role and replaced it with armies of adminichrats who generate and execute "process" mindlessly.  And play with the tools; DOORS, Rationale ROSE, TAU, Rhapsody, etc,…

Begin with the end in mind!   Why are we doing "X"?  What are the benefits?  What are the risks?  What is the cost in dollars and schedule?  (Hey- that's the basis of any change process)  WHY DON"T WE FOLLOW IT FOR THESE BUREAUCRATIC DECISIONS!?