Learning to Drive Fast on the DevOps Roadmap

January 31, 2022

Andrew Ireland

Maturity does not come with time, but with experience, at whatever age you can start doing something. The same is true with DevOps. While programmers at many IBM i stores know how to create great programs that beautifully encapsulate the operations of the companies they work in, leveraging both coding and industry skills, that doesn’t mean that they are aware of all modern techniques. and tools to manage the process of building, promoting, and maintaining apps called DevOps.

In fact, for most IBM stores, programmers are mature and DevOps is either non-existent or not maturing fast enough. But there is a way to accelerate the transition from legacy tools and old, largely manual techniques to a modern DevOps process. To make the app development process mature faster, so to speak.

Many DevOps technologies that everyone should be using were first developed and deployed by Internet titans, especially hyperscalers like Google, Amazon Web Services, Facebook, as well as large open source software projects like the Linux operating system itself. These companies were operating at such a large scale on distributed systems, largely based on clusters of X86 servers, at such a pace that they were running a myriad of data analytics and engagement systems that were critical to them. The critical part was not just creating the programs and making sure they worked well, but introducing new features and functions quickly and being able to fix them quickly, because breaking things is part of the culture. The good news is that these same DevOps technologies can be used to build and maintain business-critical applications that don’t want to break things, but also want to automate, streamline, and dramatically improve their operations. It’s the same as Formula 1 race car technologies such as fuel injection or disc brakes that eventually find their way into pickup trucks.

As with any endeavor in life, you need a roadmap to tell you where you are and where you are going and how you might get there – and at what pace. DevOps adoption by your programming team is no different. Everyone is at a different place in the IBM i market, but ultimately they are all trying to get to the same place. Increasingly we see teams outside of the IBM i platform, typically running Linux or Windows Server platforms, pushing the IBM i team to use DevOps tools such as GitHub, Jenkins and Jira and to adopt new methods of code development.

To help everyone on the path to modern coding, we’ve put together a whitepaper outlining the DevOps Maturity Roadmap, which you can download here. But we thought we’d talk about it a bit here to whet your appetite.

The purpose of the DevOps maturity roadmap is to help you identify where you are. Maybe you’re starting to adopt agile practices, maybe you have small, robust teams, maybe you’re starting to automate parts of the application lifecycle. But the one thing that’s absolutely essential is that you don’t see a roadmap as leading to an absolute destination. The most important thing to realize is that everyone is on a journey and the DevOps roadmap has no end. This is as true for hyperscalers, large software companies and large open source software projects around the world as it is for IBM i stores. But what you need to do now is start automating parts of the app development workflow and then start measuring all parts of the app development process so you can then look at the entire pipeline and optimize these processes to make it more efficient. The goal is to build better software faster and get it into production faster, and that’s the only way to get there.

Once you start automating with the right tools, your metrics help you understand where the bottlenecks are in your development and operations. It may take an average of eight days for a trouble ticket to be retrieved by anyone. The code may be pushed to User Acceptance Testing, or UAT, and sit there for three days. In many cases, to solve a bottleneck, you can automate parts of the process, and this automation will free up time for developers and testers to take on tasks that cannot be automated. Or the company may simply need to add more testers or business analysts or programmers.

The thing is, with the right tools, you can figure this out, once you have them in place, and gather a bit of data about your programming and operations workflow.

But the first thing you need to do is figure out where you are on the DevOps maturity roadmap, and then figure out how fast you want to move through the development milestones. We have identified five stages of DevOps maturity, and each of these stages leads to a growing gap between the cost of programming and the value it delivers, with the early stages focusing on eliminating waste and the later stages on improving efficiency and increased agility. effect of increasing the amount of code a company can do and reducing the overall cost of a piece of code.

Here are the five levels of maturity, which we detail in the white paper:

Maturity level 1: These are traditional waterfall practices, which have centralized change management, large periodic feature releases, and often green screen tools with developers having their own custom toolkits. There is constant tension between development and operations over system resources, and the pressure on developers to quickly make incremental changes is juxtaposed with conflicting pressures on operators to maintain high levels of availability and continuity.

Maturity level 2: This is a transition phase, where the IBM i team knows that DevOps will provide ROI and help get the job done – and during business hours too. Teams working on X86 distributed systems prove it and encourage the IBM i team to join the DevOps factory. Programmers are starting to use graphical IDEs and are adopting some automation to test and analyze code.

Maturity level 3: This is the managed phase, where the IBM i store adopted agile practices, with teams organized around pods and carrying out scrums. There is robust automation of app analysis, testing, building, and delivery.

Maturity level 4: This is the measured phase, where companies have automated tracking and measurement (i.e. Jira) and blockers are identified and removed. Adopting distributed change management with Git.

Maturity level 5: This is the Optimized phase, where achievements are visible, bottlenecks are eliminated, handoffs between team members are automated and tracked, and the IBM Store ia continuous measurement and improvement through value chain management, which we discussed last fall here at computer jungle. A unified DevOps team works closely with businesses and responds quickly and efficiently.

Maturity level 6: No one knows that’s still the case, but it’s coming. . . .

Everyone instinctively knows at this point that adopting DevOps techniques and technologies will pay off, but since everyone is at a different place on the DevOps maturity roadmap and with different skill sets in their organization, the return each company’s investment will necessarily be different. That’s why ARCAD Software has created a Return on Investment Calculator to help us, and therefore help you, determine what that ROI will be specifically for you. It’s the first step you’ll take with us, but it won’t be the most important as you commit to the DevOps roadmap and start leading your IBM i organization into the future.

Andrew Ireland is Global Alliances Manager and DevSecOps Business Manager at ARCAD Software.

This content is sponsored by ARCAD Software.

RELATED STORIES

Expanding fields are a bigger pain in the neck than you think

Value Stream Management: Bringing Lean Manufacturing Techniques to IBM i Development

Unit Testing Automation Hits Shift Left instead of Ctrl-Alt-Delete Cash

It’s time to do an app health check

The new economy presents new opportunities for IBM i

Building web services APIs can be easy on IBM i

Jenkins approximates IBM i hooks, courtesy of ARCAD

DevOps transformation: Engage your IBM i team

The omniscient and benevolent dictator of the code

Software Change Management Needs to Change with the DevOps Times

Attention Synon users: You can automate your migration to RPG Free Form and DevOps

Git started with GitHub and ARCAD on IBM i

A repository to govern source – and object – code

Data should be anonymized for development and testing

Getting progressive about regression testing

Transforming the art of code and the face of IBM i

About Jon Moses

Check Also

NSA, CISA say: don’t block PowerShell, here’s what to do instead

Image: Getty Images/iStockphoto Cybersecurity authorities in the United States, United Kingdom, and New Zealand have …