Would you commit 19 developers to building software that was already available off the shelf? Especially if I were to tell you that it would cost millions of dollars more to do it yourself?
Recently, I met with a company—a large healthcare organization—that actually did this. Following a demo of our XL Release and XL Deploy products, the Development Manager turned to me and said: “That’s good, but we’ve already built-it.” That struck me as a bit…ambitious given all the work they have to do just to develop products for their own customers.
So after peeling back the onion a bit, we uncovered that they were using an astonishing 19 developers to create builds and deployment scripts using Jenkins. Not only that, they also needed every single one of those 19 people to manage and maintain it. Every. Single. One.
Lastly, I did a rough calculation of about how much it cost them to do the job in-house:
19@ 100,000 (USD) FTE + 1@ 150,000 (USD) FTE = 2,050,000!
This is pretty simple math, but the grand total is over 2 million dollars—just to build it.
This is not chump change. This is serious money going out the window to develop software that’s already been made and paying an obscene amount of cash for the privilege of doing so. It’s enough to send the most stoic of CFOs into apoplectic shock. And that would be the appropriate response to spending millions of dollars on software that’s already available out of the box.
It’s also unnecessary. As I discussed with the Development Manager, our products automate deployment and pipeline orchestration so you don’t have to worry about building any of that. We also give you visibility so that, with your time freed up, you can focus on figuring out what’s not working and address real problems that are inhibiting your success. I explained that, if they were using our software, they could auto generate workflows.
They could plug in the tools they’re already using, which lets them continue to use the right tool for the right job. For example, they could continue to leverage Jenkins for what it’s great at—continuous integration. They could expend their energy on revenue-generating products for their customers. And they could scale the whole thing to meet growing customer demand without the blood sweat and tears that scripting entails.
Unfortunately, like a page out of the Phoenix Project, the manager had lost focus on the company’s higher objectives, which is, of course, understandable when you’re busy overseeing a staff of 19 people. For managers, it may help to occasionally remind themselves of this fundamental rule:
DevOps = people + processes + tools for the purpose of serving customers
In fairness, this manager wanted the development team to be happy, but developers are happy when they’re building software. They are not happy maintaining it.
Lots of people think that using tools like Jenkins, Puppet, Chef and all the Open source tools to build orchestration and deploy solutions makes it free, but really, it’s not. And this company, with the 2 million worth of software development they’re putting into it is a hair-raising example of that. That figure by the way, does not include the additional hundreds of thousands per year for ongoing maintenance. It also doesn’t include reporting, which the manager of the team told me was planned for phase II.
If I were a CIO, VP of Operations, or VP of Development, I would want to know how I can build my bottom line not crush it. If just 15 of those developers were freed up to develop more software that customers will pay for, I would make damn sure they didn’t get tied up doing unnecessary internal projects that suck hard-earned revenues down the drain. Wouldn’t you?