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: This gives 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:

• Product Manager
• Business Architect
• Enterprise Architect
• Solution Architect
• Developers
• Cloud Expert

Activities

• Define conceptual technical architecture
• Define a set of functional as well as non-functional proof points
• Assess economics of the PaaS platform
• Understand the cloud platform capabilities vis-à-vis the technical architecture
• Assess “fit for purpose” of the PaaS platforms for realizing the application architecture
• Shortlist cloud platform vendors for executing the proof-of-concepts
• Plan for the proof of concept against a short list of vendors
• Acquire trial subscription
• Complete the proof-of-concept
• Plan design and implementation phases (Waterfall or Agile)

Business Inputs

• Domain specific case studies and success stories specific to the target cloud platform
• Cost modeling tools for what-if analysis
• Service audit and compliance information
• Industry specific certifications
• Service level agreements
• Service availability/outage reports
• Regular support and escalation processes

Technical Inputs

• Roadmap of the essential cloud platform capabilities
• Security, compliance and governance
• Reliability, availability, performance and disaster recovery characteristics
• Capability specific collateral that enumerates features and limitations
• Capability specific reference architecture collateral for public and hybrid clouds
• Scenario specific reference architecture collateral that covers public and hybrid clouds
• Scenario centric developer content for getting started
• Capability centric developer content for getting started
• Migration processes for leveraging the existing technology investments
• ISV solution ecosystem to help with non-functional requirements (e.g. cryptography, auditing, diagnostics, monitoring) and functional requirements (e.g. special algorithms, simulators, payment processing)

Decisions

• Selection of the cloud platform: A single cloud platform will be selected for service deployment after comparing various cloud platforms through a “fit for purpose” lens.

Deliverables (by phase)

• Cloud platform comparison that includes economics, capability, supportability, security and compliance.
• Cloud platform comparison from the operations perspective: reliability, availability, scalability, performance and disaster recovery
• 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.

Activities

• Aggregate feature requirements
• Deliberate solution architecture and design specifications
• Create project plan
• Create project schedule
• Create resource plan
• Create communications plan
• Create risk mitigation strategy

Actors

• Project Manager
• Product Manager
• Business Analyst
• Business Architect
• Solution Architect
• IT Professional
• Cloud Expert

Business Inputs

• Roadmap for essential cloud platform capabilities
• Cloud project delivery best practices

Technical Inputs

• Reference architecture collateral
• Cloud capability documentation
• Cloud practical experiences in terms of what works what doesn’t work

Decisions

• Feature requirement for the current iteration
• Finalize the project plan for the current iteration
• Finalize the staffing plan for the current iteration
• Refine solution/technical architecture to realize the functional specifications
• Finalize solution design specifications for the current iteration

Deliverables

• Feature requirements for the current service iteration
• Project plan for the current iteration
• Resource plan
• Solution/technical architecture
• Design specifications
• Development Plan
• Operation Monitoring plan

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.

Actors

• Chief Security Officer
• Enterprise Architect
• Information Architect
• Solution Architect
• Procurement Manager
• IT Pro
• Cloud expert

Activities

• Negotiate service level agreements and pricing contracts for all the managed services (e.g. Compute, Storage, cache, database).
• 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.

Actors

• Product Manager
• Program Manager
• Solution Architect
• Developer
• IT Pro
• Tester
• End User
• Cloud expert

Activities

• Set up development environment
• Develop service through iterative process
• Deploy and test continuously throughout the iteration
• Enlighten application with instrumentation
• Integrate application security [e.g. single sign-on, authorization policies]
• Integrate with cloud and on-premise systems, if necessary
• Streamline data synchronization, extraction and uploading
• Integrate support and helpdesk processes
• Test service as well as integrated business processes
• Test support and helpdesk processes

Business Inputs

• None

Technical Inputs

• Guidance on the following related to the target cloud platform:
• Technical architecture
• Solution architecture
• Component architecture
• Cloud architecture patterns
• Cloud Solution Design patterns
• Integration patterns
• Migration tooling and best practices
• Managed services API usage (Cloud Storage, Middleware and Database)
• Service management API usage
• Detailed engineering capability documentation
• Application Lifecycle Management
• Unit testing and load testing

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.