Why shouldn't we outsource? We're all getting older; it's getting harder to find people to replace us. Skills such as PL/1, IMS and the like haven't been taught for years.
What holds us back are the decrepit systems that are -- our friends. They're our reason for coming into work, our reason for enjoying this IT life. "My" system -- the one I had a hand in building all those years ago.
So why aren't we doing the right thing? Why do we hang on to these relics of the past to the point where finding a sourcing partner to deal with them starts to look more attractive?
"The users will never pay to rewrite these," we say. But when was the last time anyone actually asked them? And, if users were asked, were they asked about a business decision, or were they told about obsolete programming languages, dead databases and hot new technologies?
When we ask about replacing our friends and try to be convincing by talking about our issues, we're setting ourselves up for a "no." But then, that's what we really wanted anyway.
For the past two decades, India and other outsourcing destinations have been churning out millions of graduates who have been trained in both old technologies and the latest ones. Meanwhile, in North America, the number of people who prepare for a life in IT continues to fall. We stopped training people to look after all the legacy code that runs our companies, and we didn't think about what the outcome would look like.
It looks like we're trying to solve a human resources problem overseas. That's what it looks like.
The typical U.S. IT shop hasn't done anything interesting in years. Consultants have done all the heavy lifting. No wonder the top third of graduates go to work in the vendor community!
To keep IT jobs at home, it's going to take more than outcry and protest. It's going to take hard-nosed action. We're going to have to put our old friends to sleep.
Here's what we have to do to take charge:
First, we must do serious analysis. What is the true quality of the existing application portfolio? What does the average minor change cost? What's the minimum number of people who have the required skills we'll need if we keep this system? How well does this system fit the work being done in the business today? If it didn't exist, would we build it -- or something very different? This analysis is not needed only on a system-by-system basis; it must also look across the infrastructure to see where savings could be found through change.
Second, we must sell change. We must talk in terms of business productivity, execution costs, increased responsiveness, information density and usage effects. We need to be the ones who put a pro forma business case down for an architected outcome.
Third, we must execute, and do it ourselves. That will require reorganizing, learning and managing risk. Only by taking on the job -- not by hiring the consultants -- will we be credible rebuilders.
The choice is ours: Leave the next generation with the next generation of systems, or leave them to India. What is your legacy going to be?
-- Bruce A. Stewart is a former CEO and onetime senior vice president and director of executive services at Meta Group Inc. He is now an executive adviser in Vancouver, British Columbia. He can be contacted at bruce@bastewart.com.