The SaaS Development Lifecycle

Overview

Cloud service development requires a different approach than the traditional software development lifecycle as the cloud provider becomes a critical success factor of the overall project. In a traditional software development setting, more emphasis is put on the functional aspects because it is deployed on an on-premise infrastructure with implicit security, compliance, control, operational transparency and perceived service level requirements. Another important factor is the cost of operations. It often takes back seat, especially in cost centers, due to the sunk cost and horizontal charge models. The main objective of this paper is to focus on the lifecycle aspects of SaaS service development and outline the motivation, inputs and deliverables of each activity for all the phases of the lifecycle. Cloud services can be built for internal consumption as well as for selling to external customers. The focus of this article is the cloud services built for external consumption as these require rigorous architecture practices to incorporate the service tenets necessary for a successful services business model. Even though the SaaS (Software as a Service) Development Lifecycle outlined here is scoped at external facing services, the process can easily be adopted to internal private cloud based applications that target internal users. It is clear that even enterprise IT departments have to start looking at themselves as Service Providers and act accordingly.

As a regular reader of InfoQ we assume that you are familiar with terms such as SaaS (Software as a Service), PaaS (Platform as a Service), and IaaS (Infrastructure as a Service) and the role these categories of as-a-service cloud providers play in the cloud ecosystem. We also assume that you understand Service Providers provide finished services for consumers and/or other businesses while Cloud Platform Providers host finished applications for those Service Providers.

Cloud Service Tenets

In order for a cloud service to meet the adoption goals and reach their target demographics in an economically viable manner, cloud services need to be built on a foundation that manifests certain principles at a fundamental level. These principles are Discoverability, Reachability, Economics, Scalability, and Supportability which are briefly discussed below. We like to call these principles SaaS DRESS Code for stickiness; we will expand these principles in more detail in a future paper.

Discoverability: A discoverable service is one that can be adopted by service consumers with minimal human intervention on the part of the service provider during the entire service adoption lifecycle. Discoverability helps service consumers by reducing the distance between the vision and the deployment. The main benefit of service discoverability for a provider is that it is a force multiplier in reducing the cost of sale dramatically due to the network effect created through the automation engines supported by service architecture. Essentially, discoverability will enable the creation of a service engine, the revenue potential of which is not inhibited by the sales and marketing resource constraints. Service implementation has to incorporate discoverability at its core through rigorous service architecture, subscription and provisioning automation, and investments in sales and marketing engines.

Reachability: A reachable service is one that is available globally and serves up customers spanning large enterprises and small business alike. Since cloud computing removes infrastructure obstacles for a global deployment, the service can be consumed by a Long Tail of customers given that the service functionality can be automatically adapted to the given customer context. The aspects of a service that affect reachability are: global deployment, configurable functionality, local compliance, language, currency, invoicing and supportability. Cloud platform provider selection and the service architecture will play an important role in enabling the reachability of a SaaS service.

Economic Feasibility: A cloud hosted service has to be economical to operate at varying scales of customer usage. The service subscription fee should be greater than the sum of the cloud usage cost, both direct and indirect. The variable part of the service cost model is the cloud resource usage that can eat into the profit margins if not reflected in the cloud pricing model. Independent Software Vendors (ISVs) main business is to build and sell software and services for enabling their customers. In the traditional deployment of a shrink-wrapped software package, perpetual licenses may work as the ISV is only responsible for the software bits; the dynamics of the resources like network bandwidth, server licensing, and storage capacity is entirely up to the customer. With this implicit assumption of the resource availability and the absence of any direct consequences of usage economics, the architecture may be less rigorous in clamping down the resource consumption. In a cloud setting, the architect has to be extremely diligent about every architecture decision that impacts the usage of resources such as compute, storage and networking. Cloud Platform Providers need to help SaaS architects with cost oriented service architecture (CSA) models that incorporate economical resource usage as the fundamental tenet.

Scalability: A cloud service has to support the multi-tenant platform components required to deliver consistent performance across varying conditions of usage. This is fundamental to the creation of a service ecosystem that is self-sustaining and embodies the other tenets like discoverability, reachability and supportability. The service architecture must enable the attainment of near linear scalability by eliminating resource bottlenecks through rigorous application state management. In a shrink-wrapped software installation, the high water mark of the scalability is pre-established due to the decisions made at the time of infrastructure deployment in terms of network topology, schematics of the server farm and the storage fabric interconnects and the configuration. Storage, for example, is often in the critical path of scalability. In a cloud deployment the virtualized storage removes such scalability constraints; an architect can be liberal in storage partitioning and placing them on different physical volumes and eliminate storage as the bottleneck. Similar observations are true for compute and network resources.

Supportability: Supportability often takes a backseat relative to functionality in shrink-wrapped applications because there are ISV services organizations, customer technology support teams, and customer and ISV helpdesk teams to jump in and help fix the application problems. They often have full access to the bare metal infrastructure (compute, networking and storage) and application state at run time. This is really expensive and a cloud hosted service, designed to optimize economics, can’t afford helpdesk calls as frequently as in the case of a shrink wrapped application. A cloud hosted service needs to devise support strategies with full awareness of the greater lack of control of the deployment infrastructure and the application’s run time state. The cloud service architecture should adopt supportability as one of the fundamental tenets that guide the solution design and implementation. In addition to application issues, supportability characteristic of a SaaS service should give top priority to performance, availability, back up/recovery and disaster recovery due to the external hosting environment. End user support processes need to consider online forums as one of the viable support options in addition to the more expensive support options that require human intervention.

The SaaS development Lifecycle needs to support the creation of cloud hosted services that reflect the above tenets at a fundamental level.

SaaS Development Lifecycle (SaaSDLC)

SaaS development requires a rigorous approach towards cloud provider assessment from the platform capabilities as well as the operational enablement perspective. Due to the explicit list of detailed activities during initial evaluation of the cloud provider, acquisition of production subscription and integration of operational frameworks and processes, these respective phases have been added to the traditional software development lifecycle. The resulting lifecycle is shown in Figure 1. The SaaS Development Lifecycle illustrated in Figure 1 assumes a fresh start with no preferred cloud provider prior to the start of the project.

In reality, if the SaaS service being developed is not the first one within the organization, the Evaluation, Subscribing and Operations phases will be less detailed due to leveraging the work that has already been done during the previous project

Figure 1: SaaS Development Lifecycle

Envisioning

Motivation

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.

Actors

Depending on the size of the organization various business roles will participate in the envisioning phase. Since technology will be a critical success factor of any cloud service effort, there should be a good representation of technology roles like the CTO and business/enterprise architects as well. The following are typical participants in the envisioning phase:

VP of Sales

VP of Product Management

VP of Engineering

Chief Marketing Officer

Chief Technology Officer

Business Architect

Enterprise Architect

Cloud Expert (Architect or Consultant). Note: This is very important especially for a first project on a new platform

Activities

Identify current business needs

Envision new business opportunities and new markets

Decide on “buy versus build”

High level assessment of economic model in terms of sales, marketing, and licensing

Identify solution/service needs

Business Inputs

Short, Medium and Longer Term business plans and strategy

Market or other business opportunities to be addresses first

Business value collateral of the cloud platforms

Vertical market research from sources like IDC

Cloud platform research from sources like Burton Group, Gartner, and Forrester

Economics of cloud computing for the target cloud platform

Internal market intelligence and opportunity assessment

Technical Inputs

Cloud service taxonomy and the architecture differences of various cloud platform types

Decisions

Executive sponsorship of the service:Based on the market indicators and trends of the cloud ecosystem, executives will sponsor the service development project

Economic justification: services investment will be weighed against the cost of service development

Buy versus build: in case of a “buy” the ISV will subscribe to a service and vertical specific intellectual property before publishing the service. The “build” is self-explanatory; the service will be built in-house by either existing staff or augmented through systems integrators.

Cloud platform assessment: the organization will spend time shortlisting vendors based on the vision/scope and the cloud platform characteristics identified during this phase.

Proof of concept (POC) plan:Thisgives the green light to move forward with the POC in conjunction with the cloud platform assessment.

Deliverables

Long term services vision and investment areas

Near term scope of the service

Return on investment

Resource allocation for the feasibility study

Platform Evaluation

Motivation

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.

Actors

Armed with the vision/scope, a small task force of business and technology folks will work together in zeroing in on a cloud platform for developing and deploying the service. The business folks will refine the scope for functional proof points while the technology roles will define the architecture proof points and subject the cloud platform to the scrutiny of the proof points. Typical participants may include:

POC results encompassing both functional as well as non-functional aspects of the prospective service

Refined architecture that can be implemented on the selected cloud platform

Updated plan for next phase

Planning

Motivation

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.

Deliverables

Subscribing

Motivation

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.

Activities

Validate the refined disaster recovery plan and intersect it with the cloud provider DR practices

Assess feasibility of the refined application security architecture and the ability to realize that on the cloud provider platform

Assess the feasibility of the refined data architecture on the cloud provider platform.

Validate data privacy, compliance and auditing practices

Validate industry certifications and compliance needs of the service

Acquire a cloud service subscription for production deployment

Plan for residual risk mitigation

Business Inputs

Procurement process documentation

Service audit and compliance information

Industry specific certifications

Service level agreements

Service availability/outage reports

Regular support and escalation processes

Information security and privacy processes

Technical Inputs

Cloud platform feature description and limitations

Solution reference architecture documentation

Cloud design patterns documentation

In-flight data and at-rest data security documentation

Decisions

Acquire production subscription

Deliverables

Majority of the deliverables during the Subscription phase are high level strategies based on cloud provider supplied information. These will be refined before production operations kick in.

Backup and recovery strategy

Disaster recovery strategy

Subscription management strategy

Production support strategy

Developing

Motivation

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.

Decisions

The decision making at this stage is primarily implementation oriented:

Composition of project team

Executive sponsorship

Development environment

Component architecture

Build management

Size and scope of iterations

Unit testing and load testing approaches

Deliverables

The formality of deliverables in this phase depends on the size and scope of the service being implemented. Certain mission critical service implementation with multiple entity involvement (e.g. multiple systems integrators and outsourced companies) may mandate more formal deliverables compared to less mission critical and/or in-house developed applications. Here are a few deliverables:

Refined architecture collateral

Refined iteration plan

User documentation

Support documentation

Service deployment model

Fully tested service deployment package

Operations

Motivation

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.

Actors

IT Pro

Solution Architect

Application Support Engineer

Tier 1 support lead

Tier 2 escalation lead

Activities

Assess capacity required

Perform load test

Plan for deployment

Test disaster recovery and business continuity process

Finalize support plan

Set up and test backup and recovery processes

Set up and test disaster recovery and business continuity

Create collateral for service discovery

Train end users and support personnel

Deploy the service in production

Monitoring, Performance evaluation and tuning.

Business Inputs

Functional evaluation and satisfaction feedback

Input to feature selection for next iteration

Technology Inputs

Support alerts

Decisions

Production Deployment

Disaster Recovery deployment

Deliverables

Capacity plan

Load test results

Backup and recovery test results

Disaster Recovery test results

Service discovery collateral

Training plan

Support plan

Production service deployment

Conclusion

The SaaS Development Lifecycle (SaaSDLC) is an adaptation of the traditional iterative software development process with additional important phases added. These additional phases – Evaluation, Subscribing and Operations are less prominent and implicit for on-premise deployments. However, the activities during these phases become critical success factors for a SaaS development and deployment due to an externalized multi-tenant hosting environment. While the initial SaaS projects require more emphasis on the cloud provider evaluation, subscription acquisition and operationalizing the services, the subsequent SaaS efforts can leverage the know-how acquired previously thereby allowing the project teams to short circuit Evaluation and Subscribing phases. The IT Professional needs to be extra diligent in cloud platform provider evaluation, designing the deployment environment and setting up operational processes that integrate cloud providers processes and frameworks into the existing management and monitoring environment.

The SaaSDLC described in this paper is biased towards ISVs; but is equally valid in principle for any SaaS service provided either by ISVs or by enterprise IT departments. It is clear that even enterprise IT departments must start looking at themselves as Service Providers and act accordingly.

About the Authors

Hanu Kommalapati is a Senior Technical Director at Microsoft Corporation where he is the technical lead for Windows Azure and Cloud Computing for the U.S. subsidiary of Microsoft's Platform Evangelism organization. In this capacity he works spreading the word about Cloud Computing to Microsoft customers, partners and community.

In the past he has held positions as Principal Platform Strategy Advisor and as an Architect for Microsoft. Previously he also held positions as a Principal Consultant at PricewaterhouseCoopers.

William H. Zack Is a Microsoft Principal Architect Evangelist who specializes in architecting, implementing and supporting both applications and computing infrastructures based on Microsoft Internet, Intranet, Client/Server and Cloud technologies. Over the past three year years Bill has been evangelizing Windows Azure and working with customers and partners to help them design, build and move applications to the Windows Azure Cloud Platform.
He has given cloud presentations at conferences such as Cloud Expo, as well as at local community events and has presented on Microsoft cloud strategy and implementation to technical decision makers and developers at many New York area companies.

In 2010 and 2011 he presented the talk: Patterns for Cloud Computing at Cloud Expo in New York. Bill also created the material for an award winning 2010 webcast: Windows Azure Design Patterns and subsequently delivered it as part of the Microsoft Academy Live webcast series. This won internal Microsoft awards for the most downloaded webcast of the year and the most impactful.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.