Embracing the DevOps Transformation on IBM i
Arcad Software's Philippe Magne on the evolution of DevOps and its critical role in IBM i modernization initiatives
This transcript is edited for clarity.
Charlie Guarino: Hi everybody. This is Charlie Guarino. Welcome back again to another episode of TechTalk SMB. I’m really happy today to be meeting with Mr. Phillippe Magne. Phillippe is the CEO and founder of Arcad Software, a company that specializes in DevOps for the IBM i platform—a company that’s been around for 30 years, which is pretty amazing to me. Welcome Phillippe. Thank you so much for joining me today.
Philippe Magne: Thank you, Charles, for your invitation. It’s always a pleasure talking to you about this hot topic.
Charlie: Absolutely. Phillippe, we’re sitting here today and of course the real reason is to discuss DevOps. I know this is a term that’s being used many, many times and many people hear about it, but I think in many cases people don’t entirely understand what DevOps even is or really the depth of what it is. So let’s just start our conversation with that—you know, what is DevOps perhaps, and really more importantly, how does it differ from traditional software development in IT operations?
Philippe: Well to answer such a question we have to speak about the origins of the DevOps movement. It’s a movement that was born in 2007, so quite a while ago, and the propose is about automation and monitoring of all the stages from the creation of software from the Dev up to the Ops. It proposes to have shorter cycles and dramatically increase the number of deliveries for a quicker time to market, and that’s really something that is taking enormous importance now in today’s world.
Charlie: I recognize how important DevOps is, but I don’t think some shops truly recognize the benefits that they can get from implementing a bona fide DevOps solution. What do companies stand to benefit or how do they stand to benefit by implementing something like this, especially those who are new to this in their IT journey?
Philippe: Well definitely the big premise of DevOps is to increase the developers’ productivity on one hand while having a better time to market—so, having shorter cycles in terms of software delivery. You have a virtual cycle where in fact you have quicker customer feedback and you can improve much faster the way the software is developed. That’s the big premise of DevOps.
Charlie: When you say time to market, are you talking about specifically from development to production? Is that the time to market you’re speaking of?
Philippe: Yes, exactly.
Charlie: I know one of the other roles in DevOps I hear people mention quite often is automation. What does that actually mean in this context? What exactly is automation in the world of DevOps?
Philippe: Automation is the basic principle of DevOps in the sense that it’s true automation that you can shorten all your cycles usually.
Charlie: So when you say shorter cycles, are you talking about from my development cycle to production? That entire process can be automated?
Philippe: Yes, absolutely from the user request. Then the developer does the coding and all the subsequent phases can be fully automated.
Charlie: So there’s a little bit of a disconnect for me. I think some people would question is that they hear the word DevOps, it sounds like there needs to be some kind of collaboration between development and the operations team in a true DevOps environment. Do I have that correct?
Philippe: I mean yes, absolutely. That’s the premise of DevOps. People from the Dev and the Ops up until now had kind of wall being built naturally between the two because the objectives on both sides are slightly different. On the Dev, they are requested to do more and more changes, more and more faster, while on the Ops the goal is to keep as much stability as possible. So it’s this collaboration that is creating an enormous value because people from the Dev and the Ops have to collaborate. They have to share this end viewpoints and this communication is what is creating the big value in the software supply chain.
Charlie: So there needs to be some real transparency between the two teams.
Philippe: Absolutely.
Charlie: Yeah, they can’t be working in their own silos anymore. They need to collaborate as you said.
Philippe: Exactly. I know a certain number of companies who are helping companies to implement DevOps transformation, and that’s the first point they are putting an emphasis on is to put everyone around the same table and talking along with each other.
Charlie: You know for me, Phillippe, I can tell you that whenever I discuss modernization, I always say one of the first things on the roadmap is getting your house in order. And what I mean by that is just getting the infrastructure in place and that is DevOps, but specifically to me that is things like better code-based management, things like using Git and repositories and things like that. Can you speak to why that is so important?
Philippe: Yes. As soon as we talk about DevOps transformation, it quickly comes to the tuning side of things because it’s through the tuning that the people can enforce the big transformation of an organization. There are a certain number of tools that are becoming the flagships in such a transformation. For sure Git is probably the main one, the most visible one and you know why? It’s simply because Git is the promise of collaboration between the development teams. It’s all about what we use to call optimistic logs in the sense that developers have a certain autonomy in the development process, so they can pick up a component like that on the fly regardless of whether this component has already been modified by another team. But at the end of course there will be some conflict resolution with the merge capability and this methodology that does exist within Git that is a key element, because we are talking about the parallelism of changes. Another key set of tools is the continuous integration tools, because you need some tools in order to add some subsequent phases in the development process. Let’s not forget ticketing and project management, which is giving the upper management the complete traceability of what is going on and what is currently being changed, and what is the status of each and every user demands.
Charlie: So it really is much more than just Git. It really is, again, an entire management system with CICD, Git repositories and ticketing, task management, task reporting, things like that.
Philippe: Exactly. We are talking about software supply chain in the sense that we are going to automate as I said all the different phases, automate as much as possible and all the way from any kind of request down to the final phase, which is the transfer to production.
Charlie: You know what you’re describing to me Phillippe sounds like on the surface something that only big companies would typically use, but I think you’ll agree that what you’re describing here really is a requirement for any size shop, whether they have one developer or a team of hundreds or maybe even thousands.
Philippe: Yes, I definitely confirm because it’s an amazing movement and it’s becoming a strong standard in the way of developing software, and it sort of make sense not to relate it to the size of the company. That’s the new norm in the way of development.
Charlie: It’s more of a process. That’s something we should talk about, the size of the company, but just it’s a process—a modern process of management.
Philippe: Exactly.
Charlie: And again, you mentioned also it’s not just even management of projects or tasks and changes but even automated testing, things like that.
Philippe: Oh yes, for sure. Automated testing is a key element in the process because if you keep this phase manual, for sure you will face a bottleneck during the process. So for sure that is why there is more and more awareness around how to automate the testing phase.
Charlie: That’s true. I know a lot of things that get rushed to production without thorough testing, and I read somewhere once that the cost of fixing a bug before it goes into production is far less than once it’s actually promoted and in the production environment—the cost of the same error.
Philippe: That is something that has existed many years now, if a bug that is detected in development costs 10 in the testing phase, once it is discovered in production it costs 100. So there is a movement called shift left—it’s all about moving the testing phase as close as possible to the development side of things in order to optimize the software quality.
Charlie: You know the other thing I hear all the time is that even the term DevOps does not really fully describe this whole process, because we can’t ignore security. A newer term is DevSecOps which includes security. How does security play into this equation here?
Philippe: It has become a key element because of course in software they may have some vulnerabilities in the code and in order to secure the change process, people have to be equipped with a certain set of tools that will permanently check those potential vulnerabilities in the code that may have been introduced during such a change process. This typically has become an enormous side in the DevOps movement. That’s why we are talking about DevSecOps now.
Charlie: You know the other thing, you mentioned it earlier, and that’s continuous integration, CICD. That’s an important thing but doesn’t that not require a whole new methodology? I mean we talk about different methodologies, we talk about waterfall and Agile, and you can’t have CICD in a classical waterfall methodology. It doesn’t work in that environment.
Philippe: Well we tend to oppose this notion of waterfall with DevOps because waterfall is a little bit outdated right now because it’s too siloed. It’s too strict and it does not correspond to the way of doing software development now in the sense that people need much more parallelism—and again, this is related to the adoption of Git, which is the best support of high parallelism in terms of development and all the way down to the production side of things.
Charlie: Right. And with Agile, that gives me the ability to put smaller changes more frequently into the application, so that makes for better testing, better management—better user acceptance too, I would imagine.
Philippe: Yes of course because if you deliver faster, you have a better iteration with the end users and you have much quicker feedback. So you can permanently adapt what you are developing for the Agile development and you are sticking permanently to the business requirements.
Charlie: If there’s a company today who does not have a formal DevOps policy in place or even the tools to do that, one thing they may be looking at because any project of this undertaking requires it—they want to look at a return on their investment, things like that. So are there any particular metrics that they can look at—you know, from before and after—that they can measure the success of the DevOps implementation once they have it in production?
Philippe: Yeah there is an enormous number of different metrics that can be put in place, but in my opinion you can easily measure the value of DevOps by measuring the frequency of changes, but most on top of it is the number of incidents after each and every transfer to production. It’s definitely the main one and to be clear, Google had an initiative called DORA. DORA is a way to measure the level of maturity an organization may have embracing DevOps. People can just type DORA on internet and you will find a set of questions. It’s a good way to measure this kind of progress, but what people are saying mostly is they have much more reliability after each and every transfer to production. Even though they are increasing their change rate, at the end they also have much higher reliability of what they are developing.
Charlie: Interesting. What about companies who are shifting or considering shifting more to a cloud-based system—or platform, I should say. How does DevOps really play or intersect with that environment?
Philippe: Okay, so now two different things that I would like to share with you on that one. On one end, you know that the world is becoming more and more hybrid. What does that mean? It means that in terms of infrastructure, people now realize that they can get the high value of combining a data center with a public cloud or even private cloud. It’s also related to application architecture—you know that there is a front end developing in any kind of web technology that can be combined with a back end on the data center with legacy systems, and in between of course there is this set of web services that is ensuring the connection between the two. So for sure as soon as you have this kind of infrastructure, it’s important to embrace a DevOps strategy because it’s thanks to DevOps that you are becoming quite independent from the infrastructure side of things. So that means as soon as you have a set of change, it may impact both the back end and the front end at the same time and you can deploy everything in using one single process to push into the proper infrastructure side of things. So that’s my first answer, but beyond that, we see some companies that are now fully cloud-based, and you know that the main showstopper in embracing DevOps is definitely the lack of competent resources on the ground and DevOps leaders are definitely very rare and particularly costly. So therefore for a smaller shop, consuming a pre-built DevOps—well, CICD pipeline—definitely makes sense because at the end the premise is to have just connect to this remote system in order to have the construction of such a CICD pipeline right on the fly.
Charlie: You know one thing that comes to my mind, Phillippe, is I hear what you’re saying and I’m starting to envision that this is a market that really has some very exponential growth. It sounds like the size of this market is huge. What are your thoughts on that? How big is this market right now? Do you have any metrics on that and maybe even the growth prospects of this?
Philippe: Yes, I have some numbers. So in 2021 this market was weighted at $1 billion.
Charlie: A billion?
Philippe: A billion, yes—
Charlie: Wow.
Philippe: And supposed to move up to $60 billion by 2030. So that does represent an average annual growth of about 20%. So you can see that we are not just in a new marketing wave. It’s much more than that. It’s a deep transformation on the way the IT organizations are managing the development process.
Charlie: Wow. Another thing that comes to my mind—you know you talk about this 20% growth, which is stunning to me, but we can’t ignore nor should we the newest technologies, and I’m talking about things like artificial intelligence. How does that play into this?
Philippe: Aha, good question. Yes, for sure the AI will have a major impact in DevOps on different areas. Typically we have to talk about the value it will represent in the future and increase the productivity of developers, but even beyond that, if we are positioned in the legacy system, you know the main issue for any company is about the knowledge of this huge amount of source lines already written by many developers behind the scenes. So for sure AI will play a major role in the code assistance and for me, it’s a revolution that we are living there because up until now if you look at legacy systems, the main showstopper is that we don’t have any more resources that are pertinent in the functional knowledge of those systems. So what is the option? Let’s put everything into the garbage can. But now it’s a different story because thanks to AI, any kind of new resources being onboarded can be really pertinent and productive like that on the fly. So that’s for the Dev side of things, but AI can be also introduced in the production side of things—it’s already used and this is called AIOps. You know when you have a critical system, you need to have very strict control of what’s going on, and AI can analyze all the different logs and can provide of course the related proper answering in order to fix any kind of issue that people may have in the running of the application. So it’s really critical and it’s a big revolution in the DevOps area.
Charlie: So you mentioned that new term right there: AIOps. I suspect this is going to be a term that we hear over and over again in the future.
Philippe: Exactly, yes for sure. I confirm. AIOps is a big thing.
Charlie: It’s just amazing to me how AI—you know, two years ago—was not on nearly anybody’s radar or not the way it is today, and today it’s the only thing everybody’s talking about it seems.
Philippe: Yeah, it has been highly democratized and thanks to this democratization now, people are not anymore afraid of it. That’s the key element, and it’s spread throughout different areas in the IT landscape for sure.
Charlie: Absolutely.
Philippe: Definitely IT will take major advantage of such new technologies.
Charlie: You also mentioned the term legacy. We use that word a lot, legacy, but I know even people who still have maybe legacy thinking. They sometimes think DevOps is more just change management, but I know there is just so much more to that. Specifically, I guess where does DevOps extend what we consider a more traditional change management system?
Philippe: Yes, in legacy systems, we are now using this terminology of change management. What’s the difference between DevOps and change management? Well change management is related to the way we used to work before. With DevOps a system was completely waterfall and completely silo‘ed but now we are working on a different platform with different technologies and we’ve multiple teams. This is where DevOps is progressively replacing this way of working.
Charlie: So now I want to turn this conversation into more of an IBM i shop that maybe or that is considering adopting this technology in a much more meaningful way. First of all, how does somebody get started with this in an IBM i shop specifically, and also what kind of challenges have you seen in the past that people have and how do they get around these challenges?
Philippe: Well the main challenge in the IBM i world is a natural reluctance to change of existing native teams simply because in fact we are talking about teams who have not changed anything since the last three decades, so it’s normal that there is this kind of reluctance. They don’t understand why they should change their habits because up until now things were working fine. In fact, it’s now about explaining that no one is here forever and any company has to ensure the sustainability of its IT organization and set up a long-term plan for that. So all of this to say that those guys are here. They did a good job so far but they will not be there within the next 10 or 15 years, and so this is where in fact embracing DevOps is ensuring the future of existing legacy applications.
Charlie: And not too short of a time—or not too long of a time, I should say—you do recognize some immediate benefits from adopting this new methodology.
Philippe: Well immediate—that’s not the term I would use because it’s I would say a deep transformation, and for each and every deep transformation it may take quite a long time. Because it does require a lot of mind shift and there is this methodology of selecting the people who are the most motivated in absorbing this kind of change, and these champions are going to be the ones who are going to pull the rest of the team.
Charlie: So you talk about implementing new changes, but sometimes the hardest thing to change is just people’s mindsets. What do you think about that?
Philippe: Yes, three components in the DevOps transformation: People, process, and tools. What is the most difficult to deal with is definitely people, because as Albert Einstein used to say, it’s easier to destroy an atom than a preconception.
Charlie: That’s a pretty bold statement to make, but I think it rings true even today. Absolutely that’s true.
Philippe: We’ve even said in fact there are some ways to cope with that situation, because we couldn’t blame a set of people who have not changed their habits since the last four decades. But if at least they realize that they are not here forever and they are conscious that what they have developed for the company is valuable and they want to ensure its sustainability, they could do all the required effort in order to move in such a direction.
Charlie: Sure, I agree.
Philippe: But all of this to say that, as I said, DevOps is what is [indistinct] in that business is that it’s not only a matter of technology. It’s much beyond that and it’s for most a management issue.
Charlie: And certainly we talk about DevOps again on IBM i it perfectly contributes and plays well with Git. There’s nothing unique to IBM i that they can’t work with Git. I know a lot of people somehow think IBM i is a special system, but it’s not. It’s a server that can work completely well in a complete DevOps world.
Philippe: To a certain extent you are right, but you need to also take into account that the IBM i platform has a number of specificities and application architecture particularly, and this is where in fact it’s all about having a certain set of technology that is here to absorb those particularities in order to embrace these kind of tools which have been built at the origin from in the distributed area.
Charlie: Right because we talk about IBM i specifically, the word dependencies always comes up. I hear that when we get into the world of Git and Zowe and things like in the change management side dependencies. What does that mean specifically?
Philippe: Dependencies is typically related to the IBM i application architecture, in the sense that there are a lot of links between all different components, or if you are thinking about automating the build, the build is the creation of the compilation. This is what we used to call compilation, but now it’s the build. The build is a little bit beyond a simple compilation because it’s all a way everything that is related to. If I change something, then I have recompiled all of these different kinds of things. So it’s basically an issue of managing all those dependencies.
Charlie: And of course if we discuss IBM i specifically, again back to things like security, is there anything special about security on IBM i that we need to be concerned with if we’re going to implement a full DevOps methodology?
Philippe: Well up until now in the IBM space, we tend to imagine that there couldn’t be any kind of software vulnerability, and it’s absolutely untrue. So typically what does exist since many years now in distributed systems is, let’s say hooking up in the IBM i world, because I confirm that there are some security vulnerabilities also in the IBM i application and people have to cope with this kind of situation. So like in the Db2 system, the source code vulnerability checking is a critical piece in the development process.
Charlie: Just to kind of repeat how we started our conversation, and I really believe this in my heart. If we’re going to have a conversation with any customer on a real full scale modernization project, we do need DevOps to help manage that. It’s simply too big and there’s too many moving parts to manage this without good infrastructure in place. I imagine you of course would agree with that. You said so earlier.
Philippe: Definitely. Embracing DevOps transformation is let’s say the first step that each and every company should consider when they are considering modernizing their system, and you know why? It’s simply because the key here in such a world is the skill depression. It’s becoming more and more difficult now to find native IBM i resources unless you may find an old programmer who is 60 and above. Now the challenge is to renew the set of development teams and it’s all about onboarding those younger generations, and if you don’t go through first the modernization of the way you develop, for sure in fact those younger generations will not stay on board. The younger generation needs modern tooling, the tooling that they learn from school and they are comfortable with in order to stay and continue to maintain those legacy systems. No more, no less than that. A lot of people [claim] that it’s a challenge to have young developers writing COBOL or RPG programs. That’s absolutely untrue. They don’t care about the language. They switch from one language to another one like that on the fly, but something they are very strict on is the way they develop. So using Git, having the total freedom in the development stage and using those modern tools, that’s a key factor of success in the modernization path.
Charlie: Right, and you mentioned RPG and COBOL. There’s absolutely no reason to get pigeonholed into those two languages. There has never been a reason, but maybe more so now with all the open-source tools that are available, there’s no reason to do everything in RPG when you don’t need to.
Philippe: Exactly, yeah. It’s in evidence that as it comes to application architecture as I said earlier, there is the front end and the back end. The front end is developed with any kind of web language and the back end remains in RPG or COBOL, because we all know that the best language for the IBM i platform is and will remain forever RPG. I would add a little bit more: It’s RPG free form exactly, because once again in fact if you put a young developer in front columned RPG, it’s a bit of a challenge. But transforming this old RPG into RPG free form is something that is not painful. It’s just you press the button and you have the RPG free form available, and the characteristic of RPG free form is that it is readable therefore maintainable by those younger generations. I have many examples of that kind even in my organization; my Java developers are developing in RPG free form.
Charlie: I mean, right. Without using those modern tools and modern languages, you simply cannot keep up with today’s business requirements.
Philippe: Yes, so you can see that people have to be coherent, so when you decide to move in the direction of modernization—well let’s first have consideration of the way you develop, no more, no less than that, and when you see how big the DevOps movement is, there is no question on which direction you have to take. Embrace the DevOps transformation and you will see that there is an enormous value in the end.
Charlie: It’s all true. Phillippe, let’s start wrapping this up, but one thing I want to leave people with is the ability to do their own research after they hear you and I speaking here. What resources are out there? What would you recommend people go look at, find online, things like that, some way they can learn more about this before they begin embarking on this kind of new journey? Where should they look? Where should they be reading?
Philippe: Oh, there is an enormous amount of literature that is available on the net for sure. Typically, DevOps.com I would recommend to take a look at what it is proposed in such a website because there are plenty of players around there. But beyond that, and this is where we see that we are moving into a very mature market, there is a DevOps Institute, and if you go into the DevOps Institute, you would see an enormous load of different companies all capable of providing different kinds of training in different areas with the different angles of DevOps.
Charlie: Yeah, and the future clearly is extremely bright for this technology. It’s here to stay, and the technology just gets better and better.
Philippe: Yes. You know what is important now? There is one key word there. It’s the notion of standards. People have to move into standards, and when I say standards—so we already talked about Git. Git is a de facto standard now as it comes to source code repository, and it even goes far beyond than that because Git is used in the infrastructure side of things. This is what so-called Infrastructure as Code. So it means that typically the description of your infrastructure is made through files that are stored within a Git repository, and you know what? It’s simply for having the traceability. So even the people from the network are impacted by this Git movement. But beside that, in terms of IDE, now there is a very popular IDE called VS Code. VS Code is becoming also a de facto standard. It is lightweight IDE. It was created many years ago by Microsoft. It’s in open source, and thanks to this open source model, it has been adopted by many, many different organizations including the IBM i. And I can tell you that VS Code is on its way to becoming the de facto standard as it comes to maintaining RPG or COBOL applications.
Charlie: Yeah.
Philippe: So yes, standards. That’s the key element.
Charlie: It’s true. I agree with you on that, too. So Phillippe, I want to thank you so much for sharing your time and your knowledge on this very relevant and timely topic. Thank you very, very much for joining me here today. This has been a very interesting conservation.
Philippe: You are welcome. I am very passionate about the topic. It makes more than 30 years that I am in the same business, and it’s always a pleasure to share that passion with as many people as possible, so thank you once again for your invitation.
Charlie: My pleasure for sure. All right with that I am going to wrap this up. Thank you everybody for listening to our podcast today. Please be sure to check out other podcasts on TechChannel. Always a pleasure to speak with you and until next month everybody, we’ll see you then. Bye now.