• Redmonkey
• Services
• SaaS Product Development

Software as a service (SaaS) is a software distribution model in which a cloud provider hosts applications and makes them available to end users over the intenet. In this model, an independent software vendor (ISV) may contract a third-party cloud provider to host the application. Or, with larger companies, such as Microsoft, the cloud provider might also be the software vendor.

SaaS is one of three main categories of cloud computing, alongside infrastructure as a service (IaaS) and platform as a service (PaaS). A range of IT professionals, business users and personal users use SaaS applications. Products range from personal entertainment, such as Netflix, to advanced IT tools. Unlike IaaS and PaaS, SaaS products are frequently marketed to both B2B and B2C users.

How does software as a service work?

SaaS works through the cloud delivery model. A software provider will either host the application and related data using its own servers, databases, networking and computing resources, or it may be an ISV that contracts a cloud provider to host the application in the provider's data center. The application will be accessible to any device with a network connection. SaaS applications are typically accessed via web browsers.

As a result, companies using SaaS applications are not tasked with the setup and maintenance of the software. Users simply pay a subscription fee to gain access to the software, which is a ready-made solution.

SaaS is closely related to the application service provider (ASP) and on-demand computing software delivery models where the provider hosts the customer's software and delivers it to approved end users over the intenet.

In the software-on-demand SaaS model, the provider gives customers network-based access to a single copy of an application that the provider created specifically for SaaS distribution. The application's source code is the same for all customers, and when new features or functionalities are released, they are rolled out to all customers. Depending on the service-level agreement (SLA), the customer's data for each model may be stored locally, in the cloud or both locally and in the cloud.

Organizations can integrate SaaS applications with other software using application programming interfaces (APIs). For example, a business can write its own software tools and use the SaaS provider's APIs to integrate those tools with the SaaS offering.

SaaS architecture

SaaS applications and services typically use a multi-tenant approach, which means a single instance of the SaaS application will be running on the host servers, and that single instance will serve each subscribing customer or cloud tenant. The application will run on a single version and configuration across all customers, or tenants. Though different subscribing customers will run on the same cloud instance with a common infrastructure and platform, the data from different customers will still be segregated.

The typical multi-tenant architecture of SaaS applications means the cloud service provider can manage maintenance, updates and bug fixes faster, easier and more efficiently. Rather than having to implement changes in multiple instances, engineers can make necessary changes for all customers by maintaining the one, shared instance.

Furthermore, multi-tenancy allows a greater pool of resources to be available to a larger group of people, without compromising important cloud functions such as security, speed and privacy.

SaaS advantages

SaaS removes the need for organizations to install and run applications on their own computers or in their own data centers. This eliminates the expense of hardware acquisition, provisioning and maintenance, as well as software licensing, installation and support. Other benefits of the SaaS model include:

•  Flexible payments. Rather than purchasing software to install, or additional hardware to support it, customers subscribe to a SaaS offering. Transitioning costs to a recurring operating expense allows many businesses to exercise better and more predictable budgeting. Users can also terminate SaaS offerings at any time to stop those recurring costs.
•  Scalable usage. Cloud services like SaaS offer high Vertical scalability, which gives customers the option to access more or fewer services or features on demand.
•  Automatic updates. Rather than purchasing new software, customers can rely on a SaaS provider to automatically perform updates and patch management. This further reduces the burden on in-house IT staff.
• Accessibility and persistence.  Since SaaS vendors deliver applications over the intenet, users can access them from any intenet-enabled device and location.
• Customization. SaaS applications are often customizable and can be integrated with other business applications, especially across applications from a common software provider.

SaaS development lifecycle

The development lifecycle for a SaaS product differs from the traditional software development lifecycle. There are several factors affecting the choice of core architecture.

In order to prepare for all these challenges, you need to understand the general SaaS implementation methodology and the specifics behind it. The best and fastest way to get a general idea of how SaaS development works is to examine the SaaS development lifecycle.

Note that the SaaS Development Lifecycle is a cycle, as work on the application goes on after its release. After an application is launched, you have to iterate through phases 3–6, from planning to operations.

Envisioning

During the envisioning phase, the company leadership will identify new business opportunities, how to upsell to existing customers, how to expand the customer base by reaching the Long Tail, and they will strategize to extract more value from their intellectual property. Envisioning of a SaaS service is not that radically different from the traditional software envisioning phase. As SaaS opens up additional opportunities due to discoverability, reachability and scalability of cloud hosted services, business leaders will have fewer sales, marketing and IT agility constraints in terms of aiming high. Business leaders will define the vision and scope of the SaaS service while keeping the previously described cloud service tenets in the background.

During this phase appropriate candidate applications that can benefit from leveraging the characteristics of the cloud are identified.

Platform Evaluation

Even though platform evaluation is an implicit part of a typical software development lifecycle, SaaS development requires an explicit list of activities that focus on the cloud provider selection. The Cloud provider is such a critical success factor of the entire operation that the evaluation must be done with rigor, especially if mission critical systems are planned for cloud deployment. ISVs and customers need to select a cloud provider that helps them realize the services strategy defined during the envisioning phase. The evaluation phase will also help in the identification of a cloud service provider for the current service in question. Architecture proof points will be intersected with a cloud provider’s platform capabilities in arriving at the decision of “fit for purpose”. There may be cases where the ISV’s existing relationship with a cloud provider will play a big role in tweaking the architecture to fit the cloud provider’s platform.

Planning

After having identified a cloud platform that is feasible for building the SaaS service, the planning phase will help plot the course of action for a predictable delivery of the service. Planning largely depends on the type of service and the organizational culture. The rigor of the activities and the resulting deliverables depend on the complexity and the size of the service. The activities in this phase are pretty much similar to those of the traditional software development lifecycle.

Subscribing

Subscribing is an important phase of the SaaS Development Lifecycle during which a production quality subscription is acquired. In this phase, based on the previous trial experience, the cloud provider is subjected to more scrutiny, driven by the production deployment and operational needs of the service being planned. The architects and IT Professionals will revisit the deployment models; subsequently upgrading schemes, support processes, business continuity and disaster recovery. The procurement team will work with the cloud provider in identifying the right level of subscription, either IaaS or PaaS, with full awareness of the pricing models, what-if analysis, and support costs.

Developing

This is the service construction phase during which design specifications are refined and translated into code artifacts and supporting documentation. The Developing phase is composed of a series of iterations built on top of the core architecture and high level design specifications. The architecture and detailed design may change based on the discovery of new functionality and refinement of existing functional specifications. The resource allocation, scope of functionality and project schedule determines the granularity and number of iterations. Developers and solution architects will work hand in hand in designing the iteration make up and involving end users throughout the phase for a quality service delivery.

Operations

Even though deployment and operations are an important part of the traditional SDLC, due to the explicitness of the service level agreements, support contracts, compliance, security, and shared infrastructure; activities during the Operating phase are critical for the success of the SaaS operations. The insights acquired during the evaluation, subscription and development phases are blended with the operational characteristics of the cloud platform in creating deployment and operational processes for running the cloud hosted service with the best possible systemic qualities. The evaluation and subscription phases of the SaaS development lifecycle would have given a detailed knowledge of the cloud platform operational aspects; however, in this phase the platform operational aspects are integrated and customized if necessary in the context of the service being deployed.

Conclusion