At its most mundane SaaS is a deployment model; it is not a technology solution. It is the end result of a decision to accept a different business model, a subscription model with its concomitant impact on revenue flows. The business model will also influence the organisational structure necessary for executing a product development program. Along with this, adopting streamlined agile development techniques should in all eventualities carry a lesser financial strain. The subscription or pay-per-use business models will influence both the revenue flows, and the cost of product maintenance. Since the decision for the subscription model impacts the net revenue flows it has to be a strategic business decision by the stakeholders. The benefits of a subscription model could not have a better certification than Microsoft, which has successfully forayed into the market with Office365. Once the subscription model has been decided upon there are many options available for getting the product to the market.
- Cloud and SaaS go together, a little like a “horse and buggy”; if you are not using the cloud to deploy your SaaS product then all the gains made in deciding on SaaS are wasted. Cloud is the environment for SaaS based products, it requires no capital expenditure on infrastructure, and it provides economies of scale.
- Licensing stops being an issue.
- Since many clients are using a single instance of the product, change management requires a very robust process. Versioning of the service contract is a solution, but exposing the versioning to the consumer is a bad idea.
- SaaS implementations allow a more granular costing of features in the product.
- Cloud implementation also provides an easier route to integrate with social networks to obtain user feedback.
- Integration also offers a better route for adding features in a SaaS design and cloud deployment.
- With shrink wrapped software data location is rarely an issue. But with location of personal (and sometimes other) data becoming a data compliance issue, cloud solutions have to be much more flexible, and of course handling multi-tenant data adds to the problem.
- Embracing the SaaS model also implicitly assumes embracing service oriented design. Cloud deployment would of necessity require a componentised design with REST services, and JSON as the communication medium for the business objects. Although, SOAP services are very robust with documented standards, they are comparatively difficult and take longer to implement, and in comparison JSON is far more compact than XML.
- This doesn’t need repeating, but like most software developments, SaaS products are best developed using the agile method.
- Map each small team to a specific context and hence component and its model. Each team can work independently within their context and communication between components is via an asynchronous messaging bus. Such a design effort will also enable the components to be handled as individual apps and the teams to work independently and in parallel. For example, when developing a HR management system, most would also provide a travel component. The travel component provides all the features necessary for managing travel of employees in the organisation. The messaging system could be used to reduce its dependency on other modules to a minimum, and where absolutely necessary it will use the same REST service as all other consumers. This component can be designed and built and deployed independently with its own data model.
- If executed correctly, the above design will produce a microservice implementation, where the components do one thing and only one thing, but of course, they will do it really well. Such a microservice implementation will divorce you from single implementation language and single data base management system, but may raise some maintenance issues.
SaaS has to be the only choice for developing software products, for all the reasons that have been mentioned, freedom from license hell, easier maintenance, and speed to the market. Customers prefer to pay for what they use, they do not want to buy a product with umpteen unused features, and have a room full maintenance staff to manage the product, or deal with slow to respond support services. Software use must be like any other utility, be it gas or electricity. Metered and priced according to cost of resources used plus profit margin. This blog is written with the independent software vendor in mind.