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.

SE to the rescue?

I've been a member of Institute of Electrical and Electronics Engineers (IEEE) for almost 15 years. As part of my membership in this 125 year old society I get their wonderful magazine, IEEE Spectrum. Every now and then they publish an article that just highlights the need for a stronger and more vibrant Systems Engineering profession. This months lead article did that in spades as it outlined the woes and tribulations of DoD's Weapons Acquisitions System. The article is appropriately called: "What's Wrong with Weapons Acquisitions?"

Not only does this article delve into the an area I've spent most of my career in trying to figure out, but it also explains how Systems Engineers are the key components to the process. Only problem is there are way too few of us.

"Another factor contributing to program failure is the shortage of technically trained people, especially systems engineers. A systems engineer translates technical needs into an overall system architecture that creates the best operational capability at the most affordable cost. As a project proceeds and goals or needs shift, systems engineers have to determine the difficult but necessary cost, schedule, and performance trade-offs to keep everything on track. As programs get bigger and more complex, the need for rigorous systems engineering increases."

Such a short paragraph but such a powerful explanation in how Systems Engineering brings the technical, operational and the programmatic together in beautiful harmony. Makes me proud of our humble profession. But as one of my other blog post pointed out, we are facing a shortage of engineers in general. Definitely a dilemma which will effect our future in profound ways. Only time will be able to tell us how bad it'll be.

But this article also show us that there is hero potential within every Systems Engineer. It's a great thing to be able to bring sanity to a broken process, to wrestle order out of the chaos, to bring the best solution to a profoundly perplexing predicament. If you know a Systems Engineer please give him or her a hug today. Theirs is a noble endeavour. Encourage them to greatness.

The Dark Side of "Moore's Law"

Back in the mid-60's Gordon Moore, a co-founder of Intel, predicted that number of transistors on an integrated circuit will double approximately every two years. This become the infamous Moore's Law. And the electronics industry has strived to maintain this law. Of course this is great for electronic consumers -- they can buy more computational power with every upgrade of computer, laptop, cell phone and game console. But the down side is these same electronic consumers now own computers, laptops, cell phones and game consoles that will quickly become technically obsolesce.

How many of you can relate to this story: A few years back my cell phone was showing it's age so I wanted to get a replacement. And I wanted the same exact one -- I knew the functions, I knew how to work it. It was simple. It just made phone calls. I liked it. A lot. So I'm in the wireless phone store explaining this to the sales clerk who gently explained that my phone model is no longer being made and that I can't even get a similar one either because all phones now have camera functions and texting capabilities as well. So I was FORCED into upgrading to the latest whizzbang phone. Ugh!

IEEE Spectrum magazine has a wonderful article from their April 2008 issue, entitled "Trapped on Technology's Trailing Edge" and it outlines the "dark side of Moore's Law." Technology obsolescence. It's an issue that needs to be addressed "upfront and early" when it comes to developing a new system whose life expectancy is more then five years old. And if it has anything to do with the military then believe me when I tell you it'll be more then five years old. Because it takes more then five years just to design, develop, and test a system before it gets fielded.

So when designing a system keep these lessons in the forefront of your mind and address the obsolescence issue with the same dedication and fortitude as you do when you design to meet the customer requirements. If you don't it will bite you in the end.

Will the lack of Engineers affect our future?

Here's an interesting article: "Lack of Engineers at Crisis Point, Experts Say" from our local free newspaper The Business Monthly. We're basically facing a "brain drain" in the aerospace and defense industries. What will happen as the qualified workforce -- in other words, capable engineers -- becomes smaller and smaller?? Does that mean the future is in jeopardy??
Keep this "engineer scarcity crisis" in mind as you read about the fact that the Future is Now. An article by Joel Achenbach from the Sunday, April 13, 2008 Washington Post. Here's a quote worth noting:

Science is becoming ever more specialized; technology is increasingly a series of black boxes, impenetrable to but a few. Americans' poor science literacy means that science and technology exist in a walled garden, a geek ghetto. We are a technocracy in which most of us don't really understand what's happening around us. We stagger through a world of technological and medical miracles. We're zombified by progress.[Christine Peterson, vice president of Foresight Nanotech Institute] has one recommendation: Read science fiction, especially "hard science fiction" that sticks rigorously to the scientifically possible. "If you look out into the long-term future and what you see looks like science fiction, it might be wrong," she says. "But if it doesn't look like science fiction, it's definitely wrong."

So much to discuss within these few sentences -- like "We are a technocracy" --?? What does that mean? When ever I hear of any kind of "--ocracy" I think of rulers, and not the nice kind either -- In a Theocracy the religious fanatics rule --- In a Monocracy the King rules -- In an Aristocracy the snooty people rule. So does that mean in a technocracy the technocrats rule? So I'm thinking any "--ocracy" other then Democracy is most likely a bad thing. But the thing is I don't think we have an elite class of engineers that run society. And isn't that what author Kurt Vonnegut outlined in his first novel, Player Piano? But here's a thought -- Would Achenbach's or Vounnegut's concern become valid, if we do have fewer engineers in the future? If it does get to the point where only a few can understand our world's underlying technology then -- wouldn't they be paid more, perhaps be respected more, and finally, by default, be more in control? Is a technocracy on the horizon because of the "engineer scarcity crisis?" So maybe you should encourage your kids to become engineers. The more engineers there are the more likely we'll avert this technocracy scenario. We do want to avert this, don't we?

Another great aspect of Achenbach's article is the suggestion to use "science fiction" as a means to understand the future. As if to prove his point he fills his article with Sci-Fi references, from Star Trek to Godzilla. But here's my concern . . .science fiction show us what technology is possible. But as the population of engineers decreases then logically wouldn't take longer for that future to get here. Maybe the article shouldn't be called "The Future is Now" but rather "The Future has Been Delayed Due to Technical Difficulties." Wow, depressing thought. And I really want my Jet Pack! So maybe you should encourage your kids to become engineers. It's the only way to stop the present from staying that way.

Is there any way we can solve this "engineer scarcity crisis"? According to the Business Monthly article we need to convince young people that engineering is, simply put, "cool." Well I can attest to that. After all, we're the ones who make the future happen. And that is way "cool."