Architecting a "SaaS Factory" Platform

Summary

As the Architect and Team Leader (later promoted to CTO), I was the principal designer and lead for the strategic "Business Domain Packaging" project. I transformed the company from a single-product SaaS (Finance) into a scalable, multi-product platform by architecting and delivering the "BDP Workbench"—a platform empowering our teams to create, version, and publish new, ready-to-use analytics products, slashing our time-to-market for new revenue streams.

The Business Challenge: The "One-Product" Trap

The company's platform was a powerful and successful tool for financial performance management. However, this success created a strategic problem: we were siloed. True business performance is holistic, and our clients wanted to integrate data from Sales, HR, and Operations, but our architecture was not built for this.

My challenge was to answer a critical question: How do we evolve from a single, monolithic application into a global performance management platform that can support any business domain, without quadrupling R&D costs? We needed to "industrialize" our product creation process.

The Solution: The "BDP" Platform & "SaaS Factory"

Our strategy was to abstract our core technology into a new, scalable "Business Domain Package" (BDP) concept. A BDP is a self-contained, version-controlled product (like "BDP-HR" or "BDP-Sales") that bundles three things: a data model, a set of connectors, and pre-built dashboards.

To build these, I led my team in developing two key innovations:

1. A New Core Architecture: A platform that could manage these BDPs as "pluggable" products.
2. The "BDP Workbench": An internal "factory" or "atelier" that would empower our non-engineer teams (like business analysts) to build, test, and publish new BDPs.

Key Features & Technical Implementation

This project was a foundational, architectural-level success. These are the key features I designed and my teams delivered:

A Robust, Version-Controlled Package Architecture

The foundation of the platform is the BDP model itself, which I designed to function like a modern software dependency.

• Immutable, Versioned Packages: Once a package is "Published" (e.g., BDP-HR v1.0), it becomes completely immutable. Any change requires creating a new version (v1.1), guaranteeing that existing customer tenants are never affected by development.
• Dependency Graph: I designed the system to support multiple, transitive inheritance. This allowed us to build atomic, reusable "building blocks." For example, our BDP-HR package depends on our BDP-Core-Data package. A customer subscribing to BDP-HR automatically gets all dependencies.
• Specialized Data Models: We engineered new flow types to handle the complexity of non-financial data:
  • Reference Flows: A system for managing multilingual, coded data (e.g., Code: "CDI", Label_EN: "Permanent", Label_FR: "Contrat à durée indéterminée").
  • Evolutionary Flows: A critical innovation for HR and Sales data. This flow type stores data with a validity interval (Start Date, End Date) on every row, allowing us to build "point-in-time" reports that show how data has changed over time (e.g., an employee's salary or department history).

The "BDP Workbench": An Internal Product Factory

We built a dedicated, internal Angular application that serves as the "factory floor" for our BDPs. This tool empowers our team to be product configurers, not just coders.

Click to enlarge

• Multi-Step UI: The Workbench guides the creator through the entire BDP creation process:
  1. General: Define name, version, and dependencies.
  2. Model: Define all data flow schemas.
  3. Data: Manually edit Reference Flows and upload sample data.
  4. Indicators, Visuals & Reporting: Use the platform's visual editors to build all KPIs, charts, and dashboards.
  5. Permissions: Define the package-specific roles (e.g., "HR Director," "Employee").
• Live Test Data: I mandated a "drag-and-drop" test data feature. Our BDP creators can drop a CSV onto a data flow, and the Workbench instantly populates all their dashboards. This created a tight, rapid "build-and-preview" feedback loop, dramatically increasing development speed.

Intelligent, Safe Upgrade Management

The most complex part of a versioned, multi-tenant platform is managing upgrades. I architected a robust upgrade process to ensure zero risk to customers.

• Data Schema Migration: When a tenant upgrades from v1.0 to v1.1, the system fully automates the data migration. It runs a non-blocking process that copies the tenant's data into a new table, applies any structural schema changes, and then swaps it into production.
• Impact Analysis Engine: Before an upgrade is approved, the system runs an "Impact Analysis" against the tenant. It scans all the tenant's custom reports and dashboards to see if they use a feature that the new v1.1 package has changed or deleted.
• Change Propagation UI: If a conflict is found, the administrator is presented with a simple UI forcing them to resolve it. For example: "The 'Old KPI' this report uses was deleted. You must choose to either Substitute it with 'New KPI' or Delete this report." This elegant solution prevents all "broken report" support tickets and makes upgrades 100% safe.