We entered the naughties (as we call them here in Australia) with a sigh of relief. All the preparation for Y2K paid off, so much so that I've heard plenty of people question what all the fuss was about. My non IT husband laughed at me when I took precautions, filling up the gas tank of my car in case pumps didn't work, getting some cash in case electronic payments didn't work, prepping with a couple of gallons of water and some tins of irish stew. Those tins sat in the pantry for years, I wonder what ever happened to them.
Not long after the initial relief that most systems had been adequately hardened against the century change we started to see the mainframe labour market flooded with newly released programmers. At the time I had reskilled in Java and was providing long term staff supplementation services to MCI/ Worldcom via Compuware. This assignment saved my arse when the floodgates opened and the Y2K mainframe consultants were cut loose.
The reality of the time was that there were more mainframe developers available than at any other time I've witnessed. Highly experienced alongside the newly minted. Many of them reskilled in other programming ecosystems. Some retired as Y2K was their last hurrah. And some remained firmly within the mainframe architecture as the applications still needed to run. It was around this time that tertiary education facilities removed mainframe architecture and languages from their curriculum but no one really cared, there were enough mainframe skills to last forever, or so it seemed.
To only discuss the fallout for mainframe professionals after Y2K is to ignore the bigger effect to the IT industry of the Y2K project. Prior to the Y2K efforts most IT functions were commonly performed in-house within corporate IT departments by staff or on-site consultants. Following the successful Y2K projects worldwide we saw large-scale outsourcing and offshoring of projects and whole applications from these IT departments. In the early days I typically didn't see mainframe applications sent offshore, most likely due to cost of setting up mainframes and/or fear of sending core codebase outside of corporate control. Instead they were ones that could run in environments that could be stood up quickly and configured easily, where an entire codebase was packaged in a build. Now I've seen entire mainframe applications outsourced, some the lifeblood of the company.
It seems an appropriate time to state that opinions expressed here are mine, as an individual contributor, based on my lived experience. My original take.
As an analyst/developer that wasn't responsible for a budget from where I was sitting it all came down to short term line items in a budget and little thought about long term outcomes.
- Outsourced projects were pitched as a way to shift responsibility for delivering projects to an agreed upon deadline, price, and requirements. I have seen some delivered that did this but were unmaintainable. Others proved difficult to run as problem determination was rarely a stated requirement. I saw many that were scrapped after delivery. What saved money in the short term cost money over time.
- Outsourced/offshored applications resulted in the loss of tribal knowledge and experienced in-house professionals. More than once I saw applications brought back that required the time and effort to build up the in-house experience that had been lost.
- The natural result of losing tribal knowledge and experienced IT professionals was the hollowing out of in-house IT skills needed to support these apps in the long term. Even if a few experienced staff remained no entry level staff were being hired to train up.
- An additional repercussion was the lost opportunities to improve/modernize applications. See note below on *modernize.
I'm going to digress a little bit, so bear with me. When I entered IT in 1988, and up to Y2K, it was like the wild west in the IT departments, with my experience in mainframe applications. While business would request features or modifications much of the design and delivery was nutted out within the IT department. Not a lot of consultation with the business on the user interfaces, for mainframe we're talking green screens and reports. And if projects ran over time and over budget there wasn't much pushback from business because what choice did they have. So the realization that came from Y2K efforts that projects and applications could be outsourced must have seemed like manna from heaven to upper management and the bean counters. .
I do see containing costs as a driving factor when deciding to outsource/offshore, but more importantly I saw this decision made when there were less technical managers making decisions. Hear me out... I can't blame Y2K for this, more likely it was some business consulting vendor selling their 'how to manage your IT department' process to a C suite with no technical skills. Over the past two decades I've seen a push to actively promote non-technical managers into positions of responsibility and decision making for IT departments. When this is coupled with an environment that rewards short term cost savings I've witnessed more than one manager making 2 to 3 years plans that have short term savings and then promoting up or seeking a job elsewhere, prior to the fallout of their decisions being evident. God help you if you are in what is known as a 'difficult' application because these managers love to build their reputations there.
I'm not opposed to reducing costs, improving efficiency, delivering projects on time. These are legitimate objectives for any successful organization. What concerns me is that the long-term impact of outsourcing and offshoring was not always fully considered, even as the repercussions were becoming obvious. While the short term savings showed in a budget the loss of experienced professionals, mentoring opportunities, and localized expertise was not. Decades later, as organisations struggle to find people with the skills and knowledge needed to support critical systems the consequences of those decisions are being felt across the industry.
*modernize - I use this term to describe and/all actions that help to improve a codebase. Replace outdated nested Ifs with case statements. Create a DAL (data access layer) for accessing databases, especially by external applications and services. Correct comments. So many opportunities to improve the codebase/application that can be included as a BAU of implementing any project.
Stay tuned, part 4 dropping soon.