The IT buddy movie
IT managers must direct incompatible characters
With the introduction of client/server and the infusion of heterogeneity into that mainframe-bred "glass-house," friction and skepticism run rampant. The legacy system counter-revolutionaries believe it impossible to maintain acceptable levels of RAS with Unix, NT, and NetWare, mainly due to a lack of disciplines. The client/server angry young men and women decry legacy practices as too bureaucratic, reactionary, and (the unkindest cut of all) tired. How can we get both factions working together? (700 words)
Information Technology (IT) managers are directing their own buddy movies today. Representing the prototypical "Clint Eastwood" character are the dyed-in-the-wool mainframers. The prototypical "Jim Careys" in IT are the Unix, NT, and NetWare experts. No one, but no one understands the meaning of mission critical better than Clint Eastwood. And no one understands network computing better than Jim Carey (so to speak).
You need to find a happy medium -- Clint needs to ease up a bit and Jim needs to acquire some discipline. This is, of course, easier said than done. Clint and Jim are as different as night and day. If you can combine the best of both and harness their collective power your chances for implementing the proper infrastructure are much greater. The proper infrastructure implies and creates a very flexible, streamlined, and cost-efficient environment.
It starts by getting Clint and Jim working together. We just don't mean under the same boss, we mean physically located in the same set of offices. They need to interact on a daily basis. They need to feel as if they are on the same team. Clint and Jim need to attend the same staff meetings and even hang around the coffee machine together.
Projects can build teams
You can't just talk about teamwork. You need to establish programs that instill it. We recommend establishing a hands-on curricula. In the olden days (woops, it still continues today) mainframers, especially system programmers, used to develop nifty little
help streamline and automate the production environment. Combine the
old with the new, and develop some shell scripts to manage a
Look at your current processes. Surely there could be something that needs improvement. Look at simple processes to start with, then move to something more complex. A good example of a simple yet bureaucratic legacy process might be something us old mainframers refer to as shift turnover. In a 24x7 (24 hours a day, 7 days a week) computing environment, we have a simple process of trading information between the three shifts (day, swing, and grave). What we had before was a piece of paper on a clipboard that passed between the shifts. This paper contained special requests for that night's processing (i.e., backups, batch runs, report distribution, etc.). Anything out of the ordinary was highlighted for the operations staff on different shifts. Then these forms would be stored in a file cabinet for later reference. The shift turnover document represents an effective yet cumbersome and bureaucratic process.
Jim Carey may mock this process while Clint Eastwood insists it's the way things must be. Remember what we've said in our previous columns -- never trash mainframe disciplines. Modify and streamline them to effectively manage the new enterprise, since they may not work in their present state.
You need to toss your collective Clint and Jim into this project. We
shiftT. Clint and Jim need to write a script, or
series of scripts that allow managers to fill out all shift turnover
shiftT e-mails a report to the
appropriate people on all shifts, then archives the report in a
database for auditing. It appears we found a happy medium. Clint eased
up some and Jim learned a thing or two about discipline. There are
dozens of these types of processes that need to be modified for the New
You need a unified team. But you also need to make reliability, availability, and serviceability goals a part of both Clint and Jim's performance evaluations. These sound like major commitments on the part of management -- they are -- but the alternatives are morale problems and an environment that cannot effectively support mission critical applications.
How do you know if you've succeeded? When you can claim that your network has become your data center!
We get a kick out of how many companies we visit that have decided to change the name of their existing data centers to something else. We've heard:
You can call it what you want, but unless you put the discipline back into that environment with the help of your dynamic duo it's just another name. Remember, Data Center stood for high availability, integrity, security, disaster recovery, and so on. It took decades to build this legendary environment. If it makes you feel better to change the name, then so be it. But if you don't modify those processes and disciplines you will surely fail -- whatever you call your data center.
If you have technical problems with this magazine, contact firstname.lastname@example.org