Extensibility in Dollars and Sense

Jun 21, 2018

Even if an application perfectly meets your business requirements today, it could fall short tomorrow as those requirements change. The famously volatile software market might compel your CEO to make a radical pivot, or your company might want to honor a prospective client’s niche enhancement request. BI products, especially embedded ones, must be able to cover the full gamut of client needs—even as they change or evolve over time. Software-as-a-service (SaaS) providers may move towards fulfilling these requirements as a part of their core product, an approach known as the “general-scope solution,” but shifting development resources towards a corner case is inadvisable. This is where extensibility can bridge the gap.

An application’s extensibility measures the degree to which it supports extensions, which add value to embedded solutions like Exago BI by changing, expanding on, or otherwise enhancing the software’s core functionality. But how can we measure the actual dollar value of this versatility? That depends on the importance and scarcity of the functionality the extensibility is designed to accommodate.

Defining Value

Because extensions close the divide that would separate an unsatisfactory solution from a satisfactory one, extensibility should not be seen as providing 1% of a BI product's value. In some cases, it can be the difference between 0% and 100% viability.

SaaS providers evaluating extensibility suites should first look at each suite’s general scope before assessing its performance in a hypothetical use case.

Let’s walk through this process using an integration feature commonly leveraged for extensibility purposes: the application programming interface (API). APIs sit on top of the codebase and are generally used to expose some of the internal workings of the software. BI applications can decide how much or little to expose to the SaaS client and whether to leverage the API in other ways.

Some API quantities can be assessed at face value. For instance, thorough APIs can:

  • Modify settings based on user groups at any level of granularity
  • Utilize arbitrary programmatic data sources
  • Build or modify reports and/or settings entirely in code and on the fly
  • Execute reports on the back end without utilizing the application GUI
  • Intercept and inject custom handling during application runtime
  • Arbitrarily style and alter the full application interface

A technical evaluator can vet these capabilities through discovery calls with services staff, examination of public documentation, and discussion with the product's community in online forums. The more thorough the API, the less likely the SaaS provider is to encounter problems after embedding the BI solution.

After determining the general scope of the available APIs, a more specific evaluation can be made for the actual use case. Value can be measured more concretely by breaking it down into the following component factors:

1. Efficacy – How thoroughly extensions can bridge the viability gap

2. Integration – How transparently extensions work with the main application

3. Cost – How easy to implement, and any direct expenses incurred


Can an extension fulfill the necessary use cases? Can it provide an alternative solution? Efficacy is defined by the specificity and completeness potential of an extensible solution.

In this case, specificity refers to how targeted the API allows extensions to be. This largely depends on the breadth and granularity of the API. The best extensions function not as "workarounds" for a problem but as sustainable solutions to it. The more targeted the extension, the cleaner it will be from a user-experience and maintenance perspective. Have a developer weigh in on this discussion.

Completeness is how many possible situations an extension will fulfill. Extensions adjust the user experience, and a goal should be for transparency and consistency. If some parts of the application are not targetable by an extension, then this may require either blocking off that portion from user access (thus reducing utility) or increasing the number of warnings and caveats a user will see. An incomplete solution can lead to UX issues.

Both specificity and completeness increase with thoroughness of the API, and the number of application "hooks" provided for extensibility.


Any extension is ultimately going to be compared against what could be accomplished by full-time developers working on a contractual enhancement (or full-scope solution). Can an extension work, for all intents and purposes, as part of the application itself without friction to the end user experience?

A well-integrated extension requires a good API that works along the same processing routes as the main application and provides the ability to reuse segments of the application for alternative purposes. If a developer is required to recreate functionality, then you run the risk of generating issues and inconsistencies.


Extension cost correlates with ease and speed of task completion, which in turn is influenced by a number of factors. How thorough is the API? Can your goal be accomplished without workarounds? How thorough is the documentation? Are there adequate examples for all provided features? How much knowledge is available publicly, through either community or third-party platforms, and/or first-party documents? And to what lengths do the support/services staff go to provide assistance? Are they willing to provide basic frameworks to guide your developers along the right path?

Any costs associated with making use of extensibility, such as paying additional fees for API access, purchasing service hours, or purchasing an extension directly, should be evaluated as portions of the overall product expense. Ease of implementation also affects expense, with length of development time and number of resources directly related to internal salary requirements.

And that’s it! Developing a rating scale such as the one we describe in “How to Get the Most out of a Product Evaluation” can help you keep track of prospective BI solutions and their extensibility suites as you go. Establishing a minimum rating threshold can be a useful means of ruling out incompatible extension suites at the general-scope stage. Consider also exploring more than one use case as you narrow the scope of your evaluation, as you may be able to take advantage of a preexisting extension. For extensibility use cases involving Exago BI, check out “Build it Your Way: The Value of Extensibility in Third-Party Software.


Schedule a Demo

Leave a Comment