Systems conversion: Transitioning your users
What does it take to appease your users and make your mainframe migration as painless as possible?
May 1999
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Systems conversion: Transitioning your usersWhat does it take to appease your users and make your mainframe migration as painless as possible?
|
May 1999
|
Last month, Chuck offered pointers for preparing your IT staff for mainframe-to-Unix migration. The other side of the human factor is your users. How do you get them on your side and ease them into all the technical changes they will face? It all comes down to compassion, cooperation, accommodation, education, and perseverance. (3,000 words)
 Mail this article to a friend |
f you've ever been through any kind of systems conversion or process
reengineering, you've learned the one rule that should be
cross-stitched and hung in every operations manager's office:
|
Technology Is Easy People Are Hard |
Unfortunately, most operations people are introverts, hardly inclined to think like their customers and worry about the human aspects of systems management. Being so infatuated with technology, we tend to operate in the "if we build it, they will come" mode. Most users, being more worried about the job they need to do and not the tools they need to do it, fall in to the "you can lead a horse to water, but you can't make him drink" category.
We've spent more than a year looking at many aspects of Unix technology, focusing on the delicious details of big Unix iron. Last month, we tackled one aspect of the human element of systems management: staff career growth and management. While staff issues can be tricky, at least your staff (presumably) thinks like you do, so helping them move to new technology is not the hardest task in the world. Nothing invigorates a systems programmer like dropping a $200,000 system in his lap and asking him to learn how to run it.
Customers are different. Very different. They don't like change. They just want to get their jobs done. Computers are simply another tool that either helps in the process or gets in the way. New computers and systems are often feared, harbingers of change that, good or bad, will require learning, adjustment, and compensation.
In spite of their concerns, you cannot have a successful migration from mainframe systems to Unix machines without helping your customers make the transition with you. If your customers aren't happy, your conversion is a failure. No matter how much money or time you save, if your customers cannot perceive those improvements in ways that directly benefit them, you may as well have never moved from your original systems.
Dealing with customers has nothing to do with technology and everything to do with understanding, empathy, and a genuine desire to help them do their jobs better. If you honestly approach your customers with the goal of winning them over and infusing them with enthusiasm for your new systems, you will go a long way in making your migration a success. To help you in this process, this month we're turning away from bits, bytes, and bandwidth and focusing on compassion, cooperation, accommodation, and education.
Compassion
One day you arrive home from work to find a construction crew
measuring your house, inside and out. After a bit of questioning,
you discover they are replacing your entire house with a newer,
better house. All your wood and drywall is out of date, the
appliances are old and slow, and much of your furniture is no longer
compatible with the newer furniture that is coming out. Most
alarming of all, they plan to make the change while you're living
in the house, though they promise you'll never be affected by the work.
When all is said and done, they say, you'll love the new house. Some
of the rooms may be a bit smaller, but there will be more of them
with higher ceilings, and all the closets will be bigger and shared
throughout the house. The bathrooms will use those new three-handled
faucets you've read about, and everything will have a remote
control.
But, you protest, you didn't want a new house! This one is just fine! It's worked great for years. You've figured out where the floorboards creak and gotten used to the noisy refrigerator. Two-handled faucets are good enough for you, and remotes are just confusing. Why would you want to change?
The workers are smug. Wait until you get all those remotes, they say. You'll wonder how you lived without them. Three-handled faucets are required if you want to get that new bathroom technology coming out next year. And shared closets make it easier to keep your clothes closest to the room you're currently in, no matter where you go in the house. When all is said and done, you'll be thanking them for doing all this work for you.
This is a farfetched tale, unless you happen to be on the receiving end of a major systems conversion. Users often have their favorite tools and technology stripped away, replaced by "newer, better" things that do some things well, but not everything the old tool did. Report formats change, naming conventions are altered, files are converted, and user interfaces change. Everything that was familiar is gone, replaced by tools that may be good but require a lot of learning to be made effective.
When you begin the process of systems conversion, you must walk a mile in your users' shoes. It isn't enough to know that they use your systems. You must understand how they use them, what they depend on, and how they perceive the system to function. When does performance matter? How much disk space do they really use? Which applications were custom configured to do something special that no other version will do? You can only learn all these things by seeing your systems through the eyes of a user.
Understand that systems conversion may be an exciting technology experience for you, but it's nothing but frustration and annoyances for your users. They must train for the new system, convert their tools, and rebuild their operating procedures to accommodate the new systems you're installing. You must develop tremendous compassion for the pain and agony you are about to inflict on your user community.
|
their trust, view the world through their eyes, and most importantly, don't ever stop putting them first when you make decisions |
If you take the time to understand your user community and learn their business, they will trust you when you tell them what changes are looming. If you really understand their needs, you can make better system design decisions as you deploy your new servers and tools. You may find that decisions you made in your planning stages are completely wrong for your users. You might also discover that some of the complex feature you're planning to deploy mean nothing to your users, saving you the time and trouble of making them work right.
No one likes change. Change is hard enough when you're in control of it; change can be unbearable when you have no control. Your users are at your mercy as you rebuild their house around them, promising fabulous new benefits as their tried-and-true environment disappears. Learn their business, win their trust, view the world through their eyes, and most importantly, don't ever stop putting them first when you make decisions.
|
|
|
|
|
Cooperation
If you earn the trust of your users, you can then try to win their
cooperation. Users may trust you and still fight you tooth and nail
over every minor change you want to make. You must make your users
part of the change process, giving them ownership of the new systems
and giving them at least partial control of the changes being
inflicted upon them.
The ideal way to approach any systems change is to build a team of users and system administrators who will jointly design and implement the new system. If users feel involved from the beginning, they'll understand that the new system is their system and that they need to work hard to make it do everything they need it to. If you try to design a system for your users without making them part of the process, you'll never build what they want, no matter how good your intentions.
|
change process, giving them onwership of the new systems and giving them at least partial control of the changes being inflicted upon them |
Many operations people will shy away from involving users in the design of new systems. Many users aren't capable of making the difficult technological decisions required in any systems conversion. However, users are experts at the most important topic: knowing what they want. The systems people must get over their reticence at giving up some level of control so that users are allowed to influence the final design decisions for the new environment.
When converting from mainframe to Unix systems, much of the design can revolve around how various mainframe features can be replicated in the Unix environment. Users see various features of the mainframe very differently from how the administrators see them.
Two tales involving tape illustrate these varied perspectives:
In one systems conversion I was involved in, discussion with the mainframe users revealed very strong requirements involving the ability to mount tapes throughout the day for data storage. As we've learned, (see my December 1998 article, "Unix tape services: Get on track"), Unix is weak in this area, and the users were horrified to learn that even simple tape mounting and cataloging would be far more difficult under Unix.
After many discussions, we discovered that users didn't really want tape, they wanted cheap temporary storage for data that was often purged after just a few days. Their applications and job control language (JCL) streams had been written years ago, when disk space was outrageously expensive and tapes were plentiful. Our compromise solution was to provide large areas of temporary disk storage to hold all this data. Our disk chargeback rates were tweaked to make sure that this storage would be cost-effective. The users were happy because access time to their data was much lower with the disk solution than with traditional tape.
This same user community also archived huge amounts of data to tape each night. The operations staff computed the required capacity of the Unix tape systems using the total tape capacity used by the mainframe in a given time period. Because of the archiving, the tape unit would have to be fairly large with extra drives to meet the bandwidth requirements.
Again, talking with the users got to the core of the problem. It turned out that the mainframe disk accounting package computed total disk usage every night at midnight. A bright user had figured out that they could dramatically reduce their disk charges by spooling all their data to tape at 11:00 p.m., scratching their data sets, waiting for the accounting jobs to run, and restoring all their data afterwards. When the users realized the Unix disk accounting would be done differently (charging by filesystem regardless of utilization) and that their tape trick would be pointless, they eliminated the need for the nightly archives, and we were able to redesign the tape system using a smaller, cheaper unit.
The moral of both of these stories is that continuous user involvement results in users with a sense of ownership and involvement, administrators with a better understanding of their customers, and a better overall system design.
Accommodation
You may sympathize with your users, and they may involved up to
their ears in the system design and deployment, but they will still
reject many of the tools and solutions you're willing to provide to
them. You must be willing to understand their needs and accommodate
them, no matter how foolish you think some of their decisions may
be.
Accommodation becomes critical in the areas of end user tools and user interfaces. Many mainframe users have been happily banging away on a 3270 tube for many years and have little desire to switch to either a Unix workstation or a PC as their principal desktop device. More importantly, they may be unwilling to invest the time to learn either X (the X Window System) or MS Windows 95 to understand how to use this new device on their desk.
For many users, you may find yourself deploying $2,000 worth of desktop hardware that boots up and runs a 3270 emulation package and nothing else. When that familiar green-on-black display comes up with the little lightning bolt in the status line, these users will breathe a sigh of relief at finally being given something they know how to use. We all know how much additional power is available in the device, but you'll have to sit tight and let these users figure that out on their own.
Be prepared to lose the editor fight. I'm not talking about the emacs versus vi fight, which we all know is handily won by emacs. I'm talking about any Unix editor versus your users' favorite mainframe editor, like SPF. I used to talk myself hoarse extolling the virtues of emacs and why everyone should learn it when moving to Unix, only to get the cold shoulder from my users. The users weren't happy until we tracked down a Unix version of the SPF menu and editing environment. A company called The Workstation Group sells several Unix versions of popular mainframe tools, including both SPF and REXX, the mainframe scripting language. Check them out; they will make you a hero among your ex-mainframe users.
Surprisingly, once we gave users a Unix version of their tools, they slowly began to migrate to our beloved Unix editors and scripting languages. The moral to this story is that users will move to new technology, but at their own pace. The impact of systems change is bad enough. Don't strip away their editors at the same time. Accommodate their mainframe needs in the beginning, and they will find their way to better Unix tools in due time.
Education
As your users make the mainframe-to-Unix transition, you must help them get
some formal training in the basics of Unix. Don't send them to
system administration class; they'll just get confused by
information that is too detailed for their needs. Instead, enroll
them in a shell basics class, where they can learn how to navigate
the filesystem using commands like ls and cd.
From their perspective, they're strangers in a strange land, and
everything they once knew has been thrown out the window.
Or so they think. There is little new in computing; everything we do today existed in some form or fashion in 1970. The problem with computing is that we constantly rename things as we design new systems. JCL on the mainframe is a shell script in Unix; jobs become processes; partitioned data sets become directories. Amusingly, both systems have core dumps; thankfully, neither have a Start menu. One way you can quickly help your users get up to speed is to give them a brief review of the Unix lingo, helping them talk the talk as they learn to walk the walk.
An important aspect of using Unix is to have a Unix mindset, where combining many small and simple tools allows you to quickly build bigger and better tools. Unix pipes and I/O redirection are nothing more than quick-and-easy ways to put a whole bunch of JCL on a single command line. If your mainframe users can understand this, Unix becomes a lot more familiar and easy to comprehend. When users point out other mainframe features and utilities, try to find the Unix analog and teach them how one system is similar to the other.
You might also try to share something of the history of Unix. Unix is nearing its thirtieth birthday, and many of the features in it today have their roots in some incident years ago. There is a rich story in Unix, a tale of collaboration and joint effort that has united the efforts of hundreds of thousands of users over three decades to produce an outstanding operating system. Imbue your users with that sense of history and help them to feel a part of the Unix community. Introduce them to the Unix community on the Internet and show them how to find tools and resources on the Web and in newsgroups. The more your users know about Unix, the better they will understand why it works the way it does, and the better they will be at exploiting Unix to get their jobs done.
Perseverance
You don't go through these steps once, in order, to win over your
customers.
You perform them all in parallel forever. Every user is at a different stage in his or her adjustment to your new environment and will require various levels of assistance from you. Your job isn't about your systems, remember; it's about your customers. The more time you spend helping them use your systems, the more value you'll get out of all that technology you've put together.
If it all works out right, those adamant mainframe users will one
day become adamant Unix users, and your transition from the
mainframe to Unix will have been a success.
|
|
Resources
About the author
Chuck Musciano started out as a compiler writer on a mainframe system before shifting to an R&D job in a Unix environment. He combined both environments when he helped build Harris Corporation's Corporate Unix Data Center, a mainframe-class computing environment running all-Unix systems. Along the way, he spent a lot of time tinkering on the Internet and authored the
best-selling HTML: The Definitive Guide. He is now the chief information officer for the American Kennel Club in Raleigh, NC, actively engaged in moving the AKC from its existing mainframe systems to an all-Unix computing environment.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright99.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-05-1999/swol-05-users.html
Last modified: