• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Software Change Management Has To Change With The DevOps Times

    September 9, 2019 Philippe Magne

    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.

    This content is sponsored by ARCAD Software.

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

    RELATED STORIES

    ARCAD Brings Traditional 5250 Development Into DevOps Fold

    ARCAD Debuts RPG Code Checker

    Git Started With GitHub And ARCAD On IBM i

    Get Your Git On, IBM i

    What’s Cooking With IBM i On GitHub?

    7 Must-Have Open Source Products for IBM i

    ARCAD And GitHub Prepare For A Paradigm Shift

    Git Started With GitHub And ARCAD On IBM i

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags: Tags: .NET, AS/400, DevOps, Git, IBM i, Java, Jenkins, Jira, RPG

    Sponsored by
    UCG Technologies – Vault400

    Do the Math When Looking at IBM i Hosting for Cost Savings

    COVID-19 has accelerated certain business trends that were already gaining strength prior to the start of the pandemic. E-commerce, telehealth, and video conferencing are some of the most obvious examples. One example that may not be as obvious to the general public but has a profound impact on business is the shift in strategy of IBM i infrastructure from traditional, on-premises environments to some form of remote configuration. These remote configurations and all of their variations are broadly referred to in the community as IBM i hosting.

    “Hosting” in this context can mean different things to different people, and in general, hosting refers to one of two scenarios. In the first scenario, hosting can refer to a client owned machine that is housed in a co-location facility (commonly called a co-lo for short) where the data center provides traditional system administrator services, relieving the client of administrative and operational responsibilities. In the second scenario, hosting can refer to an MSP owned machine in which partition resources are provided to the client in an on-demand capacity. This scenario allows the client to completely outsource all aspects of Power Systems hardware and the IBM i operating system and database.

    The scenario that is best for each business depends on a number of factors and is largely up for debate. In most cases, pursuing hosting purely as a cost saving strategy is a dead end. Furthermore, when you consider all of the costs associated with maintaining and IBM i environment, it is typically not a cost-effective option for the small to midsize market. The most cost-effective approach for these organizations is often a combination of a client owned and maintained system (either on-prem or in a co-lo) with cloud backup and disaster-recovery-as-a-service. Only in some cases of larger enterprise companies can a hosting strategy start to become a potentially cost-effective option.

    However, cost savings is just one part of the story. As IBM i expertise becomes scarce and IT resources run tight, the only option for some firms may be to pursue hosting in some capacity. Whatever the driving force for pursing hosting may be, the key point is that it is not just simply an option for running your workload in a different location. There are many details to consider and it is to the best interest of the client to work with an experienced MSP in weighing the benefits and drawbacks of each option. As COVID-19 rolls on, time will tell if IBM i hosting strategies will follow the other strong business trends of the pandemic.

    When we say do the math in the title above, it literally means that you need to do the math for your particular scenario. It is not about us doing the math for you, making a case for either staying on premises or for moving to the cloud. There is not one answer, but just different levels of cost to be reckoned which yield different answers. Most IBM i shops have fairly static workloads, at least measured against the larger mix of stuff on the public clouds of the world. How do you measure the value of controlling your own IT fate? That will only be fully recognized at the moment when it is sorely missed the most.

    CONTINUE READING ARTICLE

    Please visit ucgtechnologies.com/IBM-POWER9-systems for more information.

    800.211.8798 | info@ucgtechnologies.com

    Article featured in IT Jungle on April 5, 2021

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Guru: I’m A Number, You’re A Number, Everybody’s A Number Talking Digital Transformation With The New And Prior CEO

    Leave a Reply Cancel reply

TFH Volume: 29 Issue: 49

This Issue Sponsored By

  • Maxava
  • COMMON
  • RPG & DB2 Summit
  • WorksRight Software
  • Manta Technologies

Table of Contents

  • Talking Digital Transformation With The New And Prior CEO
  • Software Change Management Has To Change With The DevOps Times
  • Guru: I’m A Number, You’re A Number, Everybody’s A Number
  • IBM And Inspur Power Systems Buck The Server Decline Trends
  • IBM i PTF Guide, Volume 21, Number 35

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • Query Supervisor Gives Database Engineers New Power
  • IBM Unveils New and Improved IBM i Services
  • 3 Takeaways from the 2021 PowerTech Security Report
  • Four Hundred Monitor, April 14
  • IBM i PTF Guide, Volume 23, Number 15
  • Big Blue Unveils Spring 2021 IBM i Technology Refreshes
  • Thoroughly Modern: Innovative And Realistic Approaches To IBM i Modernization
  • Guru: Web Services, DATA-INTO and DATA-GEN, Part 2
  • Back To The Future With A New IBM i Logo
  • IBM i PTF Guide, Volume 23, Number 14

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2021 IT Jungle

loading Cancel
Post was not sent - check your email addresses!
Email check failed, please try again
Sorry, your blog cannot share posts by email.