Is Infrastructure knowledge necessary?

Most of us, who were trained in mainframe and got into development, must have studied a small introduction to mainframe infrastructure. Usually, that knowledge is neither extensive nor exhaustive to perform any significant infrastructure activity.

 However, over the years, while you start performing architecture-related works, there will be a need to collaborate with the infrastructure team(s) to either create a solution or try out a proof of concept or technology. This collaboration is inevitable especially if you have chosen a path of mainframe modernization. Hence a little bit of knowledge and further reading on infrastructure always helps. This will aid you to use some jargons and terminologies that are closer to the infrastructure person and will help you to build a better collaboration with them.



The next question then would be how much is "a little bit of knowledge". It is usually subjective, but I will list some of the following indicative knowledge that can be acquired.
  • DB2 DBA and administration activities (DDLs, Table partition, Table maintenance, etc)
  • CICS/IMS administration activities (defining resources in CICS/IMS, TCP/IP configuration, etc)
  • MQ administration activities (defining queues, triggering configurations, etc)
  • Processes and activities related to code migration to different regions
  • Configurations needed for any modernization tool (like z/OS connect, DVM, etc)
  • Message exchange standards (like JSON, SOA) and configurations needed for them

The important thing is you need to know these things exist and have a reference to this handy. The infrastructure team would of course be doing these configurations. However, you will continuously collaborate with them when you are trying these things newly until your POC or POT works and becomes implementable in production. You may extend this above list to other sets of vendor products depending on the configuration of your mainframe and the list of subsystems and external interfaces that are present.

 Remember, any additional knowledge we possess will help us immensely in building our soft skills and communication ability with different stakeholders and teams when we grow into an architect role. The infrastructure team will be one such stakeholder. Imagine the other stakeholders that are part of your projects and explore further expanding what else could be acquired. 

Comments

Popular posts from this blog

What skills to develop to become an architect?

What resources are available for learning?

Do I really have career growth if I continue in mainframe projects?