构建企业应用的新趋势

构建企业应用的新趋势

很多年以来，IT决策者们把应用来源决策看成是一个“不是购买，就是自己建设”的问题。  

企业们经历了数不清的关于是自己建设商业应用还是好，还是应该依赖于打包的应用的争论。

但是，现在的技术和市场的发展趋势使这一争论变得过时。一些大型企业正在关注如何“购买，整合并延伸他们的应用”，无论是通过扩展“标准化的”基础架构，还是通过打包的应用。在这种情况下，应用开发的目标就是要跨企业，采用标准化的接触点（touch points）和整合模板，定制并把订购的应用包结合在一起。同时，无论是对于购买的还是自有的应用，IT组织都应该推动基础架构、组件和应用的重复使用以降低成本，提高投资回报率，并且理顺企业内部的信息流。商业流程队列是推动重复使用的关键途径。

虽然重复使用带来的生产力的提高早就为人们所知，提高大规模重复使用的计划却成效不彰。原因包括技术上的障碍（组件不能够被很好地重复利用，重新使用经常会需要做一些工作），但是组织的问题，比如建立最好的实践，操作流程，共享服务退款（shared-services chargeback）模式，正在使用的管理和方法，以及系统重新使用的动机却是最大的障碍。打包的应用和“水平的”基础架构（比如中间件，开发环境，网络DOS堆栈，和安全性）越来越流行，而它们的配置能力也越来越强，这导致了上面的情况被缓慢地改变，因为供应商的代码（在巨大市场的帮助下）本质上会比企业内部自行开发的代码更容易重复利用。事实上，供应商的代码在设计的时候就是为了在很多不同的环境中“重复使用”的。而且，网络服务和以服务为导向的结构概念的引入促使全球2000强企业们考虑建立重复使用中心来推动企业内部系统的重复使用。

长远地看（2006年到2008年），网络服务互用性标准的不断普及将使应用来源演变成一个“来源和配置”的问题，而一些具有互用性的应用，应用组件，和商业服务，无论它们是来自企业内部还是从企业外部获得，都能够组合在一起，并进行重新配置以满足独特的和不断变化的商业需求。成功的企业将采用网络服务结构，根据一种共享服务的模式，把普通基础架构和应用组件的重复使用率最大化。

在最近的7、8年中，内部开发应用和打包的企业应用（比如ERP和CRM）之间的力量对比的平衡被打破了，打包的企业应用逐渐占了上风，广泛流行的“购买一切”的观念促使了大应用供应商（比如SAP、Siebel、PeopleSoft和Oracle）的成长。

但是Meta Group的调查结果显示这只在“购买还是自己建设”之间摇摆的钟摆已经到达了它的极限。虽然购买应用不断成熟，变得越来越流行，可是在全球2000强企业中，应用开发和应用管理仍然是商业原则。即便是那些对打包应用和外包应用开发/维护依赖性很强的企业也必须保证他们的应用物有所值，并且在功能上和行业内其他的企业相比也要有竞争力。

“模块化”的经济学

在很多例子中，对于新应用的需求（比如，跨企业，跨组织，内容和中央协作）被证实难以用打包的应用（或者用外包或托管的形式来解决）来定义和达成。更具有创新的包，它们会潜在地带来更多的竞争优势，从打包的功能中的获益还不如从传统的定制开发中获益多。同时，打包的应用的价格优势却经常比预期的要小的多，这是由于不断上涨的年维护费用（比如定价的20%，而20世纪90年代这一数字仅为12%到15%），频繁出现的“添加”模块，而企业安装所需的定制和整合工作量也比预期的要大，还有和现有的基础架构以及“标准”的发展之间的不兼容，等等问题造成的。

“不断上涨的费用和打包解决方案复杂性的增加使得企业们开始从‘购买一切’的信条转为考虑开发定制的应用” Meta Group的分析员Daniel Sholler表示。“而且由于基础架构平台厂商（IBM、微软、BEA和Oracle）提供了可重复使用的基础架构组件，再加上程序模块标准化的提高，这些都为开发复杂的应用创造了一个更好的环境，使得这项工作比以往更容易完成，而且费用更低。”

另一方面，一个集成打包的应用提供了它自己的基础架构（操作方法、编程语言等等），而这些是IT组织必须掌握的，当一个企业使用了多个不同的包的时候，复杂性和费用都成倍地增加了。通用应用功能最初成就了应用打包供应商--因为这些包被认为费用更低廉，而性能却和私有应用一样优秀--现在它却使应用打包供应商在和基础架构平台供应商的竞争中处于更不利的地位。因此，随着普通的基础架构组件变得越来越容易使用，打包应用供应商就更加被迫把他们的包拆分成可扩展的、具有“开放”（比如基于网络服务）API的、可重复使用的应用组件。这和正在出现的ERP的“第五代语言”的情况一起，将使“建设”和“购买”之间原本清晰的界限便得模糊。

现在的经济条件和急剧下降的销售数字已经迫使应用供应商开始把他们的产品拆分成模块（使它们能够很方便地独立进行升级）。很多企业已经把他们的主要商业流程自动化了，另一些企业以前投资的打包的应用没有产生预期的回报，这使得ERP（或者其他的）全面的打包解决方案前景堪忧。用户组织也开始拒绝费用高昂，越来越复杂的集成式的、什么都包含的包。这在CRM市场上特别明显，因为用户们现在都对大的包敬而远之，而安装一些组件并把它们和现有的应用连接在一起以满足特殊的CRM需求。甚至ERP厂商也开始对用户巨大的模块化压力做出反应了。在少数的销售机会中，增加新的组件为新的软件销售提供了更具吸引力的方法。ERP供应商也在试图通过销售添加组件进入新的（对他们来说）市场（比如CRM，供应链和分析）。用户组织应该继续推动应用供应商对他们的解决方案进行模块化拆分，采用网络服务标准，把同标准应用组件（比如信用卡授权、电子邮件和即时信息、跨多个包）之间的整合变得更加容易。

 做出转变

虽然打包应用厂商会受到这些趋势的冲击，打包应用仍将是主流，虽然将变得更加模块化并配置性能更强。虽然在某些行业仍然坚持传统的“建设”的文化（比如银行和保险行业），通常的方式是只在会巩固企业竞争地位的、创新的、独特的流程中采用“纯自己建设”应用开发方式。在很多已经有建设得很好的标准化流程的商业领域中，企业没有理由再对于那些很普通的、可以在应用包或者第三方服务中提供的商业功能（比如财务和人力资源等等）再动干戈，那无异于“重新发明轮子”。因此，企业现在关注的是购买/定制/界面方式，有时会建设一个ERP厂商不提供的应用组件或者桥。  

总的来说，我们相信“购买还是自己建设”对于企业来说不再是非此即彼的选择。IT领导人应该更专注于实际的考虑而不是毫无意义的哲学辩论。如果商业流程足够标准化，能够使得打包解决方案或服务提供的功能能够经济有效地满足内部需求，企业就会购买成熟的打包解决方案或者服务。然而，企业在“建设”他们购买的应用--对它们进行定制和整合，在整个企业内部最大化应用组件的重复使用率上的水平是不同的。

用户的行动

IT组织们必须把他们的注意力从一次性的“自己建设还是购买”的决定转移到“购买，建设，扩展”的方式上来，这种方式优化了购买的应用和开发资源、同时也把基础架构和应用组件的重复使用率最大化。这经常会需要一个组织实体（比如企业计划管理办公室），它来对结构计划者和基础架构进行管理，运做企业，管理应用开发者，并帮助管理和采用扩展的应用。应用开发组织经常是分散在商业单元的层次上满足应用定制需求，它们必须提供集中的、足够的资源以在整个企业内部成功推动重复利用工作，并接受集中结构、基础架构和操作团队领导。重复利用中心对于帮助在企业范围内推动重复使用计划也是个有效的机制。

当然，大部分企业现在仍然忠实于他们先前购买的企业应用，并且如果不考虑维护为多个应用包（比如ERP和CRM）而存在的两个基础架构的费用的话，能够立刻就进行替换。一个应用和基础架构服务方式（比如“来源和配置”）也将依赖网络服务互用性标准，这些标准需要两到三年的时间成熟起来。因此，最大化重复利用率、从而最大化应用资源的投资回报工作应该被当作一个需要持续进行、长期的工作。

从这些工作中获得即时结果的一个有效途径就是通过确保整个应用（与组件相对）能够在整个企业内部以尽可能少的费用被重新利用，而不是各个不同的商业单元在使用完全不同的应用来达到相似的结果。因为重复使用在大部分企业中还不是一个重点，它为企业节省费用和人力的潜力是巨大的，而需要进行的工作相对来说则非常少。但是即使是最初的步骤通常也需要很强的管理，应用和基础架构模式匹配，标准化的应用整合组件，资产管理，内部通讯，供应商谈判和改变管理技巧。

本文原载于ZDNeT Chian