软 件 之 死

1999年，计算机科学家布鲁克斯（Frederick Phillips Brooks,Jr.）以近70岁的“高龄”获得了图灵奖——这位数十年来蜚声世界的软硬件专家、教育家曾在其《没有银弹》（1986）一文中提出了一个迄今为止尚未被打破的著名论断：“没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性”。布鲁克斯用形象的譬喻来论述软件工程中存在的“陷阱”——“在所有恐怖民间传说的妖怪中，最可怕的是人狼，因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物”，而“大家熟悉的软件项目具有一些人狼的特性（至少在非技术经理看来），常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物”。惊悚故事里，人们只有用银弹（银质子弹）才能消灭人狼，而布鲁克斯认为，在软件工程中，“没有银弹”，没有一种能够遏制软件向“怪物”变异、同时还可大幅提升开发效率和产品质量的武器。
某种意义上，布鲁克斯的观点（抑或预言）是正确的——如果不能对基于代码的软件体系进行彻底的革新，那么在今后10年（甚至更久）的时间里，我们仍会在繁复迂曲的代码迷宫中遭遇“怪物”。
一、大型企业级应用软件已经死亡
2003年8月底，一年一度的DCI CRM展会在纽约Javitz中心举行，参加展会的有21%是来自全球性企业（平均有6600多名员工）的CxO，60%是这些企业的中层管理人员。作为CRM市场的预言家和领头羊，Siebel总裁Tom Siebel每年的主题演讲都是大家翘首以待的。但是，这一年Tom Siebel的演讲标题却让与会的所有人震惊：“CRM之死”。
“CRM产品已经没有市场了。”根据Siebel的预计：IT部门将不再购买通用的CRM软件，然后再按照自己内部的业务流程对软件进行调整了。如果Siebel的预见是正确的，那么CRM市场的终结也意味着企业关系管理市场、供应链、人力资源管理市场，以及其他大型应用软件市场的终结。通过市场调查，我们发现，国际主流的几家企业管理软件厂商，包括SAP、PeopleSoft、Siebel等，近几年来的营收一直在容与徘徊，而利润更有下降之势。当前，几乎每一种大型的企业级应用软件都在遭遇着深重的危机，以至于出现濒危甚至垂死的症状。美国国家标准和技术研究院的一份研究报告显示：“占据世界软件销售额85%的是大型的专用软件，而其开发的失败率却高达70%！”
大型企业级应用软件正在走向死亡，它表现在各个方面。
首先，以传统方式开发的大型企业级应用软件难以突破布鲁克斯的“没有银弹论”，找不到软件工程或者项目管理的方法，能够大幅度提高应用软件的开发效率——开发周期长、开发费用高，实施费用超支和工期延长，已经司空见惯。更加可怕的是，随着企业的环境和需求的不断变化，“建成即成闲置”，形成软件工程的灾难。
其次，客户对大型企业级应用软件的诸多期望几乎无法得到完全满足。例如，客户期望实现业务集成和协作，在协作基础上构建出高效的企业应用体系；客户期望对供应链上的信息进行及时传递与处理，以实现更快捷的市场响应能力；客户期望能够快速实施和低成本部署满足个性化需求的软件系统，并适应未来商业环境的变迁……一句话，客户对软件功能和性能的要求越来越高。在这种市场需求下，要实现企业各个层次的集成，必然会导致软件在规模、复杂度、功能上的空前扩张。
不仅如此，企业级应用的危机还表现为系统部署运行和维护的“危机”。应用环境
从单机应用，过渡到客户机/服务器的环境，再过渡到浏览器/服务器的环境，并进一
步向多层式（N-tier）分布式系统的网络环境迁徙。今天，基于互联网的企业级应用要求软件实现跨空间、跨时间、跨设备、跨用户的协同，软件处于极度复杂的异构环境中，这种情形下，以传统的软件开发思路应对当前的危机就只能是刻舟求剑、缘木求鱼。
类似的危机，在中国表现得尤为突出。中国是一个迅速发展和不断转型的国家，中国企业的形态因此而更复杂，中国企业的改革变化空间因此而更大。正因如此，中国企业级应用开发和运营的危机也就更为严重，企业信息化的风险更多，失败率更高。
我认为，正是传统的软件体系酝酿和加重了企业级应用的危机。
软件体系主要包括软件结构和生产方式。传统的大型企业级应用软件的主要特点是：编码式的开发方式和一次开发持续运行的应用软件——编码式的开发方式，使得快速开发企业级应用软件的愿望难以实现；一次开发持续运行的方式，则导致了软件的僵化和濒危——很明显，这种软件不但难以适应客户需求的变化，而且每次修改都必须在代码层上推倒重来，因此造成了效率的降低和资源的糜费。
传统的软件体系正在内外交困的重重危机之下走向死亡！
 
二、探究软件死亡之因
互联网时代给企业带来了无限的想象空间。企业的营销模型由传统的4P（产品、定价、地点、促销），引领出基于互联网的ABC模型（任何时间任何地点、基于网络、沟通营销）。企业系统已经从部门级、企业级，发展到社会级的实时在线的应用，应用的范围在深度、广度上都发生了质的变化。
世易时移，变“法”宜矣——当应用需求已从部门、企业上升到社会的层次，我们必须重新考察企业级应用的需求。
一方面，用户需要个性的软件。市场经济条件下，成功的企业，一定是个性化的，有独特的管理方式和企业文化，以此区别于竞争对手，以赢得市场空间。企业的价值一定是个性化的，企业信息化必须从个性出发：企业级应用软件的实施应该充分体现和放大企业的与核心竞争力相关联的个性价值，从而使企业的价值得以提升，这才应该是信息化对企业的核心贡献。如果一个信息化项目不仅不能凸显出企业的个性——反而加剧了企业与同行的“价值同质化”，那就可以判定，这个信息化项目未能获得成功。
另一方面，企业需要灵活的软件。企业的生命周期是一个动态变化的过程。在每个成长阶段，企业都需要有所区别的政策和管理；随着环境的变化，企业的业务和管理方式要相应地发生变化；再加上随着企业概念的外延扩展，如今已变成了一个涵盖供应商、客户以及各种合作伙伴的虚拟组织。因此，企业对灵活性或者弹性的需求变得十分重要，相应的，企业级应用软件也需要更高的弹性。
目前，传统的企业级应用软件产品往往采用两种典型的交付模式。
其一，以套装软件加上二次开发交付客户。此种方式主体上固化了软件的功能结构，只留一小部分参数配置。这样的软件在具体应过过程中还需要大量的二次开发，即使这样，仍然时常不能满足企业的需求。应用软件厂商通常会大肆宣扬自己的产品包含“行业最佳业务实践”，并以“管理专家”的身份对客户的管理模式强行变革，以适应这种标准化的“行业最佳业务实践”。然而每个企业所处的竞争环境千差万别，企业的战略、核心竞争力亦有所不同，企业只有保持自己鲜明的个性，并对环境的变化保持高度的柔性，随时准备调整管理策略，才是生存和发展的关键。试问哪里有这种“放之四海而皆准”的管理真理能解决所有企业的问题？由此可见，所谓的“行业最佳实践”必然是以抹煞企业特征和不适应未来发展需要为代价而实现的。“开盒即用”的方式往往具有良好的系统架构和稳定的系统性能，能够适应一定领域的市场需求，但很难满足不同用户的个性化需求。
其二，为客户从代码级开发定制的软件系统。这种定制开发方式，基本上是从客户的个性化需求出发，进行软件定制。诚然，这种定制开发的软件系统能够满足特定用户的大部分需求，但开发者总是很难全面考虑软件的扩展性、稳定性等架构因素，产品因此而不能快速适应客户的需求变化，同时也很难提高开发的效率。许多软件公司，陷身于在软件定制开发的泥潭中无法自拔——软件知识得不到有效的积累，成本又居高不下，这构成软件公司或者是系统集成公司的发展瓶颈，同时也在一定程度上妨害了软件产业的发展。
显而易见的，上述两种软件开发方式，都不能解决软件随需应变的问题——软件开发方式效率低下，软件结构死板僵化。在这个企业形态不断变化、企业外延不断扩展、企业的环境不断变迁、企业的业务不断调整的时代，这种以一次开发持续使用为特征的软件已日显陈腐和落伍。
 
三、寻找银弹
“没有银弹！”布鲁克斯如是说——真的就没有任何一种技术或管理上的进步，能够独立承诺大幅度提高软件开发的生产率、可靠性和简洁性吗？
确实，直到上个世纪末，20多年以来，软件行业的生产效率依然没有数量级的提高，软件在帮助传统行业提高效率的同时，自身却成为最原始意义上的“手工行业”。虽然，许多大型的企业级应用软件采取了大规模的生产和协作，但是这种软件往往开发时间长，效率低，无法动态调整，无法由僵硬变得灵活和敏捷。软件业也需要脱离手工作坊时代和工业时代，而走进敏捷定制的后工业时代。
软件生产方式的落后，加之需求和环境的进一步复杂，使得传统软件的生产方式，不但不能缓解软件工程的危机，而是处于不断加深的危机之中。互联网应用时代，企业期望的是以更低的成本，更快的速度，获得高质量、高灵活性的随处可得的软件。显然，依靠传统软件业落后的生产方式和僵化的软件结构，无法面对互联网应用的挑战。矛盾在不断加剧，危机在不断加深。
我的看法是，传统的软件工程的方法无法解决“软件危机”的问题；换言之，不要期望从传统的软件体系中找到真正的“银弹”。
僵化的软件结构无法产生银弹——从代码级做起的软件，强调功能实现，天生具有庞大、僵化、无法适应变化的缺点。编码式的软件，无论是采取何种方式，都无法真正实现“敏捷定制”。代码级的编程、代码级的维护使得效率不可能真正地提高。
落后的生产方式无法产生银弹——从代码级做起的软件，经历了大量重复性的需求分析、设计、编码、测试、维护工作，生产周期长、软件复用性差。依靠这样的生产方式，生产效率如何提高？又如何能保证软件的高质量？
既然传统的软件体系是导致软件危机的根本原因，固守这种软件体系，软件业将永远无法摆脱“软件危机”的噩梦，更无法实现软件大规模敏捷定制的梦想，那么，那颗用以制服“软件人狼”的银弹究竟在何方？

原文转自：http://www.ltesting.net