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.
- 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
Post a Comment