“Scalability” is one of many cloud buzzwords that is fraught with confusion. Most of the time the term is used with a mixed meaning – covering both technical scalability provided by implementations of infrastructure virtualization and business model scalability. The problem is technical scalability by itself cannot impart scalability to a business model. But, on the other hand, technical scalability can be a crucial component of a successful and scalable cloud business model.
In this two part series, we will address the key technical capabilities required in a cloud service to achieve a scalable business model. I’m writing this article because we have found the confusion to be a common thread throughout many interviews and consulting sessions with software vendors bringing their products to the Internet as services. Almost without exception, vendors address end-user functionality clearly, but fail to address their own need to have a successful, repeatable and scalable business model.
A business model is said to be scalable when the incremental cost of acquiring, implementing, servicing and supporting a client drops as the number of clients increases. In a few business models, the service is repeatable but total costs remain relatively stable as the growth curve rises. In these cases, incremental profit needs to flow from each new client regardless and attractive scalability will be hard to achieve. A fully-scalable business model is not constrained by resources such as skilled staff or materials. Full scalability is not achievable in all markets or business models. In all business models, the total incremental cost per client will eventually reach a point where it is zero or flat.
When the software industry was primarily selling licensed software – scalability was easy. ISVs would develop a software version once and sell it as many times as possible before investing in another version. Each incremental sale from a version lowered the total cost of goods for the ISV. ISV’s selling licensed software only noticed a constraint when the cost of support to each incremental client was more than the client’s share of the cost of goods generated by application development.
In a cloud service model, the challenge is to identify the services and features you must provide and then implement them so that the incremental cost of providing services for each client goes down as the number of clients grows. To accomplish this, the application has to be planned to support a scalable business model from the beginning. Otherwise the cost, risk and disruption from later changes will itself constrain scalability and cause costs to be higher rather until the investment is offset by profit.
The other challenge is that even a bad business model can look scalable during initial marketing ramp-up and growth. Rapid growth can temporarily obscure the reality that the costs of implementation, support and operations required are not actually going down as the client base grows. Eventually though, as the growth curve begins to flatten and constraints appear, the pressure to maintain cash flow will make it apparent that the business model cannot be sustained long enough to reach an attractive profit. In services where the amount of skilled staff required to implement each client is remains constant regardless of the number of client served, the cost and time required to acquire and maintain skilled staff will eventually become a brake on growth.
The length of the curve from the point where a business model begins operation to the point where it reaches a zero incremental cost per client, a flat level of cost per client, or a constrained-level of costs per client is the business model’s scalable range. As cloud service providers, the goal is plan the service so you are able to bring incremental costs per client to the far-end of the scalable range – to the point where the incremental costs per client are the most optimized.
The following points are aspects of the application and technical implementation that can provide leverage for business model scalability. They do not have to be achieved on day one of offering a new SaaS product or cloud service. However, to have a successful and scalable service from a business point of view, the application, its architecture and the infrastructure that supports it must be capable of achieving these points within a reasonable period of time without an application rewrite or major reconfiguration of the service.
Checklist for Business Scalability in the Cloud
- Application architecture is component-based, uses web-services and the database is multi-tenant. In today’s development environment for cloud services, component-based architecture and web-services should be a given. These approaches provide much of the flexibility and continuous improvement we take for granted in online applications today. And without getting into a lot of religious battles about multi-tenancy – the point here is business model scalability. If you do not use the most scalable database architecture, you will always carry the risk and skills necessary to scale and manage alternative approaches.
- Application maintenance and updates can be applied, or rolled back, to all client instances without business interruption and with minimal effort. In today’s market, cloud services are expected to have both continuous updates and operation. The procedures required to maintain application availability during updates need to be integrated into application development, straight-forward and repeatable. Again, this has become an expectation across the industry. If your service has significant “down-time,” either planned or unplanned, your availability and reliability will be suspect from a client point of view.
- Operational service functions (e.g., subscription management, billing, etc.) and reporting are part of the application but separated from client functionality so that they can be extended to additional applications over time, they can be tracked and managed. Operational functions generally scale in a linear fashion as the client base grows. If they are planned properly, they can be leveraged over multiple applications during the service lifecycle – driving down the operational cost. Not having operational functions integrated and automated as part of the application means manual processes will add to the cost of each client, payment cycle, billing change, etc. Manual operations will seriously constrain scalability and profit.. These functions facilitate client interactions with the service provider but they do not directly add to the value a client receives from the service. That doesn’t mean however they are unimportant. If these functions are not automated as part of the service they become a brake on growth as service operations struggles to keep ahead of growth while keeping costs to a minimum.
- Application services can be purchased and embedded in the offerings of other services. Planning cloud services to allow other vendors to leverage application functionality creates additional channels at very low cost and greatly improves business model scalability. It is less important to know when or how it might happen that other vendors will want to leverage a service than it is to have the capability. When it does happen, it should require nothing more than a sales negotiation.
- Outside services can be used to extend operational or client functionality as necessary. Application development is a part of the total cost of a cloud service. Just as it is important to allow other vendors to leverage service functionality in their offerings, it is equally important to have the option of leveraging other services so you can adapt their functions into the service without “redeveloping the wheel” unnecessarily. In early phases of the product lifecycle, software development will be the largest contribution to cost and will be carried as a burden over many clients before the business can reach positive cash flow. Leveraging outside services for selected functions (like pricing and billing for instance…) can lower the initial cost of development, significantly improve functionality for non-core needs and allow development effort to be focused on areas that have higher value for clients.
- User interfaces can be extended to alternative platforms through web services and API calls to allow users to access to client functionality on emerging devices. The market for smart phones, tablets and mobile devices is exploding but it is also highly fragmented. Tying a service to a single end-user platform can constrain growth and put the application in a lockstep with the lifecycle and fortunes of the selected platform. Providing standard, documented methods to extend the service to end-user devices as they develop greatly increases the market and lowers the risk that extensive rewrites will be needed to adapt to new technology.
- Client implementation is automated and immediate, on demand. Manual processes and delays required for operational functions like client implementations are costs and risks. Client implementations should not require anything more than authorization from the billing and settlement component of an application. This is a good example of the “consumerization” of software. The increasing use of online applications by consumers has created expectations for user-experience that now have moved to business software and services have to adapt to current client expectations.
- Client instance configuration and integration is client-driven. One-off customizations and integrations should be strongly avoided in favor of embedded configuration choices and API calls that provide necessary data integration. Developing and maintaining split versions is simply too risky and expensive to be considered a sustainable business practice for SaaS and cloud services. I’ve sat with many prospective vendors who say “our users demand customization” and they simply cannot imagine any other course. But the reality is the practice only works when clients are willing to deal with the costs of system integrators, delayed version updates, and the maintenance issues the practice brings in their own data center. When clients outsource to a service they expect you to bear the cost and risks. Standardizing a product to one version, including those configurations that take the place of 80% of the individual issues clients want to address, solves a great deal of problems for both the client and the service while it increases overall business scalability.
Is this all? Not by a long shot. We’ve got 12 more points in in the second half of this article. Business scalability is a core competitive edge in SaaS and Cloud Services – so please – join us for Part 2.