Why Build or Buy

When faced with the need to embed analytics into an application, most software providers arrive at the crossroads of the “build versus buy” decision.

Why Build (or Really, Code)?

The first instinct for many application developers is to build the necessary reporting functionality with the help of code libraries or charting components. This works for many developers, especially for new software applications with simple requirements. And even as organizations mature, the primary reason for taking code-intensive approaches is to maintain complete control over the look and feel of the application.

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

Application providers who stay on the “build” track are committing to staffing significant resources in developing, supporting, and keeping up with advances in data visualizations and business intelligence over the long term.

Why Buy?

Many software organizations are under pressure from customers or competitors to improve analytics capabilities, and they do not have the time or resources to build on their own. In fact, in every survey we have conducted with software providers, the top reasons for embedding with a third-party product are:

    Cost to build and maintain capabilities on their own – It can be expensive to initially develop, provide ongoing support, and continually enhance analytics capabilities.

    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.

    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 there will always be an amount of integration required for embedding a third-party product, but the shorter time-to-market for delivering a wealth of capabilities justifies this investment. Evaluating the build and the buy options requires an understanding of the targeted functionality to be implemented, the level of integration required for third-party products, and a cost/benefit analysis.

Gauging the Feasibility of Build

The first step in tackling the “build versus buy” question is to understand your requirements. Determine your desired end-user functionality, prioritize your needs, and 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 so that you can build a capabilities map matching users to the needed functionality. Here are 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

In addition to implementing core analytic functionality, it is important to plan out how these capabilities will be embedded or integrated within the context of the overall application experience.

  • Analytics module – often, application providers create a reports module or “tab” that appear in the framework of the application.
  • Inline analytics – to create a better user experience, analytic content embedded within existing application pages to guide users in the way they work inside the application.
  • Analytics workflows – to create the best and most efficient user experience, analytic capabilities are increasingly integrated with the core workflows of applications: when users interact with analytic content, they are either led to a specific part of the application, or initiate backend processes empowering users to act on the data within the same context of their analysis.

3. Prioritize

Next, prioritize the desired functionality based on the business drivers.

  • Time – What features do you need now? What features can wait?
  • Revenue impact – What capabilities will enable you to package a separate offering and monetize data and analytics? What functionality have your customers been asking for? What functionality would make it easier to retain their business?
  • Competitive differentiation – What will make you stand out from the crowd and make it easier for you to attract new customers?

4. Determine Feasibility of Coding Yourself

Finally, determine the feasibility of delivering the functionality customers need within your time constraints. Most application providers can develop basic capabilities themselves, such as filtered reporting, static charts, and data exports. For higher value and highly interactive capabilities, companies typically employ third-party products to remain competitive while implementing capabilities in a timely and resource-efficient way.

Comparing the Benefits of Build Versus Buy

In order to properly evaluate your implementation options, it is important to qualitatively, if not quantitatively, assess the benefits and costs of each option, as well as compare the ROI for each.

Defining the Time Frame

It is important to define a timeframe for such an analysis. This duration should give you enough time to understand the future benefits and costs before conditions change in a manner that may force you to consider your options again. For technology investments, a timeframe of 3-5 years is often used.

Benefits

Compared to coding on your own, utilizing a third-party product will get 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 achieving a breakeven point earlier in the project lifecycle.

Build Buy
Benefits Summary To deliver a rich set of functionality, “Build” options will generally take more time, which translates to longer time to value – slower customer acquisition and adoption, less ability to retain customers, and lower selling prices for your product – compared to “Buy” options. “Buy” options get you to market sooner, which translates to faster time to value –customer acquisition and adoption, increased customer satisfaction and retention, and higher average selling prices for your product – compared to “Build” options. Relying on a third-party provider with a range of functionality improves the clarity of your roadmap and your ability to meet changing customer demand.
Time to Market For rich functionality, code-intensive development takes longer for both the initial release and subsequent releases. This means it will take longer to realize the benefits of your analytics project and delay your potential return on investment. By getting to market sooner, you will realize the benefits of your analytics project and greatly increase your chance of seeing a positive return on your investment.
Value By getting to market sooner, new embedded analytics functionality will accelerate:
User adoption
Customer satisfaction
New sales and customer acquisition
Product differentiation
Operational Efficiency Analytics capabilities provide operational benefits :
Reduce ad hoc report requests
Create sales and marketing efficiencies for commercial application providers
Product Functionality and Visibility into Product Roadmap Dependence on internal development resources to implement new functionality limits the predictability of delivering over the long term, especially if adding developers is required. With a broad range of functionality delivered from a third-party product, you have greater visibility into your product roadmap as well as greater agility in the product delivery process.

 

Comparing the Costs of Build Versus Buy

Investment Costs

Compared to coding on your own, utilizing a third-party party product increases your cost in software licensing but reduces your cost of development, both initially and ongoing. Your analysis should also include the opportunity cost and project risk associated with your skilled development staff spending less time focusing on your core product.

Build Buy
Costs Summary: “Build” options will generally require more developer resources, and will take longer to implement similar functionality, as compared to “Buy” options. Dependence on developers also raises the opportunity costs and risks to the long-term roadmap. Summary: While “Buy” options will generally increase the investment in software, they require fewer developer resources and get you to market sooner, as compared to “Build” options. Relying on a third-party provider with a range of functionality decreases opportunity cost and risks to the roadmap.
Software Licensing Code-intensive approaches often utilize charting libraries or visualization frameworks. Developers should ensure proper licensing for use in your commercial products. For acquiring richer capabilities, monetary investment in software will be higher if you’re using a third-party business intelligence and analytics provider. Ensure an OEM agreement is in place for your commercial products.
Services – Training, Professional Services, Support Relying on your internal development team means you’ll have fewer external vendor costs. Software vendors offer a range of self-service and full-service options tailored to meet your time-to-market and staffing needs.
Internal Resources
(Development, Maintenance, and Enhancement) “Build” requires more development resources, not just in the number of resources, but in coders who are highly skilled. Note that these resources will be needed on an ongoing basis in order to maintain, support, and enhance your analytics functionality over time. With third-party software, you generally need fewer development resources and lower-skilled resources, which will be more accessible to you. Adding and enhancing functionality over time also requires fewer developer resources.
Opportunity Cost With your developer resources focused on analytics functionality, they won’t be dedicated to developing your core product or intellectual property. As a result, the roadmap of your core product will be impacted. With a monetary investment in software, it is important to balance that investment with lower development costs and faster time-to-market.
Risks You are completely dependent on internal developer resources for current functionality and your future roadmap. Though this is standard operating procedure for smaller organizations, it’s not ideal as you grow. Eliminating some development risk by leveraging a third party with out-of-the-box functionality is advantageous, particularly if you employ a partner with a proven track record.

 

Comparing the ROI of Build Versus Buy

Now 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.

Roi-chapter-4

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

To some, “build” may seem like the obvious choice for embedding analytics functionality in their application. However, even if it looks like the less costly option from the 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 12 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 positive ROI after three years, so let’s assume $150,000 in benefits each 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 we break even in less than two years.
build-vs-buy

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

Want to learn more?

To build a personalized business case for your company using our Embedded Analytics ROI Calculator, visit LogiAnalytics.com/ROI-Calculator.

Section Nav