From Saa S to Paa S Andrés G

From Saa. S to Paa. S Andrés G. Vettori, CTO andres. vettori@vmbc. com

Agenda About us What is Saa. S / Paa. S? Differences? Emerios 1. 0: our Saa. S solution. Our Pain Points Emerios 2. 0 : our Paa. S solution. Emerios 2. 0 Demo Learned lessons

About us

About vmbc 1997: Inbound and outbound call routing with Preference. Manager™ 1998: 28 DS 3’s brought on line to scale to the needs of any client 1999: Automated call compliance with Compliance. Lock™ 2000: Live reporting capabilities with In. Report™ 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 Voice. Rec™ 2007: Mobile internet and rich media delivered by VContent™ 2008: Multi-channel enrollment and verification with ERS™

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

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.

Saa. S == Software as a Service http: //en. wikipedia. org/wiki/Saa. S 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.

Paa. S == Platform as a Service http: //en. wikipedia. org/wiki/Paa. S Platform as a service (Paa. S) is the delivery of a computing platform and solution stack as a service. Paa. S 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. Paa. S 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.

Saa. S vs Paa. S? Saa. S: focus on providing application services to solve ONE vertical industry problem. Paa. S: focus on providing platform services to build any application for any industry.

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

Saa. S == Paa. S? Multi-tenancy Scalability Fault-tolerance Configurability & extensibility: optional for Saa. S, mandatory for Paa. S

Our Saa. S Solution

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.

Lifeline Enrollment Timeline A History of Success!

Safe. Link™ 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 Lexis. Nexis Validation rules. Released in July, 2009.

Safe. Link™ Enrollment Applications Received 8, 646, 325 Applications Active 4, 334, 443 Phones Shipped 6, 364, 266 In Process ~50 K Public site daily visits: ~260 K New Enrollments per day: ~10 K Phone calls processed per day: ~30 K Documents processed per day: ~5, 000

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

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

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

Safe. Link Enrollment Public site daily visits Daily Average: 266, 521 Maximum: 386, 707

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

Emerios 1. 0 System Block Diagram

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

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)

Our Paa. S 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?

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

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 nondeveloper team members.

Motivation Typical Requirements’ Lifecycle with Emerios 1. 0 :

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

Motivation 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.

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

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 App. Store)

Research - Salesforce What we did not like: – Propietary extensibility language (Apex) – Form-based configuration tools (as opposed to point-and-click and dragand-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

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 App. Store) – Integration with SAP

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

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 nontechnical 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

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)

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

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).

Research – Conclusions Buy Approach Pros 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. Cons 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 Pros 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). Cons 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. ).

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.

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.

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.

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 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 Database.

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 – – –

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.

Emerios 2. 0 – Architecture

Emerios 2. 0 – Core Metadata Module Describe Business Entities (e. g. : «products» have «price» , «sku» , etc. ) 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» ) REST API Module Expose business processes through HTTP REST (e. g. : to be consumed by “light” i. Phone applications) Other Modules – Examples Address Validation Enrollment Lifeline Customer Identity Validation (Lexis. Nexis) SOAP API Module Expose business processes as SOAP Web Services (e. g. : to be consumed by ETC’s workflows)

Case Study: E-Commerce

Case Study: E-Commerce

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 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.

Emerios 2. 0 Demo Administration site Process Workflow designer

Learned Lessons Before building anything, define your business objectives Becoming a Paa. S solution provider is not the natural (and mandatory) evolution step after Saa. S It might be, if you are worried by the economies of scale of your potential business and projects There a lot of architectural and technical challenges in any Saa. S and Paa. S solution. Paa. S adds on top of Saa. S 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

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

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