1. From SaaS to PaaS Andrés G. Vettori, CTO andres.vettori@vmbc.com

2. Agenda About us What is SaaS / PaaS? Differences? Emerios 1.0: our SaaS solution. Our Pain Points Emerios 2.0 : our PaaS solution. Emerios 2.0 Demo Learned lessons

3. About us

4. About vmbc 1997: Inbound and outbound call routing with PreferenceManager™ 1998: 28 DS3’s brought on line to scale to the needs of any client 1999: Automated call compliance with ComplianceLock™ 2000: Live reporting capabilities with InReport™ 2001: Virtual routing intelligence with Active Listening™ 2002: Multiple message testing with Rapid Recycle Resonance™ 2004: SMS capabilities to 2.2 billion mobile users with VClient ™ 2005: Web, Voice, and Mobile interoperability with VLink 360™ 2006: Artificial intelligence and speech recognition with VoiceRec™ 2007: Mobile internet and rich media delivered by VContent™ 2008: Multi-channel enrollment and verification with ERS™

5. About vmbc Pioneer the of Message Broadcasting Industry – Authoritative leader in compliance with State & FTC regulations – Best record in the industry for state-by-state and HIPPA compliance Unmatched Experience and a Worldwide Presence: – Founded in 1997, over 4 Billion+ Contacts…and counting – Worldwide Presence: Los Angeles, London, Buenos Aires, Irvine Market Leading Intelligence Response Technologies – Emerios Response Services™ database and response platform ensures superior customer experience – Storied history of innovation and development

6. About me Love technology in general, self-taught. With a Digital electronics background, I equally enjoy writing code and building stuff (computers, networks, etc.) 30 years as a software developer – That’s true. I’m 42 and wrote my first program (a text version of “Luna Lander”) when I was 12, using a Casio programmable calculator. 17 years as Project/Team Leader 15 years as Software Architect 10 years as CTO / Chief Architect Microsoft Certifications: MCSE / MCSD / MCT Some projects leaded: Renault Argentina Extranet Licitaciones, ISP Ciudad Digital, Proyecto Middleware TERNIUM.

7. SaaS == Software as a Service http://en.wikipedia.org/wiki/SaaS Software as a service, or "on-demand software," is a software delivery model in which software and its associated data are hosted centrally (typically in a public or private cloud) and are typically accessed by users using a thin client, normally a web browser over the Internet.

8. PaaS == Platform as a Service http://en.wikipedia.org/wiki/PaaS Platform as a service (PaaS) is the delivery of a computing platform and solution stack as a service. PaaS offerings facilitate deployment of applications without the cost and complexity of buying and managing the underlying hardware and software and provisioning hosting capabilities, providing all of the facilities required to support the complete life cycle of building and delivering web applications and services entirely available from the Internet. PaaS offerings may include facilities for application design, application development, testing, deployment and hosting as well as application services such as team collaboration, web service integration and marshaling, database integration, security, scalability, storage, persistence, state management, application versioning, application instrumentation and developer community facilitation. These services may be provisioned as an integrated solution over the web.

9. SaaS vs PaaS? SaaS: focus on providing application services to solve ONE vertical industry problem. PaaS: focus on providing platform services to build any application for any industry.

10. SaaS  PaaS? Building a PaaS solution might be more complex and harder. Becoming a PaaS provider is not the natural evolution step for all SaaS providers. Is just an strategic business decision based on what you want to be.

11. SaaS == PaaS? Multi-tenancy Scalability Fault-tolerance Configurability & extensibility: optional for SaaS, mandatory for PaaS

12. Our SaaS Solution

13. Emerios 1.0 Real-Time Customer Verification and Response – End-to-end multi-channel Enrollment processes. – Vmbc verifies name, address, social security number, phone number, tax information, email address and desired outcomes of customer. – VMBC requests communication preferences from customer in order to understand the method by which they prefer a response. – After verification, Vmbc responds with appropriate forms, instructions and requirements in order to service the customer – VMBC follows up to ensure the customer has responded with all necessary documentation necessary to qualify for the service. – If the enrollment business process includes periodic verification, vmbc manages that as well.

14. Lifeline Enrollment Timeline A History of Success!

15. SafeLink™ Enrollment Outstanding achievement – Less than 4 months from final PDD to production release after UAT in August, 2008. – Definition, development and rollout of 7 states in less than 4 weeks (AL, CT, DC, NH, NJ, OH, WI, WV) on June 2009. An average of 1 State every 4 days. – Less than 12 weeks to design, develop, test and release the customizable Fraud Prevention Engine through LexisNexis Validation rules. Released in July, 2009.

16. SafeLink™ Enrollment Applications Received8,646,325 Applications Active4,334,443 Phones Shipped6,364,266 In Process~50K Public site daily visits: ~260K New Enrollments per day: ~10K Phone calls processed per day: ~30K Documents processed per day: ~5,000

17. Development Platform & Tools.NET based Team Foundation Server / Team Build Visual Studio 2010 -.NET 4 ASP.NET, MVC, Ajax, WCF, WPF, WF Silverlight 3.0 Enterprise Library 4.x WS-Federation, Identity Framework Retina.NET 2.0 OR/M Others: ABCPdf, Moq, Selenium

18. Emerios 1.0 Platform Private Cloud with two redundant Data Centers Operating System – Windows Server 2008 R2 x64 – Microsoft® Hyper-V 2.0 – IIS, MSMQ, NLB, Active Directory Database: MS SQL Server 2008 x64 IVR Services: Speech Server 2007 x64 Supporting Services: TMG 2010, SUS, System Center 2007 Storage: 2x SAN Dell Storage: 45 Disks 450Gb 15K (20Tb Raw)

19. New Enrollments by day Daily Average: 9,599 Total: 2,401,483 Maximum: 13,910 SafeLink Enrollment

20. Public site daily visits Daily Average: 266,521 Maximum: 386,707 SafeLink Enrollment

21. Phone calls processed by day Daily Average: 30,579 Total: 6,988,123 Maximum: 42,050 SafeLink Enrollment

22. Emerios 1.0 System Block Diagram

23. Our Pain Points Development life cycle for “content changes” – Implemented a CMS (Sitefinity 4.x) New Release Deployments – Custom tool on top of MSDeploy Storage – IOPS vs. effective space – Monitor usage patterns to keep optimizing things – Database monitoring & tuning – Partitioning / Sharding

24. Our Pain Points Server Memory consumption – Server role consolidation (POD strategy) – Memory usage optimization – Shared caching strategies (Velocity) Data replication – Settled down on SQL Mirroring Production Monitoring & Diagnostics – Mix of System Center and custom tools (performance counters, Http Trace, self-diagnostics, etc)

25. Our PaaS Solution On top of all that, we then focused on the “business part” of our requirements: – How hard is to add new functionality or change something existing in a system? – How easy we could create a new solution for a completely new industry? – How fast and easy we could deploy a new instance of a system for a new customer?

26. Motivation Enrollment System (Emerios 1.0) limitations: – Designed for the implementation of client’s Lifeline government programs – Customizations require extensive knowledge of the code and the development environment -> long lead times for the execution of changes requested by clients – No economy of scale to maintain and support development of new features for new customers

27. Motivation Emerios 2.0 must entice the market through a powerful, graphic User Interface that provides end-to-end customization of processes and workflows that are not limited to one industry. In order to improve the value of Emerios, create business opportunities and get more clients on the platform, the solution must be dynamic and easily customizable by non- developer team members.

28. Typical Requirements’ Lifecycle with Emerios 1.0 : Motivation

29. Requirements’ lifecycle with Emerios 2.0: – Business Analysts are able to capture business requirements and execute their design models as working applications -> no more ultra- detailed documents to be interpreted by developers and testers Motivation

30. An example of module-based development on Emerios 2.0: – A new “Financial Module” is added to the existing “Qualification”, “Billing” and “Data Validation” modules. Motivation

31. Research With the aim at learning from existing model-oriented platforms, the following products were analyzed: – Salesforce – Mendix – Outsystems Agile

32. Research - Salesforce What we liked: – Rich business entity definitions – Formula-based fields and field validations supported – Automatic CRUD forms for business entities – Business model published as a web service (API) – Common business entitiy aspects (notes, attachments, etc.) – Modular Extensibility – Approval Templates (Mail, Web forms) – Business Model testing support – Integrated public UI and reporting – Module Market (like the AppStore)

33. Research - Salesforce What we did not like: – Propietary extensibility language (Apex) – Form-based configuration tools (as opposed to point-and-click and drag- and-drop UIs) – Configuration tools oriented to business developers (with some degree of programming skills) – Web-based tools with poor user experience (i.e. no intellisense, HTML source code editing, etc.) – Workflows do not enable the definition of operations, just rules

34. Research - Mendix What we liked: – A basic application can be developed in less than 5 minutes – Workflows can invoke other workflows – Document Templates (same as Emerios Enrollment System's generated PDF forms) – Business Model Versioning – Business model published as a web service (API) – API with multiple entity formats (JSON, XML, Java native), and multiple hosting protocols (HTTP, Web Services, Java native) – Both Cloud and On-premises hosting supported – Modular Extensibility – Module Market (like the AppStore) – Integration with SAP

35. Research - Mendix What we did not like: – Only Java extensibility supported (our know how is.NET-based) – On-premises hosting using Java technologies only (our know how is based on Microsoft technologies) – Configuration tools are Desktop-only – Business Entity Modeling using complex UML notation

36. Research - Outsystems Agile What we liked: – A basic application can be developed in less than 5 minutes – Configuration tools with outstanding user experience, oriented to non- technical users – Workflows for site navigation – Integrated public UI, reporting and performance KPI. – Business Model Versioning with 1-click deploy and 1-click rollback – Business data and Business Entity definitions can be imported from Excel – Application Templates (with predefined functionality for common business models) – Supports multiple platforms and languages (.NET / Java) – Automated deploy and rollback – Modular Extensibility – Both Cloud and On-premises hosting supported

37. Research - Outsystems Agile What we did not like: – Configuration tools are Desktop-only – Requires platform services side-by-side with business services (when hosted on-premises)

38. Research - Comparative SalesforceMendixOutsystems Agile Modelling Interface Web site with form-based UI Desktop App (Visual Studio alike) Desktop AppDesktop App (excellent UX) BUSINESS MODEL Entities Form-based UML class diagram / Entity-relation model Entity list (can be imported form Excel) Workflows Form-based Workflow Designer Triggers/Events Form-based Business Rules Expression editor (textual DSL)Special Workflow DSLWorkflows User Interface Raw custom-HTML editor / Visual Force Desktop editor Form editor Form editor + Workflow for navigation Versioning Supported Extensibility Apex propietary programming language Java.NET / Java 1-Click Deploy Supported 1-Click Rollback Supported (what about data changes?) ARCHITECTURE Cloud Hosting Supported On-premise Hosting Not-supportedSupported Fault-Tolerance They claim they don't have single- points-of-failure (this means full redundancy on every layer) Reporting Integrated reports (web UI) Full audit of data changes Integrated reports Integrated reports Automatic performance KPIs

39. Research – Conclusions Building Emerios 2.0 as an application platform, with almost the same functionality as the ones analyzed, would demand a great effort, thus a project of several months. However, Emerios 2.0 cannot wait so much time to enter the market, which leads to evaluate the following possibilities: – “Buy” approach: use an existing platform, taking full advantage of every aspect that it has out-of-the box, and focus on building those modules whose business Emerios knows well and has experience on. – “Incremental Build” approach: build a minimal core that can execute business models coming from different sources (code, workflow, database, etc.), using coded processes in a first stage (fastest to build and do not require a user interface), and then, in future stages, include other types of business model configuration tools (that a business analyst could use to replace every coded process).

40. Research – Conclusions Buy Approach ProsCons  Best time-to-market.  Proven technology and architecture.  The most cost-effective:  Analysis, Development, Test, IT costs demanded when building a new product.  Maintenance costs.  Less flexible (it might be impossible to extend beyond the current scope of the platform and we cannot assess this until faced with the platform limitations vs. business requirements).  Worse fit to the business (generic solutions might not be able to fit the business model as tightly as a custom solution could).  Startup cost (after buying the product, we might need to write lots of business modules to fit our current business model).  Learning curve.  Security requirements might restrict the tool selection. Build Approach ProsCons  Best flexibility (there are no platform limits; we could always extend our kernel to accomplish anything, no matter how complex).  Best business modeling accuracy (we could model only which is necessary for the business, without the overhead of writing generic modules we do not really know we will need).  More time-to-market to come up with a polished product (Salesforce has more than two years of improvement over a working platform).  Need to build and integrate the modeling tools (business entities, business processes, etc.).

41. Emerios 2.0 – Product Vision The Emerios 2.0 solution is a highly configurable business modeling platform that can host multiple business models at the same time, providing an API to interact with external systems.

42. Emerios 2.0 – Business Models Emerios 2.0 is centered on Business Models, typically consisting of: – Business Entity Definitions: a description of the data involved in the business (e.g. products, purchase orders, enrollments, customers, etc.). – Business Processes: the operations involved in the business (e.g. purchase product, list products, create enrollment, etc.). These can be executed by direct execution, an event/trigger firing or scheduling. – Business Events/Triggers: can be seen as part of the business process definition, but important enough to be noteworthy. They provide support for asynchronous interactions (system or human based) and provide a way to connect and reuse business processes.

43. Emerios 2.0 – Business Models At design time Business Analysts create or maintain Business Models using the Emerios 2.0 Modeling Tools. Those Business Models are stored in an internal database known as the Business Model Database.

44. Emerios 2.0 – Business Models At run time, the Emerios 2.0 Runtime Engine loads Business Models, from the Business Model Database, and exposes Business APIs that can be used by external sites and services to interact with the Business Models. As a result of interaction with the Business Models through the API, business data is created, updated or deleted within the Business Data Database. For example, a Customer might browse a product catalog online and purchase a product. Afterwards, he might call an IVR to check the status of his purchase order. For example, when a customer purchases some products, the stock of those products is reduced and a new purchase order is created. This business data is stored in the Business Data Database.

45. Emerios 2.0 – Modeling Tools Business Analysts are the main users of Emerios 2.0 Modeling Tools. These tools enable them to model a specific business, which includes the definition of: – The Client whose business is being modeled – The Application to be hosted on Emerios 2.0 platform – Billable Items that will be part of the client/application billing – Business Entities, to store the data involved in the business – Business Processes, to model the behavior of business operations – Web Portals that will act as points of entrance to the application hosted on Emerios 2.0 platform – Security for the application hosted on Emerios 2.0 platform – Reports on business data and operations – Data transfer between Emerios and the client’s system

46. Emerios 2.0 – Modules Emerios 2.0 supports extensibility and configurability through a modular architecture. A Module is a logical grouping of components that provide a specific functionality by integrating with external services and/or extending other Emerios 2.0 modules. Emerios 2.0 Modules: – Can be enabled and disabled on a per-tenant basis without the need to deploy or restart services. – Extend both the design-time and the run-time aspects of Emerios 2.0. – Could be developed in-house or by third-party development teams. The Emerios 2.0 Core is the set of essential built-in Modules that are always available for any Business Model of any tenant. – Our Emerios 2.0 Standard Module Library built on top of our Core will provide additional functionality like: Security (authentication, authorization, data encryption), Auditing, Logging, etc.

47. Emerios 2.0 – Architecture

48. Emerios 2.0 – Core Metadata Module Describe Business Entities (e.g.: «products» have «price», «sku», etc.) Metadata Module Describe Business Entities (e.g.: «products» have «price», «sku», etc.) Data Module Create, Read, Update and Delete Business Entities (e.g.: «products») Data Module Create, Read, Update and Delete Business Entities (e.g.: «products») Process Module Create, Read, Update and Delete Business Processes (e.g.: «purchase products») Process Module Create, Read, Update and Delete Business Processes (e.g.: «purchase products») REST API Module Expose business processes through HTTP REST (e.g.: to be consumed by “light” iPhone applications) HTTP REST REST API Module Expose business processes through HTTP REST (e.g.: to be consumed by “light” iPhone applications) HTTP REST SOAP API Module Expose business processes as SOAP Web Services (e.g.: to be consumed by ETC’s workflows)SOAP SOAP API Module Expose business processes as SOAP Web Services (e.g.: to be consumed by ETC’s workflows)SOAP Other Modules – Examples Address Validation Enrollment Lifeline Customer Identity Validation (LexisNexis) Other Modules – Examples Address Validation Enrollment Lifeline Customer Identity Validation (LexisNexis)

49. Case Study: E-Commerce

51. Emerios 2.0 “In a Nutshell” Emerios 2.0 is centered on Business Models. A Business Model is a software representation of a real-world business. The Emerios 2.0 Modeling Tools are a set of tools used by Business Analysts to create and maintain Business Models at design-time. Business Models define entities, processes, events and additional configuration (security permissions & roles, for example), which are stored in the Business Model Database. The Emerios 2.0 Runtime Engine loads Business Models from the Business Model Database and exposes Business APIs for those models. Customer-facing apps such as Web Sites, IVRs, etc. access the Business Model through its Business API. Business data (e.g. products, orders, etc.) is stored in the Business Data Database. A Module is a logical grouping of components that provide a specific functionality by integrating with external services and/or extending other Emerios 2.0 modules. Modules can be enabled and disabled on a per-tenant basis, without the need to deploy or restart services, and extend both the design-time and the run-time aspects of Emerios 2.0. The Emerios 2.0 Core is the set of essential built-in Modules that are always available for any Business Model of any tenant.

52. Emerios 2.0 Demo Administration site Process Workflow designer

53. Learned Lessons Before building anything, define your business objectives Becoming a PaaS solution provider is not the natural (and mandatory) evolution step after SaaS It might be, if you are worried by the economies of scale of your potential business and projects There are a lot of architectural and technical challenges in any SaaS and PaaS solution. PaaS adds on top of SaaS the ability to define and build completely new applications We focused on “business processes” as the way to express and build applications by non-technical users Put usability and accountability as top priorities

54. Learned Lessons Keep It Simple (KISS principle) Do performance Testing Early in the process – Unit test / micro testing – Stress test – Load test – Long duration tests – Resource consumption Think about production monitoring and debugging Think about reporting and data integration

55. Andrés G. Vettori, CTO andres.vettori@vmbc.com