70 likes | 85 Views
SF Basic Breakout. Andy Fenselau & Doug Fallstrom January 26, 2006. How to maximize overall business, mitigate commoditization threats?. Defensive Pathetic market share outside Solaris getting smaller Open Source and native tools getting better, faster
E N D
SF Basic Breakout Andy Fenselau & Doug Fallstrom January 26, 2006
How to maximize overall business, mitigate commoditization threats? • Defensive • Pathetic market share outside Solaris getting smaller • Open Source and native tools getting better, faster • Shifting business models toward support/subscription • Threat of losing relevance and inclusion at VM/FS level of stack– impact on broader centralized management and data center automation strategies? • Offensive • Expand standardization reach to low-end/midrange workloads • Grow share and relevance in non-Solaris-Sparc markets • Fully leverage central management and future DCA value propositions • Expand business model for subscription and rich upsell/cross-sell opportunities
SF Basic Goals • Maximize SF lifetime Revenue • Maximize customer footprint and upselling across under-penetrated workloads • Edge-tier (app serving, web serving, etc) • Departmental • Test/dev • Increase support/subscription revenues for vast edge-tier deployments (20%?) • Upgrade revenues to SF Std as servers pr workloads evolve (2-5%?) • Cross-sell revenues from VCS, SF Editions, CC, etc (5-10%?) • Enhance standardization deal leverage • Accelerate 5.0 adoption/upgrade revenues • Block native/free tools from further penetrating into the data center • Increase trial and customer stickiness for new CC Foundation (centralized management) and under-utilized features • Enable key channels, particularly platform vendors, for freeware bundling • Increase overall awareness, esp. Linux, Windows, and Solaris x86 • Minimize revenue risk to current high-end workloads
Customer Demand, Upside Opportunity • 11/05 Customer Survey (existing SF customers only) shows systematic under-penetration of edge-tier workloads. . . • With COST being the #1 ranked reason (Nearly 2/3 of respondents!). . . • With tremendous upside opportunities if this were addressed Source: SSMG Linux Survey of current customers 11/05
SF Basic Proposal • SF Basic as free, fully-featured SF Std across all platforms, with deployment throttles • Maximum 3-4 volumes/3-4 file systems/2-4 CPUs • Only bundled VxFS and VxVM would be supportable (no mixing/matching with 3rd party substitutes) • Full DMP ASL/APM and TPD for enterprise arrays • Select 4.1 and all 5.0 platforms • Pricing & Support • Free download with self-service (knowledgebase) support • Upselling support subscription proposed $95-195/cpu/year for 24x7 and call-packs TBD • Aggressive Timeline & Distribution strategy • Timing: LxRT 4.1 and SxRT Opteron 5/9 at Vision; UxRT 5.0 launch for others, Q4 CY06 Windows • Phase 1 (All): Direct and Web/community sites downloads • Phase 2 (Linux, Windows, Solaris): IBM and Sun bundling, possibly HP, Dell, Novell SLES and Novell Network inclusion; Other platforms TBD • Value propositions for target workloads • Out-of-the-box productivity and online management capabilities • Centralized management of multiple servers simultaneously (with 5.0) • DMP FC SAN connectivity, load-balancing, failover across multiple paths, richest HCL • PDCs for host to host data migrations • Standardized tools across Linux, Unix, Windows deployments, both physical and virtual • Seamless upgrade paths as workloads evolve
Release Vehicles and Timing • 4.1.mp2 on Linux for 5/9/06 • 4.1 for Solaris x86 5/9/06 • 5.0 for Linux, Solaris-Sparc, AIX, HPUX? for 6/5/06 • Windows Tahoe 5.0 late 2006 • 5.1 for Solaris x86 late 2006
Proposed SF Basic Throttles • Full SF Standard features (unlike failed QuickStart) • No VVR, QoSS, FlashSnap, ODM, CIO, other Editions or Enterprise features • Select 4.1 (Linux, Solaris Opteron) and all 5.0 platforms • Maximum 3-4 volumes (excluding system volumes required for booting– root disks) • Maximum 3-4 file systems (excluding root file systems) • Maximum 2-4 physical CPUs (sockets, not cores) • All limits per PHYSICAL server (not VMs) • Contractual/EULA enforcement • Honor system similar to other products/licensing • Maximizes flexibility to evolve throttle points • Avoids “the cliff” effect as customer needs/workloads evolve • Code in warnings/upgrade links as limits exceeded