DEV Community

Serhiy Kozlov
Serhiy Kozlov

Posted on

The SaaS Application Development Lifecycle

The depiction of an enterprise which has not taken advantage of SaaS is humorously portrayed by Basecamp, a SaaS project management provider:

What Basecamp is saying is that enterprises who make the decision to purchase the services of a SaaS provider will have a far more organized and efficient operation – one that is managed, is SaaS-based in the cloud and which allows all members of a team to function successfully.

Indeed, this seems to be the biggest draw of SaaS, along with the fact that all of the data and access to that data is stored and managed off-site, relieving an enterprise from software and hardware purchases and upgrades/scaling. Further, it allows designated employees to access that data from any location. And, in fact, SaaS providers deliver greater security than most enterprises can provide in-house.

In short, SaaS provides a real solution to businesses struggling with traditional and inefficient in-house systems.

Because of these benefits, SaaS is a rapidly expanding niche, and many entrepreneurs and innovators are moving into the realm of SaaS application development to solve enterprise issues and to become a reputable vendor in the marketplace.

The SaaS development process, whether for external sales or internal use, involves a life cycle, each piece of which is critical to an end product that is solid, useful, and appealing to customers or in-house staff.

The SaaS Development Life Cycle Begins With The Vision

 SaaS Development

The vision begins with identifying a need on the part of the organization or, more often, other enterprises, for a SaaS product. The product must solve a problem for it to be viable. Ideas will be thrown out and evaluated. Market research will be conducted. In the end, there will be a vision of the scope of the SaaS product that will be developed.

Developing the Plan

Developing the Plan

How will the product be developed, launched, and marketed? Software development strategies for building a SaaS are obviously the first concern, for this will involve the initial outlay of resources. Decisions regarding SaaS developers who may need to bring on board, the technical specifications which those developers will then use through that coming state of development, and, of course, the projected budget. At the end of each iteration of the project, planning should be reviewed and modified as necessary.

The Subscription Stage

The Subscription Stage

This stage in the SaaS software development life cycle comes as all decisions relative to cost and architecture have been finalized. It is the time when there is plenty of communication with the selected cloud provider. Part of this communication and cooperation will be testing that provider’s capabilities and an evaluation of their performance. This process should culminate in a subscription with that cloud provider, with custom details of the services to be provided. While there are many factors to be considered in the choice of a SaaS platform, probably the most important is the cloud provider selection.

During this phase, the other tasks will include the formulation of backup and disaster recovery plans, so that you can ensure top performance and service availability to your clients.

Each iteration, as completed, should be tested and the cloud provider’s performance audited. The subscription details may have to be modified, and, in fact, this is common.

The Development Stage

The Development Stage

This stage is complex and is where the proverbial “rubber meets the road.” Many decisions must be made in terms of architecture. There are, however, some basic elements that must be present for SaaS to be considered valuable to potential clients and to be a profitable product for the SaaS development company. They are as follows:

  • Multiple Tenants: there is no point in developing SaaS for sale unless it is developed for many tenants with the potential to scale later on.
  • User Discoverability: the software must be user-friendly and easy to pick up.
  • Security: customers must be shown and must believe that there is exceptional protection of their data – better protection than perhaps they can provide on their own. Encryption and a highly secure access process are critical.
  • Customer Support: processes built-in for this, as well as the rapid rollout of updates.

With these basic tenets in mind, the development and architecture will mean the following:

1. Selection of a Software Development Methodology

There are many choices in what is known as the “software development lifecycle.” The most common are as follows:

  • Rapid Development: a prototype is quickly developed for speed of development and then tested.
  • Iterative – small scale development with subsequent iterations for scaling.
  • Spiral – development divided into cycles, each of which is evaluated and then the next cycle may be developed with a different methodology.
  • Waterfall – The entire project is developed through a sequence of phases.
  • Agile – a type of iterative development with feedback on each iteration, so that refinement can occur before the next iteration begins.

Currently, Agile is the most commonly used; however, many SaaS project developers do switch back and forth among some of these and many other methodologies as they work through phases of a project. Sometimes, the architectural details demand it.

2. SaaS Will Mean HTML5 (at least for desktops)

New products will use HTML5 technology – it is most suitable in today’s environment. This is because it can provide RIA (rich internet applications) with no need for legacy plugins.

When Microsoft announced that it was discontinuing support of Windows XP in 2014, there began a slow death of Microsoft platforms that would not support HTML5. Current browsers (IE, Firefox, Chrome) all have a model that updates their browser automatically.

There may be some lingering issues with the use of HTML5 for mobile devices but they are rapidly disappearing. Still, testing any software on mobile should be a consideration. If developers see issues, then a native app may be the best solution.

3. SaaS Requires Published API’s

SaaS products must have API’s that provide for the development of other capabilities by value-added resellers and other third-party developers, and that will integrate with other software, such as that of Big Data and analytics. If clients cannot access their data except through the SaaS package they have purchased, then that vendor has to provide the API.

API’s have to be consistent and should be maintained after publishing, especially for any additional version of the software. In short, developers must ensure that APIs can be extended. This will require a very thoughtful architecture.

4. Multi-Tenancy Issues

SaaS development is, by definition, server-side development. When multiple clients share a common server, the demands on developers is far greater than developing for a sole tenant. Obviously, solid security is a must, so that data is isolated from other tenants. Given this, developers should provide for tenants who want dedicated storage that is in no way co-mingled with that of other tenants. Thus, developers must decide among three models for multi-tenant storage – a database schema for each tenant, a database for each tenant, or a fully shared database, with each tenant accessing its individual data via an ID. Decisions must be based upon the original vision – what types of clients will you market to?

5. SaaS and Stateless Architecture

Stateless architecture is preferred because it provides top performance, elasticity, scalability, and tolerance for fault. If applications are stateless, there is no need to allocate storage of previous requests, and the cost is lower. They can also scale easily when there are spikes in usage and contract as use declines. Stateful architecture requires more management and does take up more infrastructure resources.

Certainly, stateless SaaS architecture is not required, but it will provide the best performance.

6. SaaS Upgrades – Frequent and Non-Disruptive

The process of upgrades must be built into the architecture with a methodology that will not disrupt user clients. Generally, SaaS companies do not have a lot of versions out there – usually two. If a new version is developed with upgrades, it can be done on a separate server before any clients are migrated over – this minimizes disruptions.

SaaS companies have to be wary of disrupting the client, have to consider UI changes that might require training, and the software architecture has to provide for strong resilience from a failure with short recovery time.

7. Redundancy and High Availability Level

Failures of the software, a machine instance, data availability, the network, or data integrity do occur. The architecture must anticipate this and include the technology to recover from failures with the least disruption to clients. Redundancy can be provided by the database platform or the Infrastructure as a Service. Some IaaS providers will provide up to three copies of the data, ensuring data availability. Corruption of data is the toughest, and it will require that the software is architected to recover data from a consistent prior state.

8. Operations – Requirements for Development

Integration of such things as new tenant on-boarding and billing must be built into the software architecture. The same goes for monitoring, detection of faults and intrusions (and remediation), and security. Prior to subscribing to a SaaS provider, all of these development ops were the responsibility of the enterprise’s IT team. No longer.

The software must also provide for load balancing and providing on-demand additional resources. Help is certainly available from IaaS and PaaS providers (if they are used) and third-party tools, but integration must be in the software product itself. There is no single model for all of this, and developers will have to be creative and innovative.

SaaS Implementation Methodology and Deployment

SaaS Implementation Methodology and Deployment

Once the software is deployed, there will be frequent updates and the need for such things as security patches, so that support requests can be kept to a minimum and the UX is continually improved.

Helpdesk calls and/or support tickets all result in increased operational costs, so the goal should always be to automate as much as possible and, of course, minimize the calls for service assistance. Constant monitoring and patches/updates will keep customers happy.

SaaS Development, Operations, and Management are Unique

SaaS Development, Operations, and Management are Unique

Anyone or any enterprise considering SaaS development must invest heavily in the talent to get it done. This is the most expensive part of the endeavor, requiring very specific skill sets. And, if you intend to have a top-rated piece of software – robust, expansion-ready, innovative, well-received UX and UI, secure, and reliable in its implementation – then you must be prepared for the costs involved.

You Have Another Option

If you have an innovative SaaS idea, bring it to our development team at Romexsoft. We have a group of first-rate pros with years of experience in SaaS development. They will collaborate with you through the entire SaaS lifecycle and produce exactly what you envision. In the end, you will have world-class software to take to the marketplace.
Originally published at Romexsoft’s blog:
The SaaS Application Development Lifecycle

Top comments (1)

Collapse
 
annaboy75634026 profile image
Anna Boyko

Thank you! Very interesting info