5 Key Steps to SaaS Enablement:

Transcription

1 5 Key Steps to SaaS Enablement: A Technical Guide to Moving On-Premise Software to the Cloud whitepaper Contents Introduction... 2 The Challenges of Migrating Software to the Cloud... 2 Five Key Steps to SaaS Enablement... 3 Business and Project Planning... 4 Development and Service Process Restructuring... 4 Defining Requirements and Migrating Infrastructure... 6 Supporting Existing Products... 7 Customer Case: A Technical Example of the Evolutionary Path to SaaS... 7 A Solution for Monetizing Your SaaS Investment... 9 Conclusion...10 About CorSource Technology Group Solutions...10 About SafeNet Software Monetization Solutions Key Steps to SaaS Enablement: A Technical Guide to Moving On-Premise Software to the Cloud Whitepaper 1

2 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 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. One software company that conducted a physical audit of its SaaS customers found that 85% were not in compliance with their service contracts. 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. 5 Key Steps to SaaS Enablement: A Technical Guide to Moving On-Premise Software to the Cloud Whitepaper 2

3 Five Key Steps to SaaS Enablement Business & Project Planning Architectual Planning Development & Service Process Restructuring Defining Requirements & Migrating Infrastructure Supporting Existing Products 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 onpremise product? Are major changes to your business models or the workflow of your onpremise product required to get to SaaS? Is your current on-premise software suitable for a multi-tier architecture? Choose: Yes No Yes EVOLUTION: Evolve your On-Premise Software to SaaS No new target market (i.e., smaller businesses) Yes major feature additions, feature changes, and changes to business models & workflow No 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 and would be very difficult to evolve to SaaS. In these cases, ISVs are choosing to start from scratch with a new product development path to SaaS. For many ISVs with a portfolio of on-premise software products, it makes sense to use an evolutionary approach to migrating on-premise software to a SaaS model. This approach is more manageable because it allows smaller, more manageable steps and permits ISVs to continue to conduct business and support their current products and customer base at the same time. 5 Key Steps to SaaS Enablement: A Technical Guide to Moving On-Premise Software to the Cloud Whitepaper 3

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 onpremise 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. Tenant 1 Tenant 2 Tenant 3 Tenant 1 Tenant 2 Tenant 3 Instance 1 Instance 2 Instance 3 Instance Instance Instance Tenant 1 Tenant 2 Tenant 3 Tenant 1 Tenant 2 Tenant 3 Tenant Load Balancer Maturity Level 3: Level three is where your application starts Instance Instance Instance to become multi-tenant efficient. At this Diagram source: Microsoft 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. Instance Maturity Level 4: At level four your software is multi tenant and fully scalable. Level four supports a loadbalanced 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. 5 Key Steps to SaaS Enablement: A Technical Guide to Moving On-Premise Software to the Cloud Whitepaper 4

5 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. Layer 1 Layer 2 Layer 3 Multi-Tiered SaaS Architecture Browser/Thin Client The third layer is the data access Database 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. Metadata Services Presentation Layer Security Services Business Logic Business Services Data Access Layer 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 to the database be partitioned. Not only is the software architecture with SaaS different, but the business architecture is also different. Operable business services for deployment and ongoing management are a critical characteristic of any SaaS product. These business services include Operational Support Systems (OSS) that enable licensing, provisioning, monitoring, etc. and Billing Systems Support (BSS) to enable billing and customer care. We ll discuss these in more detail in the next section on defining requirements and then again when we talk about monetizing your SaaS product investment. 5 Key Steps to SaaS Enablement: A Technical Guide to Moving On-Premise Software to the Cloud Whitepaper 5

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. Many software developers are challenged with licensing policies that pre-date the cloud. Rudimentary licensing controls and metrics that worked for onpremise software or in the early wildfire stages of SaaS growth like per-user or per-month may no longer work as cloud services scale. ~ Amy Konary, of IDC 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? 5 Key Steps to SaaS Enablement: A Technical Guide to Moving On-Premise Software to the Cloud Whitepaper 6

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 onpremise-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 onpremise 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 database management system. 5 Key Steps to SaaS Enablement: A Technical Guide to Moving On-Premise Software to the Cloud Whitepaper 7

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. Architecture Evolution Presentation Application Services Business Persistence Data Storage Today E-Commerce Core Product Delphi Visual Components Browser ASP.NET WCF Service Delphi BOs.NET Wrapper Delphi DAOs.NET Wrapper Microsoft SQL Server Future Browser ASP.NET WCF Service Delphi BOs Delphi DAOs Microsoft SQL Server 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 would be set up by their professional services organization. 5 Key Steps to SaaS Enablement: A Technical Guide to Moving On-Premise Software to the Cloud Whitepaper 8

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. 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 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: 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 SafeNet has the newest, and most comprehensive, support for cloud licensing use cases and business models. ~Forrester Research 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 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 cloud. ISVs that build on the principles of multi-tenant efficiency, considerable scalability, and configurability driven by metadata, will be able to deliver their software more inexpensively to their existing and potential customers. As this paper illustrates, by using either an evolutionary or a revolutionary migration model, and employing feature-based user provisioning, authorization, metering and management, ISVs are better able to manage the migration as well as the business challenges of cloud service delivery. Adopting these principles will not only help you develop a conceptual framework for understanding and migrating your on-premise products to the cloud, it will put you solidly on the course to transform the way you capture and serve customers, and ultimately grow your software business. 5 Key Steps to SaaS Enablement: A Technical Guide to Moving On-Premise Software to the Cloud Whitepaper 9

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 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 Pittsburgh Glass Works About SafeNet Software Monetization Solutions Sentinel is the most trusted brand in the software industry for secure, flexible, and futureproof 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. Join the Conversation Sentinel Online Twitter twitter.com/licensinglive LinkedIn Sentinel Video Cloud LicensingLive BrightTalk Contact Us: For all office locations and contact information, please visit Follow Us: SafeNet, Inc. All rights reserved. SafeNet and SafeNet logo are registered trademarks of SafeNet. All other product names are trademarks of their respective owners. WP (EN) A Key Steps to SaaS Enablement: A Technical Guide to Moving On-Premise Software to the Cloud Whitepaper 10