Tech Stack and Architecture Fit

Architecture fit is the challenge that eliminates more embedded reporting platforms than any other — and it's the one teams check last. A platform that scores well on features, pricing, and demo quality can still be entirely wrong for your deployment if it can't run in your environment or connect to your data the way your architecture requires.

Unlike feature gaps, which can sometimes be worked around, architecture mismatches are fundamental. You can't run a cloud-only platform on a customer's on-premises infrastructure. You can't make a platform work with your database if it doesn't have a native connector for it. Finding these problems after you've signed a contract and started integration is expensive — finding them before costs nothing.

The Deployment Model Question

The first question isn't features — it's where the platform runs.

Cloud-only platforms run on the vendor's infrastructure. Your data goes to their servers for query processing. This is operationally simpler for the vendor and works well for ISVs whose entire customer base is comfortable with cloud-hosted third-party software. It becomes a problem the moment you have a customer with data residency requirements, a government contract with on-premises mandates, or an enterprise security policy that restricts third-party cloud processing of certain data categories.

Self-hosted platforms run on your infrastructure — or your customer's. Your data never leaves environments you control. The analytics engine runs wherever you need it: your cloud tenant, your data center, your customer's on-premises servers, or some combination of all three.

For ISVs with a diverse customer base, self-hosted is almost always the safer long-term choice. You can always choose not to deploy on-premises for a customer that doesn't require it. You can't retroactively add on-premises deployment capability to a cloud-only platform when an enterprise customer requires it as a condition of purchase.

Database Compatibility

The embedded reporting platform connects to your database. This sounds obvious until you discover mid-evaluation that the platform you've been trialing has limited support for your specific database version, requires a specific driver configuration your infrastructure team can't accommodate, or uses its own internal database backend that creates an unexpected dependency.

Three questions to answer explicitly before you invest trial time:

Does the platform have a native connector for your application database? "We support most databases" is not sufficient confirmation. Get a specific yes for your database type and version. Test it against your actual schema before you commit integration time.

What database does the platform use internally? Some analytics platforms use a separate database for their own metadata, user management, and report storage — independent of your application database. If that internal database is SQL Server and your environment doesn't include SQL Server, that's a new infrastructure dependency. Yurbi uses Microsoft SQL Server as its internal backend — relevant if SQL Server isn't already in your environment.

How does it handle multiple databases? If your tenants each have separate database instances, the platform needs to support dynamic connection routing. This is covered in depth in Chapter 1 — the short version is that static per-tenant connection string configuration doesn't scale, and dynamic routing at query time is what you need.

SSO Integration

Your customers are already authenticated in your application. When they navigate to the analytics section, they should not encounter a separate login screen. This requires the reporting platform to accept your application's session as the authentication source — a pattern called SSO, implemented via server-side token exchange.

The challenge here isn't the concept — it's the implementation specifics. How does your application pass the authenticated user's identity to the reporting platform? What format does the token take? Does the platform validate it server-side (correct) or client-side (a security risk)? Is the SSO integration documented clearly enough that your developer can implement it without hand-holding from the vendor?

SSO should be a standard, documented integration — not a professional services engagement. If implementing SSO with a given platform requires purchasing an implementation package or scheduling a vendor-led project, that's a signal about how the rest of the integration will go.

The Semantic Layer and Schema Stability

Connecting the platform to your database is the first step. Making your data useful in reports — without requiring your customers to understand table names and column structures — is the second. This is where the semantic layer matters.

A semantic layer maps your raw database schema to business terms your customers understand: "Monthly Recurring Revenue" instead of a join across four tables with a calculated field, "Active Users" instead of a filtered count on a status column with a specific enum value. Report builders that expose the raw schema require your customers to be SQL-literate, which most of them aren't.

The practical challenge for ISVs is schema stability. Your product evolves — tables get renamed, columns get added, relationships change. In a reporting platform with a proper semantic layer, a renamed column requires one update in the semantic layer configuration. All reports that reference that field continue to work. Without a semantic layer, a renamed column breaks every report that references it directly, requiring individual fixes across your entire report library. The more customers you have and the more reports they've built, the more expensive that maintenance becomes.