ARCAD And GitHub Prepare For A Paradigm Shift
May 17, 2017 Dan Burger
One platform. One island. One epic story of survival. That may be over dramatizing the IBM i environment, but it makes a point about the dangers of single-platform thinking in a world that is multi-platform oriented. That thought occurred to me when I first heard that ARCAD Software, an IBM i vendor specializing in application development and DevOps, was partnering with GitHub, a collaboration-oriented software company focused on code sharing and reducing software delivery schedules.
Until locking hands with ARCAD, GitHub was missing an IBM i integration point and ARCAD was relying on Rational Team Concert (RTC) for its multi-platform door opener. Both organizations realized they needed one another after a mutual customer put the idea in their heads.
ARCAD brings to GitHub the specific analysis and build and deploy technologies needed for efficient business application development on IBM i. Meanwhile, GitHub enhances the ARCAD DevOps suite with modern collaborative tooling used by a rapidly growing community of developers. ARCAD promotes DevOps as its greatest strength.
The need for cross-platform collaboration has fueled the growth of GitHub, which provides the framework for sharing source repositories with its GitHub Enterprise offering that is available on-premise or in the cloud.
The main benefit of GitHub Enterprise is that members can follow each other, rate each other’s work, receive updates for specific projects and communicate publicly or privately. It encourages innovation through developer experimentation followed by peer review. Collaboration is good, but only if controlled by a managed workflow. Think of it as a team with a game plan compared to team with no plan and a lot of widespread panic. The partnership between GitHub and ARCAD can be boiled down to workflow integration.
It’s the Wild West with a sheriff and posse keeping things from become too wild.
ARCAD will become a reseller of GitHub Enterprise technology.
Historically, IBM i shops have been isolated from other development cultures due to the specific nature of IBM i technology, ARCAD CEO Philippe Magne expressed concern about that isolation during an interview with IT Jungle at the COMMON Annual Meeting and Exposition last week in Orlando, Florida.
“This is a real danger for IBM i customers, who are now struggling to find staff with the skills to maintain their business-critical applications,” he says. “The partnership helps safeguard companies’ investments in IBM i by extending the lifetime of in-house developed software. From a longer-term perspective, the combined tooling improves software quality and opens IBM i software maintenance to a new resource pool.”
When companies began replacing RTC with GitHub, it quickly gained the attention of Magne. ARCAD began a partnership with IBM RTC a few years ago, for the same reasons it is now partnering with GitHub. RTC was an attempt to unite multiple development platforms and ARCAD became the IBM i integrator. It looked good on paper, but RTC was overly complex and expensive compared to GitHub, where open source tools are familiar to a greater number of developers.
The GitHub/ARCAD combination is already proven at some of the largest IBM i customers worldwide, according to Magne. “We are seeing a paradigm shift in development that will guarantee the IBM i community a new generation of resources in the future,” he says.
Alex Purkiss, a strategic alliances executive at GitHub, says some companies are using RTC and GitHub together. “It doesn’t have to be one or the other,” he says. “RTC has a Git component that it plugs into. It uses GitHub for collaboration and transparency. RTC works well in environments that are command-and-control driven and where there are siloes where only certain people should see certain things. GitHub takes the approach that everything should be open. The more people can learn about what’s going on and why certain decisions are being made, it allows greater efficiency.”
From a regulatory compliance standpoint, GitHub creates a continuous record of decisions that were made and not made. It’s a record that remains regardless of whether people rotate into and out of teams or leave the company.
Both GitHub and RTC are integral pieces of the DevOps strategy that’s a distant but admirable goal for most companies. The idea of multiple development teams working together with common tools and a big picture objective is should be as easily done as said, but it remains a work in progress.
“There are a lot of developers on the i who started as strictly an i developer and later adopted other languages. PHP to provide an interface, for instance,” says Jeff Tickner, a member of ARCAD’s technical team. “They shouldn’t have to do two different developer processes.”
The philosophies about building software are the same regardless of the development environment, Tickner says.
“The core tenants that make a good developer on any platform are the same,” he says. “Developers sharing content from multiple repositories and commenting on each other’s code and creating a release artifact that is joined at the hip is the goal. It may be released in the database or in RPG. And it might be consumed in a Java microservice, before it goes to a Windows mobile device. Knowing all those things can be released in harmony, at one time, in a unified manner is a big step forward.”
“The genius of Git is in its distributed branching model, which encourages you to have multiple local branches that can be entirely independent of each other,” Magne says. “Managing these individual lines of development is extremely fast on everything from small to very large projects. But raw Git lacks a GUI and some basic tools that IBM i developers are used to, like visual source compare and merge. GitHub added a collaboration layer and outstripped its competitors to become the world’s largest development community today. The future young generation of developers on IBM i will come from this community.”