TrustWorks: Enterprise Multi-Tenant SaaS Platform

TrustWorks booth at SHRM Conference

I founded TrustWorks and led the product from its architecture through its enterprise deployments. The central challenge was making the software adaptable without turning each implementation into a separate product.

A Shared Platform with Customer-Specific Knowledge

TrustWorks connected people privately with others who had relevant knowledge or experience. Individuals could participate through work, personal, and alumni communities, with anonymity available for sensitive questions. Personal interests and life experience gave people reasons to participate beyond their immediate job responsibilities.

Serving enterprises required more than separate customer accounts. Each enterprise needed its own users, branding, organizational structure, and taxonomy of knowledge. General subjects could be shared across communities; a company’s products, suppliers, and internal competencies could not be reduced to one universal list.

TrustWorks interface showing general and company-specific subjects alongside selectable communities
General knowledge and company-specific taxonomies appear together, while community selection controls where a question is directed.

Defining the Core and Its Boundaries

I led the process of deciding what belonged in the reusable core and what would vary by deployment. Tenant separation, community membership, question routing, privacy, and communication were platform concerns. Branding, knowledge taxonomies, organizational groupings, and customer-specific components needed room to vary.

Deciding the boundary between capabilities built into the core, and those built custom for each deployment, was vital to the project’s success. Had we placed too much into the core, the product would force every enterprise into the same model. However, if we left too much as custom, then each implementation would become a fork — expensive to maintain and difficult to upgrade.

I connected customer requirements to a maintainable product architecture: identifying common capabilities, separating configuration and customer data from shared behavior, and determining where custom components were justified. The objective was a product that could accommodate real differences without letting individual deployments dictate the entire roadmap.

Aaron Sylvan customizing a Deloitte-branded TrustWorks implementation at a two-monitor workstation
Customizing a TrustWorks implementation for Deloitte, September 2010. The branded deployment is visible on the left screen.

Managing Development Beyond the First Deployment

The platform ran on PHP 5 with Zend Framework, MySQL, Apache, and JavaScript/Ajax, hosted at Rackspace, built with a distributed US/Romania development team under Subversion version control.

The management problem extended beyond delivering an initial implementation. Customer-specific work had to be considered alongside shared development and ongoing releases. A feature could satisfy one enterprise immediately while creating a continuing maintenance obligation for the platform. Deciding where that feature belonged was therefore a product decision, an engineering decision, and a delivery decision at the same time.

Enterprise SaaS at Scale

In enterprise SaaS, customization is part of the value a customer buys; the architecture has to give it a deliberate place and control its cost across the product’s lifetime. TrustWorks delivered that: one shared platform, multiple enterprise implementations, and branded customizations without forking the platform’s roadmap.

Skills

Posted on

August 1st, 2009