A Mainframer's Musings

My answer to this question is purely from the perspective of a mainframe developer aspiring to become a technical architect utilizing their mainframe expertise. I have listed down some most essential technologies to learn from in-platform and outside mainframes. In Platform: Inventory analysis - ADDI is an inventory analysis tool that forms the basis for most modernization initiatives. It is essential to understand what kind of analysis may be needed for different types of modernization roadmaps. There are other products too from non-IBM vendors. DevOps on Mainframe - explore the different DevOps patterns and pipelines and find out how it helps developers, system programmers, managers and deployment teams. Currently, the adoption levels may be slow, but I am almost certain that in 5 years using DevOps will become a norm in mainframe surely. z/OS Connect - if you are exposing your application as an API to non-mainframe applications, t...

The answer to this question as any seasoned architect will give you is "it depends". I can confirm that it's not cliché but reality. There are several types of "architects" in the market each having their own value, purpose and need. They may be Technology specific architects, Enterprise Architect, Business Domain architects, Lifecycle specific architects, Data Architect, Infrastructure architects, etc. to name a few. According to me, some key qualities that an architect would need are: Be the most adaptable and flexible person who can churn out solutions and alternatives within a given scope and constraints.  Be the first to break any bad news about things that may not work (technically) with reasoning.  Provide inputs to the organization's academy or learning department to add new skill courses needed by the employees for progress. In short, give information & indications to decision-makers on architecture and t...

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