The Cloud Strategy

1,792 views

Published on

I Tweet @vikasjee.
Follow my Lists /ReligionSaaS, /CloudGurukul, /SaaSNetworkers for more such updates

My profile at http://linkd.in/vikasjee

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,792
On SlideShare
0
From Embeds
0
Number of Embeds
77
Actions
Shares
0
Downloads
22
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • In order for a cloud strategy to work a number of key requirements must be met. These requirements are commonalities between the most successful SaaS businesses and are crucial in preventing run-away cost and engineering problems while realizing the full high margin potential of the SaaS model.Low Time to Market: In order to quickly recoup the upfront investment in moving to SaaS, the ISV must get the product to market in short order. This not only contains development costs, but gets revenue flowing sooner. Being in the subscription game means that any delay in availability means forgone revenue. This is not just an upfront consideration though. Cycle times must be kept short in SaaS in order to keep up with the frequent releases that most competitors in the cloud will adopt.High Tenant Density: One of the most important attributes of the SaaS model is the concept of multi-tenancy. Multi-tenancy means sharing a single instance of an application amongst many customers (or tenants) and their associated end users. The consolidation offered by single instance, multi-tenancy is what provides the massive efficiency of scale we see in SaaS business like Salesforce.com, Workday and Netsuite, who are each able to host hundreds of tenants and thousands of end users on a single server. Compare that to the 3-5 tenants per server that the old ASP’s managed to achieve through virtualization and it becomes obvious why SaaS companies have succeeded where the ASPs failed. The graph below outlines this concept. ASP’s using virtualization incur cost for each new tenant, whereas SaaS vendors incur cost only for each new server.Customizable Application Configuration: Satisfying the needs of customers is not aone size fits all proposition, and moving to the cloud doesn’t mean regressing to the lowest common denominator in order to standardize your offering. In fact, with the right SaaS architecture, ISV’s can enhance their freedom to repackage their applications in order to come up with an entire catalog of functionality-price combinations to meet the needs of different customer sets and markets.Flexible Metering and Monetization Schemes: Inexorably linked to the configuration and packaging options an ISV must bring to market are the corresponding metering and monetization schemes. Being able to tailor both the application and its pricing is critical to expanding market reach and capturing maximum fee potential within the client base.Tenant (customer) Self Service: Automating account creation and applicationprovisioning gives customers the instant-on satisfaction that they expect in the cloud. More importantly, it is critical to making the ISV’s internal operations and workflow efficient. If on-boarding a new customer requires manual intervention from client services and/or IT growth and responsiveness will be limited and margins will be impacted by an upfront cost that should have been zero.Security and Data Isolation: The SaaS precept of multi-tenancy creates a derivative requirement around data isolation. Despite commingling data in a multi-tenant database and sharing a single instance of an application amongst multiple users (who might have different application experiences) tenant data affinity must be 100% reliable. That is, the system must be able to distinguish between users, their associate tenant accounts and correctly route their data and application settings at all times. This is an important risk point for the ISV since they are taking on responsibility for the customer’s data.Familiar Development Toolset: As with any technological change, being able to use familiar tools and languages can smooth the transition. In situations where industry standard core technologies are supported, existing code assets can be repurposed and reused, leveraging those prior investments and intellectual property.
  • The Cloud Strategy

    1. 1. The Cloud Strategy<br />The Promise, Partnership, and Prospect <br />of the new business shift<br />
    2. 2. Historical Preview of disruptions<br />As with prior shifts in the software industry, this shift has created new opportunities and shaken up the positioning of market leaders. <br />Thinking back to the early days of the software industry we see that these changes in software delivery models represent fundamental disruption points in our history. Moving from mainframe to client side applications ushered in a host of new players such as Wordperfect, Legent and Mapics, while former successes like Management Sciences America (a $50M company at one point) fell o the map. <br />Later, as client-server applications were eclipsed by clientless browser-based solutions these companies also fell away as new leaders such as Seibel, Business Objects and PeopleSoft rose to prominence in the 90’s. <br />We are again seeing a new game changer with companies like Salesforce.com, Netsuite and Workday taking the limelight with their cloud-only SaaS (Software-as-a-Services) delivery models.<br />
    3. 3. Not If but When?<br />The question is not if moving to adopt the cloud as the next big delivery medium for software makes sense it’s when<br />Ensuring that will not be too late.<br />
    4. 4. Why ASPs failed and what will make SaaSsuccessful?<br />We actually saw the early signs of this appetite and the potential for a successful remote delivery model in the mid to late 90’s with the popularity of the now defunct Application Service Providers (ASPs). <br />These players saw very strong uptake and traction with their target market by centrally hosting traditionally on-premises software products and offering them via remote delivery means. <br />Unfortunately, a fundamentally flawed technical foundation crippled their business models and lead to almost all of them shutting down, leaving paying customers in the lurch and billions of dollars in venture capital written off. <br />The current fervor for cloud applications is a continuation of this market appetite evidenced years ago and, luckily, the highly efficient technical architecture of the SaaS paradigm corrects the flaws of the fatal ASP model and opens the door to massive economies of scale and sustainable profit generating operations.<br />
    5. 5. Traditional Vs SaaS<br />Barriers to adoption and fee structure: <br />Traditional on-premises software is often very difficult to adopt due to the expensive upfront license fee and the associated capital expenditure that needs to be budgeted for. <br />SaaSsolutions, on the other hand, lend themselves to free trials and other low touch, foot-in-the-door sales tactics. They also do not require large upfront capital expenditures, as the monthly service cost is counted as an operating expense for the customer and thus often comes out of a department-levelbudget, requiring the buyer to hop over significantly lower hurdles to have the expenseapproved.<br />Installation procedure: <br />Traditional software systems often require consultants and meaningful projects to install on-site with the customer. Systems Integrators have grownto prominence largely to fill this role. The initial installation and setup process is time consuming and costly to support for both vendor and customer alike. <br />SaaS products require no installation. New customers are provisioned automatically behind the scenes and are immediately available for use. Some customization or integration work may be required in certain situations, but it is contained by eliminating the non-value added installation process and can usually be performed remotely, thereby drastically lowering the bar on time and cost.<br />Supporting infrastructure requirements: <br />An on-premises software package is only one piece of the upfront solution cost. In order to get the application up and running a full supporting system of hardware, middleware, database and network components needs to be purchase, installed and configured as a prerequisite. <br />In a SaaS model all of these expenses are all absorbed by the provider who leverages those investments across their entire customer base. A customer using a SaaS solution needs only a PC and an internet connection.<br />Ongoing responsibility: <br />In the on-premises model, the continuing requirements andprocess of maintaining, administering and patching the system rest squarely with the customer. <br />With a SaaS model, the customer does not need to invest in training nor allocate manpower and time to the ongoing support of the system; these burdens are all transferred to the vendor.<br />Business and technology risk: <br />As with the other examples, risk is also transferred from the client to the vendor. Where once the client had to shoulder the risk of poor software selection, high upfront investments, potential blame games between business departments, IT and consultants, etc… <br />Now the software vendor acts as a single expert provider responsible for software uptime, performance and quality of service (QoS). With a single “throat to choke” and lower initial commitment hurdles to clear, customers can more confidently adopt a solution.<br />
    6. 6. Benefits to the ISV<br />The thematic shift of cost, headache and risk from the client to the ISV creates both opportunity and stability for the ISV as it empowers them to deliver a much higher quality user experience than ever before.<br />Aggregate operating environment: The ISV writes the software for optimal performance on a single infrastructure profile – their own. No more headaches testing against multiple versions of supporting middleware and OS configurations. As a provider, the ISV owns their domain. No longer are you sending technicians to fix or customize your software because it doesn’t fit into a customer’s highly-specialized (or horribly outdated) infrastructure.<br />Predictable revenue stream: The subscription model of SaaS transforms the feast and famine cycle of license sales into a much more manageable recurring revenue stream. Having the flexibility to allow for various monetization schemes allows ISV’s to add high margin extras such as transaction fees. This reliable foundation makes the entire business easier to administer.<br />Continuous agile updates: By operating a single instance of the application and ISV can focus on evolving the application UI and functionality, rather than worrying about compatibility, patching and release logistics. Updates are fast and controlled.<br />Continual self service up-sell: Thanks to the instantly available nature of SaaS provisioning, new customers can automatically be on-boarded and existing customers can instantly add services and users to their account, providing a power aspect of organic account growth.<br />Ability to grow the addressable market: Moving to SaaS can grow the ISV’s target market in two ways – first the monetization flexibility and lower cost of SaaS allows for moving down-market to smaller accounts that would not have been profitable under a traditional license based business model- the Long Tail. Furthermore customers can actually allocate more budget toward the application provider since they are freed from any spending on hardware, middleware, consultants, updates, etc. For ISV’s in a leadership position within their market who are seeing fewer new license sales, these dynamics can be especially helpful in reinvigorating top line growth.<br />Improved customer experience: By taking control of application delivery, the ISV can ensure uptime, speed and reliability, providing a better end user experience than a customer’s IT department ever could. Ultimately, better quality of service (QoS) means less user push back, higher usage and better adoption – all metrics that help grow and retain existing accounts. <br />
    7. 7. Unique Requirements for Success in the Cloud<br />These requirements are crucial in preventing run-away cost and engineering problems while realizing the full high margin potential of the SaaS model<br /><ul><li>Low Time to Market
    8. 8. High Tenant Density
    9. 9. Customizable Application Configuration
    10. 10. Flexible Metering and Monetization Schemes
    11. 11. Tenant (customer) Self Service
    12. 12. Security and Data Isolation
    13. 13. Familiar Development Toolset</li></li></ul><li>New Operational Cost Elements and Metrics<br />
    14. 14. NewOperational Cost Elements<br />Unlike traditional licensed software which is essentially 100% gross margin, offering applications in the cloud means an ongoing cost associated with making it available to end users (delivery) which come directly out of the ISV’s gross margin. While the SaaS model and attributes outlined above serve to minimize these cost elements through high efficiency and economies of scale they are important to understand.<br />There are a few key elements to manage delivery cost and maximize gross margins:<br />Tenant density – the number of customers per server. Many SaaS leaders achieve densities of 100 tenants or more with thousands of associated end users.<br />Infrastructure/platform maintenance – any software development unrelated to the product application’s UI and business logic should be minimized. These are expenditures that are unrelated to your product’s value proposition and non-core to the business.<br />Application updates/patching – with potentially shortened release cycles in a SaaSmodel it is important to streamline the deployment process to minimize wasted developer cycles and IT overhead<br />
    15. 15. New Metrics<br />The SaaS business model has a number of metrics that are quite different than the measures of a traditional software business and are instrumental in managing and monitoring top line health.<br />Committed Monthly Recurring Revenue (CMRR) – the monthly revenue under contract, or booked revenue by month.<br />Customer Acquisition Cost (CAC) – in the world of SaaS where software is not 100% gross margin, the cost of acquiring each new customer must be measured carefully to ensure that each customer is indeed profitable rather than digging into a hole of unprofitable customer contracts.<br />Churn – the rate at which customers defect away from your oering. Increasing retention is often more important than adding new customers as there is no new CAC associated with retaining an existing account, making them more profitable.<br />Customer Lifetime Value (LTV) – the total value of an average customer over the expected duration of the relationship. This number must exceed the CAC + the total cost of application delivery in order to break even on a unit basis.<br />Cost of Goods Sold (COGS) – the ongoing cost of delivering the application to subscribers. This includes incremental hardware, storage, bandwidth, etc.. costs for each additional tenant and associated end user.<br />
    16. 16. Assembling Your Stack<br />Choose Your Cloud Partners Carefully<br />
    17. 17. Assembling Your StackChoose Your Cloud Partners Carefully<br />Three key decisions an ISV needs to make <br />INFRASTRUCTURE<br /> the processing power, storage, bandwidth and OS<br />PLATFORM<br /> the foundation from which to deliver their SaaS offering<br />SOFTWARE<br />
    18. 18. Infrastructurethe Foundation<br />
    19. 19. Infrastructurethe Foundation<br />This doesn’t essentially mean that ISVs need to adopt the IaaS themselves. Traditional hosting options such as <br />Managed, <br />Dedicated or <br />Co-Lo <br /> are often more cost effective and conducive foundations for a SaaS delivery model.<br />
    20. 20. Infrastructure partner<br />Key considerations when choosing an infrastructure partner<br />Public vs. Private Cloud: A public cloud shares resources amongst clients, meaning a spike in usage for one client could adversely affect others the scaling needs of others in that cloud.<br />Ease of Scaling: Any infrastructure provider must be robust enough to accommodate variability in demand. The ISV should understand the exact process for adding resources to the footprint as their business scales.<br />Setup and Deployment Cost: What are the upfront costs associated with adopting the foundation and what is the incremental cost of scaling? Are there any changes required in the application itself – ie does the provider support Java, .NET, PHP, etc?<br />Ongoing Cost: It is important to model the anticipated fully loaded cost of the environment and how the cost will scale with anticipated customer demand.<br />Transparency – The pricing mechanics should be clear enough that costs can be anticipated and reconciled.<br />
    21. 21. Platformthe Operating System<br />
    22. 22. Platformthe Operating System<br />Above the raw infrastructure layer, a cloud ISV needs the right platform to power their SaaS offering. ASP’s had the fatal flaw of relying on virtualization techniques alone to accommodate the delivery paradigm shift. In reality, an entirely new architecture is needed in order to make this change successfully. Modern SaaS ISV’s like Netsuite and Workday have invested heavily in order to realize the benefits of true SaaS architecture such as tenant density (the number of end users) – 100+/server vs. 3-5 for those using virtualization.<br />
    23. 23. The Platform Options<br />Build: Pioneering cloud software companies like Salesforce.com, Netsuite and Workday all had to build their SaaS infrastructure from the ground up. These early SaaS implementers were required to raise large sums of capital (an average of $40M) to support their development and go-to-market strategies as they invented the business and technology from the ground up. Luckily, there are now build vs. buy options available. Avoiding reinventing the wheel can eliminate 40-60% of the upfront development eort, while providing a solid foundation replete with the key attributes discussed above.<br />Frameworks: For those choosing not to go the build route there are a number of frameworks, Platform as a Service (PaaS) and application server options. Frameworks tend to aid somewhat in the initial go-to-market timeline, but offer very little in terms to the functionality needed to monetize an offering and manage/scale in the highly efficient manner necessary. An ISV must be diligent in understanding which components of the SaaS underpinning features described previously are endowed by the framework what which components must be built from scratch.<br />Platform-as-a-Service: Many PaaS offerings do provide significant SaaS enabling functionality, but tie the ISV to a per user cost model that creates a baseline COGS that is unsustainable in many cases. For example, Force.com, one of the leading PaaS offerings charges ISV’s $50-75/user/month. In order to reach even a 50% gross margin over that baseline COGS an ISV would have to charge a minimum of $100/user/month – a price point that wouldn’t be feasible in many markets. When evaluating PaaS offerings, ISV’s should analyze the vendor’s client base to understand if it is more popular with ISV or enterprise clients, as this will inform them as to the platform’s strong suit and enablement focus. Furthermore, PaaS offerings constrain the programmatic capabilities of the developer, constraining their usefulness to fairly basic applications, widgets or add-ons to existing products.<br />Application Servers: In recent years a few application server technologies have emerged specifically to provide ISV’s with the key functional attributes needed to SaaS-enable their existing product offerings. It is important to understand if these require any proprietary code and how an application built for a given application server might function if sold in a traditional on-premises fashion. These solutions provide maximum degrees of freedom for the developer while abstracting away the overhead of having to deal with SaaS underpinnings. These offerings follow in much the same vein as traditional application server like BEA’s Weblogic, except that been evolved to address the unique requirements of the SaaS model.<br />
    24. 24. SoftwareThe Building Blocks<br />
    25. 25. The Decision LinesAvailable Options In Hand<br />
    26. 26. The Microsoft Stack<br />
    27. 27. The Community Stack<br />
    28. 28. The Open Source Stack<br />
    29. 29. Building your New Business<br />The Business Lanes<br />
    30. 30. Building your Ecosystem<br />Technology, Partners, Customers… and Culture<br />
    31. 31. Owner of the Customer Relationship<br />Now, its less about technology <br />and more about relationship<br />
    32. 32. SLA<br />Change in profit realisation model<br />Usage Analytics<br />Social Scoping<br />Creating and managing User groups and communications<br />Choosing your Ecosystem - partners for services viz; Infrastructure, integration, 3rd party services for say user group management, viral marketing, data backup on-premise, custom code backup to avoid lockin (will be useful marketing selling point), online Bill Payment collection partners<br />Creating a flexible architecture for your SIs and VARs to choose their own services for localization and regulatory requirements like taxation services for an accounting software <br />Diversify Offerings – Mobile based, Offline mode.<br />
    33. 33. Marketing And Sales Teams<br />
    34. 34. Revenue Streams and Pricing Strategy<br />
    35. 35. Professional Services<br />
    36. 36. Long term Customer retention and loyalty<br />
    37. 37. Channel Partners, Aggregators, Value Added Resellers and System integrators<br />
    38. 38. The ROI Framework for your Cloud Investment<br />Value for money<br />
    39. 39. No matter what your intentions are, you're going to be judged on the execution. <br />

    ×