This is the first in a three-part series.
Over the past five years, I’ve spent a lot of time with executives having them question me about how other companies and their competitors are navigating DevSecOps. This series shares how to introduce a DevOps platform into your organization to support DevSecOps.
Realizing the need for DevOps
When I was at GitHub, I had a partner at Accenture who provided me with a great definition of DevOps that I still use today: “It is the combination of agility, collaboration, and automation that drives DevOps.” This struck a chord with me because at the time execs were “promoting” DevOps with Jira, GitHub, and Jenkins. They just needed to form a DevOps team to manage these products and provide the integration between them. Then they could mark DevOps off their KPIs for the next year and move on to the next set of challenges.
Unfortunately, this only created more challenges. Tying these products together required a significant amount of work and the people in charge of this integration were usually operations folks or consultants who were more familiar with business continuity plans, standard operating procedures, high availability, and disaster recovery than writing custom code to provide a better experience for users.
They needed functionality that would capture metrics for team leads, managers, and executives so they could understand how the platform being built was driving customer adoption, increasing revenue or reducing costs. But capturing metrics meant engineering work that led to internal dogfooding. Also, people new to the field of platform engineering were not happy with the solutions they were presented with.
The entire process led to new evaluations of different products and additional stakeholders. We started managing infrastructure as code, testing tools, security, and deployment tools as part of this solution. We were no longer just building integrations, we were building a developer platform or what most of the executives I talked to called a “Developer Self-Service Platform.”
The cost of disparate DevOps tools
The executives I talk to now know this story as they were probably in charge of building this platform five years ago and have since been promoted to own more than just the tooling: Today they’re in charge of site reliability, cloud adoption, or platform engineering. Their teams have anywhere from 10 to 50 different tools, each with their own unique use case. The challenge now is to leverage these tools in a way that they were never intended to be used.
Executives need data and analytics to optimize their business. This means collecting the data from all of the tools in a meaningful way where they can build analytical models for them to budget, plan, and report on the state of the business. I know of five Fortune 100 companies that have been on this path for more than three years and are still waiting to provide the first dashboard to their executive teams.
These companies have easily invested “eight figure” budgets to account for the people, process, culture, and tooling changes required to try and make this work. The total cost of ownership could total more than $10 million when you look at the department's profit and loss statements. The return on investment would take over five years if the team is able to generate or reduce costs by an additional $5 million a year in new revenue with a fully integrated platform that is live today.
Unfortunately, people realize quickly that just extracting the data from the tools is not enough. There is context in the conversations that drives real-time decisions and those nuances often don’t make it into the analytical stores. The end result can be knee-jerk business decisions that can be detrimental to the business for years to come.
Understanding DevOps platform requirements
Let’s begin with a simple question: Do you have requirements for this platform? You are about to embark on building an internal platform for your company. You want to leverage your intellectual capital and experience to drive innovation and create efficiencies that allow you to more effectively run your business for years to come.
If you don’t have requirements, you should start with a value stream assessment to create them. This value stream assessment looks at your lines of business, the processes used to create artifacts, and the time it takes to get those artifacts to a place where they can be used to generate revenue, retain existing customers, or generate business efficiencies.
Once you have these metrics, measure the time from initial sourcing of the need to the number of people required to touch the artifact and ensure the quality and security of it as it moves across different environments. Divide that result by the time it takes to go from initial change to a production environment.
The more touchpoints in this process, the more costs will increase and so will the risk of software supply chain issues. Think of this like an assembly line: The hand-offs between touchpoints will require you to implement quality frameworks like supply chain levels for software artifacts to ensure chain of custody for audit and compliance needs. These challenges just keep getting bigger as you try to add additional tools to this platform.
Is it possible to meet all of your requirements with a single product? Try GitLab to see what requirements we can help you meet. The only way to start capturing ROI is to stop building your platform today. If you don’t stop building it, you are still capturing costs and every tool you add chips away at the economies of scale. You can think of every new product as one input and one output. This means to go from four tools to five tools you are adding an additional 100 connections to be integrated together. It takes engineering time to properly integrate a product into the overall software supply chain instead of consuming the capabilities as a platform-enabled service that you can use out of the box to meet your requirements.
If you are interested in learning more about doing a value stream assessment – or if you have done one and looking for ways to build efficiencies inside your organization – please let me know and we can work together to help make the best choice for your organization, even if it means continuing with a platform you already started building.
In the next part of this series, we will look at how different vendors define the term “platform” and their motivation behind helping you achieve your requirements.
