InformationWeek

July 29, 1997

letter image>
<IMG SRC= Your letters to my print column and this E-mail forum ask some serious questions about managing information technology in today's world. Since today's world is essentially absurd, my serious responses may sometimes sound a little whimsical, and my occasional whimsical ones, serious. In any case, if you want to participate, write to me at secret@cmp.com . I'll respond to those letters that I can. I reserve the right to edit for size and content. Just sign your E-mail the way you want it to appear online.

Dear Herbert,

I'm a mainframe dinosaur working for a major insurance company's IT department supporting the CICS systems. I enjoy what I am doing but wonder if I will be restricting my marketability by trying to improve my competence in what is being treated as old technology. CICS and the mainframe still handle the mission-critical work but the glamour has been placed on the PC arena. But what I have seen is that everything being done on the PC is with a vendor product. "Programmers" are filling in screen spaces rather than understanding how what they are "writing" works. When something stops working they have no idea what to do. Debugging skills have been lost. Wors e, groups that bought into a product that has fallen out of favor are stuck with something they cannot support.

Since I have to stay current in my present field I need somehow to jump-start my learning of PC technology in my limited spare time, not just learn how to use specific vendor products that might be gone tomorrow. For the mainframe, IBM provides manuals such as MVS principles of operation, language manuals, subsystem manuals with everything from introductions to excruciating and incomprehensible detail. For the PC there are hundreds of books, but without knowing the subject it is difficult to choose those that are worthwhile. Is there something like "PCS for Mainframe Dinosaurs" out there that can move me from one arena to another without wasting 20 chapters on how to locate the On switch?

Ronald

Dear Ronald:

F. Scott Fitzgerald wrote that the very rich are different from you and me. Likewise, PC's are v ery different from mainframes. There are three main points to remember when working with PCs. The first is that packages reign supreme, so the ability to fill in screen spaces and understand the tools to do so is the programming (or configuring, as it is sometimes called) of today. The second point is that as the PC world has moved from DOS to Windows 95, access to the guts of the operating system has become more and more removed from the user. That's what makes it all the more frustrating when something doesn't work the way Microsoft says it should, because user intervention in the operating system has become more and more difficult. The third, and perhaps most important thing, is that learning about PCs is very different that learning about mainframes. We learned about mainframes from studying books. Learning about PCs is based more on the discovery method. The idea is to read briefly the instruction manual for a package or the operating system and try something. To learn more, hit the HELP icon and study i t. This method seems random to a person raised on mainframes, but it is the way things are best done. You will still want a book or two on helpful -- and frequently undocumented -- hints that are relevant to either the operating system or the applications package on which you are working. There are many of these. One you might consider is "Windows 95 Secrets Gold" (IDG Books Worldwide, Aug. 1996) by Brian Livingston and Davis Straub

Dear Secret CIO:

Poor Hennessy; had he gotten hold of me and my company's suite of data warehouse access, reporting and analysis tools, those answers would have come from the right side of his mouth -- WITHOUT his foot being in the way ( The Data Said What? ).

My company's product and I would have helped Hennessy and all those less-savvy users understand how the data warehouse can be accessed easily and painlessly, while adding the ability to (again) easil y and painlessly twist and turn (slice and dice -- choose your buzzwords) the data into useful information for understanding what drives the business.

You see, our data warehouse access tools are easy enough for anybody's mom to use.

Am I cocky? You tell me.

One call to our 800-number or a visit to our Web site, would have prevented Kratmeyer and the demo-ees a lot of rolling eyes!

Dave

Dear Dave:

Okay, I'll tell you. Yeah, you're cocky. Sorry for deleting your company name and quite a bit of the self-congratulatory product evaluation, but I'm sure that you and your associate, Rose, who wrote a similar letter, will understand.

Unfortunately, you've missed the point of the column. Hennessy did a great job of accessing the data warehouse -- and slicing and dicing the data -- easily and painlessly. The pain part came later when Kratmeyer got him alone and spoke to him, none too gently, about making silly co rrelations that made no sense. As Karen pointed out at the meeting, just because two variables have a high correlation, doesn't mean that they are related. That was the problem, not ease of use. Actually, I think it might be better if you made your product more difficult to use, then people might think more about the meaning of the data.

Dear Herb:

I'm a Ph.D. student in computer science, and I am looking at the problem of database integration. Now I know that this is a fairly old problem, but after talking to a couple of people in business, it doesn't seem to be solved yet. Do you have any idea of how much it costs to integrate the databases of two different companies? What are the methods IS managers use when faced with trying to get information from a database system belonging to another company with which it just merged? Is there a standard technique now in use for this process? You see, with all these companies buyi ng each other out, I assume it's no longer a problem getting these databases to work with each other. Still, people don't talk about their failures. What do you think?

Curtis

Dear Curtis:

There is no general answer to your question. It depends on how different are the technologies involved and how the information is used. The key problem tends to be that integration of the databases implies integration of the user community. Except in a brute-force acquisition, it is frequently very difficult getting agreement as to what is needed and most of the time the compromise is to ask the IS organization to satisfy both camps -- which tends to drive costs and time involved out of sight.

Dear Mr. Lovelace:

Dear Mr. Lovelace, You wrote Matt (Ask The Secret CIO, March 25, 1997), "...While it is not good to get the reputation of a job- hopper -- you need to show a progression of promotions within a company -- the one thing you do not want to do is work at a job you do not like for any extended period. Your lack of enthusiasm will show, and that is a career-stopper."

I am a senior systems engineer in one of many IS shops in a large corporation, where I have worked for about two years. I have yet to learn how often someone in my position should expect a promotion, or what protocols I should follow in seeking a promotion. For example, is it proper to negotiate with my manager about the goals I need to achieve to obtain a promotion?

Regards,
Todd M.

Dear Todd:

It is absolutely your right to know what is expected of you in order to be promoted. A good manager will be happy to discuss with you what has to be accomplished. Negotiating, however, about the goals required would probably not be viewed very favorably.

Dear Herb:

I am in the process of starting my own computer graphics company, and as all companies seem to need nowadays, I need a mission statement. I particularly liked your column ( A Mission Is Our Mission ) on why the company founder knew what was going on and the new president didn't. The gist of the column was:

1. Make money, but don't screw the customer.
2. Don't screw the community either.

I'd like to use that (or a slight paraphrasing of it) as my company motto. Would you have any problems with that, and who should I attribute the quote to? I'm envisioning something like:

"Make money, but don't stick it to the customers, or they won't be back, and don't stick it to the community or government or your employees either." --Herbert W. Lovelace

Thanks,
Jon G.

Dear Jon:

No problem with quoting me, with the attri bution to Herbert W. Lovelace, as you've stated. Good luck with your business -- and thanks for asking.

Mr. Lovelace:

About your article, "Won't Train? Don't Complain." Do you really expect us to swallow that?

I know that stereotyping the accounting/finance employees in such a way plays well with your audience.

But it was the preponderance of your audience and a helpful hand from mainframe purveyors that held America back many years ago by characterizing boxes that ran Apple or CP/M as "toys." It was the accountants who back-doored tools to get the job done.

Some of the most aggressive "users" of systems are financial users, as witnessed by the burgeoning arena for financial software well in advance of other areas.

Knowing how to use a computer is tantamount to knowing how to hold a pencil, and financial professionals know it best.

Andrew H.

Dear Andrew:

Sounds like you feel rather strongly that financial professionals have been on the forefront of holding back the forces of darkness and evil from the computer world. But, if I am guilty of stereotyping the accounting/finance employees, is it possible that you are doing the same thing to the computer types?

The point of the article was that it requires the involvement of all parties to successfully build and implement a new computer system. This means that people need to attend design sessions and it also means that it is critical for them to spend time at training sessions. If these elements are not done, useful systems will not result. Unfortunately, it is all too common for these same people to criticize the resulting system as being bad, when in fact, they may not understand how it works.

I think you are correct, however, in that the demand for financial software was well in advance of other areas. I suspect that this demand occurred for two reasons: The fi rst was that it was a straightforward opportunity to save money by displacing people. The second was that since the information systems groups traditionally reported to the finance organization, it is reasonable to assume that the emphasis of the computer systems work would be on meeting finance's goals.

View past issues of "Ask The Secret CIO"