DevOps didn't exist back then
In the late 80s to mid 90s I travelled the world implementing ENDEVOR. Best practices then was RUP (Ivar Jacobsson) and few people had the time to read his 600+ page explanation of RUP. Chapters were skipped (like how to make provision for Iterations and Increments), and the implementations resorted to be a lifecycle waterfall: first you coded, then you unit tested your code in a shared runtime environment, then you system tested your code in another shared runtime environment and so on until you finally reached the production runtime environment. The environments where isolated from each other, but using concatenated runtime libraries. Life cycle automation was provided (Compiles/links/Binds) and security established with SAF calls, and all software assets were stored and secured in a logical inventory structure.
This was before
- Commercial use of C and Java
- Long before ITIL
- Long before DevOps
To make the lifecycle more useful, many sites customized ENDEVOR by building their own frontend, integrating with functionality provided by other tools (DMR/MMR, various 4GLs and database technologies). No one was thinking about how much legacy this created.
ENDEVOR Admins don't grow on trees, and many of them are getting close to retirement. A successor on the admin position have a lot to learn in order to carry on the work. On top of that comes the request to better support modern development practices (DevOps and CI/CD), forcing sites to either reengineer or replace RUP-based solutions to something that better supports CI/CD and Agile work practices.
I conclude that it is not enough just to redefine roles and processes. You are probably also stuck with technology that disables Agile/DevOps efforts. You have to be prepared to invest in tools that enables the new way of working, or, as an alternative, reengineer what you've got. I would say "better start fresh" with a solution designed to meet todays needs and get rid of a 30 year old heavy backpack.
