Learning To Drive Fast On The DevOps Roadmap

January 31, 2022 Andrew Ireland

Maturity doesn’t come with the passing of time, but with experience, whatever age you may start doing something. So it is with DevOps. In many ways IBM i teams have been ‘ahead of their time’, deploying small code increments to production fast and often. However we are seeing that requirements in integration and hybrid cloud are pushing the boundaries in DevOps transformation, and that to avoid costly, high-risk migration projects in the future it is important to act now and start taking further steps on that IBM i DevOps maturity journey.

Full DevOps maturity depends on sharing development methods and tools across all platforms to ensure easy collaboration between experienced developers and those new to IBM i. Yet for DevOps to succeed, a ‘hybrid’ way of working is needed, allowing access to the same tools from each team’s preferred interface and IDE. Of course, there is no one roadmap for DevOps maturity and each organization will prioritize different steps on the journey. With a progressive approach based on the use of industry-standard tools shared across the enterprise, each individual step will demonstrate a measurable ROI.

Many of the DevOps technologies that everyone should be using were developed and deployed first by the Internet titans, particularly hyperscalers and cloud builders like Google, Amazon Web Services, Microsoft, and IBM, as well as by large open source software projects like the Linux operating system itself. These companies operated at such a vast scale on distributed systems, largely based on clusters of X86 servers, at such a pace to run myriad data analytics and systems of engagement that were mission critical for them. The critical part was not just creating the programs and make sure they ran well, but to introduce new features and functions fast and be able to fix them fast because breaking things is part of the culture. The good news is that these same DevOps technologies can be used to create and maintain mission critical applications at companies that do not want to break things but also who want to automate, streamline, and vastly improve their operations. This is the same as Formula 1 race car technologies such as fuel injection or disc brakes eventually making their way into pickup trucks.

As is the case with any endeavor in life, you need a roadmap to tell you where are and figure out where you are going and how you might get there – and at what pace. The adoption of DevOps 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 are seeing the teams outside of the IBM i platform driving the IBM i team to use DevOps tools like GitLab, GitHub, Jenkins, and Jira and to adopt new ways of code development.

To help everyone on their path to modern coding, we have put together a whitepaper that outlines the DevOps maturity roadmap, which you can download here. But we thought we would talk a bit about it here to whet your appetite.

The purpose of the DevOps maturity roadmap is to help you identify where you are. Maybe you are starting to adopt agile practices, maybe you have small, robust teams, maybe you are starting to automate parts of the application lifecycle. But the one thing that is absolutely critical is that you don’t treat a roadmap as leading to an absolute destination. The most important thing to realize is that everyone is on a journey, and that the DevOps roadmap doesn’t have an end. This is as equally true of the hyperscalers, major software companies, and major open source software projects in the world as it is of IBM i shops. But what you need to do now is to start automating parts of the application development workflow, and then start measuring all parts of the application development process so you can then look at the entire pipeline and optimize those processes to make it all more efficient. The goal is to deliver high quality software that meets the business objectives into production as quickly as possible — and this is the only way that it can be done.

Once you start automating with the right tools, your measurements help you understand where the bottlenecks are in your development and operations. It could be that it takes an average of eight days before a trouble ticket is picked up by anyone. It could be that code gets pushed to user acceptance testing, or UAT, and sits there for three days. In many cases, to fix a bottleneck, you can automate parts of the process, and that automation will free up time for developers and testers to take on the things that can’t be automated. Or the company may just have to add more testers or business analysts or programmers.

The point 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 drive through the stages of development. We have identified five stages of DevOps maturity, and each of these stages drive a widening gap between the cost of programming and the value it delivers, with the first stages being about eliminating waste and the later stages about driving efficiencies and increasing agility, has the effect of increasing the amount of code a company can do and lowering the overall cost of a chunk of code.

Here are the five maturity levels, which we go into greater detail about in the whitepaper:

Maturity Level 1: This is traditional waterfall practices, which have centralized change management, large periodic feature releases, and often green screen tooling with developers having their own custom toolkits. There is constant tension between development and operations about system resources, and pressure on developers to deliver incremental changes rapidly juxtaposed against conflicting pressure on operators to maintain high levels of availability and continuity.

Maturity Level 2: This is a transitional phase, where the IBM i team knows that DevOps will deliver return on investment, and help get work done – and during office hours, too. Teams working on distributed X86 systems prove this, and encourage the IBM i team to join the DevOps factory. Programmers start using graphical IDEs and adopt some automation to test and analyze code.

Maturity Level 3: This is the managed phase, where the IBM i shop has adopted agile practices, with teams organized around pods and performing scrums. There is robust automation of application analysis, testing, building, and delivery.

Maturity Level 4: This is the measured phase, where companies have automated tracking and measuring (that is, Jira) and blockers are identified and removed. Adoption of 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 i shop has continuous measuring and improving through Value Stream Management, which we discussed last fall here at IT Jungle. A unified DevOps team works closely with business and reacts rapidly and effectively.

Maturity Level 6: No one knows that this is yet, but it is coming. . . .

Everybody knows instinctively at this point that adopting DevOps techniques and technologies will pay off, but given that everyone is at a different place on the DevOps maturity roadmap and with different skillsets in their organization, the ROI for each company will necessarily be different. That’s why ARCAD Software has created an ROI Calculator to help us, and therefore help you, figure out what that ROI will be specifically for you. This is the first measurement you will do with us, but it won’t be the most important one if you get on the DevOps roadmap and start driving your IBM i organization to the future.

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

This content is sponsored by ARCAD Software.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search