Software Change Management Has To Change With The DevOps Times

September 9, 2019 Philippe Magne

(Sponsored Content) It is easier to change a system or a software development stack than it is to change the habits and preferences of people. People are the biggest friction in adopting new technologies – right up until the moment they are not. And then they are easy. So it is with any technology, and the transition from traditional software change management to open source DevOps tools is no different.

It is ironic, perhaps, that the change comes last to the tools that track the changes. But the move to DevOps is as inevitable as it is desirable, flexible, and valuable.

Over the past five years, ARCAD Software has completely adapted our solution, coming from traditional change management to evolve into a true DevOps player on the IBM i platform, with a combination of ARCAD tools along with the three most popular tools from the DevOps movement.

The first is Git and the two tools that are derived from it: BitBucket and GitHub. The purpose here is to have one single source code repository and one single methodology to manage the source code regardless of the platform. The second is Jenkins, which is a continuous integration tool, which is just a fancy way of saying that it orchestrates different tasks after the source code changes and the software gets built for rolling out into production. The typical customer has a graphical front end developed in .NET or Java and they do have to build this side of things along with the native IBM i components. The third DevOps tool we have integrated into the ARCAD stack is Jira, which allows for the management of multiple projects with multiple types of development teams and ensures the coordination between those developers across different hardware/software platform combinations as necessary.

ARCAD is responsible for integrating Git, Jenkins, and Jira into its software development toolchain for the IBM i platform, and importantly is not trying to replace the services and training offered for Git by GitHub (acquired by Microsoft last year for $7.5 billion), for Jenkins by CloudBees, or for Jira by Atlassian. We are partnered with these companies for back-end technical support and they have their own channel of local partners for training. We are responsible the integration between ARCAD tools, the IBM i platform, and those three open source DevOps tools.

Having been in this market for a while and helped many customers make the move from SCM to DevOps, there are a couple of important things that we have learned. First and foremost, it is the realization and recognition that DevOps is a strategy, an attitude, not just a set of a products.

Git is so well established that people think that by just moving to Git they are magically doing DevOps. That’s not really the way it works. Building a DevOps toolchain requires a lot more tools. We see a lot of traction around our code-checker tool, which is for code reviews, and here’s why. When opening up source code to younger developers who are used to these new tools, the first concern seasoned programmers have is how are they going to ensure programming standards. Now, if you have a stable set of developers, as many IBM i shops do, you don’t have this worry. But ensuring the quality of application code changes with new developers is essential and requires the proper tools. The success of GitHub is mainly driven by this code review approach, which is designed to allow for code review and adherence to quality standards for that code.

The shift to DevOps is coming from upper management as well as a grassroots movement among the younger developers. DevOps has different sets of users, ranging from programmers and operations staff. But in the end, DevOps is about people even if it is bringing together people, processes, and tools.

What we have observed is that people go straight to the DevOps, which I think is a good approach because it’s through the toolsets that you can then adapt your different processes and train your people. But people are always the most difficult thing to change. People come from different technology cultures and use different development tools. But the reason why upper management is so keen on DevOps is that it helps with the increasing skills gap. Up until now, the IBM i platform was a business model all on its own, with a set of developers doing everything from coding to pushing applications into production, with strong reactivity in case of a problem with the code.

This approach used to work because of the strong stability of the developing teams. But now we have to bring new technologies and a new generation of programmers on board because they won’t come into the IBM i fold without the new tools. This is why the movement around Git is so massive. Git has become a de facto standard because all of these young code slingers know it. But at the same time, the IT managers have to orchestrate the processes and tools so the more experienced developers, who know the existing code and the business far better, will stay doing their jobs and maybe expand their horizons a little.

So when we first developed what we have called the New ARCAD for DevOps – this combination of Git, Jira, and Jenkins along with ARCAD – it did well for organizations that were mature enough to absorb this all this technology. But we realized that not all companies are ready to make such a switch. That’s why in May we launched Version 11, which is a hybrid solution that can combine a set of old developers still using SEU and other older tools with people that are knowledgeable in Git and ensure that they can work together and they are controlled by the same toolset, whether or not they know it.

This is what the IBM i market is demanding now because not everybody can make such a big bang change. They can’t completely get rid of the native IBM i development tools because they can’t afford to make their legacy programmers unhappy. They will leave. So we mask it, for both old and new developers, even though the source code underneath is all controlled by Git. There is a master repository in Git, but a slave repository on the IBM i that is coming from our original software change management and it is permanently synchronized with Git.

What we really understand from the past few years of selling DevOps tools is that it is far easier to have a strategy that allows the programming camps to converge rather than to force change or allow for divergence. Two decades ago, AS/400 shops had RPG pitted against Java, and the transition to Java programming took a long time and shops still continued to develop in RPG. What we learned is that we needed a better convergence strategy, and IBM came up with RPG Free Form, which makes RPG look more like Java and therefore allows a Java developer to read and therefore maintain that RPG code to a certain extent. It’s not a big deal for a Java developer to move in RPG Free Form.

With regards to DevOps, the companies that are doing the best are the ones that have already moved along with those tools mentioned above – Git, Jenkins, and Jira – and that have a set of people who are knowledgeable about how they all work. In fact, when you have the entire ARCAD stack, there is a natural collaboration between the legacy programmers and the new programmers. Companies don’t need to spend a lot of money on training because there is a natural transfer of skills between the two sets of programmers. If you are moving into DevOps and your two types of programmers are not talking to each other, it won’t be good for the company. It’s all about finding as many points of convergence as possible. You don’t have to converge the programming languages down to one, but all the tools around them have to move in the direction of an assumed convergence.

We still encounter some customers that want to convert all of their RPG code into Java, and we keep saying: Please don’t be stupid. If you have a huge amount of RPG code, the only effort you should undertake is converting that RPG code to RPG Free Form. That way, it won’t look like an alien language to new developers who have never seen an RPG program. And once you have done that, get your programmers into a strong DevOps tool chain.

Philippe Magne is the CEO and Chairman of ARCAD Software, a developer of DevOps software for IBM i and other platforms.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search