Build or Buy?
Assessing Product Fit
Building vs Buying:
Embedded Business Intelligence
Software-as-a-service (SaaS) providers, particularly those in the B2B space, face mounting pressure to provide in-application business intelligence. Market forces, customer demand, and a need to free internal IT teams from reporting duties make acquiring analytics an imperative. But should you build that solution in house or buy business intelligence software from a third-party provider?
This is an important question, as the SaaS industry’s competitiveness leaves little room for error. An inadequate and labor-intensive homegrown solution could be just as disastrous as a costly out-of-box solution that takes an eternity to implement. Embedded BI software constitutes a significant investment no matter how it’s acquired, and entertaining the build vs buy question is critical to finding the most efficient means to your desired end.
This guide will help you assess your product objectives and weigh them against the challenges of both building and buying business intelligence software. We hope that by the end of this guide, you will have a clearer sense of which option is right for you.
Establishing Your BI Requirements
Because business intelligence represents a category of software rather than a finite set of features, knowing what you want in a BI solution is a critical first step toward acquiring it. Broadly speaking, BI applications allow users to access, analyze, and present business data. Though spreadsheet applications like MS Excel and Google Sheets fit this definition, they’re unlikely to meet your BI requirements. Exploring and enumerating those requirements will clarify exactly what you would need to build or buy.
/* Hidden accordion to close all accordions */
Step 1: Understand Your Users' Needs
If your IT team is drowning in ad hoc reporting requests, your users’ needs may seem fairly clear to you already; but digging deeper will give you the full picture. Benjamin Emanuel, Product Manager at fintech SaaS provider Abrigo, says “knowing exactly what end users are going to be trying to report on beforehand is key” to establishing requirements. Delving into these use cases will reveal what data transformations/calculations, report layouts, visualizations, and sharing features they’ll require.
Below are a list of questions to consider as you explore these use cases:
- Will my users primarily be running preexisting “canned” reports, or will they also need to be able to build and edit their own reports using self-service or “ad hoc” capabilities?
- Do my users need the ability to build and/or run dashboards?
- What types of data visualizations will my users need to be able to build?
- Do my users need the ability to export reports? To which formats?
- Do my users need to be able to email reports?
- Is it important to have interactive reporting controls, such as filters and drilldowns?
- What specific kinds of reports will they need to build or have the ability to build?
- What sorts of functions and formulas will they need for their data analysis?
- Will my users need the ability to fill out industry forms with their data?
- Do I want my users to be able to restructure report data models?
The answer to these questions may well uncover others specific to your customer base and/or application. Do your best to answer them all before moving on to the next step.
Step 2: Visualize the UX
Now that you understand your users’ analytics needs, you can begin to explore what sorts of UI/UX combinations might best meet them. Keep in mind that you will likely have both technical and non-technical users to accommodate. Non-technical users typically run and manipulate pre-made reports or build simple ones from scratch, turning to more technical users for help with more complex tasks. With the proper tools, technical users can then furnish most of their organization’s ad hoc reporting needs. Consider how and where in your application each user group would interact with which BI tools.
Here are some questions to help you through this step:
- How do I want BI to integrate into existing workflows?
- Where would I expect my users to access stock reports, report-building tools, and their own report libraries?
- How would I like the BI UI to look and feel?
- What ease-of-use features (e.g., drag-and-drop controls) would be essential?
- What accessibility standards would the UI need to meet?
- Would the UI need to be localized for international users?
- Would different user groups use different tool sets?
Once you’ve answered these questions, you should have a pretty clear picture of what your BI needs to do for the customer. Now it’s time to take stock of internal requirements.
Step 3: List Technical Parameters
A list of technical requirements is especially important when buying BI, but it’s also good preparation for building it. These will likely be pretty easy to enumerate, but we’ve prepared a list of prompts to help you check all the boxes:
- What computing platform(s) must the BI application run on?
- What server language(s) must be supported?
- What kind(s) of hosting do I use or want to use?
- What kind of traffic must it be able to accommodate now and in the foreseeable future?
- How must the solution be able to scale — horizontally or vertically?
- With what other business applications will the BI solution need to interface?
- What data sources will we need to be able to connect to?
- What kind of data security do I have in place, and what kind of permissioning will I require?
- How easy is my data to report off? Will it need to be warehoused?
Regardless of whether you build or buy BI software, give special consideration to the state of your data. Companies tend to underestimate how important data hygiene is to the overall success of a BI project. Business intelligence forms a bridge between SaaS users and their data, but if the data is prone to inaccuracy, confusing, difficult to navigate, or otherwise problematic, it will hamper user adoption rates. Factor data preparation and any necessary ETL or metadata management tools into your projections.
Step 4: Take Inventory of Your Resources
Whether you opt to build or buy, your BI project will require some combination of money, time, and talent. Before you estimate resource requirements for each scenario, take an inventory of what you have right currently. This will help you plan for any necessary adjustments later on.
- Budget: How much money do you have earmarked for BI? Be sure to factor in any relevant salaries.
- Talent: How many staff could you currently spare for the project? Make note of any knowledge gaps you might need to fill with new recruits.
- Time: How does BI fit into your product roadmap? Is there a deadline you’re hoping to meet?
Step 5: Review Your Core Value Propositions
Most SaaS platforms exist to help consumers and/or businesses manage a system, whether it be personal finance, supply chain routes, insurance claims, customer relationships, or something else. Because reporting and analytics are so closely tied to management, it can be tricky to tell whether BI qualifies as a core value proposition.
Here’s a quick and easy test: go to your product website, and read the copy accompanying the hero image on the homepage. This is probably a distillation of your product’s value proposition. Does it mention reporting and/or analytics? If so, BI may be integral to your core value proposition. If not, test to see if it could be a future value proposition by mentally editing the copy to include reporting. Does this revised copy reflect your vision for the product?
If BI is indeed a new or evolving aspect of your product core, then having full autonomy over its functionality may be critical to your success. It also may not! That judgement call will depend on what you require of the software and what BI options are available to you on the market. It’s important to know, however, how integral to your brand BI will become, regardless of the route you choose.
Refer to your answers to the questions in Steps 1 – 3 and 5 above as you browse the embedded BI market. Are there any solutions that already satisfy your core requirements? If BI is to become part of your product core, are there any solutions that give you enough flexibility and autonomy to make them your own?
If the answer is an unmitigated “no,” you’re almost certainly better off engineering your own BI tool. You might have to lengthen your project roadmap and/or acquire additional capital in order to execute this plan, but this is what must be done to realize a unique vision.
Chances are, however, that there are at least a handful of solutions on the market capable of meeting most (if not all) of your requirements. Buying BI software is the right choice if doing so would mean not having to reinvent the wheel. One of our clients said as much in a customer review: “Exago is our partner in bringing (our) mission to life… we don’t have to expend developmental bandwidth to do what they are already doing so well.” If the prospect of licensing an existing BI solution gives you this feeling, you’re on the right track.
Buying business intelligence software is guaranteed to be faster than building it, but how much faster depends, once again, on your requirements. To give you a ballpark, the charts at the bottom of this comparison between Exago BI and a competitor reflect that most embedded BI deployments happen sometime in the one- to three-month range. This timeline is consistent with BARC’s recommendations for a successful initial implementation.
There are too many variables to say definitively how long it would take to build a BI solution from scratch, but a study by Aberdeen Research Group found that independent software vendors (ISVs), who were more apt to buy embedded BI, “experienced a 27% faster time to market” than enterprises, most of which built their own BI. This is a handy estimate, but it’s best to make your own projections based on resources at your disposal.
In most cases, it’s cheaper in terms of revenue and labor to buy rather than build BI. With a purchased solution, you know what your cost will be up front and can budget accordingly. In-house projects, by contrast, tend to “run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted,” according to a 2012 study by McKinsey and the University of Oxford.
In-house solutions also incur higher ongoing maintenance costs. Building BI will likely require additional permanent development, quality assurance, and support staff whereas the bulk of that work is offloaded to the BI provider in a contract scenario. The only way such internal costs would pay for themselves over time is if the BI tool developed genuinely offered something uniquely valuable and disruptive, dramatically increasing your application’s market share and/or penetration. This is why the requirements process above devotes so much more time to establishing product goals than to enumerating resources. Your ambitions for the product will likely be the deciding factor.
If this guide has led you to the conclusion that the right next step for you and your team is to build a BI tool in house, let us be the first to congratulate you on having discovered an unmet analytical need in your industry vertical! We are glad to have played even a small role in helping you arrive at that insight. We hope you will find use for your requirements notes as you begin work on your application!
If, on the other hand, you feel confident that licensing an embedded BI solution is the right next move for you and your team, we invite you to proceed to our Assessing Product Fit guide, which will help you research potential solutions, align your requirements with feature offerings, and move confidently into the product evaluation phase. If you’re curious to learn more about Exago BI in specific, feel free to browse our website, get in touch, or attend one of our biweekly product overview webinars.