Technology Transformation - Technology is the easy bit, culture is the hard part

I have had the good fortune of having fun rather than working in the technology industry for the last 22 years. I had the aspiration of becoming a doctor early in my career, but after a few failed attempts at trying to pass my science tests, I decided to do something else. It turned out technology that was my calling, and it has been indeed. If you have followed a path similar to mine you have probably gone through several technology transformations with fancy project names (I bet “Nextgen” was probably one of them) that never saw daylight after hundreds of millions of dollars in spending. Trust me, Technology was not the hard part in these transformations, it was the culture that killed it most occasions.

 My first job out of college was working for one of the Ma Bells providing Unix support for an automated workforce management application. If this application stopped working, it meant technicians didn’t get their work orders and customers in turn didn’t get their new phone service or their trouble calls attended to. Believe me, nothing about this application was automated, and I didn’t fancy wearing a tie to work for a night shift support job. However, I honed my vi, emacs editing skills and sh, ksh and bash scripting skills. I wanted to get into application development, but my shift supervisor told me there were many people waiting in line, and that it would be a while before I could write a line of code. I wasn’t going to wait for my turn, decided that it was time for me to move on, and ended up relocating to a place where there were more cows than people. It turned out no one wanted to live there because it was in the middle of nowhere and too cold, but it was a great opportunity for a youngster like me who was aspiring to write code.

 The first few weeks at this new job was interesting. We were part of a big organization and the water cooler talk was that we were special compared to the rest of the company. We were part of a transformational program that was going to change the course of our company. The project was called three C’s. Our mission in life was to create a three-tier client-server application that replaced a legacy system that ran on mainframes. This application had been built over a period of 20 years using COBOL, Assembly, IMS, DB2, etc., and had been running successfully without any major outages, except for planned nightly maintenance windows. Millions of customers were being served across the globe and billions of dollars in transactions were being managed by this application. I was assigned the task of figuring out how to handle the integrity of transactions and scaling the application horizontally to support millions of concurrent clients. The UI was a major improvement compared to the green screens (3270 Terminals) and the call center agents no longer had to remember product, reason codes, etc. However, the application lacked major features and uptime was a major issue.

 After spending several hundred millions of dollars, the project was gracefully shut down. Delivering new features meant business analysts from IT sitting in meetings for several weeks, months with business owners gathering requirements, documenting them, and getting the golden “sign-offs”. By the time it got to a developer, it was a good 3-4 month exercise. Oh, wait! We had to provide estimates for development timelines before we could start writing code. Our estimates were as good as anyone’s guess. We also didn’t have the burden of thinking about non-functional (performance, operational) requirements. The business needed more features than what we could deliver and the features kept changing constantly. Culture wasn’t the issue in this company. The scope of what we tried to tackle was too big and performance was an after thought and a major issue with the new architecture. By this time I was more marketable with my new and shiny skills in C++, Tuxedo, and Oracle and left for greener pastures before the meltdown. Transformation project #1 killer – waterfall development methodology, performance constraints of new architecture.

Part #2 - More to come