Session 3a The SF SaaS Framework
Download as PPTX, PDF1 like519 views
This document provides an overview of a SaaS application developed using lean software development principles. It discusses why the application was created as a demo product, describes the generic supply chain application and major entities, and covers considerations for SaaS including pricing models, costing, tenant separation, technical support, signups/payments, customer service, and security.
Session 3a The SF SaaS Framework
- 1. SaaS A practical example of a real-world SaaS application done with LEAN software development. • Stuart Williams, Principal Lead, Magenic SF
- 2. Why? We needed a demo • We really can’t show most of our project to potential customers and at community events because the things we do are confidential. We wanted – to make a real SaaS product with the latest stable technology – the milieu to be understandable by anyone – to be able to give the parts of the code away – to give sales a “killer demo” – to show off what we thought were good patterns and practices in all of the technology areas that are part of the demo – to leverage some of the services in windows and azure service bus • So, we thought about it as a group and decided that what we would do would be a real project treated like a product, made with high quality, and delivered the same way we would deliver it for a real customer
- 3. Why SaaS? • Because we want economies of scale – Shared infrastructure will lower the per user cost • Because we want one version of our product – Everyone benefits from an upgrade with new features or fixes – Cost of developing new features defrayed across multiple tenants • Because we want to have a per user/per month pricing model – That way cost to tenants is predictable and scales smoothly • Tenants can start using the product very quickly – Nothing to install, just some configuration and data and off they go • Easy to debug tenant issues as opposed to premise – we have full access to the infrastructure and inspect as needed
- 4. The What: Generic Supply Chain Application • Focusing on B2B delivery of goods and services • Examples: – Cleaning Supplies – Cleaning Services – Linen Service – Specialized Office Supplies – Appliance Parts – Etc. • The portal we are building will be for the benefit of the employees of the company who we are providing software for (AKA the TENANT) who is the client of the SaaS company (Magenic) • SaaS means that on the same infrastructure we can support multiple Tenants each with their own business
- 5. Screen Shot
- 6. Major Entities • Tenant • Sales Orders – One instance for a specific – Customer buys products and client services – Also used for refunds and • Company adjustments – All kinds: Customers, Vendors, • Purchase orders Others – Client (Tenant) buys stuff to sell • Contact • Delivery/Shipment – People of all kinds – Covers deliveries and shipments – People belong to Companies • Payments • Products – Client get paid from their – Stuff to sell customers – Includes services • Transactions – Record of all transactions Lots of other smaller tables like notes, etc.
- 7. SaaS Pricing Models • Free – Open source projects that rely on contributions (rare) – More commonly buy-up to better features, extra services • Extras billed as used • Per user/per month – Most common, predictable, easy to understand • Usually monthly billing with pre-pay discounts for multi-month • Extra charges itemized on each invoice – Usually with some sort of limits on transactions or storage • Per XXXX – Per transaction or event • Usually instant billing – Good for services people will only want occasionally
- 8. SaaS: Costing • The nuance of course is figuring out how much a SaaS offering on a platform will cost. For cloud this is especially tricky as there is a fair amount of variable cost possible e.g. they bill you like a Taxi, typically you bill your customers like a magazine subscription. The question is of course is, do you make more than it costs? • To really model the cost You MUST – Have a pretty good idea of your architecture and what services etc. your application are using – Have a solid visualization of the actual usage patterns of your customers e.g. how many users per tenant, how much storage, transactions, uploads, etc. – Monitor the ACTUAL resource usage of your customers to make sure you did not over or worse under estimate their usage • Magenic’s cloud group can help organizations build models for SaaS offerings working with IT and Finance
- 9. SaaS Cost + Pricing • The problem is that even if the resource usage scales linearly with users, the infrastructure cost is generally stair step or sinusoidal – So up to a point adding additional users does not change the cost model, but then to comply with the expectations of the users you will have to add an aliquot of capacity which is in larger whole units, from then on until a new break even point is reached you are paying for infrastructure you are not using but are paying for – More subtly, adding a new customer (not just more users) may have start up costs of its own, such as a need for another SQL instance, another set of storage keys, etc. This makes the stair step even more jagged. – Again working with Finance is key, as they may have other considerations such as CAPX vs. OPX, etc. they want have considered. • Of course you need to pay to develop it, operate it, and of course make money.
- 10. The Stair Step Is this line above (good) below (bad) or on the stairs? $$$$ Subscribers
- 11. Typical Costing vs. Pricing Calculator (Excel) Basic Facts Sizing and Frequency based on data model, expectations of usage, frequency of updates, etc. One Tenant Cost # Tenants (projected) Additional fixed and variable costs Pricing Models
- 12. SaaS: Key Requirements To Think About • Capture user events for billing and analysis – Logins – Transactions – Data Storage (GB) – Uploads/Downloads (KB) • Use these to make sure your projection of cost agrees with what you planned so as to validate your pricing model • Make sure you keep track per tenant the invoicing events, you can insert these as events into an events table along with the other events • Even if you plan to offer it free, keep track anyway • Instrumentation can be hard to add in later, so plan for it from the start
- 13. SaaS: Tenant Separation • Prospective tenants will be anxious about how we will go about keeping their data separate from everyone else • This is the single most important issue for both business and architects • Strategies: – Database • For all entity tables make sure that the tenant ID is a required FK • For queries, test, test, test, make sure that tenant separation tests are P0 fails • Sadly, instance/tenant is not economical – Storage • Use providers container mechanisms to keep them logically separate • Make tenant Id part of storage path or key – Web site • Make tenant id or alias part of path (MVC is good at this) • Make sure pages fail if no tenant or if record requested does not belong to tenant • TEST TEST TEST • Even one tenant separation failure Very bad news
- 14. SaaS: Tech support considerations • Do we allow tech support to impersonate the tenant admin and look at the tenant’s data? – If so, how much of it? • Could be scary and risky – If not • then some sort of screen/session sharing is essential • Can avoid having to deal with user login issues if using FI (More about this later) • Tenant Administrator (Superuser) can do basic stuff to tenant like re-issuing the invitation for the Company Admin to link up FI or enabling/disabling tenants • Make good screens so Company Admin can self manage their own data and users – Some problems are beyond tech support, so have a plan just in case – In all cases must provide repudiation protection via logging and audit trail
- 15. SaaS: How do they sign-up? Pay? • Do you allow self signup? – For consumer apps this is not even a question it is a MUST HAVE. – For commercial apps, typically not, might require more setup and configuration, not to mention hand holding • How do they pay? – Consumer apps • typical e-commerce methods PayPal, credit cards • Unless e-commerce is your core business outsource payments – Commercial apps • Can do credit cards if amounts are < $X • Typically invoiced monthly • also invoicing forces some degree of interaction with customers
- 16. SaaS: Provide great customer service • SaaS (or any other web app) is not an excuse for poor customer service • Some hallmarks: – Decent help text, ideally on each page as they go – FAQ focused on problem areas – Walkthroughs of common tasks – Provide live chat (especially for commercial apps) – Provide easy to find e-mail help with guidance – Solicit feedback on each page and on the site in general – Keep help content fresh with new content driven by customer service and customer feedback • Great support and easy to use features == Customer Loyalty
- 17. SaaS and Security • Organizations – spend too much mental energy on if the cloud host (Azure for example) is secure and – far too little effort and energy on if the code of their application is secure • The chances that the infrastructure will let you down from a security point of view is REMOTE compared to the risks of: – Poor deployment – Horrible configuration – Bad key management – Security holes in the code • There is not substitute for having a Security Development Lifecycle and building in security at all levels and processes
- 18. Q+A Ask away!