The Build vs Buy Debate on Embedded Analytics is Moot

As embedded analytics become increasingly prominent in the business intelligence (BI) landscape, the question of whether companies should build or buy embedded BI applications seems to be more relevant than ever. The numerous attempts to answer this question ignore the basic fact that the question itself is misleading, since for most organizations there is not a simple yes-or-no answer. Instead, best practices for embedded analytics are neither “build” nor “buy” — but is in fact more akin to partnership.

Understanding the Debate

“Embedded analytics” is a blanket term that describes the integration of various features of business intelligence tools into other applications (often, but not exclusively, in SaaS). For example, a company that develops CRM software might want to provide more in-depth insights from the data it collects to either enhance the company’s general value proposition or to sell a premium service. Hence it may look to incorporate features such as data transformation, rapid big data querying or interactive visualizations to its own CRM software package.

Gartner estimated that by 2015, 25 percent of analytics capabilities would be embedded, growing from just 5 percent in 2010. Most professionals in the BI industry would agree that embedded BI has become a major area of focus for both business and technology. Customers are demanding self-service, meaningful access to data, and competition is forcing companies to accommodate these demands, which in turn leads to more focus on building these types of capabilities.

In-House or Out-of-the-Box

The question of “to build or not to build” has become the subject of heated discussions when considering an embedded analytics project. Run a quick Google search for “build vs buy embedded analytics,” and you’ll be bombarded with page after page of articles asking and attempting to answer this exact question. I will briefly present the most common arguments for each side of the debate:

• Developing BI features in-house gives companies more flexibility and control over the end product. The original application developer is the most intimately familiar with its product and customers, and so will be able to tailor a solution more precisely. Building BI features in-house, however, requires a significant investment and often yields sub-par results due to the level of investment required and the need for specialized skills.
• Buying an “out-of-the-box” solution enables a company to leverage the massive investments already made by the BI provider and gives access to state-of-the-art BI capabilities.

In a majority of cases, companies that seek to provide meaningful data analysis capabilities to their customers would be better off looking to embed an existing product rather than starting from scratch. However, what I would like to stress is that the way this question is posed is in itself misleading: by far, the more common — and preferable — scenario is actually neither build nor buy, but a third solution that could more accurately be described as partnership.

Business Intelligence is Not a Commodity Product (Yet)

When people talk about “build vs buy,” one might get the impression that the option exists to go online and buy a turnkey embedded BI solution, which one can easily plug in to an existing product and presto! Instant customer-facing analytics. Sadly, when it comes to more sophisticated needs and products, this is almost never the case.

I do not mean to imply that BI implementations need to be lengthy or difficult affairs, but merely that each implementation is different. A company that typically wants to present a hundred thousand rows of data to its customers does not need the same technological “muscle” as one that works with a hundred million rows; likewise, data that comes from dozens of structured and unstructured sources is quite different than neatly-organized tables in a SQL database. High-level data visualization is one thing (for example, an e-commerce app that displays traffic and sales to sellers), whereas advanced analytics, drill-downs and customizable reports require entirely different capabilities.

When it comes to these types of more advanced use cases, the notion of a one-size-fits-all solution is unrealistic: the analytical features will need to be integrated into the existing application and customized to meet the exact needs of the specific product and customer base in terms of data modeling, security, management and reporting. Again, this is not to say that these integration efforts need to be overly complicated or require extensive development resources — however, they will require an understanding of the underlying data, and the ability to easily customize and communicate with the BI platform via API access.

Partnership, Not a One-Time Transaction

The decision to use an external provider for embedding analytics is more similar to a partnership than to a “get it and forget it” type of purchase. The developer and the BI provider work together to build the required data product, and continue to collaborate as products mature, new features are added and new needs arise.

Does this mean that the developer will have to rely on the BI provider for every change or customization? Absolutely not — developers should have complete independence and control over their own product. They should be the sole owner of the product, from end to end, and be able to develop it on their own, without having to rely on a vendor’s professional services or external consultants. In order to achieve such an outcome, developers should partner with a BI vendor that is an enabler, always keeping developers in mind. Best practices include maintenance of a comprehensive SDK, with excellent documentation, and designing the BI product as an open platform.

Open platforms enable easy access via commonly used APIs, ensuring the BI software is flexible enough to integrate with the developers’ existing systems seamlessly, and accommodating specific needs and requirements around data sources, security and similar considerations. And for the truly complex, heavyweight implementations — top BI vendors provide the professional resources needed to get customers up and running as fast as possible, and to address the various maintenance issues that inevitably arise.

Furthermore, both parties should see their relationship as long term — new features introduced in the BI platform should always be built in an “API-first” approach, enabling application developers to quickly and easily incorporate these features into their own offering; communication between the BI vendor and the application developer needs to be open and frequent so that both can gain a better understanding of the other’s strengths and limitations and adjust development, support and account management efforts accordingly.

Understanding embedded analytics as an ongoing partnership, rather than a one-off purchase, will lead developers to ask more relevant questions before embarking on an embedded BI project; and lead BI providers to make a serious commitment to building truly open platforms, maintaining superb customer service and documentation. In such cases, everyone stands to benefit.