Emergence: The Mystery of Systems Engineering

It’s a well know cartoon. Two scientists are gazing at an eminence blackboard filled from top to bottom with a complicated formula filled with mathematical equations and process jargon and symbols. One of the scientists points to an area of the blackboard where the process states, “Then a Miracle Occurs.” He explains to his partner, “I think we need to be more explicit here in step 29.” I can’t but laugh every time and yet it’s so profoundly true it makes me shudder.

Our whole Systems Engineering profession is build around decomposition, implementation, integration and verification. And so this mystery (or miracle) of emergence is just assumed or taken for granted. I teach this stuff at the graduate level and even I am unsure how to explain why properties and/or capabilities will emerge when you put together components of a system. Even though these various individual pieces have none of the properties and/or capabilities of the larger system. It just happens.

My interest in emergence came about when I was exploring the phenomenon of "Unintended Consequences." I wanted to know if there was a way we could plan and manage these unexpected results of our system development efforts. “Unintended Consequences” are basically unwanted emergent properties. And just like the senseless task of looking for an “unknown, unknown” risk, how can you predict the unpredictable?

You can’t, but you can at least appreciate the mystery unfolding before your very eyes.

There is an excellent book appropriately called, Emergence, by Steven Johnson which explores this topic in detail from a more societal point of view.

By the way, another really great exploration of Emergence was also done by one of my favorite radio show and podcast, “Radio Lab.” It's well worth a listen.

The Value of Failure

I have two iconic images which depict failure in a positive light. (1) A scene from the movie Meet the Robinsons: The protagonist has just had an experiment blow up in his face and as he dejectedly faced his family he is surprised to find them celebrating his failure with enthusiasm usually saved for birthdays. They explained that failure was the sure sign you're getting closer to the solution. (2) One of my favorite demotional poster: A ship is sinking, bow up and two thirds in the water. Caption reads - “MISTAKES: It could be that the purpose of your life is only to serve as a warning to others.”

Both of these cultural ditties push the one aspect of failure which makes it an important part of our lives ... it’s the “lessoned learned” which informs us of what NOT to do ... it’s the Feddback Loop into our lives, allowing us to eventually succeed.

As Systems Engineers we face failures every time we take our product in the evaluation phase of its development cycle. Will it meet the requirements, both technical and operational? And of course we’re the ones who need to evaluate the impact these failures will have on the overall project. The cost, schedule and performance issues must be addressed in a creative and resourceful way. Such is the burden and responsibility of the Systems Engineer.

Of course failures come in may sizes. Small ones from your test events that can be worked off as a “lien” against the product acceptance. Or the large failures which occur after the product has been deployed and during its operation. Lives and the environment can be ruined as a result. Just look at BP oil spill in the gulf. But no matter the size or enormity of the failure it’s still there as a “warning.” Don’t make the same mistake, learn from the lesson, embrace the failure as a part of the price to be payed towards the road of a positive outcome. It’s OK to fail, just don’t let it stop you from going forward.

The girl engineer in my life

There's a confluence of two celebrations this month that for me personally hit home.

The first: The well regarded and well know celebration of my chosen profession, National Engineer's Week. A week long celebration that makes New Orleans celebration of the Saint's Superbowl victory look like a picnic. We're talking about Future City Competitions and School presentations and other neat stuff, which I can't think of right now.

But the best part of the whole holiday is today's "Introduce A Girl To Engineering Day, February 19, 2009"

Which actually brings me to the second celebration. The less well know celebration of an obscure monk named Valentine. You may not be aware of this tradition of blessing the loved ones in your lives with cards, flowers and candy but I am one a few who know and follow the old ways.

One of my loved ones is my daughter Stephanie who is in her third year at University of Maryland, College Park, on her way to an Engineering degree. She's smart, beautiful and an absolute gem.

So I'm posting today in order to tell my favorite women engineer in my life, "I love you and couldn't be prouder. Keep up the good work."

Two out of Three ain't bad!

Here's a great article that justifies my career choices of Systems Engineer and part time College Professorship. Money magazine and PayScale.com rated the top 50 careers with great pay and growth prospects. Systems Engineer is #1 and College Professor is #3. Nice.

Even better, the Systems Engineer article mentions the CSEP as a required certification for some jobs. Maybe I'll get more students for the CSEP preparation course I teach.

Only problem is they do place SE under Information Technology. This kind of bugs me to no end. I know IT requires SE but SE is more then IT. During my recent job search I kept getting recruiters asking for a more IT related System Engineering work, i.e. Do you know UNIX or JAVA? How good are your System administration skills in Unix, Linux, and/or Windows platforms? Do you have experience with VMware ESX server, Lab Manager, Virtual Infrastructure Client? Do you have the ability to write basic scripts using shell scripting or Perl?

I got so feed up I created a standard reply:

Thank you for the info but I'm not really an IT guy or software development guy. I help PMs and their Program Offices with the technical aspects of acquiring new systems and capabilities for DoD. Milestone Documentation, Architecture review, Requirement Tracability, Validation and Verification of requirements, test planning via TEMP development, etc. Look at chapter 4.1 of the Defense Acquisition Guidebook. That will give you a good understanding of what I do. Bottom Line is my strength is in Systems Engineering/Technical Advisory (SETA) work.

I know it's kind of snippy but it was the best way for me to deal with it.

Well I got to get back to work here at the Best Job in America. OORAH!

2009 ~ Busy year for a SE Scholar

Thing's have been busy for me lately -- extensive travel and a new job situation -- so it's been hard to keep this blog current. Here are few things since the last update:

(1) I was able to give lecture on the new DoD 5000.02 changes at the February INCOSE meeting. (My slides are here.)

My tenure as the Programs Director for our local INCOSE chapter has been fun. I've gotten a lot of great speakers.

Date	Topic (links in this column for the presentation material)	Presentation by(links in this column for the speaker bio)
11/18/09	The State of Graduate Level System Engineering Education	Peter Hoch, D.Sc.
10/21/09	Systems Engineering Opportunities in the Emerging PBL World	Michael “Bo” Gourley, DML
9/16/09	Essential elements of SE: What's the minimum needed for project success	David M. Fadeley, PE, PMP
8/19/09	Update: System Readiness Level for Defense Acquisition Programs	Eric Forbes
7/15/09	Where Is Systems Engineering in the SOA/EA Relationship?	Janalea M. Milford, CEA
6/17/09	Leadership Styles for Complex Adaptive Systems	Suzette S. Johnson
5/20/09	Status of Model Based SE in INCOSE	L. Mark Walker
4/15/09	Gathering Requirements in a Post-Modern World	Steven Edwards
3/18/09	DoD 5000.02 - Revolutionary Revamp	Paul Martin
2/18/09	Second Life Gets Systems Engineering	Robert Ostergaard
1/21/09	A Systems Approach To Engineering Investigations	Dr. Gareth Digby

So come on out to our Monthly dinner every third Wednesday night at JHU/APL from 5:30 - 8:00pm. It's a great networking opportunity.

(2) This October I'll be teaching Certified Systems Engineering Professional (CSEP) Preparation course for UMBC Training Center. Please register if you have any interest in getting your CSEP designation from INCOSE.

It's interesting to think that I started this blog years ago just to document my experience in getting my CSEP. I've come full circle as I try to help others get their certification as well.

Weapon Systems Acquisition Reform Act of 2009

A good friend of mine pointed me to this news item just now hitting the News circuits. Carl Levin, the Michigan Democrat who heads the Senate Armed Services Committee and senior Republican panel member John McCain of Arizona introduced bipartisan legislation, called the Weapon Systems Acquisition Reform Act of 2009, which would make it easier to kill weapons programs that spawn runaway development costs, while taking steps to improve competition in the heavily consolidated industry. If you read the Government Executive article you’ll find this great quote from Levin, "The key to successful acquisition programs is getting things right from the start with sound systems engineering, cost-estimating and developmental testing early in the program cycle." Can I get all my engineering friends to shout a hardy AMEN! But it gets better. The article also explains the “The Levin-McCain bill also would require Defense to:

• Re-establish systems engineering organizations and developmental testing capabilities.
• Introduce trade-offs between cost, schedule and performance early in the program cycle.
• Use prototypes more often, including competitive prototypes, to prove that new technologies work before attempting to produce them.”

Just as I pointed out in my blog post “SE to the rescue?” it will fall on the Systems Engineers to see this through. Are we up to the challenge?


By the way, it really is strange that this legislation is coming out just a few months after DoD revamped their Defense Acquisition Management System with a major update to DoD Instruction 5000.02, Operation of the Defense Acquisition System, dated December 2, 2008. It grew from 37 to 80 pages – that’s about 116%. It incorporates new policies that originated from a very active Congress from 2004 thru 2008, including six National Defense Authorization Acts (NDAA) for FY’s 2004 through 2009. The update includes a new emphasis on:

• Technology Development: This phase now includes a mandatory requirement for competitive prototyping of the system or key-system elements.
• Integrated System Design. This effort is intended to define system and system-of-systems functionality and interfaces, complete hardware and software detailed design, and reduce system-level risk. Integrated System Design includes the establishment of the product baseline for all configuration items.
• System Capability and Manufacturing Process Demonstration. This effort is intended to demonstrate the ability of the system to operate in a useful way consistent with the approved KPPs and that system production can be supported by demonstrated manufacturing processes.

All of this points to DoD’s desire to put a greater emphasis on doing Systems Engineering upfront and early. They even include an Enclosure 12 -- Systems Engineering -- which proclaims:

SYSTEMS ENGINEERING ACROSS THE ACQUISITION LIFE CYCLE. Rigorous systems engineering discipline is necessary to ensure that the Department of Defense meets the challenge of developing and maintaining needed warfighting capability. Systems engineering provides the integrating technical processes to define and balance system performance, cost, schedule, and risk within a family-of-systems and systems-of-systems context. Systems engineering shall be embedded in program planning and be designed to support the entire acquisition life cycle.

Don't these senators or staff read this stuff? Isn’t the Levin-McCain bill just preaching to the choir? Just wondering.

The Zune software bug -- What's a leap year?

On Dec 31st my Zune went into a coma. It wasn't pretty. It stayed in this perpetual start up screen. It didn't respond to any outward stimuli. And it turns out I wasn't the only one affected but every 30GB Zune player on the planet had the same problem. The geek press was a calling it the Zune Apocalypse.

Fortunately it was a short lived Apocalypse. The Zune software had "a bug in the internal clock driver related to the way the device handles a leap year. " Click here for a story about Microsoft's official response. Which basically says, "Wait 'till New Years officially gets underway and everything will go back to normal. " Which it did by the way. My Zune is back and happily providing me podcasts, like Radio Lab, for me to enjoy during my work commute.

But here's the best part of the Microsoft press release:

"... there was a widespread issue affecting our 2006 model Zune 30GB devices (a large number of which are still actively being used)."

The parentheses indicate to me that Microsoft is actually surprised, yes surprised, by the fact that many people would actually use the device for more then two years. --- A device these people spent more then $100 to own. -- Did Microsoft really think that customers would get tired of these things after a few months and get rid of them? What kind of short sighted development is that? And how does any software engineering team working on a internal clock not include leap year into their calculations??

This bug could have been caught and eradicated if the software went through a peer review. In the SE class I teach I explain that the two biggest Quality Control Points are:

• Peer Reviews
• Unit Test

These should be protected at all cost.

But even a peer review can fail if you don't have the knowledgeable and experienced programmers on the team in order to help catch errors or discover overlooked industry conventions. So I also emphasize to my students the heuristic: variations among people account for the biggest differences in software productivity. So always try to hire good people.