5 Key Steps to SaaS Enablement:

(1)

5 Key Steps to SaaS Enablement:

A Technical Guide to Moving On-Premise Software

to the Cloud

(2)

introduction

Software as a Service (SaaS) represents a significant shift in the way software is delivered. As more and more makers of traditional on-premise software are choosing to migrate their products to the cloud, they are discovering that it does not come without challenges.

This paper explores those challenges and then presents key planning, architectural design and implementation considerations for migrating on-premise software to the cloud. Using best practices gained from many successful migrations and a case study example, you will learn a step-by-step process for successfully migrating your on-premise software to the cloud and fully monetizing your SaaS product investment.

the Challenges of Migrating Software to the Cloud

Moving your on-premise software to an on-demand model is much more than a technology change and generally takes longer than first expected. It requires forethought, planning and many important business strategy and product-based decisions.

Finding the correct balance between planning and implementation for current on-premise and on-demand product roadmaps can be extremely challenging. It’s important to use a phased approach, beginning with a very general overview and then going back to fill in the details. For starters, how will get to the Cloud? You will need to decide if it is best to use an evolutionary or a revolutionary development approach. Next you will need to make decisions about the technical architecture, requirements, infrastructure, and so on.

Not only will the switch from a product to a service bring challenges to product development, it will also bring many business and service delivery challenges. What will your service catalog look like? How will you handle provisioning and authorize user access?

Service agreement compliance is one of the top challenges for ISVs moving to the cloud. Managing and enforcing entitlements across enterprise account structures is complex. Once you deliver your software service, you will need to ensure that your customers are using that service according to the terms of the contract they have in place.

Most ISVs do not have the controls in place to ensure that their customers are using only the features and functionality for which they’ve contracted – or that they’re limiting the number of users that have access. As an example, one ISV launched their software service with no controls in place to limit access and when they actually conducted a physical audit of their customers, they found that 85% were not in compliance with their service contracts which meant they were essentially giving away their software. A potential revenue opportunity – lost without the proper controls in place.

Another challenge is being able to quickly adapt service offerings for new and evolving market opportunities as well as managing back-office functions for both on-premise software and SaaS offerings.

This is just a start – there are many other technical and business challenges to consider when migrating your software to the Cloud.

Fortunately, there’s help. Keep reading to see how you can leverage the experience and best practices of other ISVs and service providers with hundreds, if not thousands of successful migrations under their belts, to help move your software to the Cloud and better manage the continued development and support of your larger product portfolios.

what’s Driving Software

publishers to the Cloud?

• 75 percent are in search of new revenue

• 65 percent want to simplify operational processes

• 48 percent want to reach new and niche markets

• 46 percent want to improve end-user experience

• 33 percent want usage tracking and reporting capabilities

• 32 percent want to shorten time to market

~”The State of Software Monetization” survey 2013, SafeNet and the Software & Information Industry Association

One software company that

conducted a physical audit of its

SaaS customers found that 85%

were not in compliance with

their service contracts.

(3)

Five Key Steps to SaaS enablement

1. Business and project planning

Business and project planning is the first and one of the most important steps to SaaS enablement. Surprisingly though, it is also the step that is most often overlooked. It requires a significant amount of forethought as far as business objectives and how you will approach the project. Who are you targeting with this product? How are you going to make money? Which license models will you choose?

Take a look at your current on-premise software product to determine if it can be leveraged for the SaaS version. What skills might be needed to move forward with the project? Will you use an incremental or phased project plan that evolves your current on-premise offering? Or start from scratch with a new SaaS product development project? This planning phase requires that you carefully examine your business objectives and your desired business model before mapping out your project plan.

Choosing the Right Path to SaaS is an important component to the project planning stage. Should you evolve to SaaS from where you are with your current on-premise product or should you develop a new SaaS product from scratch. Your answers to the questions in table below may help you decide.

Choosing the right path to SaaS

Is the target market for your SaaS product the same as for your current on-premise product?

Yes

No

new target market (i.e., smaller businesses)

Are major changes to your business models or the workflow of your on-premise product required to get to SaaS?

No

Yes

major feature additions, feature changes, and changes to business models & workflow

Is your current on-premise software

suitable for a multi-tier architecture? Yes No

Choose: eVOLUtiON: evolve your On-premise Software to SaaS

reVOLUtiON: Develop New SaaS product from Scratch

Many ISVs choose the evolutionary path to SaaS. If you plan to target the same audience with your SaaS product and you see no major changes to your business model or workflow of the product and the architecture is suitable, you too may choose the evolutionary path. The evolutionary path makes sense if you simply want to modernize your interface and offer your target market an on-demand version of your software.

On the other hand, some ISVs decide to target a new market. Experience has shown that the majority of these ISVs want to broaden their market by offering a SaaS version of their software to those prospects that either cannot afford their current offering or only need a subset of features, or new features, which would require a complete rewrite and modernization of the interface, business model and workflows. Many of these ISVs realize that their current architecture, particularly in some of the older products is not suitable for moving to multi-tier Business & project planning architectual planning Development & Service process restructuring Defining requirements & Migrating infrastructure Supporting existing products

(4)

2. architectural planning

Once you’ve completed your business and project plan, you’ll move on to architectural planning. It is at this point that you’ll need to determine how your architecture will support multi-tenancy. What about scalability and the many manageability considerations? Which technical approach will you use? And will you be able to use some or any of your existing on-premise product? In the architectural planning stage, it’s important to understand the four levels of SaaS maturity.

the Four Levels of SaaS Maturity

Maturity Level 1:

At level one, your software is internet accessible and each customer is able to access its own unique instance of your application and their data. At this level, there is minimum configurability and there may be custom coding involved for each customer.

Maturity Level 2:

At level two, there is still one instance of the application for each customer but these are no longer unique instances. Each instance contains the identical code base and is configurable without relying on custom code.

Maturity Level 3:

Level three is where your application starts to become multi-tenant efficient. At this

level, instead of many instances of your product running to serve your customer base, there is only one instance of your software that serves multiple tenants, or customers. But, at level three, there are not multiple databases to house tenant data. At level three, it is still a single database.

Maturity Level 4:

At level four your software is multi tenant and fully scalable. Level four supports a load-balanced farm of identical applications, serving multiple tenants and running on a variable number of servers. At level four, capacity can adjust dynamically to match demand without changing any of the system architecture and of course, even at this level, it is fully configurable. Once at level four, your application has fully evolved to a service-based offering with a true multi-tiered architecture.

3. Development and Service process restructuring

Next, you’ll need to look at development and service process restructuring. As with all software development, flexibility is important if you want to avoid problems moving forward. Your development processes need to be flexible for requirements, change management and testing. You will also need to determine your customer service model and how you will provide support in a multi-tenant environment.

Tenant 1 Tenant 2 Tenant 3

1 2 3 4

Instance 1 Instance 2

Instance

Instance 3 Instance Instance Instance

Instance Instance

Tenant Load Balancer

Instance

(5)

Multi-tiered SaaS architecture

There are many software layers to consider when making the move to Software as a Service. The top layer in a multi-tiered architecture is the user interface layer. This layer represents how the user interacts with the system through their Web browser or possibly even a thin client. If you have chosen to brand your software service for each customer with their corporate colors and logo, it will occur in the user interface layer.

The second layer is the business logic or services layer. This is the logic that represents the customer’s customizable work flow, user-determined security access, and business services such as provisioning, licensing, reporting, and billing which enable you to monetize your software investment.

The third layer is the data access layer. This is the layer where you can implement custom data fields for each

of your customers. And even though it all resides in a single database, secure access and proper partitioning will ensure that there is no data that bleeds over between customers. Let’s unpack these ideas a bit further and take a look at some of the key characteristics of this architecture.

Characteristics of the SaaS Software Architecture

In order to best suit the needs of each of your customers, each and every layer of your SaaS software needs to be tenant configurable; presentation, business logic, security, and database. Generally supported by metadata, this allows unique tenant configurations for branding, internationalization and localization, workflows, user-access control to different parts of the application, specific data tables and fields, and also allows for client-specific extensions. Multi-tenant efficiency is derived from the sharing of key layers of the application architecture among tenants while still maintaining isolation between them. Employing a business logic layer which is threaded and pooled, a security layer which is shared but separate, and a database with is common but isolated. This requires up front design or may even include a complete redesign of an existing application, depending on the suitability of the current design. Multi-tenant efficiency ensures that multiple objectives can be achieved using common components while also allowing for custom business logic for each client.

Scalability is a key driver for SaaS in order to reach a broader range of clients with the same application infrastructure. Scalability requires careful design using stateless, pooled business logic. It requires cached, pooled, asynchronous data access, and also necessitates that access

Browser/Thin Client La yer 1 La yer 2 La yer 3 Presentation Layer Business Logic

Data Access Layer

Database

Me

tada

ta Services

(6)

4. Defining requirements and Migrating infrastructure

Once you’ve considered development and service process restructuring, you will define your requirements. It is important that your requirements be well articulated and that they tie back to your business and project objectives. You’ll want to be sure you’re answering these types of questions when determining your requirements: Do we use all or just a subset of the features from our current on-premise product? Do we do it all and then use licensing and provisioning to create different versions to target different user segments? How will we manage that? Do we want to add additional features not found in the on-premise software? Do we want to modernize the user interface? Updating the user interface is an important requirement if you want to provide the right experience for today’s audience.

You’ll also need to consider infrastructure migration. The infrastructure for your SaaS product will most certainly be different than what you’re doing today with on-premise. So you will need to move to a more flexible and much more maintainable infrastructure for your on-demand products.

Another consideration when defining requirements is product versatility and business agility. Quite often when a software publisher launches their first SaaS product, they start with a fairly basic version of their offering. Then quickly realize that for competitive reasons, or when they get customer requests, they need to be able to offer different editions or flavors of their product. It might be a version for small business users, the mid market, or even larger corporations. Whatever the reason, from a business perspective, ISVs need to be agile enough to respond – and many don’t have the tools in place to make those adjustments quickly. Instead, engineering has to go in and hard code these types of changes which not only takes time – but means they are slower to respond to market needs.

Similarly, ISVs are realizing that the subscription-based licensing they employed at launch, may not be enough anymore. According to Amy Konary, of IDC, “Many software developers are challenged with licensing policies that pre-date the cloud. Rudimentary licensing controls and metrics that worked for on-premise software or in the early ‘wildfire’ stages of SaaS growth – like per-user or per-month – may no longer work as cloud services scale.”

There are many more ways you can monetize your SaaS investment. For example, you may want to be able to employ a usage-based business model. Do you have the tools in place to be able to track usage and then license accordingly? There are many sophisticated licensing models. The challenge is in being able to offer your service in the many ways that your customers want to buy – freemium, subscription-based, feature-based, usage-based, metered, or any combination of these and more.

And once you’re collecting customer usage data the challenge is to leverage that data in order to better understand your business, and how your customers are using your products. This is business intelligence that will not only help you know where to invest or divest resources, it will also inform your sales and marketing initiatives. To be effective in this area, you’ll need the proper systems in place to be able to collect, aggregate, analyze, and act on the information properly.

Likewise, most ISVs are not leaving their on-premise business behind. They plan to continue to develop, market, and support their on-premise software right alongside their new SaaS offering. This brings up the next challenge which is back-office support. How will you support multiple products and delivery platforms from an operations perspective? Do you use multiple back office-systems? How do you manage licensing and entitlements across both types of delivery mechanisms?

“Many software developers

are challenged with licensing

policies that pre-date the cloud.

Rudimentary licensing controls

and metrics that worked for

on-premise software or in the early

‘wildfire’ stages of SaaS

growth–like per-user or

per-month–may no longer work

as cloud services scale.”

(7)

5. Supporting existing products

Lastly, you will want to determine how you will balance resources to support ongoing development for each of your different products during this time. Experience has shown that this is a key area of importance to ISVs when adding a SaaS initiative to what was once an on-premise-only business model. They come to recognize that the existing on-premise software cannot just stand still, but will need to continue moving forward in some form, whether through an evolution to SaaS, or through two distinctly different development cycles. Because you may have one development cycle for the existing software product and one for the new SaaS product, you will need to work out how to balance finite development resources between your existing product and SaaS development.

Customer Case: a technical example of the evolutionary path to SaaS

The Company

A leading provider of retail POS systems and software solutions for small to mid-sized retailers

Their Challenge

This retail provider wanted to grow their mid-market business by reaching prospects they had never reached before. They decided to do this by developing a SaaS version of their POS solution, at a lower price point and to launch it as soon as they possibly could.

They indicated that they didn’t know how to get to a SaaS version of their retail POS solution, they didn’t understand what it meant architecturally to their business models, nor did they have the resources available as they were also busy developing their current on-premise product. They contacted CorSource Technology Group to help.

Their Current Technology, Priorities and Planning

According to CorSource, they were using somewhat dated technologies for their current on-premise software product including a Delphi development environment, Crystal Reports and SharePoint.

In order of importance, their priorities were to develop a SaaS POS solution as soon as possible to start capturing market share. Move to more up to date technology. Improve the software’s extensibility to partners. Improve the user interface and functionality. And, support product segmentation for modular deployment.

For planning purposes, they decided to leverage existing product by keeping a large part of the design. In addition, they would keep some code initially, and re-use what they already had in stateless architecture. They would adopt Microsoft technologies to leverage their current code and skills as well as provide a career path for staff. They would target simpler businesses at launch with limited, but nearly complete functionality. They would continue to use professional services for all new customer deployments. Moreover, they would change the current GUI for the SaaS product so that it provides a rich user experience.

Their Primary Technology Choices for SaaS Development

Since they had current skills and a portion of their foundational architecture in Microsoft SQL server, they chose to go with Microsoft .NET for their application architecture. They chose Microsoft ASP .NET for their GUI platform because it aligns best with .NET and other scripting and rapid development choices such as PHP or Ruby on Rails did not provide the robustness and flexibility required of enterprise software. They chose Microsoft SQL Server as their

(8)

The Evolution of Their Architecture

This diagram below represents the architecture roadmap and the necessary steps to evolve their on-premise POS software solution to SaaS. It also illustrates how this maps to a relief plan and a relief roadmap for the following two to three years.

If we look at the current product architecture which is already somewhat modular, we see that their core product was built on Delphi with an SQL server database. Next, in an update to their current product, they added an e-commerce component which is browser-based and was written in Microsoft ASP .NET with communication services that connect with Delphi business objects and data objects through .NET wrappers. Evolutionary in that they kept the entire business object and data layer the same, but through .NET, allowed the new e-commerce product to use all of the existing Delphi architecture.

Next, in the steps to future product architecture for SaaS, we see a rewrite of the front end and communications using Microsoft. Likewise as they continue to add new functionality to the SaaS product and take advantage of the .NET wrapper technology, they will not need to rewrite everything from scratch but instead evolve and roll out one piece at a time.

The future product also includes a rewrite of the back end using Microsoft so that, in the end, the entire SaaS architecture which has evolved is written using Microsoft technologies. What’s more, their architecture actually maps to their release plans.

Their ‘Evolutionary’ Release Plan

release 1 – web enablement

In the Web Enablement phase which is essentially maturity level one, this POS provider wanted software they could say was a Web-accessed product. In this first phase, they would build a new Web user interface, and interface enhancements with a light services layer. They would use their current Delphi business objects and data access objects and build in customizability via forms designer or plugins, and provide data integrations to such things as offline POS. They would migrate from Crystal Reports to Web-based reporting and the data would still include SharePoint services. All new installations of the software would be set up by their professional services organization as planned.

release 2 – SaaS Launch

In the SaaS Launch phase they would release software which is considered maturity level two because it includes some architectural considerations. The application would be multi-tenant aware, would have some functional enhancements, a partition able interface for the different customers, a separate (but the same) database for each customer and would also include load testing to ensure it was all running well. All new installations of the software would be set up by their professional services organization.

release 3 – true SaaS product

The true SaaS Product release includes a muti-tenant database, a tenant administration tool, migration tools, and additional functional enhancements. All new installations of the software

Presentation

Delphi Visual Components

Browser ASP.NET E -Commer ce Cor e Pr oduc t WCF Service

Browser ASP.NET WCF Service

Delphi BOs Delphi DAOs .NET Wrapper .NET Wrapper

Microsoft SQL Server

Delphi BOs Delphi DAOs Microsoft_{SQL Server}

Today

Future

Application Services Business Persistence Data Storage

(9)

release 4 – Full technology Migration to SaaS

This release is what is considered the fully staffed SaaS product where they would completely migrate all of their technology to Microsoft and have one full Microsoft-driven SaaS solution. Where the business objects, the data access would all be accomplished via .NET and include a complete services set and active directory. At this point it is considered to be at a true level four maturity level.

Software release four is the largest development piece and can only be accomplished within the three-year goal by developing in parallel to the first three releases.

Optional release 5 – extreme Scalability

This release is an optional release that would provide extreme scalability by refactoring data access objects.

This customer case illustrates the technical journey that one software vendor took in migrating to SaaS.

Their release plan, spanning approximately three years, represents the successful real-life evolution of an on-premise POS software product built on legacy development platforms to a fully-staffed SaaS point-of-sale solution.

The technical migration is only half the story. It’s also important to consider the different aspects of monetizing your software migration investment. You need to be able to easily package and deliver your new SaaS products to customers – while also managing the product, the business and the operations side of marketing your new SaaS products.

a Solution for Monetizing Your SaaS investment

Sentinel Cloud Services makes it quick and easy for SaaS providers to build versatile service catalogs, provision and authorize user access, measure service usage, and instantly adapt their service offerings to embrace new and evolving market opportunities. Only with Sentinel can software publishers successfully package, deliver, and manage any cloud-based application delivered to a PC, laptop, mobile device, or otherwise. Fully aligned with the software monetization lifecycle, Sentinel Cloud Services enables software publishers to:

Conclusion

SaaS represents a significant shift in the way software is delivered and more and more makers of traditional on-premise software are choosing to migrate their software products to the

Getting up and running with

Sentinel Cloud took one

developer only two days –

one day to be functional, an

additional day to polish the

implementation.

~Centercode

“SafeNet has the newest, and

most comprehensive, support

for cloud licensing use cases

and business models.”

~Forrester Research

DEFINE

service catalog and pricing models at the feature level to boost product versatility and business agility

PROVISION

service agreements instantly to improve operational efficiency and minimize manual errors

CONTROL

user authorization to enable service agreement compliance

MEASURE

customer usage for business intelligence and billing support tosimplify operations and improve strategic decision-making capabilities

ADAPT

service offerings and pricing models on the fly, without the involvement of engineering, to instantly embrace evolving market demands

(10)

about CorSource technology Group

CorSource Technology Group is the leading provider of strategic consulting, development services and technical staffing that businesses need to succeed in the fast-moving, highly competitive world of software development and IT.

CorSource software development experts assist with front-end business analysis and planning, while ensuring that processes and requirements are clearly communicated and understood. Whether dealing with infrastructure migration or legacy product support, a team of experienced consultants will help you to position your applications within the Cloud. CorSource is headquartered in Portland, Ore. with an office in San Mateo, Calif., serving SMBs and ISVs nationwide. Learn more at www.corsource.com

about SafeNet Software Monetization Solutions

Sentinel is the most trusted brand in the software industry for secure, flexible, and future-proof software monetization solutions. The robust portfolio of products and services address each and every aspect of the software monetization lifecycle – from copy and intellectual property (IP) protection to product catalog management and ongoing end-user experience improvement. SafeNet is the first and only vendor to offer a complete portfolio of software licensing and entitlement management solutions to enable monetization of any type of software – installed, embedded, and cloud services – using any combination of business models via any sales channel to any end-user device.

Sentinel Cloud Services offers the industry’s first and only software licensing and entitlement management solution delivered in the cloud for the cloud.

Software Monetization resources:

Request a free trial.

Learn more about Sentinel Cloud Services.

View the “The State of Software Monetization” survey Sentinel

Cloud Monetization Survey now.

≥

Sentinel Online

www.safenet-inc.com/sentinel

≥

Twitter

twitter.com/LicensingLive

≥

http://bit.ly/LinkedInLicensingLive

≥

Sentinel Video Cloud

http://sentinelvideos.safenet-inc.com/

≥

LicensingLive

http://licensinglive.com/

≥

BrightTalk

Join the Conversation

“We were all impressed with

your team in helping to organize

our project and validate our

plan. I feel confident that we

are on the right track and

have made sound decisions in

our architecture due to your

assistance.”

~CorSource Client, Darrin Olson

Director of IT, Service

free trial

Sentinel Cloud Services

Sentinel Cloud Monetization Survey

www.safenet-inc.com/sentinel

twitter.com/LicensingLive

/bit.ly/LinkedInLicensingLive

ttp://licensinglive.com/

http://www.brighttalk.com/channel/5572

5 Key Steps to SaaS Enablement:

Contents