In our last blog post, we talked about how on-prem software for the enterprise isn’t going anywhere. This $400 billion industry dwarfs enterprise SaaS, but it doesn’t often get the attention it deserves. Let’s show it some love.Join us as we explore the biggest question of on-prem delivery and management: is it better to build your solution or buy it? We’ll start with planning for success.
Just tuning in? Go back and read Part 1: Why On-Prem Matters
Skip ahead. Get the entire series now in this free eBook.
Part 2: Planning For Success
“An hour of planning can save you ten hours of doing.” – Dale Carnegie
Although you might already have an idea of how you want to manage and deliver your on-prem software, it’s always good to grok on it first. In this part of the series, we’ll cover the major up-front factors you need to consider during the planning phase.
Cost
Buying off-the-shelf software comes with a fixed price, but building and maintaining your own solution can be much more expensive. The up-front costs are obvious: design, engineering, support, and operational costs. However, there are many hidden costs to rolling your own solution that is not easily quantified:missed opportunity costs, on-going support costs (issue triage, bug fixes), and productivity costs (pulling teams away from projects) canall create a hidden expense in terms of time and productivity. Before you fall victim to an unexpected scope creep, consider the long-term costs and labor commitments you could be signing up for if you opt to build.
Time to Market
As every engineering and product team knows, there is an inverse relationship between team size and time to market. It takes two people longer to design, build, and paint a house than it takes twenty people to do it. If you’ve got plenty of leeway in terms of your deployment schedule, an unlimited number of team members, or a tiny house to build, then developing your delivery and management solution from scratch could be the way to go. But if you need to take advantage of streamlined processes in order to build more in less time, then buying an off-the-shelf, on-prem software solution would be the fastest way to get your product into your users’ hands (ahem, servers).And that gives you a better shot at picking up more slices of the $400billion pie.
Internal Resources
Aside from the time and money part of the staffing equation, there are the logistics of building a new internal team (or tasking an existing one) to build a new software delivery solution. Will you hire full-time staff, or contract it out? It all comes down to your deployment needs and your access to a qualified talent pool.
If your in-house team already has the specialized knowledge and time available to use it, then building might be the way to go. But even if your team has time, do they know how to create a licensing system? And is that what you want them focusing on instead of other tasks?
Be More Resource-full
In many cases, buying an off-the-shelf solution and letting your team focus on your core business is a much better use of time and resources. After looking at the data from 3000 companies––including 96 that reached $1 billion in annual sales––McKinsey found that when it comes to the software business, high rates of growth are a major predictor of long-term success. That means if you want your business to succeed, you need to be prepared to grow quickly… not spend a lot of time reinventing the wheel along the way.
Business Continuity
One of the most important considerations in the build vs buy debate is the longevity of the chosen solution.Beyond thinking about the ongoing engineering hours that will be needed for development, security patches, Kubernetes releases, etc, there is the question of succession planning.
Silos of Excellence are Not so Excellent
Think about it this way: most home grown solutions are created by one or two engineers who become the experts in the systems they’re creating. This makes a lot of sense for core business logic and apps that are going to constantly evolve with a steady stream of new members onboarded. However, for ancillary systems that support the core business, these applications end up becoming a silo of knowledge. The question isn’t, “How much time will this take someone to maintain after they build it?” It’s really about, “Who will maintain this after them, and who after them?” followed by, “How will each new person learn the intricacies of the system?” If the answers to these questions aren’t clear, then you may be in a situation where buying is the best option.
That’s because a delivery solution vendor will be focusing on this problem exclusively, as delivery is their core product. In other words, part of the off-the-shelf product you’re getting is the succession plan that comes with it. Since no specific person in your organization is building the system, no single person will be responsible for it. Instead, there will be several key points of contact engaging with the platform in several ways, starting with SREs/DevOps and expanding to SupportEngineers, QA, and even Sales Engineers. Each of these functions gains some amount of user-level knowledge on how the system works, with a clear understanding that the vendor will own the ongoing improvements and extensions of the underlying system.
DIY or DIBuy?
In the next post, we’ll get into the implications of building vs buying when it comes to execution.
We’ll explore:
- Customer Experience
- Control & Compatibility
- Maintenance & Support
Hate to wait? Download our free eBook now to read it all and get started on planning for success.