吃掉IT大象:从绿海到棕海

　　本书是一本适用于大型IT项目管理人员的图书，重点介绍一种全新的项目开发方法：棕海方法。本书立意新颖，语言生动，书中穿插大量真实案例，以方便读者的理解。书中解释了为什么日积月累的业务和IT复杂性是大型项目失败的根本原因，并展示了如何通过“一口一口吃掉大象”来克服这种复杂性。借助此书，我们将学会如伺管理棕海项目的每个阶段，如何利用突破性的协作、沟通和虚拟工具，包括web 2.0、语义软件工程，模型驱动的开发和体系结构，甚至是虚拟世界。...
　　

推荐序一.
推荐序二
译者序
序一
序二
前言
第一部分 棕海简介
第1章 吃掉大象是一件难事
1.1 当今的交付方法
1.2 为什么大型项目会失败
1.2.1 全球化it系统的要求
1.2.2 组织和规划
1.2.3 项目报告
1.2.4 变更管理
1.2.5 引入的复杂性
1.2.6 需求定义
1.3 环境的复杂性
1.3.1 复杂性无处不在
1.3.2 复杂性是如何造成的
1.3.3 环境复杂性的效应

　　信息技术（IT）是一门神奇的学科，自它悄然诞生的那一刻起，就以势不可挡的脚步走入我们的生活，它凭借神秘的力量潜移默化地改变着我们生活的点点滴滴，也改变着整个世界。.
　　然而，在人们在惊叹于信息技术的巨大创造力的同时，不应忘记这样一个事实：几乎70%的真正意义上的大型IT项目以失败告终。这些项目要么超过了交付期限，要么成本超支，甚至有些项目尚未完成就被迫取消了。导致IT项目失败的因素有很多，包括全球化因素、组织和规划问题、变更管理不完善、对环境复杂性的理解不够、需求定义不完整，等等。本书的目标就是解决这些问题。
　　本书介绍了一种审视IT项目的全新方式，并引入了一种新的方法――棕海方法。棕海方法的概念来自于建筑业中的“棕地开发”，即现有城市、郊区和乡村土地的重新开发。在IT领域中，棕海开发是指在现有环境中对遗留系统进行重新开发，亦称为重构，由于现有环境可能是被各种复杂性“污染”的，因此棕海开发变得更加困难。与棕海开发相对的是绿海开发，即全新的IT项目的开发。目前我们所使用的大部分方法都是绿海方法，而大多数的项目却是棕海项目，从一张白纸开始的绿海项目已经非常罕见了。为了让大型的IT项目摆脱失败的命运，我们必须从绿海开发迁移到棕海开发。..
　　本书两位作者均来自IBM英国服务部门的IT架构师，他们曾负责IBM的一些最大型的系统集成和重构项目，有着非常丰富的经验。他们的棕海方法已经在一些IT项目中卓见成效。当作者一步一步揭开棕海方法的面纱时，一幅生动的画卷就展现在我们面前，我们看到了一种全然不同的思想，这种思想是一枚能够点燃无数灵感的火花。
　　本书共分两部分。第一部分适用于所有读者，它指出了大型IT项目一贯采用的错误思想，并确定了失败的根源。第二部分解释了棕海的技术和实践方面。
　　本书立意新颖，论述详尽，特别适用于CIO、CTO、IT主管、项目执行官、项目主管、首席架构师或主管设计师。那些对成功交付IT项目感兴趣的技术读者也将从本书中获得大量有益的思想和创意。
　　参与翻译和校对工作的人员包括赵俐、马燕新、王善凤、王举华、盛海艳、盛立良、于波、王玲、张延青等。赵俐完成了本书的统稿和审校工作。衷心感谢机械工业出版社华章分社陈冀康先生在翻译工作中给予的精心指导和宝贵意见，同时感谢华章分社编辑所做的大量工作，使本书得以顺利、快捷地出版。由于时间仓促，译者水平有限，在翻译过程中难免会出现一些错误，恳请读者批评指正。...
　　译者
　　2008年9月
　　

　　每家企业的愿望都是为满足客户要求而对自身做出迅速调整。这样的调整通常涉及IT支持系统的改变。当需要进行重大的业务变更时，伴随的IT变更也将非常巨大。但是，这些大型项目常常遇到问题、超出预算、延期或简单地被取消了。甚至在2006年，65%的IT项目以失败告终1。大型项目的成功率甚至更低。当代价非常高昂时，这样低的成功率令人担忧。本书指出了IT行业当前方法的最根本的核心问题，并提供了一种全新的未来方法。大规模的业务和IT变更中涉及的所有人员都应该阅读本书。.
　　大象的生日
　　IT行业有很多重要事件，但1964年IBM新一代大型机（称为System/360）的引入标志着一个全新时代的开始。在此之前，购买新的商用计算机意味着必须重写现有软件。System/360改变了这一切，它引入了一个兼容的计算机家族以及相关设备。在某台计算机上运行的程序也可以运行在任何其他计算机上。业界纷纷以类似的产品效仿，一举改变了IT的性质。
　　现在，IT投资的保护很容易。运行在System/360上的程序仍运行在现今的IBM大型机平台上。
　　开始时，这是一个不易察觉的变化，但它是一个重大的里程碑。从那时开始，IT复杂性开始在企业内部累积。系统随着企业增长。数以千计的“人年”（person-year）时间、工作和资金流入这些IT系统中。它们日趋复杂，它们变成了大象。
　　同时，各种IT风格也经历了兴衰演变。多年以来，最初的结构化程序得到了面向对象编程的补充，经过了基础组件开发的包装，并且通过面向服务架构（SOA）得以传播。这些运动中的每一个都有着自己的解决复杂性的策略，但它们都没有抓住问题的核心。
　　当今的IT系统如此复杂，以至于平常的理解都很难，当我们试图靠近它时，它却迅速地溜走了。维护它们的责任被分配到拥有各种技能的小组中，而且数不清的产品和程序共存，用以维系企业的功能。为了处理这个“九头怪”，我们绘制了高层体系结构图，以便使事实看起来更简单。但这些图只是一种幻想，一种假象，一种外观。它们至少近似于一种简单的假定和高层的沟通。在最坏的情况下，它们灌输了一种盲目的乐观主义，使人们对改变这种复杂性的能力产生了错误认识。
　　这样的“云雾”图无法永远隐藏真实的复杂性。为了实现业务目标并改变这些系统，我们必须理解、沟通和治理真实的复杂性。没有人能够理解所有复杂性，因此完成这些任务就需要大量良好协调的团队工作和明确的沟通。高度的复杂性与数以百计不同人员之间的沟通需求交织到一起，成为摧毁大型项目的杀手。
　　是否需要从绿海迁移到棕海
　　一般情况下，现在IT系统已经不再是在绿海上实现的。1964年以来累积的复杂性意味着大多数IT项目的环境都是一个巨大的挑战，而且与几乎无数的环境约束交织在一起。
　　这是大多数大型IT项目失败的根本原因。只有30%的大型IT项目获得成功。
　　大型项目通常是在“被污染的”环境中执行的，在这样的环境中，我们需要仔细考虑在哪里以及如何构建项目；某个位置上发生的改变可能会以无法预料的方式影响其他系统。在这样的环境中，棕海性质多于绿海性质，而且IT行业需要采用面向棕海的方法来成功解决这些问题。
　　本书引入了这样一种棕海方法，并解释了为什么目前我们所使用的方法本质上仍然是绿海方法。本书的对象是那些想要改变企业的人，他们知道只有在过去基础上构建项目才能实现所需的改变。本书适用于以下情况：
　　·正在构思对IT环境做出重大改变的CIO、CTO、IT主管、项目执行官、项目主管、首席架构师或主管设计师。
　　·无法承担替换整个IT环境的费用。
　　·系统与大量不在控制范围之内的其他系统进行通信。
　　·打算重构现有IT环境，以保持未来的灵活性。
　　·对当前的IT项目失败率感到深深失望。
　　·正打算将很大一部分IT开发和测试工作外包到国外。..
　　作为本书的作者，我们是IBM全职的执行IT架构师，我们接触过上述各种情况，曾经负责IBM的一些最大型的系统集成和重构项目的技术方向和日常实现。我们坚信现有绿海开发方法在通过IT解决方案解决当今业务问题方面日渐失效。坦率地讲, 多年以来我们积累了宝贵的经验，我们不遣余力地解决IT交付的问题。近年来，我们刻意去寻找一种不同的方法；以下几页详细介绍了我们与同事共同努力所获得的成果。我们可能是信奉非正统见解的人，但我们也是实用主义者，我们在这里分享的见解已经极大地加速和简化了大量的IBM项目。

　　序一
　　粗略地计算一下，我们就可以知道，全球每年约产生330亿新代码或修改后的代码。日积月累，这意味着自20世纪40年代和50年代以来（当更高级的编程语言开始流行时），我们已经生产了约1万亿行源代码。.
　　一方面，这种规模的产量说明我们的行业是一个充满活力和创新的行业。另一方面，这是一个令我们惭愧的事实，因为通过这1万亿行完全由不同的人手工编写的代码，我们改变了整个世界。
　　事实上，在每年产生的330亿行代码中，为数不少的一部分刚刚诞生就已经死亡，或者很快就被丢弃了。但是，很多代码有着较长的“半衰期”，有些代码的生存时间甚至达到10年、20年、30年或更长的时间。对于很多开发人员来说，他们今天编写的代码到了明天就成为遗留代码，某一天，他们的下一代或再下一代可能会注视着这些代码，尝试使用它、适应它、演进它，并提出这样的问题：“这位开发者到底在想什么？”
　　坦白地讲，绿海开发是一种巨大的乐趣，因为我们从一张白纸开始，因此不受过去任何事情的羁绊。在很大程度上，我们在学校中讲授的是绿海开发；此外，新公司看起来比老公司敏捷得多，因为他们没有遗留系统里程碑的瓶颈问题。困境将降临到那些刚刚步入现实世界的学生们头上（现实世界与大学不同，除非他们从大学的温床直接进入新成立的公司的温床），困境也会降临到那些开始步入持续性开发并迅速认识到已经无法从头开始的公司身上。
　　Richard和Kevin为我们揭示了一个常常被业界忽略的现实：即不断演变的遗留系统的问题，他们将其称为“棕海开发”。在当今的经济效益模式下，典型的系统都在不断演进（我们无法阻止这种演进），同时也在不断增长。作者认为问题的根源在于复杂性，并提供了一种聚焦于基本抽象和有效沟通的新方法，从而一步一步地解决转换问题。他们的视图、资料库、转换和工件模式提供了用于推理和执行棕海系统转换的一种方法。他们提出了一个棕海生命周期，包括调查、工程、验收和部署，从而提供了控制转换的手段。
　　正如一句谚语所说“大象是要一口一口吃掉的”。Richard和Kevin带领我们来到摆好刀叉和其他工具的餐桌旁，并为我们展示了一种在房间里吃掉大象的方法。..
　　Grady Booch
　　IBM院士
　　2008年1月
　　序二
　　1969年，我从学校直接迈入计算机行业，职业是一名计算机工程师。在近40年的职业生涯中，我主要致力于应用程序开发和系统集成领域。我在1969年编写了第一个应用程序，它是一个计算机辅助设计（CAD）的图形应用程序，帮助硬件工程师设计印刷电路板。此应用程序为电路板设计人员提供了一个工具，它具有电子元件的必要物理规则，以及如何使用的规则。在20世纪70年代初，我开发了CAD和其他应用程序，用来帮助建筑师设计大型公共建筑，例如学校和医院。这些系统在建筑师和市政工程师的建筑设计过程中提供帮助；通过捕获设计，它能够生成所有必需的图纸和建筑材料清单。
　　在这40年当中，我经历过各种不同的角色，包括程序员、分析师、设计人员、架构师、项目经理和问题解决专家。我所开发的系统用于广泛的行业，包括制造业、银行业、保险业、零售业、公用事业以及本地和联邦政府。现在，我是IBM全球业务服务部的IBM院士[1]，也是IBM技术研究院的积极成员。我的主要职责是从技术上规划和确保大型、复杂的系统集成和战略外包计划及投标的技术健康。我是一名皇家特许IT专家（CITP）、皇家特许工程师（CEng）、英国计算机协会会员（FBCS）[3]，和英国工程技术学会会员（FIET）[4]。
　　回顾20世纪70年代我们在电子电路设计和构建以及建筑业中的尝试，我对于IT行业在基于工程的方法的采用方面深感失望，甚至在某种程度上感到绝望，因为IT行业在规划、设计、构建、集成和测试IT系统时，缺乏对基于工程的方法的成功采用（这种方法应该由基于计算机的工具来支持）。在当今世界中，在没有工程原则和IT行业提供的工程工具的情况下，要想开发复杂系统（例如Airbus 380）是不可想象的。IT行业在采用工程技术开发复杂系统方面，还相当不成熟。IT行业已经无法再依靠相对不成熟的实践，这些实践通常是由办公生产力工具提供支持的，例如文字处理工具、幻灯片工具和电子表格。IT行业需要更广泛地采用真正基于工程的技术，这些技术由专门为工程师设计的工具提供支持。
　　根据我近年来的经验，构建定制（自定义）应用程序或定制商用成品（COTS）软件包的总成本和复杂度正在不断增加，风险也随之加大。通过进一步的调查，可以得到一个明显的事实，即并不是构建成本增加了，而是在系统环境中集成这样项目的规模和复杂度增加了。从我最近的经验来看，新的构建工作与集成工作的比例为3：1。对于在新功能上花费的每一美元，将该功能转化为生产的总成本是4美元。此成本并不包括最终用户的培训费用。在系统规模和复杂度不断增加的环境中，维护成本也将增加。此外，企业还必须满足不断提高的法律和法规要求。所有这些导致用于新开发的预算下降，并且在全球化24 x 7的服务文化中部署新功能的机会也降低了。IT创新被遏止了。现今使用的方法和工具（虽然受限）主要是针对绿海系统环境的。现实情况是，21世纪的大多数组织都拥有一个现有的、复杂的系统环境。我这里所说的系统环境（systems landscape）同时包括业务环境和为其提供支持的IT系统。这些IT系统又由应用程序组成，并且它们的数据通常部署在复杂的网络和计算机基础设施上。这些系统的文档化程度往往很低，并且其后续的维护高度依赖于少数知识丰富的“系统专家”5。IT行业需要一种更强的结构化方法来理解这些系统环境。
　　这就是当今世界的现实状况，本书作者Richard Hopkins和Kevin Jenkins还有我，都在客户的现有复杂系统环境中规划、设计和实现新的系统。现在是IT行业面对现实状况的时候了，我们需要新的开发方法和工具来解决这些问题，并将我们的行业带入21世纪。
　　解决此问题的重要的第一步是提供一个同时用于描述问题及其解决方案的名称。在命名过程中，两位作者将目光转向建筑行业，其中越来越多的新建筑是在棕地6上开发的。这是对当今大部分在棕海系统环境中开发的新系统的类比；根据我的经验，超过90%的新开发是部署到棕海环境中的。挑战并不仅限于遗留系统的转换，还包括将其集成到棕海系统环境中。
　　本书描述了一种用于未来系统开发的全新方法。它是一种已经认识到这些挑战的结构化方法，它基于工程原则，并且由适当的工具提供支持。它是专门为应对棕海开发挑战而设计的方法。...
　　Chris Winter
　　CEng CITP FBCS FIET，IBM院士

　　“Richard和Kevin为我们揭示了一个常常被业界忽略的现实，即不断演变的遗留系统的问题，他们将其称为‘棕海开发’。作者认为问题的根源在于复杂性，并提供了一种聚焦于基本抽象和有效沟通的方法，从而一步一步地解决转换问题。正如一句谚语所说：‘大象是要一口一口吃掉的’。Richard和Kevin带领我们来到摆好刀叉和其他工具的餐桌旁，并为我们展示了在房间里吃掉大象的方法。”.
　　——Grady Booch，IBM院士，UML的共同创建者之一
　　本书提出了一个有根本意义的问题，就是我们面对的不是从零开始、无牵无挂的软件环境，而是既有现有的IT应用或者系统，又有新的需求，我们应该如何进行软件开发?其次，作者们不但提出了问题，而且给出了一套解决问题的方法论。…………更难能可贵的是他们把这些方法论付诸于实践，并且取得了可喜的成功。..
　　——寇卫东 IBM软件集团两岸三地大中华区 总工程师
　　从一个全新的视角提供了一个棕海生命周期的、有效的解决方案。Richard和Kevin不仅教会了我们如何吃掉IT大象，更重要的是，他们让我们开始思考如何避免培育出难以吃掉的IT大象，而是要培育出能够跳舞的大象。
　　——严成文 中国软件开发中心Rational 总经理
　　本书的作者对那些庞大复杂的项目进行了定义，而且制定了完整的方法论。在经历了太多的失败之后，作者和他的团队将为数不多的成功者历史有效总结，为后来者铺路。
　　——欧阳璟《程序员》杂志编辑部副主任...