Johannesburg, 29 Jan 2020
“It all comes down to release velocity and deployment automation,” says Gary de Menezes, Managing Director of Micro Focus South Africa.
The objective of agile and DevOps is to get updates into production as quickly as possible. This is easier when you’re dealing with small teams and small applications. However, when you’re doing this in an enterprise environment, the whole process becomes a lot more complicated, says Stephen James Smith, software business consultant at Micro Focus South Africa.
“If you consider a financial institution, the internal processes are traditionally slow-moving. Any software development invariably has an effect on multiple systems and applications, which means that when the business is trying to introduce updates, it has to spread the load, planning and effort across multiple teams in order to achieve a particular release with a new feature. In the back end, this type of project can touch a lot of areas, having a knock-on effect.
“In order for one new capability to be added to a core application, a lot of different things need to be orchestrated in parallel to achieve the required release, which can slow things down. You need to address release velocity from the ideation stage to the production stage, using deployment automation along the whole path. Unfortunately, automation is often just used right at the end of the process.”
De Menezes says: “A lot of companies invest skills, time and training on implementing agility at the development phase, but I don’t see those same companies adding the same level of automation and intelligence to getting those releases into production.
“We need to modernise and automate that piece of the value chain too. If we don’t, agile development is only of use to the development team because the results of their labour are going to encounter a buffer of things needing to be released into production. Legacy mentality and manual processes around handing over from development to testing to operations creates this backlog, which means that agile becomes ineffective and its benefits to developers are negated as release velocity isn’t increased.”
While a lot of processes can be automated and sped up, people still want to maintain a degree of manual control between the different environments. They want a human to check or make the final release decision instead of automating it, which is understandable, says Smith.
But there are ways and means for an enterprise to deal with that, such as by implementing requirements around freeze periods and corporate governance.
De Menezes says: “This is a challenge faced by many of our customers. As agile becomes more prevalent in development in enterprise, how do you increase the velocity of releases to end-user customers? By taking it to the next level of automation.
“There’s a tendency to automate in isolation, which doesn’t provide the desired speed and agility because you don’t have visibility into where new bottlenecks have developed. You just moved the bottleneck. You need visibility into the end-to-end landscape. Without visibility and control, you’ll start hitting problems.”
This is all too often a self-inflicted problem as agile and DevOps require autonomy and that the teams involved be given more trust and control. However, this allows team members to deploy their tool of choice, which results in a range of different open source tools that create islands of automation, with no visibility or control across all of them. This is where the enterprise requires a solution that can plug into those different islands, get visibility into what’s happening and start linking them together as far as that particular release is concerned.
Another challenge is that different blocks of work are allocated to different teams, and you want to make sure they move in parallel towards the end-goal, without encountering barriers en route. By plugging into all of the islands and providing the enterprise with visibility into what’s happening, they can track the progress of the various parts of the project and see whether enough resources have been allocated, where the roadblocks are, what the quality is like and where they are in the testing stage.
De Menezes says: “During the last six months of 2019, some well-documented and high-impact outages occurred because of just this problem. When enterprises moved from waterfall to agile or DevOps, the bottlenecks were pushed forward to the testing phase. Then enterprises started choosing tools to automate the testing environment, which in turn pushed the bottleneck towards the release phase.”
What De Menezes and Smith are both saying is that while the autonomy of teams is part of DevOps, you can’t give autonomy unless you have control. But old-fashioned controls negate the benefits of agile and DevOps. The next level in automation provides control before the update goes into production, while catering for the ensuing wave of development that’s coming from behind.
To improve release velocity, you need to employ the principle of visibility across the landscape from end-to-end and enable more control over what’s taking place.
Another knock-on effect with agile is that you tend to have an accumulation of releases piling up, waiting to be deployed into operations. But operations can be slow to release changes because they’re afraid that they’ll cause downtime. If something goes wrong, the responsibility lies with operations and they have to deal with the fallout.
In some cases, operations people have lost their jobs because of release velocity and the quality of releases. This can be addressed to some degree by giving operations visibility into what’s coming down the line.
Smith says: “Operations people are by their very nature conservative and not agile, and they find it difficult to change that mindset. It requires a catalyst to help these people change internally. This needs to be driven from C-level down into the enterprise. You need to link the whole chain together; you need incorporation into the team from the start of the process and throughout the progress.
“The solution to this problem is not only a tooling problem, it’s how an organisation structures itself from the first line of code written to the stage at which operations people need to be included. In fact, it can even go back as far as the initial proposals to business, the decisions around what’s approved to go forward, and budget allocation.
“Failure to do this can result in roadblocks because of a clash in culture between operations and developers. Developers are highly intelligent and want to move quickly, while operations are conservative and require a lot of information before reaching a decision.”
The question is: How can tools and business processes be deployed to break down those walls and ultimately improve release velocity?
De Menezes explains: “You need ensure that you relook your people and your processes, as well as your tools. While agile and DevOps are linked to tool selection, the ethos of the methodologies used also needs to change, extending across people, tools and processes, and possibly even entailing structural changes within the business.”
Click here to download a Gartner report on using adaptive release governance to remove constraints to DevOps.
Share