Become SaaS Ready in 6 Weeks

The world of software applications and products has evolved from being hosted on-premises to a Software-as-a-Service (SaaS) model. Perpetual license earnings are dwindling, while subscription revenue including SaaS is expanding rapidly. Per a recent PWC report, subscription revenue (including SaaS) is set to grow at a 17.5% compounded annual rate, reaching 24% of total software revenue by 2016. Roughly 40% of the turnover of 10 of the top 100 software companies worldwide is created by the SaaS service.

Gartner predicts that 77% of companies intend to boost their spending on SaaS in the next couple of years. So the big question is, how can you (as a software application or product vendor) swiftly move to SaaS, test it and ride the wave of opportunity before losing your specific competitive advantage to some of the fast-progressing SaaS vendors like Workday, Oracle, Saleforce.com, SAP, Microsoft, Intuit, and Zuora.

The second question is – what should one do in order to SaaS-enable an existing application or a product? Having seen many product teams labor for months with just putting together the fundamental understanding and plan, here are a few ideas on how to think about and devise a detailed SaaS-enablement strategy from an engineering standpoint. These ideas are based on my various assessments and conversations with product owners and solution architects.

I’ve split my suggestions into three SaaS-enablement strategy pillars for engineering – SaaS architecture, SaaS design thinking, and SaaS implementation planning. These pillars will help frame your thinking and help develop a fully baked thought process that will ‘concretize’ your SaaS-enablement roadmap. (Please note these don’t delve into other areas like a business case, process change, and market rollouts.)

SaaS Architecture

• Build an understanding of prospective SaaS offerings, anticipated consumption patterns, scale, competitive offerings and revenue model.
• Evaluate which multi-tenancy model will be most suitable for your offerings – isolated tenancy, shared tenancy, or hybrid tenancy.
• Look at the existing application architecture, tiers, components used, their interaction and dependencies, etc.
• Based on the time-to-market guidelines from product management, devise the redesign strategy – product re-writing vs. new product composition using on-demand third-party platform services vs. re-tooling with different deployment options.
• Identify platform services that could potentially replace existing application components without affecting the functionality, e.g., database, caching, search, logging, messaging, etc.
• Evaluate your platform service vendors and whether they offer individual services as on-demand hosted services with scale and commitments. It’s best to think of platform-as-a-service (PaaS) choices in the market that provide these capabilities (e.g., Heroku, Force.com, Cloud Foundry, Microsoft Azure, CloudBees, Stackato, SaaSGrid, Engine Yard, etc.).
• Map the rest of the tiered components with platform-specific runtime engines – web front end, back-end process, jobs, storage (local for sequential I/O, remote storage), etc.

SaaS Design Thinking

• Identify customization requirements for potential tenants – UI, Branding, Process, and Data Model.
• Make design changes across the layers to drive customization through configurations.
• Ensure UI components are dynamic except for the basic layout (in most cases).
• Use the new branding component for UI to help with tenant-specific look and feel.
• In case tenants need flexibility in the user process/navigation flow, the new SaaS application may need to have the workflow engine at the core (think third party vs. platform service vs. simple property-based).
• The data model will need changes across existing objects to build the association with tenant organizations. It will also need new meta-data object definition and indexing logic to handle the access conditions and volume of data.
• Ensure that entire design and access provides data isolation for the tenants.
• Based on the target markets, application design will need to support internationalization as well.
• Other re-design considerations to factor in – sensitivity of data, local governance, privacy standards and any other compliance issues.
• Employ the ‘design for failure’ philosophy and try using platform-specific best practices to make application components highly available all the time.

SaaS Implementation Planning

• Understand the complexity involved and where it comes from, for instance- type of use cases, existing design, dependencies on third-party components and services, technologies used, business workflow complexity, service consumption levels, data mass to be handled, target market, regularity needs, etc. Decide and drive the SaaS-enablement efforts in terms of time and cost involved.
• Plan to develop a small, quick and end-to-end use case to begin with and then iterate over it as you test for functionality, isolation and performance.
• For selling SaaS services, applications will need additional components, such as offering catalog, customer and order management, service entitlement, usage metering, billing, payment, self-service portal, etc. You can either think of insourcing these services or plan to build your own support systems to enable more applications as SaaS using the same.
• Implement continuous integration management using platform APIs for quick feature patching and rollouts.
• If you are not planning to use any platform-as-a-service, then identify and employ a DevOps tool for continuous integration, release, patching and automation of operations including sanity tests, etc.
• Evaluate services like support, dashboard and analytics (unless it needs highly customized analytics) using platform services.
• Add robustness to your SaaS implementation
  • From the outset, an overall application needs to be thought of as a scalable platform by ensuring stateless and loosely coupled components.
  • Have an alert mechanism on platform as well as application logs.
  • SaaS applications should able to gather and infer parameters for SLA metrics using underlying platform measurements.

• Add interoperability into your SaaS application
  • If the SaaS application supports the use case of integrating with other systems (like IDM, content management) to insource the identity or other data, then the inclusion of adapter interface definitions will be required.
  • If other enterprise systems need to make use of SaaS application or data, then the access mechanism will have to be built using API frameworks like JSON + REST or XML + SOAP.

• To ensure your SaaS application goes the distance in a successful SaaS business, make sure you factor in managing things like getting your SaaS application platform audited (if you are hosting it yourself), scale and performance management, user experience, disaster recovery, creating testing environments, feature rollback mechanism, and security and privacy best practices.

Several of the above directions and recommended actions may become secondary depending on your overall solution architecture approach, e.g., if you decide to leverage any of the existing platform-as-a-services to build your SaaS application on top, then that platform may do many things for you but at the same time it will also drive many of your decisions as well.

Naturally, going to market with revitalized offerings (SaaS in this case) and delivering the required value and features to your customers is a very serious bet. This is where an “I-can-do-all-things-myself” attitude poses a risk to the new business model whereas timely guidance from relevant experts might make life much simpler and the business a real possibility.

With the right mindset and experience, SaaS enablement of your software product could be a quick possibility – as few as six weeks. The key point I’d like to drive home here is that your future business may be at risk if you are taking too long to put together a detailed and concrete SaaS-enablement roadmap. Now is the time to get started.