Devops in a Regulated Mainframe Environment

Striving for real world experiences with agile, kanban, lean, and devops I ran a series of email interviews. Today I want to share the answers of Manu Khronis, NRB, Belgium.

1. Please tell me a little about your current situation, your team and your job
   I am responsible for IT change management at Network Resource Belgium, or NRB – the company provides IT solutions and services to companies in the finance and utilities markets, and public sector organisations. Our work covers everything from outsourcing of IT hardware through to application development and delivery.
   
   This role includes a lot of work across mainframe environments: we have more than 120 experts in mainframe technology and applications on staff, and a lot of our customers rely on us to develop and support their applications that run on their IBM environments.
2. Please list all the challenges you are facing in adopting agile, lean, or devops principles within your organization
   
   The companies that use mainframes, and therefore require applications for them, tend to be in regulated environments. The finance and banking sector requires you to have tracking and audit trails for application development and changes, while the utilities sector has a similar requirement. Demonstrating that we are following those requirements is therefore a big part of our work, and that adds an overhead.

   Another challenge is managing the release of software through to the business, either internally or on behalf of a client. This can involve a lot of work across different individuals that are involved in the process. Again, the requirement for tracking and audit around the release of the software is a challenge.

   Finally, the biggest challenge is around the development process itself – making sure that our processes around how staff are working are optimised to create the best results and in the shortest possible time frame, but also not at the expense of quality.
   
   

3. What is your biggest challenge of the ones above? And why?
   
   These all tend to be tied together, but overall I would say that the area of release management is one of the biggest challenges that we face. There are two reasons for this: the first is that managing the release can be a manual process that can consume a lot of time for the development team involved.

   Secondly, what the business sees as the result of the investment in application development is not the actual work. It’s what is released out to the organisation and how this is delivered. If an application is delivered late or it does not get rolled out properly, then it affects all the users that are relying on that service.

   As we are responsible for delivering these solutions out to customers, it has to go smoothly. Anything else just is not an option.

4. What keeps you from changing the situation so that you can remove the biggest obstacle?
   
   Actually, we are already tackling this problem – automating the release management process has two benefits for us. Firstly, it takes the task away from the development team and reduces the amount of effort they have to put in to make a release go successfully. Secondly, it allows us to have that audit trail and accountability around implementations.

   We have been working with Serena Software on this issue of release management automation. The product we implemented will help address those problems on the mainframe side, and as an added bonus can support our work on distributed platforms as well.

5. What would be the single most helpful thing to get things moving into the right direction?
   
   Overall, the whole application development industry is having to change, as the speed at which we have to deliver software is increasing. At the same time, the tolerance for errors is also going down. The way in which we work has to take this into account, so greater automation is required. Everything from how new software or updates are required.