A Mainframer's Musings

 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...