SaaS & Cloud Services: Business Model Scalability Checklist – Part 2

This is the second half of our two part series covering the points you should consider when planning a SaaS or Cloud Service to achieve a scalable business model. That means – if you want to make money over the long run from your service this is a checklist you should consider. If you haven’t already read the first installment – go there before you start this half of the article.

Checklist for Business Scalability in the Cloud

Continued from Part 1…

9. Client functionality is available on demand, functional capacities are clearly defined by packaging. Just like the implementation of clients, all functionality should be available as authorized by the package the client without manual intervention. When a client authorizes functionality, they should be able to easily understand the capacity (mb of storage, number of transactions, etc), roles, and situations where it applies without help.  This may sound elementary, but in a utility-based model if there is not a simple way to recognize and manage capacity, clients will balk at buying. Less buying = Less Growth = Constraint!
10. Client functionality that is elastic in nature can be commissioned automatically on demand, transparently to clients. Current virtualization capabilities go beyond the simple server replacement paradigm and now allow compute, web roles, database capacity, storage, content distribution and more to be broken out and managed separately. Leveraging this capability requires a different architecture and an awareness of the scaling characteristics of individual application components. Example: If a feature implements storage – the storage is available immediately without manual intervention when the client is ready to use it. The storage expands to the amount provided by the package the feature is a part of, on demand.
11. Client instances and unneeded capacity can be closed and decommissioned automatically. Unneeded capacity adds to overhead. Processes and automated operations need to be able to decommission unnecessary instances and client capacity without intervention. At the level of a single client, an extra gigabyte of idle capacity may seem like a minor issue but when spread over hundreds or thousands of clients the capability and cost that can be reclaimed becomes significant. By managing to a level of total spare capacity to allow for required allocation on demand, the cost of the entire operation is kept under control while the capability remains intact.  In cloud-based services this needs to be an automated function that is part of the application.
12. Client functionality that is used on a scheduled basis can be activated by scheduled batch provisions that consume resources only as long as the batch is being processed. Virtualization allows capabilities to be brought up as needed, but there is a time delay to allow resources to “spin up” and become available. Recognizing that some functionality is used on a scheduled basis (reports, payroll runs, sales to inventory replenishment) the total amount of “spare capacity” a service needs to handle ongoing demand can be lowered by providing for scheduled jobs that request the resources they need, wait until they are ready, run the required function and then shut down the capacity in an orderly fashion. This is a practice that has been in use since the first mainframes – which were of course shared capacity. We will see this approach coming back, especially in the case of compute heavy jobs that can be scheduled and it just makes sense. Why do you need to pay for your top level requirements to be available fulltime when you only use it once a month?
13. Client functionality is separated where possible into utility-based costing that can be packaged, priced and sold in packages that match market and client needs. Utilities measure use in ways that related to the value a client receives. Features in applications can also be matched to resource usage and costs. As an example: Running payroll requires data access, movement, storage, computation, etc. Should the client that runs one payroll a month for ten salaried staff members pay the same as the client that runs payroll weekly for 500 part-time employees? If your feature package and pricing is based on the assumption that you will have a lot of small clients and in fact you have a lot of large clients with intensive payroll calculations you can be losing more than you make every time they run payrolls. When companies installed and maintained their own servers, they bore the cost differential for the implementation, resource usage and maintenance. In a cloud service, the vendor carries the cost unless utility-based pricing allows them to recapture them from the clients who get the most value from the service.
14. Availability, reliability, data surety, and client support can be packaged in levels to fit client requirements. Virtualization allows more control over these issues and allows vendors to consider offering SLAs that fit specific market needs as a part of service packaging. One option might include data backups that are retained off platform for a specific number of days so client instances could be restored or rolled back as needed. Another might include the providing failover protection to another data center in case of an extraordinary failure at a specific site. The point is that providing these features has a cost and rather than guessing that clients want them – they can be offered as part of the service in ways that offset the costs and address market needs.  The assumption that clients would see these issues and take the steps they needed to offset their risk is naive. The recent Amazon failure showed that clients will immediately blame the service provider for their own failure to recognize their risk and plan for necessary redundancy. By building options into SLAs that can be purchased as needed, the provider makes it clear what is service responsibility and what is left on the table for the client to offset.
15. Clients can chose from more than one model of automated billing and settlement to allow purchasing patterns to match market requirements. It may seem attractive at first to have a single option to pay for a service on a monthly basis, but after the service becomes “embedded” in the processes of a client, many will want the option to modify how they pay for services. They may not want to pay by credit card – preferring to pay yearly by invoice or by bank transfer. Whatever the motivation, there has to be ways for the application settlement system to deal with upgrades, changes in the number of users during paid periods, changes to contract duration, etc., so that clients are not lost and manual intervention is not required to take care of what should be minor billing issues. In billing and settlement we’ve been assuming for too long that “one-size fits all.” In just the difference between the enterprise market and SMBs it is easy to understand different motivations
16. First level client support is self-serve. All subsequent levels can be reached from the application and all interaction is monitored and logged. Providing self-serve support for users is a normal feature of applications today, but having them in a multi-user, multi-client configuration gives benefits to the service and the user community it supports that are hard to duplicate in other environments. If monitoring and logging for support events is in place, frequent issues can be addressed as a part of improving support and product management backlog. User communities can highlight and provide insight into specific issues. Support issues that require development can be addressed directly by reviewing logs and interviewing users. Since service support is part of the “outsourcing contract” with clients, providing support access from inside the application without requiring users to sit in endless phone queues should be considered a basic requirement of cloud services.  This doesn’t mean it has to be implemented as in-product chat, but it should allow users to notify support, receive acknowledgement and then a direct response by phone or email depending on the support policy and issue involved.
17. Product management, feature monitoring, reporting and feedback are built into the application. SaaS and cloud services have largely moved past the days of announced product “versions” and long development cycles in favor of an agile-based development approach. Now product management is quickly moving to match that move with in product feature monitoring, user feedback and feature planning that is integrated with the user community. When implemented properly, this results in an agile product management cycle that ties community and feature monitoring directly into a continuous development cycle – increasing user satisfaction, application “stickiness” and client retention. But in turn, this means a product management needs to rely on reporting and community management functions in the application to reap the benefits most directly.
18. The availability and usage of service functionality can be granularly controlled, packaged, and monitored. When planning an application or adding new features, it is hard to know how functionality may need to be managed as part of a package or role at a later time. Certain features may only be of value in specific verticals or they may actually represent a part of what appears to be a separate product in a different market, but breaking features out and managing them discretely is only possible if they have been set up for this type of control from the beginning. Can a report that requires a high resource allocation be limited to a number of runs under a certain type of subscription? Can clients buy a quantity of transactions in a package like they would buy donuts?
19. Metadata from feature monitoring can be anonymized, stored, analyzed and used to drive additional services, reporting and provide additional income streams. Aggregating data across the community of clients that use a product can provide a lot of valuable insight. How much time do users spend online in the product? How much time do they spend performing a specific task? Which segments of the community use features X and Y the most? Where are clients using feature D? At what times of day do they use it most? The information can be brought together in reports that give the client community new insights into features, best practices and when tracked over time – sold. On a purely selfish level, metadata can be part of the metrics you use to manage the business. And in some verticals, the insight can be sold to third-parties to help them understand market drivers.
20. Language frameworks are in place so that additional markets can be reached with minimal effort over time. Adding additional languages to a service is relatively easy – if you have the frameworks in place from the start. If you don’t, back-porting a single language application can take a lot of effort and time. Initially, you may think your only market is in your own backyard – but what if a strong multi-national client wants to use the application in places that don’t use your chosen language?  Will you be able to just walk away?

These are certainly not the only questions that SaaS and Cloud Service product developers should ask themselves or the only significant issues in achieving business model scalability. But they are important to consider. How does your application score against this list? What other points will you consider?

Follow Me on Twitter