The Systems Engineer Scholar

Emergence: The Mystery of Systems Engineering

2010-10-03T09:56:00.001-04:00

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

2010-05-03T09:51:00.000-04:00

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

2010-02-19T06:43:00.001-05:00

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!

2009-10-15T13:57:00.004-04:00

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-09-18T10:38:00.010-04:00

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

2009-02-26T14:58:00.007-05:00

A good friend of mind 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?

2009-01-02T10:00:00.009-05:00

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?

2008-11-21T10:00:00.009-05:00

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"

2008-06-20T06:00:00.002-04:00

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?

2008-04-20T20:19:00.008-04:00

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."

Is an Engineer responsible?

2007-12-06T10:06:00.001-05:00

You can look at practically any part of anything man made around you and think "... some engineer was frustrated while designing this ... " It's a little human connection. —Randall Munroe

(original comic from http://xkcd.com/277/)

What's saves more energy? Hummer vs Prius

2007-10-03T18:10:00.000-04:00

Trade Studies

Another tool in the engineer tool belt is the trade study. Need a decision among many alternatives? Do a trade study. The hardest part, what criteria to use. For instance, looking for the best car for the environment? Well you want to look a gas mileage, fuel used, and emissions emitted. But here's a trade study which took a more holistic view by taking into account the environmental impact of the cars production and most importantly, DISPOSAL. The winner: The Hummer. Controversial but true. Trade Studies, specially a 479 page report, can't lie. Can it?

How would you test the world's first Electronic Calculator

2007-10-01T09:30:00.000-04:00

Here's a great NPR report on the creation of the first handheld calculator about 40 years ago. It was marvel for its time: It could perform addition, subtraction, multiplication, and division. Input was with a small keyboard with 18 keys and a visual output that displayed up to 12 decimal digits using a thermal printhead and paper tape.

The First Handheld Calculator

In 1967, Texas Instruments introduced the first handheld calculator. The opened unit in the picture shows the paper tape used as output. (Image from Computer Desktop Encyclopedia (c) 2000 Texas Instruments, Inc.)

As you listen to this report you'll notice the engineer Jerry Merryman was concerned about how to test this brand new innovation at the time. The solution was to create a Simulator which could show how the circuitry would react to inputs. This simulator was many times bigger then the final device but it was a necessary step in proving the design.

As you start planning a new project, testing and verification has to be taken into account, not only technically, but from a fiscal and schedule standpoint as well . It takes time and money and can not be ignored. It's considered a key Systems Engineering Process Activity with in INCOSE's Systems Engineering Handbook vs 3

9.6 Modeling, Simulation, and Prototyping

Modeling, simulation, and prototyping used during architecture design can significantly reduce the risk of failure in the finished system. These techniques enable the development of complex and costly enabling systems, such as a flight simulator or a high-volume production line, which allow validation of the system’s concepts, or supports training of personnel in ways that would otherwise be cost prohibitive. Systems engineers use modeling and simulation on large complex projects to manage the risk of failure to meet system mission and performance requirements. This form of analysis is best conducted by subject matter experts who develop and validate the models, conduct the simulations, and analyze the results.

The importance of Marketing to the engineer

2007-09-14T20:28:00.000-04:00

When I first meet my future wife and she told me she was in marketing I quickly explained that I was her slave ... in a professional sense. Engineers are just totally dependent on Marketing to tell us what the customer wants and needs. Once we know that we can go about actually creating the product to meet these desires.

And then there's the reverse of this situation. Engineers have created something new or upgraded an existing product. Now Marketing is in the unenviable position of creating a marketing campaign to extol the products characteristics and convince the customer that their life is not complete without this product or upgrade.

Below is a Microsoft produced 5 minute long "rap" commercial extolling the virtues of MS DOS 5.

Warning -- This is way too funny. I mean it "Frees 45k of memory, at least"

That looks like way too much fun. Makes me wonder if I should have picked Marketing as a profession instead of Engineering.

The present according to a past future

2007-09-10T10:29:00.000-04:00

Some times a Systems Engineer is called upon to make long term predictions about the future so they can then start the actual process of creating the devices which will then make these predictions come true. Of course predictions can be fought with our own prejudice and wrong headed opinions. Take the famous example of the Thomas Watson, chairman of IBM, in 1943, who said, "I think there is a world market for maybe five computers."

But every now and then we get close but not in the way we first thought. In 1967 Philco-Ford Corporation came out with a short film called 1999 A.D. which missed by only a decade some of the idea's put forth. Take a look here. Of course we don't have "Split second lunches, color-keyed disposable dishes" but we do have ultra-cool flat screens.

The end of the line ... for time.

2007-08-29T20:06:00.000-04:00

One area my Systems Engineering class covers is the concept that the Systems Engineer has to be concern about a system from "cradle to grave' or "lust to dust." When you start your design, you need to think through how your system will eventually be dismantled and disposed of. The new INCOSE Systems Engineering Handbook actually has a section dedicated to this process.

4.12.1 Purpose
The purpose of the Disposal Process is to remove a system element from the operational environment with the intent of permanently terminating its use; and to deal with any hazardous or toxic materials or waste products in accordance with applicable guidance, policy, regulations, and statutes.

Below is a story from the LA Times where a system, the AT&T automatic time-teller system, that was in service since the '50s is finally coming to an end. Even though the story focuses on the human element, it does make you wonder where all the equipment will be trashed. Even good and useful systems come to an end.

Time of day calling it quits at AT&T

2007-08-29T10:18:00.000-04:00

From the Los Angeles Times

Time of day calling it quits at AT&T

David Lazarus --- Consumer Confidential

August 29, 2007
It's the end of time, at least as far as AT&T is concerned.

The brief note in customers' bills hardly does justice to the momentousness of the decision. "Service withdrawal," it blandly declares. "Effective September 2007, Time of Day information service will be discontinued."

What that means is that people throughout Southern California will no longer be able to call 853-1212 to hear a woman's recorded voice state that "at the tone,Pacific Daylight Time will be . . ." with the recording automatically updating at 10-second intervals.

"Times change," said John Britton, an AT&T spokesman. "In today's world, there are just too many other ways to get this information. You can look at your cellphone or your computer. You no longer have to pick up the telephone."

Indeed, time already has stopped in 48 other states, he said. California and Nevada are the two remaining holdouts.

In Northern California, the prefix for calling time is 767, or P-O-P on a telephone keypad. For decades, locals up there have dialed POPCORN any time they have had to reset their watches or reprogram electronic gadgets after a power failure.

"In California, our equipment has gotten old," Britton said. "It's reached the end of its life span."

Time's up statewide Sept. 19. Britton said Nevada service would live on borrowed time for an unspecified period, until the equipment in that state similarly starts breaking down.

One upside: AT&T says doing away with time would enable the creation of about 300,000 new phone numbers in California beginning with the 853 or 767 prefixes. (No such numbers have been issued to date because, when coupled with any four other digits, you get time.)

To be sure, time marches on. Yet for many Californians, the looming demise of the "time lady," as she's come to be known, marks the end of a more genteel era, when we all had time to share.

"It was always there," said Orlo Brown, 70, who for many years kept Pacific Bell's (and subsequently SBC's) time machines running in a downtown Los Angeles office building. "Everybody knew the number."

Richard Frenkiel was assigned to work on the time machines when he joined Bell Labs in the early 1960s. He described the devices as large drums about 2 feet in diameter, with as many as 100 album-like audio tracks on the exterior. Whenever someone called time, the drums would start turning and a message would begin, with different tracks mixed together on the fly.

"The people who worked on it took it very seriously," Frenkiel, 64, recalled. "They took a lot of pride in it."

In a twist of historical irony, Frenkiel went on to play a leading role in development of the technology that makes cellphones possible -- the very device that's now instrumental in killing time.

Phone companies have been providing the time to callers since the 1920s. In the early days, live operators read the time off clocks on the wall.

In the 1930s, an Atlanta company called Audichron devised a system for the time to be provided automatically. Audichron leased its technology to phone companies nationwide, often with sponsorship from local businesses.

Time ladies -- and a few gentlemen -- came and went over the years. Then, in the 1950s, a woman named Mary Moore emerged as the nation's leading time-teller.

Her reading of hours, minutes and seconds was delivered in a distinctive if somewhat prissy tone. Moore's odd pronunciation of the numbers 5 ("fiyev") and 9 ("niyun") influenced a generation of operators, much as flying ace Chuck Yeager's West Virginia drawl is said to have been adopted by innumerable airline pilots.

By far the most prominent time lady was Jane Barbe, who succeeded Moore at Audichron in the 1960s. A former big band singer, Barbe (pronounced "Barbie") went on to become the voice of recorded telephone messages in the 1970s and '80s in the United States and elsewhere.

Along with her interpretations of the time and current temperature, Barbe delivered the bad news too, telling you that circuits in a specific area were busy, please try again later, or that your call cannot be completed as dialed.

And who will ever forget her heartbreaking rendition of "I'm sorry, the number you have dialed is no longer in service"?

Barbe died of cancer-related complications in 2003 at age 74. It's estimated that at the height of her fame, Barbe's voice was heard worldwide about 40 million times a day.

AT&T's Britton said the company started using Audichron's machines in 1948 and then switched to a different system manufactured by rival Weatherchron, also of Atlanta, in the 1960s. He was unable to identify the current time lady, saying that perhaps no one at AT&T knows who she is.

Ellis Bryant, the 83-year-old president of Weatherchron, also was unsure whose voice Californians hear when they call time. So he dialed 853-1212 and listened to the recording.

"Oh, that's Joanne," Bryant said without hesitation. "Joanne Daniels. No doubt about it."

He said Daniels started recording the time for Weatherchron about 25 years ago. At some point after Pacific Bell switched to his company's system, Daniels became California's time lady.

Reached at her Atlanta home, Daniels, 65, estimated that her reach was once nearly as extensive as that of Barbe, who was a friend. Daniels is now retired.

"I've done the time in many areas -- Eastern Standard Time, central time, Pacific time," she said. "The fun part was doing the temperatures for places like Alaska."

Daniels switched to her professional voice, her soft Southern accent instantly vanishing. "At the tone," she said, "the temperature is minus 12 degrees." She laughed and her accent returned. "I liked that."

No one had told her that AT&T was about to stop time.

"I think that's very sad," Daniels said. "I was told at one time that my voice would last until well into the 21st century. Now it looks like I'm about to be laid to rest."

When that day comes, Daniels said, she knows what her epitaph will be: "She knew the time."

Consumer Confidential runs Wednesdays and Sundays in the LA Times.

Funny Flow Charts

2007-08-17T18:06:00.000-04:00

Flow charts are a required Systems Engineering tool for communicating a requirement or design. Here's an interesting and actually funny flow chart on the use of "Oh Snap"

Here's a more complicated but still funny that's been around for ages. The original is too vulgar for this family friendly site so I cleaned it up.

And of course the CLASSIC super complicated flow chart that destroyed the Neanderthals. Here's one of the conversations from one of the many Hunting Process Review (HPR) meetings they had.

The founder of Calculus??

2007-08-16T14:20:00.000-04:00

One of the fundamentals of Engineering is an understanding and appreciation of Calculus. Of course we all have to thank Newton for this. Or do we? It turns out that a school of mathematics and astronomy in Kerala, South India, between the 14th and 16th centuries had the basis for Calculus figured out. Some 250 years before Newton. Read about this controversy here and here.

Jet Packs - for real

2007-08-16T11:17:00.001-04:00

Back in the late '60s and early 70's, I was a Lost in Space junkie. Love the idea of Space travel, ray guns, and when I saw John Robinson fly in that Jet Pack. Man, I wanted to get one of those.

Here it is, some 40 years later and there is no safe personal jet packs available on the open market that you can use to commute to work. But it looks like there are some serious enthusiast out there. Check out this report from the second annual Rocketbelt Convention. Cool stuff. I love the last line: "... paraphrasing the words of the great Stephen Colbert: For years we’ve been promised little wrist-sized televisions, a meal in a pill and jetpacks —- let’s hope this year that promise finally becomes a reality."

Are you a techno-translator?

2007-04-03T12:08:00.000-04:00

One point I try to make to my students is the importance of being a translator in our job as a Systems Engineer. You're a translator between the customer and the technical specialist. You have to understand the customer domain and needs enough to convey those needs to the techno-geeks, all the while speaking their techno-bable. And you have to understand the technology capabilities and limitations enough in order to explain them to lay people using lay terms. That's the challenge.

And it doesn't help when each technical domain has its own phraseology. Take IT with its bewildering array of terms and buzzwords. Here's an article that highlights the difficulty we System Engineers face as Techno-Translators.

Buzzwords: Making Sense of the IT World by Mary K. Pratt, October 09, 2006 (Computerworld)

How I was able to become part of the exclusive CSEP club

2007-03-26T19:36:00.000-04:00

On March 23rd, at around 1:45pm, I clicked the "end test" button and then I confirmed that I did indeed want to end the test. Then I waited, staring at the blank screen This is not as instantaneous as they made it sound. As I waited I thought about how much time and effort it took me to get to this place. Would it be enough? Will I be able to say to my peers that I am a "Certified Systems Engineering Professional"? I was seconds from finding out. To think I started this process 254 days (or 9 months and 11 days) earlier, back on . . .

13 June 2006: I e-mailed four of my colleagues who knew my background in System Engineering. Three where engineers and the forth was my program manager. I did this several weeks before I started my INCOSE application. This was to (1) give them warning of what I was about to do; (2) make sure they were willing to do it and (3) get their contact information. Keep in mind that once I submitted the application, my references only have TWO WEEKS to submit their recommendation. So I wanted to give them plenty of time to think about what they were going to say about me. Also I wanted be sure I could get at least three. If any refused I would have to keep looking. When I e-mailed them I attached the recommendation instructions and form. I also related what activities they would be aware I did back to the SE Roles located on the back of the instructions. Here's a sample e-mail:

Dear so and so,

I’m applying for a Certification as a Systems Engineering Professional with the International Council on Systems Engineering (INCOSE). Part of the certification process requires three references who can attest to my systems engineering acumen. So I thought of you and how you can explain my work in [place here Systems engineering function(s) i.e. Requirements Engineering] for [place here the activity you did i.e. the SpaceAge contract where I analyzed the customer comments against the system spec and went through the CM process in order to incorporate the changes.]

Attached are the instructions and form. They need a two week turn around, so before I submit my application and start the clock I wanted to make sure my references where agreeable and available to help me out. So let me know if you can. No pressure if you’re uncomfortable with the request or, more likely, too busy. Just let me know so I can keep looking around.

Thanks for the consideration. Just let me know if you can or can’t. If you can, please send me back your “reference information” for the application. Thanks again, Paul

20 July 2006: Fortunately, three of the four did respond in the affirmative. (I found out later one of the engineers was on vacation and got inundated with work when he got back.) Once I had my references, along with their addresses, I sat down to fill out the application. It had two parts:

The application itself -- where you supply general information about you, your education and, of course, your experiences at you places of employment. I just copied my resume (which turned out to be a BIG mistake.) Also the name and addresses/phone number of your references.

and the proof of my education. -- They do allow you to scan your college transcript or diploma. Which was fine for my Master’s Degree from George Mason University. However, my diploma for BS in Engineering from Widener University was laminated into a 22x34 frame. I couldn't get it on the scanner so I took a digital picture, but it took several attempts to get the lighting, glare and shadows just right.

Finally ready, I sent in my application and digital images of my college transcript/diploma to secert@incose.org. I also got on the INCOSE website and paid my $300 Certification fee.

Also on the same day I sent out e-mails to my references, again with the recommendation instructions and form. I filled out as much as I could for them. I also reminded them to e-mail the completed recommendation form electronically to INCOSE. Here’s a sample e-mail:

Dear so and so,

I finally got my application off to INCOSE for a certification as a Systems Engineering Professional. As I explained in my last e-mail, part of the certification process requires three references who can attest to my systems engineering prowess. I was thinking you could explain my work on [relate your experience to “Systems engineering functions”]

Attached are the instructions and form. To expedite processing, it is preferred that you submit your response to them electronically at secert@incose.org. If you sent it off a few weeks back, would you mind sending it off again. They need a two week turn around so let me know if that's a problem.

Thanks for the help, Paul

3 Aug 2006: All my references sent INCOSE recommendations within the time required. I did have to follow up with a few reminder e-mails but they did come through for me. I sent INCOSE a note to say I had jumped through their hoops -- now what? They responded -- Yes, your application and references have been sent to the review committee. Once it is approved, you will be notified as to how to take the exam. -- Now all I could do is wait.

23 Aug 2006: E-Mail received -- Hi Paul, written notice was mailed to you on August 14th. Unfortunately, your application was denied. I have attached a copy of the letter. There is an opportunity for you to appeal the decision. -- Wow, didn't see that coming. Looks like I got more work to get this to stick. After reading the rejection letter and evaluating their reasons for rejecting me, it looks like I made a few major mistakes in my application submission -- one was asking my Program Manager for a recommendation (he wasn't a qualified reference) and another was I just cut and paste my resume without giving thought to the 13 SE roles. I also should have tried better to get references from further in my past.

To address these issues:

I asked two additional references to provide recommendations, to replace the Program Manager from my original application. A few years back I left my Government job as a NAVSEA systems engineer to become an official "belt-way bandit." Everyone I worked with at NAVSEA had retired or moved to different positions. Having no way to contact them I originally stuck to peers at my present work place, where I've been for almost three years. However, it was now more important then ever to find someone from NAVSEA to attest to my over15 years of SE activities there. This required some real Internet detective work. I finally found old NAVSEA comrade and called him up in Colorado, where he retired. We had great time catching up and, thankfully, he was more then willing to help.

I completely revised “Section 5 Experience” part of my application. This was at the suggestion of the rejection letter. For each job I mapped my experience to the 13 SE roles. For each role and experience I put the number of months I worked that area. This helped when I filled out the optional summary table because I just added up the number of months for each SE Role I worked.

28 Aug 2006: I sent in my appeal application to INCOSE. After a few days they said -- I received your appeal. I have not received information from your references yet, so I have not proceeded. Any idea when I should expect to receive that information? -- This led me to prod my friends on the references.

11 Oct 2006: Talk about a comedy of errors. I lost a week when I mistyped my NAVSEA friend's e-mail address. By the time I realized my mistake my friend was off to a family reunion for a week. Looks like retirement is just a busy as working. When he got back we had several exchanges about his write-up. Finally he sent in his recommendation but it took another week to notice that my friend had mistyped INCOSE's e-mail address. By now I couldn't get a hold of him, he was on another trip. When he got back he apologized and resent it. Today INCOSE informed me -- I received [the recommendation] today. I will now forward your appeal information back to the committee. I will notify you once they have reached a decision. -- This is taking longer then I planned but I'm getting closer.

07 Dec 2006: Oh happy Day. The INCOSE e-mail I've been waiting for has come. -- Your application for certification as a Systems Engineering Professional has been reviewed by the Certification Program Office and your education and work experience have been determined to satisfy the minimum standards for certification. The next step is for you to take the Certification Examination through Prometrics. If you pass the exam, you will be certified as a Certified Systems Engineering Professional. -- The ball is officially in my court.

23 January 2007: OK, up to this point I didn't even dribble the ball. I guess I should confess I am a family man, with a beautiful wife and six wonderful kids. So December and January was filled with family matter ... a one week trip Christmas trip with the whole family to visit my wife's sister in Tampa Fla; a nieces wedding; a murder mystery party for my oldest daughter's 18th birthday; and a concentration on taxes and FAFSA to help my daughter with her college ambitions. However, things have now calmed down sufficiently enough for me to at least look at the ball in my hand. A few days ago I got a very pleasant surprise came within my e-mail inbox. The latest INCOSE newsletter had an article about a Tutorial on the INCOSE SE Handbook in Preparation for SE Certification. The teacher is no other then a friend from my days with NAVSEA -- John Clark. What are the odds? The Tutorial is every Friday from 12 -1330 for 11 weeks John was using teleconference technology and provided slides before hand. My plan is to take this class and then take the exam. With this in mind, I went to http://www.prometric.com, following the step by step instructions given in the 07 Dec 2006 INCOSE e-mail. I scheduled the test for March 23rd.

23 March 2007: I indeed called into the class every week and for this past week I re-read the handbook. I arrived at the Prometric test center around noon. They would only allow me to take my reading glasses and driver's license into the testing area. Everything else went into a locker. They gave me 2 hours to answer 120 questions. I took a hour and 45 minutes. Some questions where easy, some where hard, some didn't make sense, and I found all of them where awkwardly worded. I did the best I could and hit the "end test" button. The moment of truth had arrived. Seconds ticked by. A screen came up which announced: I PASSED!

Man, what a relief. The test was hard enough that I wouldn't have been surprised if I failed. But I PASSED! I am a Certified Systems Engineering Professional. And according to the INCOSE website, it looks like I one of about 130 people on the planet with this designation. It was definitely worth the time and effort.