企业应用开发和开放源码项目 (转)

企业应用开发和开放源码项目 (转)[@more@]

北京奥捷特通信技术有限公司技术总监 刘天北

1
开放源码运动是家中的不速之客。只是当它已经在软件业的门庭内安家落户，成为一股难以驱遣而又不可低估的力量时，传统软件企业才如梦初醒，开始认真地体味这位难以测度的来客给整个行业的带来的变革。
而这位来客自身也在变化之中。随着开放源码运动的不断深入，它在软件开发的各个特定领域都投下了意味深长的身影。目前一个可见的趋势是，开放源码的潮流已经越出了操作系统、数据库管理系统、web服务器等系统开发领域，开始在企业应用开发这块新的领地寻找它的市场份额。像在其他地方一样，人们的神经再一次受到搅动。应该怎样面对这股潮流？它会这个领域的生态链造成怎样的影响？企业应用的开发者和最终用户都在暗自思忖这个问题。

我们首先勾勒出企业应用开发行业的现状。什么是企业应用？这个问题甚至连Martin Fowler本人都觉得难以回答。在经典之作《Patterns of Enterprise Application Architecture》中，他只是满足于举出若干常见的企业应用系统作为例子，并没有提供更一般的概念。如果容忍一个模糊的定义，也许我们可以把企业应用考虑为“服务于商业目的，处理企业业务信息、数据的软件系统”。企业应用区别于系统平台、控制系统、个人桌面应用、嵌入式应用等软件系统。常见的订单/预订处理、供应链管理（SCM）、财务/资产管理是企业应用的明显例子。
现代企业随着自身发展，不少业务流程需要专门的信息系统处理，借以提高自动化程度、信息传递速度、信息安全性以及信息处理/分析能力。这是企业应用得以产生的缘由。因此，从需求角度说，企业应用的核心在于企业业务的电算化。能否通过软件系统，成功地实现企业需要的业务流程，就成为企业应用开发成败的关键。

企业要建设自己的业务应用系统，可选择方式主要有：
1. 购买现成产品
2. 自行开发
3. 委托开发商专项开发
其中2需要企业内部具备较强的开发团队，这对于多数企业来说并不现实。而1则要求现成产品直接完全地满足企业业务需要。由于不同的企业各具面目，同一企业在不同的发展时期需求也不一致，因此不加变化的现成产品也很难符合企业需求。所以目前企业开发的一般做法，是介乎1和3之间的折衷方案：软件产品供应商提供“业务平台”产品，再由开发商做“定制”开发。所谓“业务平台”，是指独立于特定业务流程，但封装了该领域、该行业的一般业务模型的软件系统。所谓“定制开发”，是指基于上述业务平台，通过从数据配置到编程开发的繁简不同的形式，实现符合特定企业需要的应用系统。目前我们熟悉的电子商务、企业网站内容管理、ERP、SCM、企业管理信息系统（MIS）等领域都有大量软件产品供应商提供平台产品。根据企业现状和经营战略，咨询公司给出目标业务流程和实施规划，由系统集成商和软件开发商完成系统搭建和实际实施。

2
上面谈的是企业应用开发的一般形式。这种形式究竟有何弊端？开放源码软件能为此带来多大的变革？不少人只是把开放源码软件作为降低总体拥有成本（TCO）的一种廉价选择，而我将在下面论证：开放源码软件在企业应用开发中的具有更重要的作用，即降低项目的风险，提高客户对项目的控制能力。
企业应用开发具有相当高的复杂度和风险。据资料显示，1998年美国企业应用项目不成功的比率高达75％，其中28%的项目最终被撤销，40%导致项目周期被无限拖长或资金超出预算。目前国内软件业中，企业应用开发的失败率也居高不下，最近的几次大型ERP项目的可悲失败就是明证。
为什么失败在这个领域特别盛产？我认为，这往往和参与者对企业应用开发的认识有关。一方面，在初始规划阶段，企业客户对于系统需求常常只具有模糊的一知半解，比如说，客户会要求开发一套“电子商务系统”，却无法给出具体的业务细节；而在系统开发成型、投入使用一段时间之后，随着使用者对系统的熟悉，许多需求变更和全新的业务需求才会浮现出来。另一方面，平台供应商为了推介产品，往往夸大其灵活性和可扩展性，给客户一种只需简单安装、配置就能实现业务需要的错觉；而负责具体实施的开发商为了缩短实施周期，又倾向于尽量限制客户的需求变更，力图达到“彻底设计（up-front design）”，即，一劳永逸地完成整个系统的分析、设计，以最短的时间获得最理想的系统。
由此，供应商和开发商向客户许诺的永远是一个完美的系统和快捷的实施计划，而实际的实施过程却肯定是漫长的、不断被客户反馈和需求变更打乱的。这种乐观估计和悲观实际之间的反差，我认为，是造成企业应用开发的一个重要因素。

恰恰也是在这里，开放源码软件能戏剧性地改变原有的商业动力学和开发模式，从而给这一领域带来革命性的变化。请考虑这样一个隐喻：父母为发育期的小孩儿置办衣服，假设这个小孩儿的身材特殊，没有成衣能够妥帖合适，只能定做；如果衣料足够便宜的话，这里的问题也容易解决，只需找到手艺合格的裁缝常年服务就是了——但是，假设当地的衣料又非常稀缺，只有专门店铺才能买到，甚至这些店铺还要强调，必须一次购买这个小孩儿一生的所有衣料。这样，付清昂贵衣料费用之后，父母就很难再为裁缝拨出合理的预算——甚至会动念头：干脆“一步到位”地做一套大衣服，让孩子穿一辈子！
透过这个荒诞而辛酸的故事，我们能发现企业应用开发困境的症结：付给平台供应商的过高的初期投资（initial investment）蚕食了后续开发的预算，但一个企业应用系统又是一个“身材特殊”又处在发育期的孩子，不可能用现成软件（“成衣”）简单的打发掉，更不可能通过一次实施的系统就完全解决今后遇到的所有问题。但是，如果不依靠可重用的平台产品（“衣料”），每次都从头开始开发，也会大大降低开发效率，延长交付时间。是的，答案已经呼之欲出：开放源码软件正是这里急需的廉价衣料。
由于采用开放源码软件无需在项目初期就支付高额的平台软件费用，在这种开发模式下，“软件”与“服务”之间就真正实现了等同。工作的重心转移到客户与软件开发商之间频繁的交互、反馈上。企业客户可以把一个软件项目考虑为一种常年的服务，其中包括周期性发布（release）和迭代（iteration）过程，每次发布可以短至几周，集中于解决企业当前面对的最紧迫问题。受益于低廉的初期投资和快速的发布周期，企业客户能最大程度的避开前面谈到的风险，并最大程度地更改原先的决策和设计。具体地说，在项目进行的任何时刻，客户都能够以很小的代价选择：
* 更改业务需求。现代企业自身的业务模式处在不断变化之中；系统的使用者由于认识的深入，也会提出与原先设计不同的业务流程和业务模型。这里，原有的开放源代码好比是形成珍珠的那个沙粒，通过在项目中不断的塑造、发展，形成最符合需要的系统。与此相比，封闭源码的平台软件只能按照设计时开放的接口加以开发，其灵活性远逊于前者。
* 扩展业务领域。企业应用的边界往往是模糊的。比如说，很多客户要求开发“电子商务系统”，但其功能需求却远不限于网上购物、产品管理、订单处理等内容，还会包括供应链管理、财务/资产管理、网站内容管理甚至客户关系管理的模块，其中每一个模块都有专门的领域软件完成。开放源码软件的自由特性，能允许客户在最适合的时候，选用多个不同的开放源码软件，实现“源代码级别上”的应用集成。与此相比，封闭源码产品或者选择“大而全”的“企业套件”（同时又暗示了更高的初期投资），或者通过专门的企业应用集成方案完成基于接口的集成（效果再一次远逊于开放源码软件）。
* 推迟项目开发或放弃项目。由于初期投资远为低廉，客户同样可以在自己认为最恰当的时候做出推迟或放弃项目的选择，同时仍然享用至此为止开发的成果。

简言之，将开放源码软件引入企业应用开发的，远不只是成本上的考虑，而更多地应该关注它与渐进式（emergent）开发模式之间的亲和性。渐进式策略推崇最小的初期投资、通过多次发布和反馈完善系统，推崇主动迎接“变化”而不是拒斥甚至否认变化的价值。与之相对的策略是，通过包罗万象的平台产品和一步到位的实施锁定所有变化的可能性。这两种策略在软件开发的不同领域应该各有胜场，但针对企业应用系统来说，我认为前者对这里涌动的风险具有更强的抵抗力。
在企业应用的各个专门领域，比如网络门户/内容管理、电子商务、电子办公、ERP、SCM、CRM等等方面，都已涌现出大量成熟的开放源码产品。对于渴求提高灵活度、避免风险的开发项目，采用开放源码企业应用产品已经不再只是幻想，而是正被很多企业成功实践着的现实选择。

3
那么，对于一个规划搭建企业应用系统的企业，一旦选择使用开放源码产品，又怎样才能确保项目成功呢？我认为至少有以下几点重要考虑：
* 策略和态度
如上所述，对于企业应用开发，过分乐观的、速胜的态度肯定是有害的。应该把企业应用项目视为一个长期的、谨慎的过程，不少时候甚至要应用到“退一步，进两步”的策略。应该从特定问题尤其是业务瓶颈入手形成应用，而无需追求面面俱到，或者从“电子商务”或“ERP”的抽象概念出发确定系统功能。
* 开发商
开发商的经验和素质对于企业应用开发来说也是至关重要的。合格的开发商，应该对客户所处的行业有较深的理解和开发经验，对选用的开放源码产品非常熟悉——不少选用开放源码产品开发的厂商本身也参与了该产品的开发，或者是经过开放源码项目组织的特别认证，这些对于实际项目来说都是重要优势。另外，开放商应该能认同软件开发作为服务的观念，能够采取拥抱而不是拒斥变化的态度。
* 产品
面对日益丰富的开源产品，毫无疑问应该选择其中最成熟的（而不是功能最多的）。一般开源软件都有较完善的用户社区，在考察过程中，应该关注这些社区中的用户问题，尤其看对特定问题的回答速度。不同开源软件形成的企业应用平台之间也有明显的水平差距。成熟的平台往往已经包括了大量的可重用组件，对认证/权限、工作流、报表、数据缓存等技术层面都形成了完整的解决方案。优先考虑类似的平台产品能够显著地提高开发速度。
* 规划
渐进式开发强调小型的、经常性的发布。基于这一点，在项目规划中，应该保持概要性的长期目标和明确的短期目标。短期目标由企业目前需求最紧迫的一组系统功能集构成。一般的做法是，每次发布实现哪些功能，各个功能之间的优先度由客户决定，开发商确定完成这些功能需要的时间。
* 反馈
渐进式开发需要开发商和客户之间的紧密合作与反馈，借此随时调整开发方向，确定实现细节。因此在每一发布周期的初始阶段，开发商无需花费太长时间过度设计（over-design），而是通过客户的及时反馈确定开发结果是否合格。一个可考虑的做法是，一位客户方代表长期与开发团队共同办公，由此能使客户的反馈机制更加制度化。
* 许可问题
与很多人的设想不同，开放源码产品并不意味着完全免费——虽然价格往往是低廉的。不同的开源项目包含的许可方式各有差别，其中常见的如GPL（gnu General Public License），LGPL（GNU Lesser General Public License），MPL（Mozilla Public License），apache License，Open Software License等，每一种都包含着较为严格的使用条款和特定的法律隐含。尤其是在项目开发时，不仅调用了开放源码组件库，而且修改了原有代码的情况下，更应该彻底研究相关软件的授权模式，以最终确定开发成果的版权归属。

最后，也许该谈谈什么样的企业应用项目不适合采用上面谈到的开发模式。我能想到的大致有这样几种情形：
* 企业的需求非常简单、固定，并且已经有现成产品恰好满足这一需求。对于这种情形，采用现成产品并不会造成导致更大的风险。客户可以完全依靠软件供应商提供简单的服务和维护。单纯的财会系统是这方面的明显例子。
* 要求项目在极短期内完成。这会使渐进式的开发策略变得完全不可能。
* 项目的初期预算过于充裕。当然，严格地说，预算永远不应该“过于”充裕。但这却是不少国内企业的实情：一笔一次性并包含时限的拨款，如果数目过大，当然不适合选用廉价的方案——但我们可以料想，这样的项目无论怎样选型，实施的风险都不会降低。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10748419/viewspace-958092/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10748419/viewspace-958092/