Working Up

by Dwayne Phillips

What is systems engineering? One answer is, “you can do it with only a pencil and piece of paper.”

I have been plagued with the question, “What is systems engineering?” for too long. As a job seeker, a common job opening is Systems Engineer. A quick reading of the job description shows that many so-called systems engineering jobs are really system administrator jobs.

Systems engineering job descriptions often have words like: CDR, PDR, CONOPS, requirements, design, eliciting information, DOORS, and RVTM.

System administrator job descriptions often have words like: server, Linux, Windows Server, install, setup, configure, VMWare, and Solaris.

One thing I have noticed about systems engineering:

you can do it with a pencil and piece of paper

I’m not saying that would be easy. Computers and applications make many jobs easier, and systems engineering is not an exception. DOORS and its related products from IBM make the systems engineer job easier, but the job can be done with pencil and paper.

The system administrator job cannot be done with pencil and paper. The system administrator quite simply administers computer systems. You can’t install a server without having the server. You can’t configure a server without a server and a computer terminal connected to the server. The pencil and paper can help, and I find them woefully under-used, but they are not sufficient.

So, when trying to decide if a job should be called a systems engineer or a system administrator, ask, “can I do this with a pencil and paper?”

For a few more details, see the International Council on Systems Engineering at incose.org.

by Dwayne Phillips

One function of systems engineering is to open the black boxes, look at the entire system, and apply some wisdom.

We often build systems by connecting existing systems and subsystems. These existing pieces are black boxes, i.e., we don’t know or don’t care to know what is inside them and how they work. These black boxes have defined interfaces and a history of functioning per these interfaces. These properties allow us to combine them into something that does what we want.

There comes a point, however, when building a system from black boxes doesn’t work or doesn’t work as well as we wish. At that time, the systems engineer opens the black boxes and peers inside. Hmm, we only this this part of this black box. We can discard the rest. That black box, well, we need all of it. That black box, we only need one little part of it. That black box, well, we don’t need any of it given that we are using only select parts of the other black boxes. And so on.

The systems engineer considers all the parts of all the black boxes and applies some wisdom. The result of wisdom is a new system that is more efficient, has fewer parts, is more maintainable, and lots of other better attributes.

The systems engineer’s job isn’t easy, and it isn’t easy to find a person with the required knowledge and experience. The hunt and application, however, are worth the effort.

For more on this and other aspects of systems engineering, see this short, free book on the subject.

by Dwayne Phillips

Sometimes we have to update the technology even when old technology still does the job.

Requirements are real. We work to meet requirements in systems. Once the requirements are met, that is it. But what about the people?

Many years ago, I worked with a system that used old technology. It was embarrassing how old it was. Several people proclaimed, “Come on! We have to replace that with current technology!”

A senior manager replied, “The old technology meets the requirements. Current technology will require a new design, implementation, test, integration, test, etc., and that means money, money, and more money.”

Several years later, I had the same experience. We used technology so old that it was embarrassing. People wanted to replace it, but it met requirements. A young engineering hit me with, “But it’s 20xx. If we are stuck with this technology, I’m gone.”

There are times that the morale and pride of the people who work with systems become paramount. Old technology can truly be embarrassing, and there is a point when people won’t work with it. They will leave.

This is another example of including persons in the definition of a system. No persons, no system. Project managers and others must accept that.

by Dwayne Phillips

Systems are commonly built by connecting smaller systems. This requires that the systems are connect-able, and that requires a defined interface.

Most of the time, we build systems by connecting large boxes together in a system diagram. There are exceptions, and another post will discuss some of those. Still, connect the boxes with lines and arrows and such. The boxes may represent hardware, software, or persons.

To connect boxes, the boxes must be connect-able. This means the interfaces of the boxes must match. We can’t connect a 110-volt electric outlet to a water hose. The interfaces don’t match.

The systems engineer is the person responsible for ensuring the interfaces match. Each box needs to have a defined interface. This documentation can take many forms (paper, audio, video, etc.), but it must exist. In technical terms, the defined interface is called an Interface Control Document or ICD. Again, it doesn’t have to be a paper document, but it must exist.

Some people think of the ICD as a contract. Others think of it as a UML diagram. Others think of it as a service-level agreement. All these work fine in the appropriate circumstances. The ICD should be visible and usable. There are no secrets here. The secrets are inside the boxes (what is there and how it works). The services provided by the box must be openly visible.

This may seem obvious and common sense to most persons. It is not, however, common practice. Lots of angst on systems development occurs because the ICD is…well, it doesn’t exist and persons think it is bureaucratic nonsense.

This is yet another answer to, “Why do we need someone called a systems engineer?”

by Dwayne Phillips

The original hackers were the good guys. Some of today’s hackers still are.

Nintendo recently brought back a handful of old video games in a clever packages called the NES Classic Edition. They sold a boat-load of them. The trouble is, you can’t add any games to it.

Enter good-old hackers who add functions to computer hardware and software. Now we can add games to a supposedly closed box.

Yes, there are good guy hackers. They take open source code, or reverse engineer code that is not open source, and add to it. They augment the functions of computers. Almost everyone wins here. Game players will have more games to play on their clever little box. Nintendo, who should have made the box’s source code open, will sell more units. Someone out there will write a few new games to run on limited hardware and might make enough money to buy a lunch or two. A lot of younger people will learn something about video game systems and software.

I trust that no one will ruin all this by calling a lawyer.

I suppose there is a moral to this story and I’m supposed to provide it. Let’s try this one:

You have a good product. Let persons see the inside. You never know what they might do that will benefit a lot of others and you, too.

by Dwayne Phillips

Is this real? Is this a fake?

Sometimes politicians and other childlike creatures show a firm grasp of the obvious. Mr. Trump did this recently with a comment about writing a note on paper and having it hand delivered. Aside from security, there is the attribute of authenticity.

authentic: adjective, of undisputed origin; genuine.

The recipient of the note can recognize my handwriting in every word and in my signature. Yes, these can be forged, but what is easier to forge, a page of handwriting or a page of typed and printed text? The answer shows a firm grasp of the obvious.

There are many objections to the “write a note and have it delivered” method of communication. Nevertheless, the simplicity and ability to recognize the  message as genuine are real.

Do not minimize authenticity. With fast, inexpensive, and plentiful digital communication, we have forgotten something about a message of undisputed origin.

by Dwayne Phillips

Instead of describing smart things as “common sense,” try, “that’s smart.”

I grew up with the phrase, “common sense.” Common sense was superior to “book sense” or education. Common sense was what people who knew what they were doing and could “get things done” had.

Enough phrases from my childhood in qoutes. I recently—as an adult—watched a video series by Seth Godin. He repeatedly used the phrase “that’s smart.”

• don’t try to shoe horses in Los Angeles
• don’t try go manufacure goods cheaper than China
• don’t try to do what everyone else does already

Those things weren’t “common sense.” Godin’s description was, “that’s smart.” Hmm, I like that. It sounds so much better to me than “that’s common sense.” I think it would sound better to the other person as well.

by Dwayne Phillips

Want to be something? Ask a simple question and live the answer.

Twenty something years ago, Robin Williams was in the movie “Mrs. Doubtfire.” He impersonates a woman and gets a job as a nanny to his former wife so he can be near his children. He is the best, most fun, most wonderful person around kids since Julie Andrews in “The Sound of Music” and “Mary Poppins” combined.

He was a failed father. He became the best person to be near his kids. How? The movie doesn’t reveal it, but he asked the question, “If I was the best person to be with my kids, what would I do?” And then he did it.

Examples:

• If I were a great people person, what would I do at this party?
• If I were a great supervisor, what would I do at work?
• If I were a great leader, what would I do?
• If I were a diligent writer, what would I do?
• If I were a great husband or wife, what would I do?
• If I were a great parent, what would I do?
• If I were a great news reporter, what clothes would I wear? How would I stand?

The list goes on and can include the one thing I want to be. I have yet to find an exception to this technique for better living.

Ask. Answer seriously. Begin living—better.

by Dwayne Phillips

If elected leaders want it, of course someone will build the fill-in-the-blank registry (if it doesn’t already exist).

Big news lately about how large numbers of programmers have pledged not to build a fill-in-the-blank registry. (It is pretty easy to make such a pledge when you are employed and have enough work stacked up to keep you employed over the horizon, but that is another blog post.) If our elected representatives want a fill-in-the-blank registry, it will be created.

One of the missing items in all this registry talk is that the fill-in-the-blank registry probably already exists. The persons in the fill-in-the-blank group built it and use it everyday. That is how they keep track of their fill-in-the-blank members for things like mailings and greetings and such. Fill-in-the-blankers want to know other fill-in-the-blankers.

Then there are those anti-fill-in-the-blankers. They have registries of other anti-fill-in-the-blankers. If they don’t have the registries already, they are building them now.

Silly? Am I poking fun at something very serious? Probably. Do these registries already exist? Yes, they do. One recent “registry” case is a government agency “refusing” to give the President-elect a “list of names” (Oh boy, here we go!) of their scientists who attended climate change conferences. Government employees who attend conferences do so on taxpayers’ dollars. Those expenses are public knowledge. A FOIA request provides the details. Let’s see, the next President files a FOIA request and… Silly? Yes. Reality? Yes. Of course the government agency will provide the names if requested. That is the law.

Now, back to these fill-in-the-blank registries. The information is out there. Those fill-in-the-blankers provided it. Sometimes they were required by law, but most of the time they did so voluntarily. We all provide our names voluntarily everyday. That is our lives in this 21st century world.

by Dwayne Phillips

I write all the time. I am not afraid to write. One reason is that no one ever told me that I should be afraid to write. Please don’t ever tell anyone they should be afraid.

I write. I write everyday. This is the third or fourth piece of writing I am completing this morning before 9AM.

I am not afraid to write. I have met many persons who are afraid to write, but that is not me. Perhaps someone who analyzes such things could analyze my life, background, parents, childhood, etc. and produce an analysis that explains my situation.

Basically, I never knew that I was supposed to be afraid to write.

Perhaps I am not smart enough to realize this.

My granddaughter appears to be like me in this respect. She is five years old and has been writing stories for several years. No one has yet told her that she should be afraid to do this. I pity the person who tries to convince her to be afraid. I shall have a discussion with that person.