The First Step In DevOps Is Not Tools, But Culture Change

September 25, 2023 Andrew Clark

The combination and automation of application development and IT operations, commonly known as DevOps, is itself like the processes it automates – it is a process of continual change through iteration and improvement. And so, like most things in life (other than vacation, maybe), it is a journey – not a destination.

When people think about a DevOps roadmap journey, they are typically thinking about putting in some kind of DevOps tooling like git or Jenkins; this is really not the place to start – the first step on the DevOps roadmap, for most companies, is actually a culture change.

For most IBM i shops, there are these two camps: you have the IBM i people in one camp, and then the non-IBM i people – usually running Windows and .NET, or Linux and Java or Node.js – in another camp. What we often find is that the non-IBM i people already have some of these DevOps processes in place; and for the IBM i camp, what usually makes the most sense is to look at what the non-IBM i camp is doing, and to start adopting the tools and workflows that have already been adopted. What I also find is that, a lot of times, the two camps just simply don’t talk to each other – and they could begin to solve many of these problems just by having conversations among both groups.

There are a couple other things that are important as you are doing this kind of a discovery between the IBM i and non-IBM i teams. You often find that the two teams actually have code bases that sometimes do exactly the same thing – they will actually write the same function in different languages (RPG and Java, for example), which is entirely detrimental to the whole DevOps process; if you can just get both teams to work together and discover problems like this early in the process, you can obviously mitigate a lot of the problems related to dual-maintenance, etc., and you end up with an overall smaller, cleaner codebase that works much better in the DevOps pipeline.

And interestingly for those of us in the IBM i camp, a lot of times, the IBM i platform makes a lot of sense as the right platform on which to implement those functions – not the non-IBM i platforms. The IBM i platform does certain things very well – it does packed decimal arithmetic very well, it does heavy transactions very, very well, whereas the non-IBM i platforms and their languages, (Java, C#, node.js, etc.) don’t do those things nearly as well.

The way I think about it is that there are three big pre-steps on the DevOps roadmap: the first steps are things that can be done without tooling, things like documentation and the culture change that we’ve been talking about, then there is getting the tooling and workflow in place (what most people think is the first step), and then there is the advanced stuff like moving to hybrid cloud, or all-cloud or containerization of applications.

For most IBM i shops, the first step towards cloud probably involves testing; actually offloading testing from on-premises hardware, to off-premise (cloud) hardware in some form can make a ton of sense. This is not universally true, but for a lot of companies, they are paying for a box sitting somewhere, and all it does is testing, and it is only used when they are doing testing. And even with all of the subscription pricing that is coming to the IBM i platform, (which is very interesting by the way) it just doesn’t make a lot of sense to have a box sitting there just for it to be spun up for a few hours, and then not used again until the next testing cycle goes through; cloud is perfect for that kind of scenario, though. Until very recently, cloud adoption was almost impossible for Power hardware; but today, IBM, Microsoft/Skytap, and even Google offer cloud slices of Power 9 and Power10 on a subscription basis.

I also see a lot of resistance in companies toward DevOps; they say it’s too much work, or it’s too complicated. A lot of IBM i developers want to work another five or ten years, and they don’t want to learn a new way of doing things after they have worked a certain way for two or three decades.

But here is the thing: the DevOps roadmap levels the field, whether it is a playing field or a field of battle – pick you metaphor. When you talk about IT as a whole, there are surveys that show that 80% of companies consider themselves “elite” DevOps performers – that is, they produce multiple iterations a day with very low occurrence of error. Studies by DORA and other groups prove that DevOps returns a staggeringly effective ROI; almost every company adopting DevOps will see a complete ROI in less than one year, and some companies in as little as seven months. We’ve even built a “DevOps ROI Calculator”, and what has been proven over time is that DevOps ends up saving companies roughly half of what they pay their developers; so if you’re paying 25 developers an average of $60,000 per year ($1.5 million) then DevOps ends up saving you half of that, $750,000 per year! Those are staggering numbers, that companies just simply cannot afford to ignore anymore.

The transition to DevOps does not have to be difficult, and any company can start today; one of the simplest, and most important, thing that IBM i shops can do right now, is to start using free-format RPG. No one is suggesting that the IBM i team completely re-write their applications from scratch in free-form RPG – that would be expensive and crazy from a regression testing standpoint – but when they implement a new function or refactor an existing one, it should not be done in classic (fixed-form) RPG. As soon as you start moving to fully-free RPG, your code base immediately becomes more modern and readable, which lends itself to code sharing with the non-IBM i camp, and to new hires that might otherwise be reluctant to learn fixed-form RPG. This is also a great way to start modularizing the RPG code, which also allows the business functions to be pulled out from the IBM i applications and make those functions also available for non-IBM platforms. And if you want to convert your applications to fully free RPG, we have transformation tools to help automate a lot of this so it is not such an onerous and risky task as it would be if it was done by hand.

Once you’ve modularized the code, then you can begin to split out business functionality from your user-interface code; instead of those guys “on the other side of the wall” rewriting the stuff that you’ve already done, you can just expose it as APIs, maybe even as SQL user-defined functions or stored procedures. As an aside, the Db2 for i database is the most complete database I have ever seen on any platform – it has all of this great functionality where you can define the procedure in SQL, but actually call a high-level language (like RPG) to execute the function; that capability simply doesn’t exist on other database platforms. Because of that great integration, IBM i developers can easily expose programs, using SQL as a sort of “black box” that can be easily called from the other platforms. That means that both camps are working together, using their respective tooling and languages on both sides of the wall -and from the IBM i developer perspective, they not only create code for the company that runs better, but ensures that their contributions and expertise are critical to the company, which also helps to ensure the life of the platform itself.

So as you embark on your DevOps journey, consider automation and tooling as one (albeit important) brick in the edifice. Vital to your success is ensuring a cultural exchange between the IBM i and non-IBM i camps.

To learn more on the options available in IBM i DevOps:

[Webinar] BYOT – Bring Your Own Tool to the IBM i DevOps workflow

Andrew Clark is DevOps product manager at ARCAD Software.

This content is sponsored by ARCAD Software.

One thought on “The First Step In DevOps Is Not Tools, But Culture Change”

ema tissani says:

September 25, 2023 at 11:33 am

maybe counterintuitively, IBMi is one of the best platform to iterate on software dev and conduct devops.
It has a powerful concept that other platforms don’t have: the LIBL, library list.
Even in a single OS instance, this will allow, if rightly structured, if you think in “software layers”, a lot flexibility, different environments to easily test software, and immediately test a single new program along with a real environment without spawning new environments, bulk copying, with a lot of efficiency.
regarding MVC: this is promoted from the origin of the OS with a dedicated concept, the “display file”, even maybe before MVC became a thing.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search