How to Approach the Make vs. Buy Decision for Software Infrastructure Components

Tips for balancing leverage, risk, and costs when you have a successful product in market

The Boston Consulting Group (BCG) had a great 2x2 matrix where the Y axis was doing the “right thing” vs. the “wrong thing” and the X axis was “doing it poorly” vs “doing it well.” Their main point was that when you had to drive change in an organization, the toughest box to get people to move out from is the “doing the wrong thing well! The team says we’re making money, our product has the top honors, and we’re high on the analyst’s charts, so why change?

You may need to change because the customer’s expectations have changed, the data has changed, the markets have changed or the competition has changed around you. It’s usually a sea-change event, such as when the CEO/CTO announces that they have a new initiative around big data, or your top customer(s) let you know they are leaving you to go to another vendor.

Are you facing an inflection point today with your software? If so, are you asking yourself, “Which path should I take, and how fast can I get there?”

How do you navigate the make vs. buy decisions today with multiple big data software vendors who have more offerings than ever? In this blog post, I’ll explore your choices when you have an existing product in market. Basically, it comes down to two choices: incremental change or wholesale change. Let’s explore the levers to pull and how to select partners to lean on in order to gain leverage and manage risk and costs.

Leverage your partners in order to take advantage of new technologies

Most likely, your team’s skill set is in traditional RDBMS and storage techniques, so you need to find a way to reuse those skills while getting a big data cluster up and running. Given your existing commitments and infrastructure, it’s important to choose the right data platform that will enable your existing SQL-based software and give you access to the new technologies like Spark, NoSQL and JSON documents. Leverage allows you to maintain the existing version while staffing up and driving new big data-enabled version to market.

Postponing your decision will increase your risk

I guarantee that doing nothing or waiting until later will increase your people and revenue risk. Your team knows that big data is happening, and if they have to leave in order to get in on the future offered by big data software, they will depart and leave you with a knowledge vacuum. Additionally, your customers are interested in faster queries and larger data sets that are enabled by big data; if you don’t provide them with a roadmap, they will leave as well.

Program management is key to speeding up development

With a buy decision, you are increasing your feature set and speeding up time to market, meaning a faster and more predictable program. Getting a big data program up and running will help with roadmap discussions with your existing customers, and allow you to market and capture new customers for your software. These roadmap discussions will allow your agile development team to get the right features ready early and create success.

Keep your team small and make sure senior execs support your decision

Create a small team that is empowered to investigate and make decisions on which infrastructure software to use, with ownership spread across business strategy, product strategy, and program management (execution) of the project. If at all possible, keep the number of decision makers limited to three people.

Your first key decision is whether your new project replaces your existing offering, is an extension of your existing offering, or is in an adjacent offering that can coexist. This business strategy drives your minimal viable product (MVP), your staffing, and your schedule. This decision will be driven by risks and fear of failure, and has to come from and be supported by the highest levels of the company to succeed.

You’ll come out stronger by making a wholesale replacement of your product

This decision creates focus and pressure; you will divide your team 80/20, where 80% is working on the new product. This can create personnel issues, since no one likes working on a “last revision” product, and yet you need them to deliver for your installed base. Usually this only happens if your current product has failed, or has been trumped in the market and the product crisis is well known.

It takes a strong leader to make a wholesale change when their existing product is doing well in the market. A good example of this is Adobe; they changed their business model from a licensed purchase model to a subscription model and cloud deployment. Adobe executives had to explain and manage this transition with their customers, stockholders, and the public at large. The end result is that Adobe came out stronger for making the change.

This was a BOD/CEO focus, and that strong executive support and pervasive communications about the plan, goals and metrics to all internal and external parties was the key to a successful transition to the new model.

Extend the value of your existing product by taking advantage of a big data platform

Most of you will recommend and be involved in extending your existing product to take advantage of a big data platform. Your choices range from timid to bold, where the timid approach means merely building a data transfer connector and doing some compatibility testing. This is a quick, controlled project, but offers no added value or differentiation.

A bold decision is where you explore and take advantage of what a big data platform offers, so that your existing product is 10x more valuable to the customer. You can move from offering customers access to 90 days of data with a 15 minute SLA, to offering them 7 years of data with a 10 second SLA.

Build an adjacent product once you have increased funding

Once you have increased funding, building an adjacent product is straightforward; you can build out an agile team that’s 100% focused on a MVP goal, select your partners to gain leverage, and manage risks and costs. You can run your team like a startup by staffing it with known experts and talented new hires, creating quick revisions and multiple betas, and engaging your customers to discover the highest-value problem.

If you don’t get increased funding, maybe you should think twice about starting the project. If management does not understand and agree on the business goal and therefore does not see the value of the project, why start? You risk your existing product deliverables and your own personal MBOs, as well as your bosses MBOs.

Decision dimensions

Focus your engineering efforts on your core competency

Focus your engineering efforts on your core competency; this is what differentiates you in the marketplace. Even with Agile development, you have a fixed-size team (budget) and defined sprint times that constrain the features that are available per sprint release. Take a look Microsoft — they have re-focused their products on personal and business productivity for a mobile world, enabled by the cloud. They are not trying to build out hardware devices anymore; instead, they are focused on what they do best.

Your mission is to put a 10x product into market as soon as possible, and in the best environment. Your product should solve your customers’ problems that they are willing to pay for. Look to your big data platform partners to decrease your risk, speed up development, and give your team leverage.



Ebook: Getting Started with Apache Spark
Apache Spark is a powerful, multi-purpose execution engine for big data enabling rapid application development and high performance.

Streaming Data Architecture:

New Designs Using Apache Kafka and MapR Streams




Download for free