Migrating off the mainframe does not always reduce IT costs and boost performance. In these fictional diary entries,...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
a sys admin finds out firsthand that a mainframe migration is not always the best cost-saving option.
Today is the day! Finally, we're going to migrate off the mainframe. No more spending millions for a system, no more paying exorbitant fees for utilities. I'll finally be able to let go of Kwan Lee, my crotchety, stubborn old system administrator. I won't have to listen to him muttering in the halls about JCL, VTAM, ISAM and other incomprehensible stuff.
Boy, am I going to look good for doing this!
A minor glitch in moving our apps to the new systems: It appears that an undocumented feature in our old accounting software doesn't handle dates after 1999 well. It seems that Kwan Lee patched the system to work on dates up to 2009, but never got around to updating the patch for 2010 and beyond. This has caused odd results in our forecasting. Good thing we caught it before Jan. 1. I have reassured the CFO that this is a normal problem and will be fixed immediately. The unfortunate thing about this is that with our forecasting on the fritz, our top execs haven't yet seen how much money I will save.
I am very pleased with Suzie Wong, our new system administrator. She's smart, she knows all the latest technology and she costs far less than old Kwan. She should be able to solve any problems pronto.
O.K., this is getting annoying. Kwan left the mainframe apps in a total mess. Suzie and I can't find all the places we need to re-patch the code. We guessed as best we could, but I finally had to call in Kwan temporarily to double-check our work.
Meanwhile, a surge in usage as we approach the end of the quarter maxed out both ERP and accounting, because we don't yet have an effective way of load balancing and throwing PCs at the legacy apps to scale them. All the folks who used to complain about restricted access to our business-critical apps are now complaining about lousy response times. If I can't get a quick working fix soon, I'm going to have to bring in a big blade server or a high-end Linux machine. At least that's still way cheaper than buying a mainframe.
It seems like life is just one thing after another. The patches seem to have worked, so I can forget about that problem -- for five years, anyway, and I'm sure I'll be promoted by then. I've reduced the performance problems a lot by buying a few more PC/Linux servers and adding a blade server. It wasn't in my budget, and there's a spending freeze on, but management understood this was an emergency. So this morning it seemed as if I were beginning to see daylight, still with a nice cost saving to my credit from deep-sixing the mainframe.
Then I walk in today and find out that management has changed my requirements. Some government regulations or other require that more data is stored. That means I have to add more servers to handle the increased workload resulting from providing access to the increased data. Suzie is already pulling major overtime to handle the new servers I just got -- there's no way she can handle the additional increase. So I'm going to need another administrator. The worst part is, all this additional expenditure is going to make it seem like I didn't save much money at all. It just isn't fair! Luckily, my boss understands what I'm doing and how we would have the same surge in costs even if we still had the mainframe.
Well, it turns out that adding servers and increasing load balancing was only a temporary fix. Response time for the old mainframe apps is getting slowly worse, it's hard to figure out how to tune them and it's really hard to justify all their operational costs when management can see much cheaper versions out on the Web. Business-critical or not, it's time to consider buying or developing new apps to replace them, and that's what I've recommended.
Surprisingly, there was a lot of pushback on that in the management meeting today. I expected nervousness about the new systems; I didn't expect concerns about the amount of money this would cost. Yes, I know we're in a cost crunch, but we can save a lot more money in the long run by improving our business processes, and the new Web apps have all the bells and whistles to do that. They were very reluctant, but in the end they saw the light. I was given the go-ahead on two conditions: one, strict cost controls for the transition, and two, no loss of functionality for each app we replace.
There was one odd remark. Someone made a crack about "three envelopes," whatever that means.
Today was the worst day of my life. And I hadn't a clue when I walked in this morning.
It was supposed to be the kickoff day for the first new Web app that's replacing our mainframe accounting app. This should have been a slam dunk. The Web app had all the same functionality, we did a test accounting run on it using current data (although, with the rush and the cost controls, we vetoed any unnecessary testing), and we'd trained everybody on all the new things they needed to do to use it. But we missed one thing: We had to load all the data for the old app into the new app, and Kwan's patch was in the mainframe app, not the data. Accounting runs were fine, but forecasting went screwy again for 2010.
The next thing I found out was that Suzie Wong and the other new administrator, Chandra Patel, were both out sick. Yes, they both had to pull extra hours to manage the test systems for the new apps, but that's temporary stuff. It was just my bad luck that they weren't there right when I needed them to figure out a fix for the new Web app.
Just as I was catching my breath and beginning to deal with end-user complaints, I got called away into a management meeting. Boy, was I blindsided. Apparently, they had brought in a consultant who claimed that we could load all our Linux apps onto a mainframe and save money. The consultant asserted that because nobody had bothered to recycle our old mainframe, it wouldn't cost any money for the hardware, and because Linux app licenses are per-system, we could save enough on licensing costs to make up for the high mainframe software utility charges. And, he claimed, people costs would be lower.
At that point, what with everything I was dealing with, I admit I lost it. I said, "Look, we just got through getting off the mainframe, with its expensive hardware, expensive software and expensive administrators. We're just about to see daylight on getting rid of mainframe apps that even in the new environments have high operational costs, and you want to take us right back to the old days?"
And right at that moment, in walks the CFO. It turns out he's been getting an earful from his reports about the new app, and before I got a chance to talk to them and calm everybody down, he bends down and whispers in my boss's ear what is happening.
You can guess what happens next. The boss takes me outside and says it's time to move on. Management has made up their minds, and I just happen to be associated with a project they've decided not to pursue, in the middle of a cost crunch.
Well, they're going to regret it. Me, I don't regret anything.
I'm ready to move on. But as a final gracious gesture, I pinged Suzie Wong to express the hope that she wasn't too badly affected by my departure.
She says Kwan Lee is back. He's very helpful. And he's cute.
ABOUT THE AUTHOR: Wayne Kernochan is president of Infostructure Associates, an affiliate of Valley View Ventures. Infostructure Associates aims to provide thought leadership and sound advice to vendors and users of information technology. This document is the result of Infostructure Associates-sponsored research. Infostructure Associates believes that its findings are objective and represent the best analysis available at the time of publication.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at email@example.com.