S299137 Enterprise Saa S Behind The Operational Scenes Of Oracle Crm On Demand

2,297 views

Published on

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,297
On SlideShare
0
From Embeds
0
Number of Embeds
113
Actions
Shares
0
Downloads
130
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • S299137 Enterprise Saa S Behind The Operational Scenes Of Oracle Crm On Demand

    1. 1. Enterprise SaaS: Behind the Operational Scenes of CRM On Demand Adam May, Director of Product Management, CRM On Demand
    2. 2. The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle. Safe Harbor Statement
    3. 3. Program Agenda <ul><li>Current Enterprise SaaS Solution </li></ul><ul><li>Roadmap </li></ul><ul><li>VISA Case Study </li></ul><ul><li>Question and Answer </li></ul><Insert Picture Here>
    4. 4. Oracle CRM On Demand Strategy Integrated CRM Packaged integrations to EBS, JDE, Siebel etc Social CRM Social Networks, Sales Productivity Solutions Enterprise Grade SaaS Appropriate tenancy on Oracle’s Grid Industry CRM CRM Solutions by Industry
    5. 5. Enterprise Grade SaaS Its All About the Service . . . ? SaaS Vendors Customers “ I couldn't care one bit how the application was running as long as the delivery price, usability, functionality and performance meet my requirements. From an end user perspective, who cares if it is running multi-tenant or single tenant in a virtualized environment” Price Usability Functionality Performance
    6. 6. Enterprise Grade SaaS Its All About the Service . . . ? Availability Security Integration Upgradeability IT Organizations “ I take responsibility for my company; its data and its technology, I expect high availability, complete security, and tight integration with my other systems There are times in our business cycles when we cannot and will not allow upgrades or patches to be installed…” SaaS Vendors Customers “ I couldn't care one bit how the application was running as long as the delivery price, usability, functionality and performance meet my requirements. From an end user perspective, who cares if it is running multi-tenant or single tenant in a virtualized environment” Price Usability Functionality Performance
    7. 7. Enterprise Grade SaaS Flexible & Reliable Deployment Options Monitoring Management Shared Pods Private Pods @Customer
    8. 8. CRM On Demand Network Architecture Hosting Environment Business Tier DMZ Tier Presentation Tier Data Tier Pod 1 … Load-Balancing / SSL Acceleration / NIDS Database Servers Web Application Servers Interactive & Batch Business Process Servers Firewall … Pod N Internet HTTPS … CRM On Demand Shared Services Command Center: Management, performance and security tools Intelligent Routing LDAP (Authentication) SMTP (Email) Backup System Network Attached Storage End User
    9. 9. Customers Chose Enterprise Grade SaaS
    10. 10. Customer Test Environment <ul><li>2 Customer Test Environments offered (in addition to stage) </li></ul><ul><ul><li>Leading CTE (Early Adopter) </li></ul></ul><ul><ul><li>Following CTE (Late follower) </li></ul></ul><ul><li>No Cost </li></ul><ul><li>Details </li></ul><ul><ul><li>Typical use: development, testing, training, etc. </li></ul></ul><ul><ul><li>Data, configuration, etc. controlled by customer (no refreshes) </li></ul></ul><ul><ul><li>One account / customer on each CTE </li></ul></ul><ul><ul><li>Up to 20 active users </li></ul></ul><ul><ul><li>Multi-tenant, no SLAs (but kept in standard production zone) </li></ul></ul><ul><ul><li>No automated transfer of data between systems </li></ul></ul><ul><ul><li>Forbidden: production use, load testing, security testing </li></ul></ul>
    11. 11. Customer Test Environment <ul><li>How to Request CTE account(s) </li></ul><ul><ul><li>Submit a Service Request (Customer Care or through MetaLink) </li></ul></ul><ul><ul><ul><li>The Service Request title must include “CTE account request” </li></ul></ul></ul><ul><ul><ul><li>State the desired type of CTE account(s) (Leading CTE , Following CTE, or Both) </li></ul></ul></ul><ul><ul><ul><li>Provide the name and contact information for the primary contact and administrator for the account </li></ul></ul></ul><ul><ul><ul><li>Provide the requestor’s production account name </li></ul></ul></ul>
    12. 12. <Insert Picture Here> Roadmap
    13. 13. Disaster Recovery has always been about Business… not computers <ul><li>Most businesses view it in terms of risk vs. cost </li></ul><ul><ul><li>43% of business impacted by disaster never reopen 1 </li></ul></ul><ul><ul><li>72% of business impacted by disaster do not exist within 3 years from the disaster 1 </li></ul></ul><ul><ul><li>93% of businesses that suffer significant data loss are out of business in 5 years 2 </li></ul></ul><ul><li>Regulated industries view it as a requirement… </li></ul><ul><ul><li>Financial, Healthcare, Government, etc, </li></ul></ul>1 US National Fire Protection Agency 2 US Labor Dept
    14. 14. Business Continuity and DR Overview <ul><li>Business </li></ul><ul><ul><li>Analysis </li></ul></ul><ul><ul><li>Solution Design </li></ul></ul><ul><ul><li>Implementation </li></ul></ul><ul><ul><li>Testing </li></ul></ul><ul><ul><li>Maintenance / Optimization </li></ul></ul><ul><li>Systems </li></ul><ul><ul><li>Minimize the chance of unplanned downtime </li></ul></ul><ul><ul><li>Get the system back up ASAP when it does go down </li></ul></ul><ul><ul><li>Disaster Recovery when not able to bring up quickly </li></ul></ul>Sarbanes Oxley Hurricane Katrina London Terrorist Attack
    15. 15. There are Two Factors to Consider in DR Planning Catastrophe Strikes Disaster Declaration “ How much data can you afford to lose?” Recovery Point Objective (RPO) The maximum possible time-length for which data could be irretrievably lost if a disaster happens – usually equivalent to the time interval between backups Backups Service Restored “ How long can you afford to be down?” Recovery Time Objective (RTO) The maximum possible time-length for which the service could be down after a disaster is declared (note: this could be different from when a disaster actually strikes or begins to strike)
    16. 16. Disaster Recovery Services <ul><li>Standard Service for all customers </li></ul><ul><li>Data storage on NAS </li></ul><ul><li>Daily and weekly backups to disk and tape </li></ul><ul><li>Tape storage in secure offsite storage vault facility </li></ul><ul><li>Hotbackup used for DB </li></ul><ul><li>DB, OS, File System backed up separately </li></ul><ul><li>Disaster Recovery (Single Tenant) </li></ul><ul><li>Staging System will be in CO and used for DR </li></ul><ul><li>Primary and secondary sites 700 miles apart </li></ul><ul><li>Geographically dispersed personnel </li></ul><ul><li>Identical infrastructure for consistent recovery </li></ul><ul><li>Semiannual testing </li></ul>RPO: 1 hour RTO: 24 hours Dataguard DR Option
    17. 17. Disaster Recovery Comparison Description CRMOD CRMOD DR SLA 99.5 / 99.7 99.5 / 99.7 RPO Best Efforts 1 Hour Primary Site Location ADC ADC Operations Personnel Distributed Distributed Secondary Site TBD CO RTO Best Efforts 24 Hours Pricing Included Additional
    18. 18. Questions

    ×