从“口水”打到“专利”
以往,无论是PC机与苹果电脑之争,还是微软对抗世界的操作系统大战,都是在争夺定义行业标准的权力。但今天,企业们所争夺者的是“平台标准”,谁能率先打造出自己所在领域的生态系统,谁就拥有对于行业的决定性力量。
尽管在应用软件领域具有统治地位,但这样SAP就可以高枕无忧了?答案并没那么绝对。夏嘉曦力主的模块化软件也将彻底颠覆这个公司过往的运营模式。这不仅仅是产品的升级换代,也是整个公司的全面转型。
这个转型意味着双重风险。首先是巨大升级换代带来的客户心理的不确定性,怀着等等看的心态,绝大多数的SAP用户都选择不成为最早的接受者。调研公司Forrester估计有90%至95%的用户仍然使用SAP R/3企业版应用软件。即使那些有心转变的客户,也面临着选择:是否在转变的同时减少SAP软件的购买量,试一试Oracle的产品?
更重要的是,一家提供“敏捷”、“柔性”产品的公司,自己必须也是“敏捷”、“柔性”的,从刚性的ERP向基于网络服务的组件架构世界转化的过程无比复杂。甚至SAP公司的组织架构也不得不随之重组。
关于Netweaver和Fusion的竞争,已经演化为一场口水仗:甲骨文的高层们通常将Netweaver称做“NetDeceiver”(网络骗子),而SAP的反击是,把Project Fusion喻为“Project Confusion”(混乱项目)。甲骨文不停宣称,他们的技术比NetWeaver更加开放。埃利森则表示,SAP的产品是采用数十年前的专用语言编写的,而Fusion技术则全部基于业界的标准。
虽然业界暂时还无法确定看出Oracle的Fusion在SOA方面的进展状况,但是Oracle的优势在于其刚收购的仁科软件(PeopleSoft)在收购前就声称投入到SOA方面的研发中,如果Oracle能够充分利用其中间件优势,或许能一部分转化其劣势。但问题是相比德国人稳健的成长来说,Oracle在通过大肆收购扩张的同时并没有得到1+1等于2甚至大于2的局面。另外,Oracle面临的潜在矛盾是,它从PeopleSoft、Sieble等公司中获得的各种组件之间存在相互兼容的问题。
最早进入这个领域的BEA尽管规模不大,但是在SOA领域的实力却不容忽视。2005年6月,BEA发布了其全新品牌“Think Liquid(流体思维)”,这一思维旨在把企业IT环境中冻结的、硬连接的资产转变成流动的企业资产,简化企业原有信息的传递。同时发布的还有其AquaLogic系列产品,而AquaLogic正是BEA的SOA计划中的拳头产品。BEA首席执行官庄思浩称这是BEA历史上里程碑式的变化,“让信息像水一样在企业流动”成为BEA的诉求主题。
但BEA在SOA上不得不面对来自IBM、Oracle、微软和SAP的竞争,IBM有On-Demand策略,Oracle有强大的产品链条,从企业应用、数据库到中间件来带动其SOA服务,微软从操作系统到应用都有强大的技术支持,而SAP的NetWeaver同样为人关注。与它们进行竞争,BEA同样难以避免在单一中间件产品上的困局。
庄思浩现在能够想到的办法是在销售方式上进行变化,通过AquaLogic和WebLogic这两个系列的产品,在应用基础架构和服务基础架构方面进行“多元化的产品组合”,进行组合式的销售。
IBM同样野心勃勃,期望继续在中间件市场取得霸主地位。IBM WebSphere在IBM中间件的基础上也强化了很多应用接口,正如IBM所强调的“总线”概念,它关注的领域是系统领域,为企业用户提供全套的架构服务。
与此同时,受到新型网络服务压力最大的微软也通过收购推出了自己的商务应用软件Dynamics,虽然微软刚刚进入这个领域,但以其多年的实力和雄厚的软件市场基础,同样是一股不可小看的力量。
如何选择和成功实施SOA?
正因为实施SOA并不是简单的技术问题,因此企业在考虑实施SOA之前一定要全面分析,谨慎行事。简而言之,选择SOA大概要考虑三个方面的问题。
首先,企业在考虑实施SOA之前应该评估自己的业务需求和IT系统,了解自身实施SOA的条件是否成熟?评估的方法或许有多种,但最方便实用的一种是采用BEA公司在今年2月推出的“SOA准备状态评估工具”。这是一个基于Web的在线工具,它可以帮助IT经理规划SOA组件采用、进行基准测试,以确定如何最有效地向更具适应性的IT设计和基础架构上迁移。目前,全球已有500多家客户以6种不同的语言使用这一工具,并取得了很好的效果。
其次,要选择适当的基础平台。今天,BEA、IBM、Oracle等厂商都有自己的SOA解决方案,用户需要多方比较再做决定。
最后,对任何一家企业来说,实施SOA都需要平衡长期与短期目标,而这必须通过对组织结构、财务、运作、设计及付诸实际等方面的综合考虑来实现。
虽然实施SOA的好处是明显的,但成功实施却并非易事。因为对企业来说,能否成功实施SOA并不仅仅是一个技术问题,它还涉及到管理、企业文化、业务流程等问题。
首先遇到的是管理难题。共享服务是SOA的关键,能否迅速组合应用取决于提供这些功能的服务是否能够被共享,而资源的共享离不开管理。其次,转移到SOA上需要对原有的应用开发方式进行显著的调整。今天,很多开发人员仍然喜欢把每一个应用当作一个独立的项目进行开发,因此代码很少被重用。但在SOA中,开发人员在编写应用时必须时刻考虑重用问题,这既包括重用现有代码,也包括在编写新代码时就为其今后的重用做好准备。这就对企业原有的开发文化提出了挑战。第三是业务流程架构技能问题,SOA使得业务人员和IT人员在创建新业务流程的过程中能够更有效地协作。
SOA:关注业务胜过技术
顾名思义,SOA(面向服务的架构)就是以服务为基本元素建立企业IT架构。如果用技术层面来看,SOA是一种“抽象的、松散耦合的粒度软件架构”;而从业务层面来看,SOA的核心概念是“重用”和“互操作”,它将企业的IT资源整合成可操作的、基于标准的服务,使其能被重新组合和应用。SOA能够在实际应用中获得成功有两个最重要的因素:灵活性和“与业务相关”,这使得它成为弥合企业业务发展需求与企业IT支持能力之间鸿沟的最佳途径。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
如何避免云计算与SOA冲突