甲骨文的硬件赌注

2010年1月27日早晨，太阳微系统公司的一名工程师走进门洛帕克园区办公楼时，发现前台桌上立着一块白底红字的临时指示牌，上面印着“Oracle客户接待处”。他后来向同事描述这个场景时用了一个技术术语——“系统切换中的状态不一致”：旧进程还没终止，新进程已经开始写入内存。这块指示牌不是Oracle正式下发的品牌物料。它来自合同整合团队的一名项目经理，前一天晚上从办公用品柜里翻出来的空白标牌，用激光打印机打上了Oracle的标识。没有人授权她这么做，也没有人阻止她。收购在一周前正式完成，但新的管理流程还没下达到每个楼层。这种真空状态让一些人感到不安，另一些人则看到了行动的自由。

这名工程师在自己的工位上坐下，打开邮件，发现收件箱里有两封未读消息。第一封来自Oracle人力资源部，标题是“欢迎加入Oracle大家庭”，附件是一份四十七页的员工手册和一份需要在一周内签署的知识产权协议。而就在几周前，整个行业还在追问同一个问题：Oracle会在Exadata的“预集成”道路上走多远？现在，答案正在以这种无声的方式被写入现实——不是通过战略声明，而是通过一块临时指示牌、一封欢迎邮件和一份知识产权协议。

第二封来自他的直属经理——一位在太阳工作了十四年的副总裁——标题只有一行字：“我决定离开。”他后来才知道，这位副总裁在收购完成当天就递交了辞呈，但延迟了一周才通知团队。在这七天里，他每天照常参加Oracle的整合会议，照常审阅产品路线图文档，照常在邮件末尾写“谢谢”。没有人看出异样。

这不是一个孤立事件。在收购完成后的头三个月里，太阳微系统的高管离职率超过了百分之三十。一部分人是在收购谈判期间就已经决定离开的——他们手里的股票期权在交易完成后自动兑现，财务自由让他们不需要忍受整合期的混乱。另一部分人是在目睹了Oracle的管理方式后选择退出的——他们无法适应一家软件公司对硬件业务的理解方式。这种理解方式的差异体现在最细微的地方。Oracle的合同整合团队进驻太阳园区的第一周，做的第一件事不是审查技术路线图或客户清单，而是重新定价太阳的硬件产品线。

他们从Oracle总部带来了一个财务模型，这个模型的核心假设是：硬件不再作为独立产品存在，而是作为全栈解决方案的组件。在这个模型里，一台服务器的价值不取决于它的CPU主频或内存容量，而取决于它在运行Oracle数据库时能贡献多少性能增益。

太阳的工程师们第一次看到这个模型时，反应不是愤怒，而是困惑。他们花了二十年时间优化SPARC处理器的每一条指令、Solaris内核的每一个调度算法、存储阵列的每一个I/O路径，现在有人告诉他们，这些优化的价值不是由它们自身的性能决定的，而是由另一个公司的软件定义的。这种困惑很快转化成了更具体的焦虑：如果硬件的价值被数据库软件定义，那么硬件工程师的职业生涯也被数据库公司定义。

这正是埃里森想要的效果。他在一次内部会议上说得更直白：“我们买的不是硬件业务。我们买的是数据库业务的护城河。”

这句话需要拆解。2009年秋天，当Oracle的收购要约还在欧盟委员会的反垄断审查中时，埃里森召集了一次战略规划会议。与会者包括Oracle总裁马克·赫德、首席架构师爱德华·斯克里文和几位高级副总裁。会议的主题是：如果这笔交易完成，Oracle将如何利用太阳的资产？一位与会者后来在法庭证词中描述了当时的讨论过程。埃里森在白板上画了一个四层堆栈：最底层是硬件，往上是操作系统和虚拟化层，再往上是数据库和中间件，最顶层是应用程序。他在数据库那一层画了一个圆圈，然后从这个圆圈向外画了四条箭头，分别指向其他三层。“这是我们的城堡，”他指着圆圈说，“但这些墙正在被侵蚀。”

他说的“侵蚀”指的是两个趋势。第一个趋势是开源数据库的崛起。MySQL在Web 2.0时代积累了超过一千二百万的安装量——尽管其中绝大多数部署在中小网站和初创公司，但那个数字本身就构成了一种威胁。它意味着新一代开发者学习的第一套SQL语法是MySQL的语法，而不是Oracle的。当这些开发者成长为企业的技术决策者时，他们对数据库的选择偏好将重塑市场结构。

第二个趋势是云计算的出现。亚马逊Web服务在2006年推出S3存储和EC2计算服务后，企业开始尝试将工作负载迁移到公有云。在云环境中，数据库的选择逻辑发生了根本变化：它不再由企业IT部门的长期规划决定，而是由应用开发团队在项目启动时的即时需求决定。如果开发者可以在亚马逊的云上启动一个托管的MySQL实例——后来是亚马逊自己的Aurora数据库——并且按小时付费，为什么还要向Oracle支付数十万美元的年度授权费？

这两个趋势指向同一个后果：数据库层的锁定效应正在被技术架构的变迁削弱。当客户可以相对容易地切换到替代方案时，Oracle的整个商业模式就面临解构风险。埃里森在白板上写了一个数字：百分之四十八。这是Oracle数据库在全球关系型数据库市场的份额——一个在正常竞争环境下几乎不可动摇的位置。然后他在旁边写了另一个数字：百分之六十二。这是x86服务器在全球服务器市场出货量中的占比——一个Oracle完全没有参与的市场。“如果数据库运行在别人的硬件上，”埃里森说，“我们就是在租用别人的城堡来保护自己的国王。”

这个比喻暴露了Oracle数据霸权范式的内在焦虑。三十年来，Oracle通过控制关系型数据库这一ERP系统的底层数据基础设施，获得了向上吞噬应用层的能力。这种霸权的核心机制是：谁拥有数据层，谁就能定义数据之上的业务流程。当一家企业将其财务数据、库存数据、客户数据全部存储在Oracle数据库中时，它的ERP系统——无论是SAP的还是Oracle自己的——都必须通过Oracle定义的接口来访问这些数据。而这些接口的授权条款、性能优化方向和技术支持策略都由Oracle单方面决定。

但这种霸权有一个致命前提：数据必须存储在Oracle控制的层中。如果客户将数据迁移到其他数据库——无论是MySQL、微软SQL Server还是后来的云原生数据库——那么Oracle就失去了定义业务流程的权力。而开源和云计算恰恰在降低这种迁移的门槛。收购太阳微系统就是对这个威胁的直接回应。

如果数据库层的锁定效应正在被削弱，那么就在数据库层之下再建一层锁定——硬件层。如果客户不能轻易更换数据库，因为他们被锁定在全栈一体机中；如果客户不能轻易更换一体机，因为他们被锁定在SPARC处理器和Solaris操作系统的深度优化中；如果客户不能轻易更换任何一层，因为每一层的性能都依赖于其他层的集成——那么Oracle就重建了被开源和云计算削弱的护城河。

这就是数据霸权的物理化：将软件层面的控制权延伸到硅片层面。这个策略的第一个载体是Exadata数据库一体机。它的原型在2008年已经发布，当时Oracle与惠普合作，由惠普提供硬件平台。但在收购太阳之后，Oracle迅速切断了与惠普的合作关系——这一决定后来导致了惠普与Oracle之间长达数年的诉讼——并将Exadata的硬件供应切换到太阳的生产线。

2010年9月，旧金山莫斯康展览中心。Oracle OpenWorld大会的主题演讲厅里挤满了超过四万名参会者。

埃里森走上舞台时穿了一件黑色高领衫——这个细节后来被媒体反复提及，因为那是史蒂夫·乔布斯的标志性着装风格。

但埃里森接下来展示的东西与苹果的产品哲学有着根本差异。他在大屏幕上投射了一张对比图表：Exadata V2在数据仓库查询速度上比IBM和惠普的“最佳配置”快十到五十倍。然后他宣布了两项政策：第一，Oracle将不再单独销售Exadata的组件——客户必须购买整个一体机；第二，Oracle将不再为其他硬件平台优化数据库性能——如果客户想要最快的Oracle数据库体验，唯一的途径是购买Exadata。

会场里响起了掌声，但掌声主要来自Oracle的销售团队和合作伙伴。客户席位上的一些人则在低头交流——他们在计算这个政策对自己数据中心预算的影响。一家大型零售企业的技术副总裁后来告诉分析师：他的团队原本计划在下一个财年采购一批惠普服务器来运行升级后的Oracle数据库，现在这个计划必须推倒重来。

而推倒重来的成本——包括重新评估Exadata的总拥有成本、测试应用兼容性、修改采购合同——估计需要三个月的时间和数十万美元的投入。这正是全栈锁定策略的经济学本质：它不是通过更好的技术赢得客户选择权，而是通过消除选择权来降低客户的议价能力。如果你想要最快的Oracle数据库——而你的业务依赖于这个速度——你就必须购买Oracle的硬件。如果你想要Oracle的应用服务器获得最佳性能——而你的定制应用建立在这个平台上——你就必须运行在Solaris操作系统上。如果你想要Oracle的企业应用套件得到完整的技术支持——而你的核心业务流程运行在这套系统上——你就必须接受Oracle的全栈架构。这个逻辑的自洽性无可辩驳。

IBM在大型机时代就是靠这个逻辑建立了长达三十年的市场主导地位：System/360的成功不是因为每一项技术都领先于竞争对手——事实上它在某些方面落后于宝来和CDC的产品——而是因为客户一旦选择了IBM的硬件、操作系统和应用程序生态，切换成本就变得不可承受。埃里森想在现代数据中心复制这个模式。

但逻辑自洽不等于市场接受。全栈锁定策略有一个致命前提：客户必须相信Oracle能够在堆栈的每一个层面都提供足够好的产品。如果任何一个层面出现短板——如果SPARC处理器的性能无法追赶英特尔的x86芯片、如果Solaris操作系统的市场份额持续被Linux侵蚀、如果太阳的存储产品线在与EMC和NetApp的竞争中继续失血——那么整个全栈战略就会变成一条正在下沉的船。而锁在上面的客户将与船一同下沉。

这个风险不是理论上的。到2009年太阳被收购时，SPARC处理器在与x86的性能竞赛中已经明显落后。

英特尔的至强处理器系列遵循摩尔定律稳步推进——每十八到二十四个月性能翻倍——而SPARC的开发周期更长、迭代更慢、单核性能差距逐年扩大。Solaris操作系统虽然技术优秀——它的DTrace动态追踪工具和ZFS文件系统至今仍被一些工程师推崇——但它的市场份额被Linux快速侵蚀。在Web服务器领域,Linux已经成为事实标准；在应用服务器领域,Linux正在取代Solaris成为Java应用的首选部署平台；甚至在数据库服务器领域，越来越多的Oracle客户选择在Linux上运行Oracle数据库，而不是Solaris。

太阳的存储产品线同样面临压力。它的ZFS存储设备在技术上具有创新性，但在市场销售上无法与EMC的Symmetrix系列和NetApp的FAS系列竞争。太阳在2005年以四十一亿美元收购StorageTek试图加强存储业务，但这笔交易从未产生预期的协同效应，反而增加了产品线的复杂性和内部协调成本。

这就是埃里森花了七十四亿美元买下的资产组合：一个正在失去竞争力的处理器架构、一个市场份额萎缩的操作系统、一个表现平平的存储业务，加上两项软件资产——Java编程语言和MySQL开源数据库——它们的战略价值取决于如何使用，而不是它们本身能创造多少收入。从华尔街的标准来看，这不是一笔划算的买卖。甲骨文在2010财年的营收为二百六十八亿美元，净利润为八十五亿美元，七十四亿美元的收购价格相当于公司全年利润的近九成。而太阳微系统在被收购前的最后一个完整财年亏损了二十二亿美元，其硬件业务在可预见的将来看不到恢复盈利的前景。

但埃里森从来不是在华尔街的分析框架内做决策的人。他的计算逻辑不是“这笔资产值多少钱”,而是“这笔资产能为数据库业务构建多深的护城河”。在这个逻辑下，七十四亿美元不是购买太阳的价格，而是保护Oracle数据库业务的保险费——这项业务每年创造超过一百二十亿美元的营收，而且毛利率超过百分之八十。

如果全栈锁定策略成功,Oracle将获得一个几乎不可替代的竞争位置：客户一旦进入Exadata生态，迁移成本将高到足以阻止任何理性决策者考虑替代方案。这就像IBM大型机时代的客户关系——不是没有竞争产品，而是切换竞争产品的成本远远超过忍受现有供应商的成本。但如果策略失败——如果客户拒绝接受全栈锁定并开始寻找替代方案——那么Oracle不仅损失了七十四亿美元的收购成本，还可能加速其数据库业务的衰落。因为全栈锁定策略的实施意味着Oracle主动切断了与其他硬件厂商的合作关系，将那些不想被锁定的客户推向了竞争对手的怀抱。

这正是SAP看到的机会窗口。2009年12月，当哈索·普拉特纳在维也纳首次公开展示HANA原型机时,SAP的定位仍然主要是一个技术突破：将分析型工作负载从磁盘迁移到内存，实现实时计算能力。但到2010年中，随着Oracle全栈锁定策略的轮廓越来越清晰,SAP开始调整HANA的市场叙事。

新的叙事可以概括为一句话：如果你不想被Oracle锁定，那么HANA是你的开放替代方案。这个叙事在2011年5月的SAPPHIRE大会上得到了完整表达。普拉特纳在主题演讲中宣布,HANA将作为独立数据库产品推向市场，不捆绑任何特定硬件平台。SAP同时宣布与惠普、IBM、戴尔和思科签署硬件合作协议——每家合作伙伴将提供经过认证的HANA一体机，客户可以根据自己的数据中心标准选择硬件品牌。普拉特纳用一个精心设计的比喻来阐述这个策略:“我们提供引擎，你可以选择你喜欢的车身。”这个比喻直接击中了Oracle全栈策略的痛点：它暗示客户不需要为了获得性能而牺牲选择权。SAP承诺HANA在任何经过认证的硬件上都能提供同等的性能表现，而认证的门槛是公开的技术标准，不是商业排他协议。

但SAP自己的困境同样深刻。HANA是一个全新的数据库平台，它要求客户将数据从现有的数据库系统——主要是Oracle数据库——迁移到HANA的内存架构中。

这不仅涉及技术迁移的成本和风险，更涉及一个根本性的信任问题:SAP从来没有做过数据库产品，它的第一个数据库产品就要求企业将核心业务数据托付给它。

一家制造业巨头的CIO在2011年初的内部评估报告中列出了三个风险点。第一,HANA的内存架构要求将所有活跃数据加载到内存中，这意味着硬件的内存配置必须足够大，而企业级内存的成本远高于磁盘存储。第二,HANA最初只支持分析型工作负载，对于订单处理和库存管理等事务处理场景仍需依赖传统数据库——这意味着客户实际上要同时维护两套数据库系统，增加运维复杂性和成本。第三,SAP的数据库技术团队规模远小于Oracle,其产品的成熟度和支持能力未经大规模部署验证。

这三个风险点都是事实,SAP没有否认它们。它的应对策略是将HANA定位为一个渐进式迁移路径：先迁移分析型工作负载以证明性能优势，等待事务处理功能成熟后再迁移全部工作负载。

对于内存成本问题,SAP与硬件合作伙伴共同设计了数据分层存储方案——频繁访问的热数据保留在内存中，不常访问的温数据和冷数据存储在固态硬盘或传统磁盘上。对于成熟度问题,SAP公布了HANA的早期客户名单，包括可口可乐、三星电子和德国电信等知名企业，以建立市场信心。但真正让HANA获得市场合法性的事件，不是SAP自己的营销努力，而是Oracle在2011年10月OpenWorld大会上宣布的技术脱钩决定。10月2日，旧金山莫斯康展览中心的主会场座无虚席。埃里森在主题演讲进行到第四十分钟时，切入了一张新的幻灯片，标题是“技术合作政策更新”。他用一种刻意平静的语气宣布:Oracle将停止为SAP应用程序开发基于Oracle数据库的优化功能。

这句话的技术含义是：如果一家企业使用SAP ERP系统运行在Oracle数据库上，它仍然可以继续使用——数据库的基本功能不受影响——但它将无法获得Oracle新版本的性能优化和针对SAP工作负载的特性支持。这些优化和支持仍然存在于数据库中，但Oracle不会针对SAP应用的数据访问模式进行适配测试和参数调优。

影响范围巨大。根据当时的市场估算，全球约有四万家企业使用SAP ERP系统运行在Oracle数据库上，其中包括大量大型跨国公司。这些企业的ERP系统支撑着采购、生产、销售、财务等核心业务流程，任何影响系统性能和稳定性的变化都可能造成业务中断。

埃里森的措辞经过精心设计:“我们不会再为竞争对手的应用软件优化我们的数据库。”这句话将决定框定为正常的商业资源分配决策：既然SAP选择进入数据库市场与Oracle竞争，那么Oracle没有义务继续为SAP的应用提供免费优化服务。

但这个框架掩盖了一个更深层的战略意图：技术脱钩的真正目的是迫使SAP的客户在两家公司之间做出选择。如果他们继续使用SAP ERP系统，他们将失去Oracle数据库的性能优化保障——这些优化可能影响报表查询速度、批量处理效率或系统升级的平滑性。如果他们转向Oracle的ERP套件，他们将获得全栈集成的性能优势，但必须承担应用迁移的巨大成本和业务中断风险。如果他们选择SAP HANA作为替代数据库，他们将进入一个未经大规模验证的技术平台，但可以摆脱对Oracle的技术依赖。

这是一个精心计算的压力点，它的时间窗口恰好与HANA的商用化进程重叠。埃里森的逻辑是：在HANA尚未成熟到可以承担关键业务负载之前，通过技术脱钩制造不确定性，迫使客户推迟或取消向HANA迁移的计划。

SAP的反应迅速而激烈。OpenWorld大会结束后第四天,SAP发布了一份客户公告，称Oracle的决定是“反竞争行为”,并承诺SAP将继续支持运行在Oracle数据库上的客户系统，同时加速HANA的认证和迁移工具开发。公告中有一句话后来被反复引用:“客户的选择权不应被供应商的商业纠纷绑架。”

这句话抓住了问题的核心。技术脱钩的本质不是技术问题，而是商业问题：一家公司在数据库市场拥有支配地位，现在它利用这种地位来施压应用软件市场的竞争格局。这恰恰暴露了全栈锁定策略的内在逻辑——控制一层以施压另一层。

SAP的回应策略是多管齐下的。在产品层面,SAP加速了HANA的开发节奏:2011年11月发布HANA 1.0 Service Pack 3,增加了对更多数据源类型的支持和改进的数据迁移工具;12月在影响者峰会上公布了事务处理功能的开发时间表，承诺在十二个月内完成从分析型平台到全功能数据库的跨越。在生态层面,SAP扩大了硬件联盟的范围：新增富士通和日立作为认证合作伙伴，使HANA认证硬件平台的数量增加到六家；与惠普签署了深度合作协议，惠普承诺为HANA专门设计服务器配置并投入联合市场推广资源；与IBM达成谅解备忘录，确保HANA在IBM Power Systems上的兼容性认证按计划推进。

在客户层面,SAP启动了一项名为“HANA快速部署计划”的服务：由SAP顾问团队负责在六周内完成从Oracle到HANA的概念验证迁移,SAP承担迁移失败的成本和风险；首批目标客户是那些已经表达了对Oracle全栈锁定不满的企业——它们的共同特征是拥有大规模的SAP系统部署、对IT供应商锁定的历史敏感、以及足够的技术团队来评估迁移风险。

这三项措施的共同目标是降低客户的迁移决策门槛。SAP意识到技术脱钩创造了一个时间窗口：那些已经在考虑从Oracle数据库迁移的客户现在有了更强的动力采取行动；那些仍在观望的客户面临更大的不确定性压力；而那些从未考虑过迁移的客户则被迫开始评估替代方案的可能性。但迁移的速度取决于一个关键变量:HANA能否证明自己在事务处理场景下的性能和可靠性达到企业级标准。

2011年的HANA仍然主要是一个分析型平台：它在报表查询和数据挖掘方面表现出色——一些早期客户的报表生成时间从小时级缩短到秒级——但在订单处理、库存管理和财务记账等事务处理场景下，它仍然需要依赖传统数据库作为后端存储。这意味着即使客户愿意迁移，他们也只能先迁移分析型工作负载——商务智能报表、盈利能力分析、销售预测等——事务处理部分仍需继续运行在Oracle上并等待HANA的事务处理版本发布。

这个技术瓶颈给了Oracle一个反击窗口。在2011年第四季度的销售季中,Oracle的销售团队向SAP客户传递了一个精心设计的信息：如果你的ERP系统需要同时处理分析和事务两种工作负载——而几乎所有大型企业的ERP系统都需要——那么Exadata是唯一经过大规模部署验证的全栈解决方案;HANA只能处理分析工作负载，而且它的路线图承诺的事务处理功能能否按时交付仍是未知数。

这个信息在技术上是准确的：截至2011年底,HANA确实不支持事务处理;Exadata确实可以同时优化两种工作负载;HANA事务处理版本的发布时间确实存在不确定性——软件开发的进度预测从来不是精密科学。但它省略了一个关键事实:SAP已经将HANA的事务处理版本作为最高优先级项目投入了数百名工程师的资源；早期内部测试表明事务处理的性能指标达到了设计目标；而且SAP有足够的财务动机来确保按时交付——因为HANA的成功与否将决定SAP能否摆脱对Oracle数据库的战略依赖。

这场信息战在两个战线上同时展开：销售战线和技术路线战线。在销售战线上，两家公司的销售团队向同一个客户群体传递相互矛盾的信息；在技术路线战线上，两家公司的高管在公开场合互相攻击对方架构的可行性。埃里森在2011年10月的一次媒体采访中说:“内存计算不是一个新概念,TimesTen在九十年代就做了。(SAP）只是把它包装成了一个营销故事。”TimesTen是Oracle在2005年收购的内存数据库产品，主要用于电信和金融行业的实时交易处理。普拉特纳在一次分析师电话会议上回应道:“Exadata是一个昂贵的专有硬件捆绑方案，它解决的问题是如何让磁盘跑得更快;HANA解决的是一个完全不同的问题：当数据已经在内存中时，你可以用全新的方式设计应用程序。”

这两种表述揭示了更深层的分歧：它们不是在争论哪个产品更好，而是在争论企业计算的未来架构应该是什么样子。Oracle认为未来仍然是磁盘存储加智能缓存的分层架构——Exadata通过将存储、网络和计算深度整合来消除传统架构中的瓶颈;SAP认为未来是全内存计算架构——当内存成本持续下降时，将所有活跃数据加载到内存中将比维护复杂的分层存储更简单、更快速。

这两种愿景的对立在2011年底还没有定论。内存的价格确实在持续下降——按照历史趋势每十八个月下降约百分之三十——但要达到能够经济地承载大型企业全部业务数据的规模还需要数年时间。在这期间,SAP的策略是先覆盖分析型工作负载这个细分市场——因为分析查询的性能提升最明显、最容易说服客户尝试新平台；然后逐步扩展到事务处理领域；最终目标是让HANA成为SAP生态系统的默认数据库平台。

到2011年底，两种范式的对抗格局已经清晰可辨：一边是Oracle的全栈锁定范式——通过控制从芯片到应用的每一层来构建不可替代性；另一边是SAP的开放联盟范式——通过建立技术标准和多供应商合作来构建生态护城河。

这场对抗的结果不取决于任何一方的技术优越性宣称，而取决于全球数千家企业数据中心里的实际决策：那些CIO们在阅读技术脱钩公告后做出的选择将累积成市场结构的质变。而这个选择最残酷的地方在于：无论选择哪一方，都要承担不可逆的成本和风险。选择继续留在Oracle全栈生态中意味着接受更高的供应商锁定程度和未来价格谈判中的弱势地位；选择迁移到SAP HANA意味着承担新技术平台的稳定性风险和迁移过程中的业务中断可能性；而选择观望则意味着在两个阵营都在加速推进的情况下可能错失最佳迁移窗口期。

这个压力点就是2011年OpenWorld大会留给行业的具体后果：一个没有中间地带的二元选择，它将在接下来的三年里持续发酵并最终在云计算的浪潮中重塑整个企业软件市场的格局。

而那位太阳工程师在前台看到的那块临时指示牌所象征的过程——一家软件公司试图消化一家硬件公司并将其转化为护城河的一部分——正在以一种更宏大的规模在数千家企业数据中心里重演：每一家选择Exadata的企业都在加固Oracle的全栈帝国；每一家选择HANA的企业都在为SAP开放联盟投票；而每一次投票的结果都不可撤销地改变着双雄之间的力量平衡。这场博弈没有道德上的对错之分——两家公司都在用各自的范式回应同一个根本挑战：当技术架构变迁削弱了传统的锁定机制时，如何重建可持续竞争优势？但回答这个问题的方式本身就定义了他们是谁：一家公司相信答案在于控制更多层级的堆栈，另一家公司相信答案在于建立更广泛的生态联盟。

一家公司试图用硬件锁住客户的未来，另一家公司试图用开放赢得客户的信任；一家公司的赌注是客户对性能极致优化的追求压倒了对供应商锁定的恐惧，另一家公司的赌注是客户对选择自由的珍视压倒了对新技术风险的规避。这两组矛盾的赌注在2011年底同时悬浮在企业软件行业的上空，等待着时间和客户决策给出裁决。