| | JUNE 201919CIOReviewAs multi-tenant SaaS platform providers grow, it's important for them to enhance their feature sets to support more customers with different use cases over time. As they do, it's almost inevitable that they will need to confront the challenge of how to meet the unique functional requirements of customers in the short-term, while also building generic capabilities for scalable growth over the long-term. This tension between acquiring new business today and building for scale tomorrow is more acute among SaaS platforms who target the enterprise segment.Enterprise customers have invested heavily over the years in complex businesses and operational support systems that are key to running their companies. They rarely decide to replace those systems overnight to adopt a new provider's solution. Instead, most enterprises expect technology providers to adapt their solutions to the unique, and often bespoke, environments of the customers they hope to serve. As a result, SaaS platform providers often struggle with the choice of whether or not to build a feature generically. Meaning, should they build features customers can adopt without additional coding (also known as `feature flagging'), or build more targeted customizations to meet the unique needs of a specific customer's use case? Out of all the factors, time-to-market can be a key consideration in such a decision, since it usually takes more development time and effort to create the generic feature than the customization. When confronting this scaling conundrum of configurability versus customization in SaaS platform development, below are a few considerations for an enterprise SaaS provider (and its customers) to examine:SCALING SAAS PLATFORMS: CONFIGURABILITY VS CUSTOMIZATIONBy Michael Cassin, VP of Product Management at AppDirectVisionary platforms are extensibleThe most visionary multi-tenant SaaS architects design their technology with expansion to additional customer use cases and markets in mind from the start. They provide a well- structured set of APIs on top of a service-oriented architecture and, importantly, as much configurable functionality as possible. Contemplating such `extensibility' from the start, or at least investing in the refactoring work required to add it in later, enables the platform to meet the needs of new customers, while also allowing their existing customers to seamlessly adopt the features they need. This flexibility is important to enterprises, as their own internal technology stacks and related operational processes evolve and become more tightly integrated with the SaaS platform's solution.Balance product investments to avoid technical debtThe main challenge for enterprise-focused SaaS platforms is how to provide the flexibility that larger customers expect without building one-off customizations that can cause technical debt to accumulate. Why should an enterprise technology buyer care about a SaaS platform's amount of technical debt? Simply put, it can impact the ability of the SaaS provider to maintain code quality.The SaaS platform's product development team is responsible for prioritizing features and capabilities that will achieve the best product-market fit in the shortest period of time, as well as creating balance across the platform's product roadmap. Specifically, a balance between:a) Building new generic functionality that is flexible enough to be reused across multiple customers;b) enhancements to existing functionality to address additional use cases; andc) maintaining product quality and reliability via bug reduction and elimination of technical debt. Given the urgency to acquire new revenue and secure reference customers, it can be all too tempting for the product management team to compromise on that balance ­ accepting more customization requests to the detriment of generic feature Michael Cassin
< Page 9 | Page 11 >