In the late 90’s and early 2000’s, companies like Yahoo and other consumer web companies were experiencing an unprecedented scale challenge –more than a hundred million users were using their web application. This was a scale that had never been seen before by makers of traditional software components and products. Shrink-wrapped products and platform components were written for large organizations and offline bulk processing and thus could not scale. From outside, I used to hear that Yahoo had to develop everything on their own since no third party software could meet their scale needs. Later on, I worked at Yahoo and saw first hand the scale challenges and built technology platforms to address them.
When I started at Jobvite in 2008, we started to bring in open source technologies and gradually phased out proprietary technologies because we wanted to build a platform that would scale for millions of users without breaking the bank. Back then, Jobvite’s application served 40,000 users. Today, Jobvite’s recruiting platform serves nearly 50 million users.
Although the majority of our platform stack is based on open source technologies, we have come across situations where we’ve had to look for a third party paid software component because either there is no open source alternative and/or we do not want to get distracted from our core. When we start to look at third party technologies, we hardly find anything that supports the fundamental building blocks of SaaS. Hence we are forced to build from scratch on our own or do major re-architecture of a third party component. Here are the five reasons why Jobvite and many SaaS companies can’t use third party software out of the box:
1. Multi tenancy – Third party software components are typically designed for a single company/organization (tenant) use. A SaaS platform needs to cater to multiple organizations using a single instance. Having all user requests served by a single instance has huge cost, development speed, version management and maintenance advantage, which ultimately result into a competitive advantage.
2. Security model – Most shrink-wrapped components/apps are developed for a single tenant use (one organization). A single tenant app usually has a very simple security model – one user has administrative privileges with access to everything in the system and normal users can see all or some of the data and take actions based on their role. In a multi-tenant environment you will need multiple admins – one admin for each company and ensure that the data access and actions for admin and non-admin users are restricted to their company only. This is perhaps the most important requirement from a data security and privacy perspective.
3. Scale – SaaS companies support thousands of companies and millions of users on their platform at any given point in time. Most third party single tenant apps/components aren’t created for this scale and they can’t reliably meet the performance objectives of a SaaS app. Though some 3rd party components can be clustered together for performance and scalability, they usually come at a heavy price due to CPU core or per unit licensing model. This high cost can erode the margins.
4. Scope – SaaS platforms start with addressing the most common pain points by supporting simple use cases and over a period of time they start to support complex functions, workflow and use cases. As the adoption of the platform increases, the scope increases. Hence demand for supporting internationalization (i18n), localization (l10n), business unit level data segregation, consolidation of data from global entities into a single source, multiple templates and complex workflow increases. Most underlying third party component technologies do not support these functions hence limiting the SaaS platform’s ability to meet the increased scope requirement.
5. Customization and personalization – SaaS platforms cater to a wide variety of organizations and users. Every organization has its own business process and users within the organization have their own personal preferences such as color, font, placement and notification preferences etc. If the underlying components can’t provide customization and personalization support then the SaaS platform cannot enable this for its end users. Many third party components can only support customization and personalization for a single tenant.
So what should SaaS companies do? Build their own?
The answer is complex and depends on:
1. If the component is core to your business
2. If you have the core competence to build the component/technology
3. If there are solutions that can meet some of the requirements if not all
4. If the cost of development or licensing is justifiable from your R&D cost and Cost of Goods Sold perspective
5. Opportunity cost etc.
If it’s not core to your business, do extensive research and compare all solutions in the market place and find a vendor who has the solution that meets at least few of your key requirements in a cost effective way. License the technology from the vendor and form a partnership with them to solve the problems collaboratively with you. However, be prepared to plan for contingencies and redefining of schedules. We currently have one similar project in the final stages of beta testing. Watch for a future blog explaining how we formed the partnership and what we learnt by collaborating with a partner on building a scalable solution.