If you think about your mobile phone and the applications on it, most of the time you aren't even aware that they've been updated, it just happens in the background. The changes are so incremental that you just adapt to them gradually, without even really thinking about it. Why can't changes within business work the same way? Well, they can, according to Micro Focus Presales Solutions Consulting Director Paul Cripsey. "Mobile technology is driving the rapid development and evolution of applications for business too," he says.
"Another term that can be used instead of DevOps is agile development," says Cripsey. "It describes a lifecycle of continuous development that entails ongoing testing, doing bite-sized changes to applications that are more dynamic, more often."
The monolithic way of implementing change can't keep pace with the demands of today's agile ever-evolving environment, as well as the capability that's now possible and expected as a result of the cloud and Internet, says Cripsey. "You can't take five years to develop a system. By the time you've implemented it, it will be outdated and won't offer the required functionality.
"DevOps is at a stage where you could add a function a month, if that's what you need to do. You can roll out the new capability, get feedback from users and improve it and add functionality as you go along."
Some 20 years ago, companies had their own coders on site, teams of people who sat and developed applications and controlled their release. Today, developers can be located anywhere in the world. This is particularly useful in South Africa, where there's a shortage of developers. Companies need to keep pace with this new way of doing things if they want to survive, says Gary de Menezes, Country General Manager, Sub-Saharan Africa for Micro Focus.
Surprisingly, a large proportion of big business don't subscribe to agile, they still carry out monolithic releases over time in major release cycles. This approach is incredibly resource intensive, says De Menezes. "With DevOps, you can automate as much of the process as possible, even the testing is automated so it's not such a heavy lift."
He continues: "If you look at new applications on mobile phones, it's a clear indicator that people (and business) need and expect more functionality quicker than ever before."
This makes sense, when you consider that many applications are written by individuals or small companies, initial versions are launched quickly and the bugs are ironed out en route. There's no reason why an organisation shouldn't benefit from the same agility instead of adhering to the old waterfall development cycle where it takes a panel or committee to approve the next step.
Cripsey says: "Most software vendors do one major release a year, which doesn't really help customers who might need those new functionalities for most of the year prior to their official release."
De Menezes points out: "The organisation's infrastructure also needs to be able to consume those changes rapidly, there's no point in implementing agile development if the customer can't actually deploy those changes."
And therein lies the rub. All too often companies that do adopt a DevOps approach find that their legacy mainframe just can't sustain that level of agility, Cripsey says, "A monolithic infrastructure that's been around for 40 years could almost be described as anti-change as it just wasn't set up to be agile."
De Menezes says part of the problem is that in the past, companies would pick multiple vendors to supply multiple solutions that would then have to be integrated and implemented on the monolithic system, which all too often poses compatibility challenges. "The latest evolution in DevOps sees one vendor offering a whole suite of DevOps products that are already integrated, so the customer doesn't have to pick and choose different products from different vendors to implement their DevOps strategy."
Another challenge that businesses face when implementing new functionality is that the applications are developed by young, agile developers but have to be implemented by the mainframe developers, who may be at retirement age. So the app developers don't have insight into the mainframe, the mainframe developers don't have insight into agile development, possibly resulting in an implementation divide that needs to be bridged.
Cripsey says: "This is where mainframe modernisation comes into play. You want to retain all of the logic that the mainframe has acquired over the past 20 or so years, but you want to make it accessible in a way that's able to sustain the fast-changing market that's expected today.
"Modern interfaces are able to offer more productivity combined with the solid 'old' logic. This is why it's so vital that the implementation of any new, modern DevOps strategy must include the integration of the mainframe. These are no longer two separate things that can't be integrated. And this is what's holding back a large number of South African organisations from starting a DevOps strategy. Until now, it's been the mainframe versus DevOps, but this doesn't have to be the case going forward."
"There's absolutely no reason why you can't develop small, bite-sized chunks of enhancements to the mainframe and roll it out on a monthly cycle as the business needs it. If you can't roll out new functionality, you're stalling your business. A business has to stay relevant to its customers or it'll be replaced by a more agile or relevant business."
De Menezes is quick to highlight that organisations can be agile and ensure consistent user experience at the same time. "Absolutely, we can bring agility to the mainframe, implementing the cycle of constant change, user feedback and updates based on that. But at the same time you need to keep the organisation's requirements intact in terms of version control, audits, ability to rollback to prior releases if necessary."
It's key to integrate the people as well as the process in order to accommodate agile and legacy while moving the business forward. This can be done with an integrated DevOps strategy that includes the mainframe.