What will be the death of networked computing? Will it be the technology? Support costs or security concerns? Nope

June  1997

What is the number one problem of client/server and network computing? It's not what you think. We tell you what it is and how to effectively and productively deal with it. (1,800 words)

Mail this article to a friend

Will the death of networked computing be technology, support costs, or security concerns? Naah...None of the above. We've been saying it for three years -- many didn't want to or didn't have the time to listen until now. Those Fortune 500 corporations we've been preaching to are now feeling a lot of pain. Some are starting to admit it: The number one problem with client/server or networked computing is dealing with people issues.

Communication is still IT's biggest downfall, and client/server with decentralized support organizations has made it worse than ever before. In the old days of MIS, dialogue didn't even exist between IT and its users -- users were isolated from the glass house. It was manageable because we had a clear demarkation for support roles and responsibilities, and IT personnel were usually in the same building.

Today it's a whole different ball game. IT personnel are scattered throughout the globe. Ongoing communication is more critical than ever, and in most IT organizations it doesn't even exist. The execs reading this column might argue saying they have quarterly get togethers or yearly picnics for everyone to participate. If you think that a quarterly get together or a picnic instills effective communication -- well...we won't get nasty. Communication needs to be practiced daily! The only way to do that is with a process. Talking about it and having periodic get togethers just won't cut it.

In previous articles and in chapter nine of our second book, Managing the New Enterprise, we refer to a process called client/server production acceptance which is an application deployment and ongoing production support methodology that forces groups to communicate on a continual basis. This means that decentralized support groups communicate with centralized support staff, applications development communicate with operations, and users communicate with technoids.

Different species
There are obvious cultural differences between mainframe dictators and Unix techies. These two groups of people simply do not get along. They come from two different worlds: We're not talking North America and Europe -- we're talking different galaxies. Data center dictators eat and breathe mission-critical applications. When something goes wrong during off hours (i.e. 3 a.m. Sunday morning) these professionals spring into action, and it's business as usual. Nothing would prevent a mainframer from resolving problems -- not weather, family, whatever. If management says jump to resolve a problem they ask how high. So we'll say it again, and maybe by now some of you execs out there will start listening to us. No one can support mission-critical systems better than mainframers.

Are they perfect? Not at all. Along with all that discipline comes bureaucracy. Their way of thinking is outdated. Times have changed, and they must change in order to survive. All those disciplined bureaucratic processes must be streamlined and automated. In our third book, Networking the New Enterprise, we define the 18 disciplines and what automation really means.

Unix techies, on the other hand, do not have this type of mentality. Are they any less important? Absolutely not. You need their new wave thinking in networked computing. Ok, so you need both mentalities; but how in the world can you expect to get both groups working together as a single unit?

Transitioning your staff
It takes a lot of time, patience, and "hand-holding." More than anything else it takes the latter. Here are the areas you should invest in as you implement a cost-effective and flexible infrastructure to support the enterprise.

Let's start off by telling you that more than 50 percent of the organizations we visit still have walls between legacy and client/server staff. They're organized by technology versus functionality. One of our 10 commandments (methodologies) is that a production system is a production system, is a production system.

Everything should be treated equally. The quicker you bless and adopt this throughout your organization the smoother the transition will be. The walls must come down. Many executives may argue that they cannot disrupt their companies' most mission-critical systems on those mainframes. Legacy staff is already working 50 to 60 hours a week -- what's the point of reorganizing to mesh the organizations if no one can take advantage of it?

That's where the biggest mistake is made. The opportunity should be made available for everyone to learn the new and exciting technology if they want. At the same time let it be known that this training needs to be done on their own time. If you leave anyone out you will most definitely have morale problems.

In most corporations the mainframe is still there and isn't going away in the foreseeable future. You'd be surprised how many mainframers will actually work more hours to take advantage of learning something new and exciting and actually work 70- to 80-hour work weeks. Let them make that decision. Never exclude anyone -- always provide the opportunity to the entire organization from the most junior staff to the most senior. Try and locate functionalities together (i.e., mainframe and client/server database administrators, or systems programming and systems administration).

Get with the program
So now you've got them sitting next to each other, and if you're lucky, they're taking periodic coffee breaks together. But that alone doesn't promote teamwork. You need to establish curriculums that do.

1. Automation projects using scripts -- our personal favorite. Surely there are cumbersome and bureaucratic processes that need to be streamlined and automated. In the mainframe environment we used to write clists to automate manual tasks -- now we write scripts. But it's not the language that's important although it is easier to write scripts than clists. The reason this is our favorite program is because it takes the best from both worlds: legacy dictators who understand disciplines and Unix cowboys who know network computing.

2. Get acquainted to the hardware. Your IT staff has always treated platforms a little differently -- especially those holy and sacred mainframes. That's not their fault. The glass house was constructed to show off that beautiful iron. It was the showcase and still is in many corporations because it runs most of their mission-critical applications. We're not talking desktop applications; we're talking payroll, manufacturing systems, etc. No wonder they treat these dinosaurs a bit differently.

   The goal is to get the staff thinking that a production system is a production system, is a production system regardless of the hardware. So we designed an environment which brings disparate groups within IT together and puts them to work on a hardware project. The project was designed to show that mainframes and servers can be "equal."

   We spent half a day in a classroom (computer operators, application developers, database administrators, etc.) examining the inside of a server. That afternoon those same technoids were paired up -- can you imagine a systems programmer and applications developer working together?

   We told them to set up the equipment in their own habitat. They pulled every board out of the server. By the end of the day the boards were placed back in, and the lights were blinking again. They loved it!

3. Brown bag weekly tutoring sessions. Establish a get-to-know Unix course -- from its history to the more advanced technoid stuff. Each chapter should have homework assignments. The best way to teach a course like this is with a program we use called "train the trainer." Have your most senior guru -- not an outside consultant -- develop and train the course. There is no better way to bring the folks together than having one of their own teach the course.

4. Brown bag weekly/monthly technology exchange. Technology changes daily. Use your vendor. It's important to ask your vendors to bring in their top technologists to share all their new goodies.

   These curriculums are very time consuming. Wouldn't it be easier to send them all to classes? Classes aren't the best solution. And besides many companies don't have the budget for them. You need to establish the hands-on projects and curriculums we've mentioned instead. Of course there really aren't extra resources to have consultants fill for IT staff members while they go to class. Ask them this: When you wanted to learn something new didn't you go to night school? Well now management is asking the same thing. There is no time, money, or extra resources. If you want a degree in Unix just like your degree in "mainframe" this is how it's going to work.

   It's also important for management to get involved. Grade homework and establish a test lab for them. Show them that you care. Yeah, we know there's no time, but the more you show your staff the importance of their involvement as well as your own the easier it will be to get the most out of them.

Don't forget about metrics
What about metrics? And what does it have to do with people issues? It's quite simple, but we cannot underestimate its importance. During our extensive training program we documented which classes, homework assignments, and projects were completed by each of our mainframers. That information was noted in our monthly status report. These metrics were tracked very closely by our entire IT organization. Why?

Think about it for a moment. What if one of our employees could not handle this transition for whatever reason -- let's say it's a performance problem. This individual then decides to go to human resources and tells them that the proper training was never provided. This is where metrics comes in. "Excuse me, Mr. Employee, here are all the courses that you took over the past several years, the assignments completed, and projects you participated in. Now, what was that issue you had in regards to training?

What about politics, you ask? Heck every company has it, and there isn't anything you can do about it so why waste your time and ours?

Resources

• "Client Server Production Acceptance 1996," October 1996 Unix Enterprise column.
  http://www.sunworld.com/swol-10-1996/swol-10-unix.html
• Full listing of Unix Enterprise columns in SunWorld
  http://www.sunworld.com/common/swol-backissues-columns.html#unix
• Browse SunSoft Press offerings
  http://www.sun.com/smi/ssoftpress

About the author
Harris Kern (harris.kern@sunworld.com) is Sun's Open Systems Migration Consultant for NAAFO Market Development. Randy Johnson (randy.johnson@sunworld.com) owns R&# 38;H Associates, a full-time rightsizing consultancy in Boulder Creek, CA. R&H Associates helps people worldwide in implementing and supporting client/server infrastructures based on their proven methodologies. © 1997 Harris Kern and Randy Johnson. All rights reserved.

Harris Kern and Randy Johnson are authors of Rightsizing The New Enterprise: The Proof, Not the Hype and coauthors of Managing The New Enterprise: The Proof, Not the Hype, and Networking The New Enterprise: The Proof, Not the Hype. You can buy these at Amazon.com Books. Select the hyperlinks to learn more about each and Amazon.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-06-1997/swol-06-unix.html
Last modified: