Based on the comments and reactions I got it seems clear that every stakeholder (developer, quality assurance, operations...) look at the discussions mostly from their perspective. Which is human.
But be it traditional or modern mainframe development there should be an end-to-end view, taking into account the requirements of every stakeholder and taking into account the whole process:
- What do I need from my developers as a tester to facilitate my job?
- And how can we make sure the operators get all the information and deliverables they need?
- And how do we assure correct and timely feedback when something goes wrong?
- Is every process step reliable, documented, repeatable and verifiable?
Some people said they don’t see any reason to change their traditional way of developing. Well this can be perfectly true! The first question we should ask and answer if there is a business case to change the way we work, are all relevant stakeholders involved and do we have the time and budget?
If there is a business case, the first question is to know what the functional requirements are, for compilation by example! The main stakeholders here are the developers and operations.
Developers because they will want to compile from within their development environment and they want to have the ability to set debug or trace options.
First functional question is if you want a standardized compile procedure used by all developers or do you let developers have their own compile procedures?
What are the benefits (or drawbacks) from a unified developer compile procedure?
Once the developer “commits” his code to the versioning system the next functional requirement is to have a standardized compile procedure that again is standard, well documented, repeatable and performing and takes out all pure development oriented compile options.
As for the development compile results, the “official” compile results should be archived.
Your Quality Assurance can consist of one or more levels: functional testing, performance testing, …
QA can be manually, automated or a mix. Is it a functional requirement that these automated tests are a standard part of your compile procedures or not?
Do you have one, big compile procedure that does, by example, just batch COBOL, or also takes into account DB2 and CICS?
Make an inventory
Again, making an inventory of your functional requirements and having an overview on the AS IS and TO BE situation. Make a list per stakeholder of their requirements and the expected deliverables for themselves and the other stakeholders.
What, by example, does your internal audit expect?
Once you have your business case, your functional requirements you can start looking for the technical implementation. If, by example, you decide to keep on using ISPF, it doesn’t make sense to look at compilers that support Eclipse.
Or you might need both…
Continue reading in our next post: Deployment (Mainframes and DevOps)
About the author
Hello, my name is René De Vleeschauwer.
Throughout my career I've been responsible for the development of enterprise software. Since 12 years I've been leading the development of IKAN ALM, an open DevOps framework.