Many of us think of extensibility as roughly synonymous with customizability, but there’s more than a semantic distinction between terms, and understanding that distinction could be the difference between a successful software implementation and an underutilized one.
Whereas customizability measures the degree and ease with which users can modify existing features, extensibility measures the degree and ease with which they can add new ones. This may seem like a minor difference since changes are being made to the software in either case, but: you can’t customize a feature that isn’t there, and when the functionality you need does not yet exist within the application, it’s hard to overstate the value of extensibility.
Of course, the value of an application’s extensibility features will depend entirely on what functions they allow your company to build upon. Since its users can already customize the UI and session state through CSS and the API, Exago’s extensibility features give them control over something else: the running state. Server and action events allow users to interrupt the running state to add intra-session changes of their own design, enabling them to redefine some of the application’s basic functions.
We Interrupt This Program to Bring You Something Completely Different
Server and action events (SAEs) are the meat-and-potatoes of Exago’s extensibility, and the only difference between them is how they are triggered. Action events are triggered by client-side user actions, things like clicking a button or loading a report or performing some other task in the UI. Server events, on the other hand, are triggered by an application process occurring server-side, like running a SQL query or loading a configuration file. These triggers, or events, are flagged by Exago developers as code injection points where application architects can take advantage of the program’s JIT compiler to make changes to the program’s running state. In other words, the application administrators get to decide for themselves what happens at these event points, and if what they want is to interrupt the default programming to bring end users something completely different, they can.
“Built from the Ground Up with Extensibility in Mind”
If building and implementing SAEs sounds like work, that’s because it is. Designing server events requires time, development resources, and sometimes also guidance from the Exago Support Team; but, the freedom and flexibility it affords client companies can be invaluable.
The architecture firm Elemental embraced this same tradeoff when in 2010 a tsunami razed 80% of the buildings in Constitución, Chile. Elemental worked with the city on a housing project for the displaced and were challenged to come up with a design that a single mother could afford but which could house an extended family. Their solution: extensibility. Elemental proposed a community of houses split vertically down the middle with one half ready for move-in day and the other little more than a roof over the foundation. This way, construction would be swift and inexpensive, and each family could expand on the house as needed and in their own time. Yes, it was more work, but it gave people the power to shape their environment to suit their needs. That is the value of extensibility.
Exago operates according to the same philosophy because the alternative to extensibility is waiting (and hoping) for enhancements. Tim Keogh is an Application Architect at Sageworks, a financial analysis software company, and helped implement Exago five years ago. While extensibility wasn’t a high priority for his team during the product evaluation period, its utility became clear later on. “It seems like Exago was built from the ground up with extensibility in mind,” he says. “With Exago, it’s very easy to do things like figure out what kind of SQL you’re running because of logging and extensibility features. If I’m using another BI solution, I might have to find a DBA to help me track the SQL that’s running and try to track that back to which report I’m running to determine if it optimized correctly, and I don’t want to have to go through all those hoops.”
In Keogh’s experience, not having access to extensibility features means “you have to submit enhancement requests, which usually don’t get turned around in a very quick manner.” Exago’s clients always have the option of submitting enhancement requests but are encouraged to develop SAEs as interim solutions whenever possible because global changes to the application require significantly more time to review and implement.
The following examples illustrate how companies have used SAEs to solve problems specific to their environment.
One of the beautiful things about an extensible BI solution is that it fosters collaborative innovation between client and provider. Instead of simply requesting development from the provider, the client company can contribute to the programming process by building their own extensions and demonstrating their applicability, putting that feature on the fast track to global implementation should it be relevant to a wider audience. ESM, a leading provider of spend management solutions, for example, used SAEs to always format certain data fields as currency upon report execution, and as of v2016.3.0, “currency” is available as a data type category in column metadata. Similarly, it was Logfire, a provider of warehouse management applications, who developed the event that inspired the schedule-to-repository enhancement, which enables scheduled reports to be stored in a directory rather than emailed.
An important value of extensibility as a product design practice is its potential to accelerate innovation and build meaningful partnerships between participating businesses, all while getting the job done.
Quick Guide to Evaluating Extensibility
Since every solution has a different name for its extensibility features, below are some questions to ask during a product demonstration to determine whether the BI solution has an extensible running state or something equivalent to Exago SAEs. The questions all ask after the same functionality but are worded to accommodate different levels of technical proficiency, ordered from least to most technical.
- “Can I have a data field always formatted as currency, regardless of whether the user has applied that formatting and regardless of how the data is formatted in the database?”
- “Can I modify SQL during report execution?”
- “Can I make intrasession changes to the running state?”