A Mainframer's Musings

This is probably the most asked question to me by entry to mid-level developers. However, there is no straightforward answer to this. Most of you, who had joined the IT workforce as a mainframe developer in recent years, may have opted for this due to a lack of other choices. So, for some of you, mainframe modernization may sound like an escape route to a better and more sophisticated career.  If I look back at my journey, I admit that I was lucky to be part of projects that involved modernization. I did not realize the value of such projects initially. Over time, with guidance from many of my mentors and well-wishers, I got to know that some of them were first-of-a-kind and progressive projects in terms of what the customer’s competitors did.  If I were joining the IT workforce today as a mainframe developer, after knowing what I do now, I would follow the below re-direction path and suggest the same for the audience. Evaluate: Understand the roadmap of your current project a...

There are several dimensions to mainframe modernization and visiting my previous blog will help you put this question to the right perspective You may not have to learn all of these to pursue a career in modernization. However, in today's "quick execution" world, it is important to know the dimensions and choices available to a legacy application. The end state or modernization option chosen is completely dependent on the current and future business vision, architectural vision etc. of the organization. I have tried to classify the topics (techniques) to acquire the skill sets needed to perform the various modernization methods listed in my previous blog. The dimension that your project(s) takes might determine what you may need to learn. Most of these things may be associated with a specific product/software when you try to do a web search for further reading. My 2 cents will be to concentrate on the "technique used" to solve a problem than the nitty-gritty if...

 There are varying opinions on classifying the projects that we execute in Mainframe technologies. I am almost certain this is also true to an extent for other legacy technologies as well. If you are a developer (typically experience from 2 to 8 years), you really need to understand the big picture of the project you work for.  In my view, if your project does any of the following, then it can qualify as modernization. These are not exhaustive but usually fits in 80-20 rule based on my experience. Business requirement related Maintenance, cost or skill constraints related The first one is driven by either the need to scale or by competitors of the business. The second one is driven by the need to simplify existing processes to make headway through competitors or sustain business. Driven by Business requirements: Various scenarios in business requirements can drive modernization. Few of them are listed below. Expand channels (user interfaces options) to existing customers - Thi...

Over the last 3 or so years, especially after the pandemic began, I get a lot of queries from my LinkedIn connections as well as fellow junior colleagues about shaping their careers within the context of being a mainframe application developer or a senior developer. They look to me for some guidance as I have, over a couple of decades of my software career, had gone through different changes, challenges, and transformations. This triggered my idea to write a blog to address these repeated (yet very essential) questions.  I Intend to initially answer in each of my blog posts to answer questions like: 1. What is (qualifies as) mainframe modernization? 2. What to learn for mainframe modernization? 3. How to divert my career into mainframe modernization? 4. What skills to develop to become an architect? 5. What technologies should I learn? 6. What resources are available for learning? 7. Should I do cloud certification? Which one to choose? 8. Do I need to learn DevOps...