As organizations strive to cultivate data-driven cultures, the need for embedding analytics into business processes when and where users make decisions is becoming a critical capability. Although traditional business intelligence and modern data discovery tools offer aspects of embedded BI, I learned that those solutions are not ideal for integration or OEM use by a SaaS or ISV.
In a recent briefing with Izenda, an embedded BI software company providing a platform designed for OEM use by other software companies, the challenges their clients faced when integrating other BI tools and platforms were discussed, including:
- inapt licensing models
- proprietary infrastructure
- cost and complexity to integrate and white label
- need for extensive professional services
- proprietary infrastructure
- immature APIs
- awkward experiences challenge users
Intrigued by our conversation, I decided to dig a little deeper on my own. In this article, I will share my top lessons learned and key considerations for selecting an OEM friendly embedded BI solution.
As an entrepreneur, I have just started reviewing new revenue streams where I can apply my analytics talent and passion. One of the areas that I am exploring involves embedding analytics that I can brand into an application. Since the architectural foundation and design choices are not easy to change, I have been diligently investigating my options. I want to ensure that I can live with my selections while continuing to scale by growing my user base profitably over time.
To provide a CX/UX that will delight my customers, I want to consistently deliver a seamless, unified experience. I don’t want to send them to another portal or present an iframe of another solution. I also want to empower business users of my application with the ability to create their own reports, dashboards and visualizations in an entirely web based experience with predictable costs. If I can’t do that, I risk high churn and could end up in an endlessly expensive treadmill of always needing to find new customers. The goal is to grow my little business by expanding and offering more capabilities to the same user base.
Thus my potential solution assessment begins. In the market today, there are a variety of directions that I could go with components, tools or platforms. Here are the most popular ones.
#1 Deal Breaker = Usage-Based Models
The first lesson that I learned looking over Izenda’s Total Cost of Ownership (TCO) calculator is that usage-based models are deal breakers. Any licensing model that charges usage fees by instance, per core, per user or per view is out.
I can invest a little bit today on a true embedded BI offering or pay a whole lot more later with a usage-based licensing model.
I appreciate usage-based models with scale up hardware and database hosting. I don’t see why it would ever make sense for rendering charts and reports when I can build or buy this capability one time with an unlimited usage model. There are excellent alternatives in the market today that enable me to pay once and then reap amplified rewards as I grow my business.
If I went with a usage-based model, I would never get to enjoy financial economies of scale. The usage-based embedded BI vendor gets to relish in the labors of my hard work…not me. Assuming my application is a success, why bother if not, a usage-based model punishes me as a vendor. As more users log on and begin to rely on my app daily, the cost to offer it increases exponentially.
The unknown cost risk for me is also intolerable. I am not going to charge my users per log in, report render or click. I want them to delight in using my application… not be thinking about how quickly to get in and out of it. Besides in the mega-competitive SaaS market, monthly fees are standard and expected. Anything other than that will be confusing and likely drive prospects to my competitor’s offerings that do have easy to understand pricing.
Buy Embedded BI, Don’t Build
Having immediately ruled out usage-model licensing for embedding BI into my application, I now consider build versus buy. I am technical and I can sling code. Digging into programming libraries and piecing solutions together will not deter me if it that is the best way to go. I also happen to be a huge fan of the open source community and the wonderful value those offerings provide.
Amazing data visualization libraries such as D3.js are successfully implemented within many web applications today. The licensing cost of zero, just provide the standard library disclaimer, is a no-brainer for the right use cases. Where the decision gets complicated is when you want to sell open source in a commercial offering.
I want to embed BI in my commercial application. That means my solution must work, be secure and I am contractually obligated to support it. In a constantly changing web world, keeping my open source project up to date might be more effort than I expect it to be. I also need to consider how much additional functionality I need to build to have an appealing minimum viable product.
Having worked in technology for 20+ years, I know building a robust, secure, high scale app is NOT a stitch a couple lines of open source code together type endeavor.
I would need to hire several top-notch developers and a cloud scale DBA to create and continue to maintain my custom project. In the build case, I essentially end up significantly investing in development effort while losing precious time to market. I also take on unnecessary development risks. Then I would continue to spend money on ongoing operational support resources for a commodity reporting feature. I’d much rather invest in creating state-of-the-art predictive algorithms that truly differentiate my offering.
When reviewing embedded BI and analytics platforms like Izenda that provide continuous innovation with unlimited use OEM-friendly licensing models without proprietary infrastructure limitations, the buy decision absolutely makes the most sense for me. The benefits of a buy from my perspective include:
- Avoid rebuilding the wheel (and supporting it)
- Reduce development costs and risks
- Invest in developing core differentiating features
- Significantly expedite time to market
- Sleep at night with no-surprises or pricing fears
- Celebrate application success and usage growth
- Make $$$
Key Considerations for Embedded BI
Now that I have narrowed down my options to buy with unlimited OEM-friendly licensing models, there are not many vendors left to check out. For the remaining shortlisted OEM friendly Embedded BI solutions, here are my key considerations that I will continue to review.
- Does the embedded BI solution allow business user self-service report design or does a BI professional need to create reports that get embedded for self-service consumption? There is a big difference in those approaches. Business users expect to be empowered today.
- Are you able to white label all aspects of the embedded BI platform or can you only brand the report output?
- What is the integration development level of effort with your application?
- Beware of APIs marketed as a self-service embedded BI and self-service BI that provides an embedded API. If embedded BI is not the vendor focus, significant development efforts might be needed to get to the same place as alternative pre-packaged embedded BI offerings.
For more embedded BI selection criteria and considerations, Wayne Eckerson’s white paper is an excellent read.
I hope that you have found my embedded BI evaluation insights helpful. If you are considering monetizing your data or offering embedded analytics within an application, you will most likely want to buy to prosper profitably as your business grows.
Unlike the traditional BI and data discovery players that get a lot of public coverage, you rarely hear about white label friendly embedded BI platforms that quietly empower the world’s largest applications. Evaluation information for embedded BI is a bit more elusive. I’ll share more information as I continue in my review process.