Embedded Analytics: Build versus Buy

Why Build or Buy

When faced with the need to add analytics to an application, most software providers arrive at the crossroads of the “should I build or buy” decision.

Why Build (or Really, Code)?

Many app developers’ first instinct is to build. They believe that they can provide the necessary reporting functionality with the help of code libraries or charting components. This may work for many, especially in the case of new software apps that have simple requirements. As organizations grow, the primary reason for taking these code-intensive approaches is to maintain control of the look and feel of the app.

What invariably happens over time is that users ask for more functionality, more flexibility in their analysis, and more methods to gain insight. They want to accomplish all of this without your help. For some customers, the thirst for data will be satiated by exporting data to a spreadsheet or extracting it through an API. Unfortunately, these outlets only satisfy the customers who are interested in doing the legwork. They do not build value into the app in a scalable way.

App providers who stay on the “build” track must commit to significant staffing resources to develop, support, and maintain data visualization and BI updates over the long term.

Why Buy?

Many software organizations are charged with adding analytics to keep up with competitors and customer needs. Unfortunately, they do not have the time or resources to build on their own. In fact, in every survey of software providers, the top reasons for embedding with a third-party solution are:

• Cost to build and maintain capabilities on their own
  It can be expensive to initially develop, then support, and continually enhance analytics.
• Need to get to market faster
  There is usually a small window of time available to satisfy customers, differentiate a product offering, and stand out in the marketplace. Time to market may vary depending on the level of requirements needed. Typically, between 30 to 50 percent of the entire project time is dedicated to researching and evaluating different components. This work is the type of exercise that has already been completed by analytics vendors.
• Desire to have internal resources focused on core application functionality
  Delivering functionality with a third party makes the development team more efficient and frees up resources for your core product.

Those on the “buy” track should understand that some level of integration will be required for embedding a third-party product, but the shorter time-to-market for delivery of analytics justifies this investment. Evaluating whether to build or buy requires a deep understanding of your desired functionality and level of integration.

Gauging the Feasibility of Build

The first step in tackling the “build versus buy” question is to understand your requirements. First, list out your desired end-user functionality, and prioritize your needs. Then, evaluate the feasibility of building such capabilities.

1. Identify Core Functionality

As outlined in the previous chapter, it is vital to understand the gaps in functionality you’re looking to fill. You can then build a map that plots out capabilities and matches users to the needed functionality.

The Features Application Providers Often Look to Implement

• Information Delivery
  • Dashboards and data visualizations
  • Reports
  • Mobile
  • Scheduling and Exports
• Interactivity
  • Linking
  • Personalization
  • Dashboards and report authoring
  • Workflow, write-backs, and processes
• Analysis
  • Visual analytics
  • Benchmarking
  • Advanced analytics
  • External data

2. Choose an Integrated User Experience

It is important to plan out how these capabilities will be embedded or integrated within the context of the overall application UX.

• Analytics module: Application providers create a report module or “tab” that appears in the framework of the app.
• Analytics workflows: To create the best UX, analytics are integrated into the workflow of the core app. When users interact with analytics content, two actions may take place. They are either directed to a specific part of the application, or back-end processes are triggered (which empower users to act on the data within the same context of their analysis).

3. Prioritize

Next, prioritize the desired functionality based on business drivers.

• Time: What features do you need now? Which features can wait?
• Impact on dollars: What capabilities will enable you to package an offering that makes the most out of data and analytics? What functionality have your customers been asking for? What types of capabilities would make clients want to stay?
• Edge up on the competition: What will make you stand out from the crowd and make it easier for you to attract new customers?

4. Determine Feasibility of Doing Your Own Coding

Finally, figure out if you can bring the functionality your customers need in a timely manner. Most app providers can carry out the most basic of capabilities on their own through things like static charts and data exports. For the more advanced and interactive, companies will often use third-party products. This allows them to launch features in a timely and efficient way.

Comparing the Benefits of Build Versus Buy

When planning your implementation, it is important to qualitatively, if not quantitatively, assess the benefits and costs of each option. At this point we bring it all together to compare the ROI on embedded analytics.

By building a cost-benefit analysis over time, you can calculate the ROI for each buy or build option. Here is the ROI formula we outlined in Part 2:

• Timeframe: Quantitative analysis for a technology investment is performed over an extended period of time, typically three to five years.
• Benefits: The combination of the strategic benefits (e.g., revenue increase) and operational benefits (e.g., cost reduction).
• Costs: The investment to develop and maintain the solution.
• “-1”: The formula assures that a positive ROI is achieved only when benefits exceed the costs.

Defining the Timeframe

It is also important to chart a timeframe. This duration should give you enough time to understand the future benefits and costs before conditions change. You don’t want to be forced to re-consider your options. For technology investments, a timeframe of three to five years is often used.

Benefits

Compared to coding on your own, utilizing a third-party product will give you access to more capabilities in less time. The faster path to value usually drives the “buy” decision. If you are building quantitative ROI models, that difference in time will show up as the breakeven point earlier in the project lifecycle.

The Advantages of “Build”

• More Control: Application departments will have complete control. They will lead the charge in the functionality, its branding, and user experience.
• Lower Hard Costs: Companies that choose to build may spend their budget on the components they need to build their own solution.
• Avoid the Vendor Evaluation Process: Research takes time. By building, companies can cut down on the time needed to meet with sales vendors. Navigating the BI market can be confusing. It is also chock full of competitors vying for your attention.
• Independence: Companies may not want to become reliant on a third-party. They may raise prices over time or fall flat with customer support.

The Advantages of “Buy”

• Faster Time to Market: Competition is tough. Companies have a small window of opportunity to add functionality. This is essential to differentiate a product offering and stand out in the marketplace. Buying is a quick fix.
• Access to Existing Expertise: Buying any software is particularly valuable when you’re looking at a known, solved-for space. A well-established market, like BI, means that buying gives you access to experts who’ve done this for years. If you have questions or need to add a new feature, this expertise can be priceless.
• Focus on Product Functionality: Buying a third-party tool frees up the development team’s time. They can focus on the core functionality of the product and provide advanced analytics capabilities.
• Lower Administration & Maintenance Cost: It is costly to build a solution. Buying a product means ongoing vendor support. Instead of using internal resources, you can get expert help in feature enhancements.

Comparing the Costs of Build Versus Buy

Investment Costs

Compared to coding on your own, utilizing a third-party product increases your cost in software licensing but reduces your cost of development, both initially and ongoingly. Your analysis should also take into consideration the opportunity cost and project risk. Your skilled development staff will be spending less time on your core product when they need to focus on analytics.

Comparing the ROI of Build Versus Buy

To some, “build” may seem like the obvious choice for embedding analytics. Even if it looks like the less costly option from the initial investment standpoint, it may not be the most worthwhile option. Let’s look at an example.

Suppose the desired functionality requires one full-time developer to go to market in twelve months (equivalent to $150,000). And, it takes one third of their time to support and enhance the capabilities in subsequent years ($50,000 annually). We expect a positive ROI after three years. Let’s assume $150,000 in benefits each year, after the initial year-long investment. Based on these assumptions, we get an ROI of 20 percent over three years, breaking even after 2.5 years.

Now let’s say the equivalent “buy” option cuts the development effort in half ($75,000 first year and $25,000 subsequently). To get there, suppose the software costs $50,000 each year, support costs $4,000 each year, and training costs another $4,000 in the first year. On the upside, you get to market six months sooner, thus reaping $75,000 in benefits during the first year. This reduction in development time is vital to the analysis. Even though costs are higher compared to the first scenario, benefits are also higher. We get an ROI of 29 percent over three years, and break even in less than two years.

This is a simplified example, but the point is to assess both the benefits and costs when building a business case based on a comparison of calculated ROI.