GitLab Makes Economic Case for DevOps Platform
GitLab is advancing its case for integrating as many DevOps processes as possible on a single platform by making available an economic analysis that claims organizations can improve application development and delivery by 87%, resulting in a savings of more than $23 million.
Based on an analysis conducted by Forrester Consulting on behalf of GitLab, the report concludes organizations can save as much as $3.7 million by reducing the number of DevOps tools they need to acquire by a factor of four.
The report also claims organizations can also see a 12x increase in the number of revenue-generating application releases in a year, resulting in $12.3 million in additional revenue, while at the same time reducing code defects to generate more than $16.8 million in savings.
Overall, the report says there is a 407% return on investment (ROI) in the GitLab platform.
GitLab has made available an online DevOps cost estimator based on the Forrester Consulting report.
Colin Fletcher, manager for market research and customer insights for GitLab, said the core GitLab platform is designed from the ground up to make every integrated tool a natural extension of the existing DevOps workflow.
IT organizations are also focusing on productivity and workflow now that it’s apparent most DevOps teams will be working from home to help combat the spread of the COVID-19 pandemic well into 2021. That shift is requiring some organizations to reorganize DevOps teams around specific development projects, he noted.
In the wake of the economic downturn brought on by the pandemic, there is also naturally a lot more focus on costs. At the same time, many organizations are trying to accelerate the rate at which applications are developed and deployed as part of a larger digital business transformation initiative. The more business processes become digitized, the more dependent organizations become on software.
The issue many IT leaders are trying to navigate is finding a way to reduce costs without forcing every member of the DevOps team to standardize on the same set of tools. While it’s arguable there are too many tools employed in a DevOps process today, it’s also clear that most members of those teams prefer to select their own tool whenever possible.
It’s too early to say to what degree IT organizations may be willing to re-engineer their DevOps processes. Most have spent a significant amount of time and effort tailoring existing platforms to fit their needs. The level of inertia surrounding existing DevOps workflows inside an IT organization is considerable, so IT leaders would have to exercise a considerable amount of political will to switch DevOps platforms. There are, however, often multiple DevOps platforms in use within the same organization. The pressure to rationalize those platforms increases in a downturn.
In the meantime, there are plenty of IT teams that have still not embraced DevOps. As the size of the DevOps market continues to expand, competition among providers of DevOps platforms is intensifying. For the average IT organization, that’s usually a good thing until a key vendor is acquired by a rival that is not as committed to a platform on which the DevOps team depends.