By now, the majority of organisations will have embarked on a drive towards agile and DevOps. Traditionally, all planning, testing and releasing has been done separately using a host of different tools, many of these being open source. It’s fair to say that open source started the whole shift to agile and DevOps. However, the dilemma faced is that none of these tools integrate with each other. Each open source tool is fit for purpose for a point solution.
Gary de Menezes, Country General Manager for sub-Saharan Africa at Micro Focus, says: “The ability to move towards a successful agile methodology requires you to have enterprise-class integration from planning all the way through to deployment. Every stage, from planning and governing, testing, development, coding, user acceptance, then release of that project into a production environment needs to be integrated. If you can’t do this end-to-end, you’ll never be agile.”
The problem with open source toolsets is that they cater to a team working on a specific component, not to an enterprise with multiple teams and multiple projects in progress at any given moment. Open source works really well when it’s a small team on a single project. But, how do you control time, human resources and financial resources across multiple projects?
“When speaking to customers, I find this is a major challenge for them,” says De Menezes. “Within the same organisation you’ll find up to half a dozen different types of open source tools being used by different teams, all doing the same thing. There’s no standardisation or common practices that can be shared across the teams; they’re each doing their own thing. Each division decides what it wants to do and work happens in silos.
“This worked well in the past because it gave the organisation a level of agility it never had previously, but when companies moved towards having multiple projects running in parallel, they started losing control and quality suffered, errors start creeping into the process. So, while open source has helped customers to start achieving continuous development and continuous integration (CICD), it’s not a solution to get you on a true agile and DevOps journey, where you have different parts of the value stream of the organisation integrated.”
A lot of enterprise toolsets coming out actually promulgate that organisations must get rid of open source. “The problem is that a lot of open source tools are usually well embedded into an organisation and the business doesn’t always know how to cater for developers who want to use the software of their choice, which can make them resistant to moving across onto the enterprise software. The correct architecture is to find a healthy balance between the two, ie, open source and enterprise-class technology, which accommodates the existing investment into open source technology. If you can find the right balance, the entire organisation will move to agile a lot quicker.”
Going back to his reference to the organisation’s ‘investment’ in open source, De Menezes explains: “A lot of people think open source is free, and this is where a lot of customers become entrapped by open source. While the software might be free initially, the minute you entrench it into the organisation, one of two things happens. Either the business starts needing the upgraded support offered on the tool, which requires a hefty investment. Secondly, and more importantly, organisations have to invest a fair amount of time and skill into developing the right scripting that’s required to execute the testing you want to do.
“The challenge becomes that the customer has invested so heavily into open source that it can’t just rip it out anymore. On the other hand, enterprise toolsets may be costly to acquire upfront, but they already have the necessary scripting, etc, available, so the time to implement is much faster than using open source. This is a fundamental difference between the two.”
Paul Cripsey, Presales Solutions Consulting Director at Micro Focus Northern Europe and South Africa, says: “None of the open source toolsets is able to provide the required levels of reporting and oversight at enterprise level of multiple streams of projects; there’s no analytics across all projects and teams.”
Organisations that want to succeed in their journey to true DevOps and agile need to have an enterprise-class architecture established that does ‘shift left’ and ‘shift right’, ie, extending planning and governing on the left and extending operations management and performance testing (and release) on the right. For that to be achieved, enterprise toolsets are a requirement as they’re the only ones that can provide integration across the value stream. The successful enterprise toolset is one with building blocks that can cater for current investments into current technology, including open source.
Cripsey adds: “Open source tools predominate on the Dev part of the journey, but are less prevalent on the Ops part of the journey. The ability to automate across the value stream is a key element of any DevOps journey. Organisations allocate too much time and other resources on manual testing, which is why the automatic deployment of work coming out of the Dev environment is so important. Automation is more reliable, more effective and quicker than manual testing. If you’re going to be on a continuous Dev and continuous integration drive, automation is a prerequisite to achieve that. Robotic process automation is a part of that.”
“Enterprise-class software vendors should be in co-opetition with open source,” according to De Menezes. “They shouldn’t tell customers to rip and replace; they need to find a way to allow the business to use what works for its teams. Enterprise-class vendors should be focusing their investment and R&D into providing a solution set that incorporates links into existing assets, regardless of what they are.”
He’s advocating that competitors join forces: “This means co-creating solutions with the customer using their existing open source. The time and cost required to move a team from one technology to another is just too great, plus it requires change management, training on new skills and even then, people might not adopt and use the new technology.”
One of the biggest challenges the C-suite faces is it has no idea how to control the quality, time, budget and human resources required by each of the Dev projects within their environment. This was manageable when organisations were issuing two releases a year. However, an agile environment that wants continuous development, release and integration cycles just can’t sustain that with manual control over projects. That’s where the ‘shift left’ and ‘shift right’ drive comes in. They need better processes to plan and deliver a project, which requires automation, and therefore tools.
“Today’s philosophy is to release incremental small changes on a regular basis across multiple environments. The ability to manage agility is the management challenge of the future,” predicts De Menezes.
You can read more about succeeding on your journey to Agile and DevOps by downloading this white paper.
Johannesburg
