Beruflich Dokumente
Kultur Dokumente
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
About us
About vmbc
1997: 1998: 1999: 2000: 2001: 2002: 2004: 2005: 2006: 2007: 2008: Inbound and outbound call routing with PreferenceManager 28 DS3s brought on line to scale to the needs of any client Automated call compliance with ComplianceLock Live reporting capabilities with InReport Virtual routing intelligence with Active Listening Multiple message testing with Rapid Recycle Resonance SMS capabilities to 2.2 billion mobile users with VClient Web, Voice, and Mobile interoperability with VLink 360 Artificial intelligence and speech recognition with VoiceRec Mobile internet and rich media delivered by VContent 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
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
Thats true. Im 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.
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.
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.
SaaS == PaaS? Multi-tenancy Scalability Fault-tolerance Configurability & extensibility: optional for SaaS, mandatory for PaaS
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.
New States
Alabama West Virginia New Jersey Connecticut New Hampshire DC Ohio Wisconsin
Q4-Y2008
Q3-Y2008
-Multi language
New States
New York Pennsylvania Michigan North Carolina Delaware
Initial Release
New States Tennessee Florida
New States
Virginia Georgia Massachusetts
#Reqs:794
#Reqs:595
#Reqs:281 #Reqs:608
A History of Success!
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.
SafeLink Enrollment
Applications Received Applications Active Phones Shipped In Process Public site daily visits: New Enrollments per day: Phone calls processed per day: Documents processed per day: 8,646,325 4,334,443 6,364,266 ~50K ~260K ~10K ~30K ~5,000
SafeLink Enrollment
New Enrollments by day
16000 14000 12000 10000 8000 Count 6000 4000 2000 0 Poly. (Count)
SafeLink Enrollment
Public site daily visits
450,000 400,000
350,000
300,000 250,000 200,000 150,000 100,000 50,000 0 Page Views Poly. (Page Views)
SafeLink Enrollment
Phone calls processed by day
60000 50000
40000
30000
20000
10000
SSL
SSL
SSL
CRM Manager
Enrollment Service
WorkFlow Manager
Principal
DDBB
Mirror
Staging
Address Validation
Workflow ServIce
CRM
Data replication
Settled down on SQL Mirroring
Motivation
Enrollment System (Emerios 1.0) limitations:
Designed for the implementation of clients 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 :
Customer Sign Off
2 weeks
Product Development
Requirements gathering and definition
Product Backlog
Development
Quality Assurance
Deployment to PRE
For User Acceptance Tests
Deployment to PROD
Requirements prioritization
Motivation
Requirements lifecycle with Emerios 2.0:
Customer Sign Off Customer Sign Off
Deployment to PROD
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:
Billing Module Finance Module
Billing Module
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 AppStore)
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 AppStore) 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 - Comparative
Salesforce
Modelling Interface Web site with form-based UI Desktop App (Visual Studio alike) Desktop App
Mendix
Outsystems Agile
Desktop App (excellent UX)
BUSINESS MODEL Entities Workflows Triggers/Events Business Rules User Interface Versioning Extensibility 1-Click Deploy 1-Click Rollback ARCHITECTURE Cloud Hosting On-premise Hosting Fault-Tolerance
Form-based
Form-based Form-based Expression editor (textual DSL) Raw custom-HTML editor / Visual Force Desktop editor Supported Apex propietary programming language Supported
UML class diagram / Entity-relation model Workflow Designer Special Workflow DSL Form editor Supported Java Supported
Entity list (can be imported form Excel) Workflow Designer Workflows Form editor + Workflow for navigation Supported .NET / Java Supported Supported (what about data changes?) Supported Supported
Reporting
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 Supported
Integrated reports
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.).
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.
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.
Security
CMS
Metadata Module Describe Business Entities (e.g.: products have price, sku, etc.) Process Module Create, Read, Update and Delete Business Processes (e.g.: purchase products)
Data Module Create, Read, Update and Delete Business Entities (e.g.: products) REST API Module Expose business processes through HTTP REST (e.g.: to be consumed by light iPhone applications) Other Modules Examples Address Validation Enrollment Lifeline Customer Identity Validation (LexisNexis) SOAP API Module Expose business processes as SOAP Web Services (e.g.: to be consumed by ETCs workflows)
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
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