Business Strategy or just Mainframe Migration?

As many of IT veterans, I started my career as mainframe programmer in 1998. As from Electrical Engg background, I equally loved and hated my job, loved her salary part and hated her job nature. This is similar to when one is getting married with rich girl (which I am not actually J) and one don’t like her (not true in my case J). Eventually with time one gets used to situation and start liking your wife. Similar happened with my job, for first two years don’t have any clue what I am doing, why and what benefit a person sitting across the continent is getting to pay me handsomely. Gradually mainframe technology started making sense and then next 10 years or so flies away in executing projects, handling teams, customer site travels and so on till the time the shock came. 

I opened a pdf document to read a joined case study conducted by organization and Gartner on future of mainframe technology. It was predicated that mainframe will get sunset in next 10 years, based on which organization had planned to demise in next 3-4 years. This shock was no less than a rich wife seeking divorce from husband, so how husband will survive? Especially when mainframe has helped sustain my job during IT recession. I started perceiving movement of people to Java, testing, quality/PMO from this perspective to keep on increasing my heart-bits. 

However one thought did struck at that time if the mainframes are going to sunset, there must be some alternate systems which should support this business I am helping running from last 10 years. So either there should be new system or one should be migrating from mainframe to existing systems. Like spark in dry forest, this ignited many thoughts, readings and discussion around this point. 

As I was from development background, first thoughts were about development tools and I am fortunate to get the opportunity to explore many of them especially RDz and Enterprise Developers. Next was about code/source management tools which we migrated to eclipsed based interface of Endevor tool and also then to SVN in another organization, also got my hands dirty on GIT, and believe me, more or less they are similar. Next was to find alternate solution for mainframe proprietary tools or capabilities like VSAM, GDG etc. This was being handled by moving to database or file system, someone can use rehosting solutions available in market, or one can replace the mainframe commands with native language capability. Then as thought progresses around Operations and handling it efficiently, Continuous Integration, Continuous deployment, continuous delivery started making sense which we then expanded to DevOps and tools associated with it like Jenkins, Docker, Puppet etc. 

This is still ongoing journey and these events provided the opportunity to solidify some of the basic concepts of life and business:

• We are in the business of living, so let’s do this business of living well. I am not very good at it, however few of my friends and colleagues are great at having fun in life.
• While in the business of living, we need to do some business for living. We need to earn and there are many choices to earn, so don’t get panic if one option dry out. Remember that our core business of living is going on, so this secondary business for living will evolve.
• Technology is secondary, business is primary and hence technology should be less complicated than the business which it is supporting. If it’s not the case, something is wrong and one needs to figure it out. 

After working for long time in the business of technology, I think couples of core fundamental principal are important for technology success:

• Close proximity to business: Technical people must understand their business domain, expectations of their business leaders, business strategy, business targets, business process/architect for next couple of years. And every technical activity/work one should able to link to these business objectives. I had experienced that it’s not easy always, but giving a shot will help to keep your perspective right.
• Leadership and Vision are important: When I started thinking about mainframe migration, I thought it’s damn technical and need great technical research or at least great expertise. However after working on it for some years, realize that it’s all about leadership and vision. In my previous organization I got the opportunity to work with great people who had vision and oversight of next couple of years of objective and technical guys were motivated towards that. In my current organization, from a year or so this focus and technology leadership started working which I think will take this great product to next generation, to defy the product life-cycle. Technical guys can do miracle if motivated and worked with business leaders.
• Technology is not your wife: Don’t give a damn to it, current will go and new will come tomorrow and make your technology architecture blueprint reflect this ethos. Don’t get emotional about it, be on top of it and remember its servant. Earlier I was always advocating mainframe and keeping distance from open source systems, however realized that once you are good at one technology, workable knowledge of other technology can be acquired comparatively quickly. It’s like Engineering degree, once you got one degree in four years, getting second degree in Engineering will take may be only 1-2 years as foundation is there and only couple of core subject differ, once you get hang of them, you are thru.

 In essential, for me it was not only mainframe migration, but it’s migration of entire thought process, migration from narrow view to broader perspective of business and technology. Technology is important, but more important is business it’s supporting and help flourishing. And primary business of living is more important than the secondary business. So we should live well and to fullest. Best wishes to execute your primary business well.  Live it!