用于管理、演进和转换遗留IT系统的实用的、完整的方法！适用于每一位IT执行官、经理、架构师、程序领导者、项目领导者和主管分析师！

本书共分两部分。第一部分适用于所有读者，它指出了大型IT项目一贯采用的错误思想，并确定了失败的根源。第二部分解释了棕海的技术和实践两个方面。

本书立意新颖，论述详尽，特别适用于CIO、CTO、IT主管、项目执行官、项目主管、首席架构师或主管设计师。那些对成功交付lT项目感兴趣的技术人员也将从本书中获得大量有益的思想和创意。

本书是一本适用于大型IT项目管理人员的图书，重点介绍一种全新的项目开发方法：棕海方法。本书立意新颖，语言生动，书中穿插大量真实案例，以方便读者的理解。书中解释了为什么日积月累的业务和IT复杂性是大型项目失败的根本原因，并展示了如何通过“一口一口吃掉大象”来克服这种复杂性。借助此书，我们将学会如何管理棕海项目的每个阶段，如何利用突破性的协作、沟通和虚拟工具，包括Web2.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 环境复杂性的效应

　1.4 必须审视棕海

　注释

第2章 语言的混淆

　2.1 棕海简介

　2.2 关键的沟通问题

　2.3 克服沟通的复杂性

　注释

第3章 我们需要一个大嘴超人

　3.1 吃掉大象的策略

　3.2 理解环境

　3.3 设计ELEPHANT EATER的结构

3.3.1 视图

3.3.2 资料库

3.3.3 转换

3.3.4 工件

　3.4 ELEPHANT EATER实战演习

3.4.1 棕海生命周期

3.4.2 迭代式的生成和精化

3.4.3 利用现有环境

　3.5 棕海信仰

3.5.1 使业务与IT密不可分

3.5.2 接受复杂性

3.5.3 利用现有环境

3.5.4 迭代式生成和精化

3.5.5 使用你自己的语言

3.5.6 只建立一个事实版本

3.5.7 消除业务与IT之间的鸿沟

　注释

第4章 通向大脑的高速公路

　4.1 另一种壁纸

　4.2 侵入HILBERT空间

　4.3 体系结构是解决方案

　4.4 在业务/IT鸿沟之间架起桥梁

　注释

第5章 神秘的元人

　5.1 让一切成为可能

5.1.1 软件考古学家发现了“宝贝鱼”

5.1.2 基本的业务选项

5.1.3 按你的需要提供服务

　5.2 业务服务的长尾巴

5.2.1 实现语义Web

5.2.2 动态服务

5.2.3 我们所做的每件事都是由你驱动的

　5.3 吸引企业的“企业吸引子”

　5.4 棕海之死

　注释

第二部分 ELEPHANT EATER

第6章 只有在完美的世界中， 抽象才有用

　6.1 ELEPHANT EATER的几点考虑

6.1.1 缺少透明度

6.1.2 多个互相冲突的目标

6.1.3 动态方面

　6.2 系统集成和工程技术

　6.3 抽象是体系结构的核心

6.3.1 魔镜， 魔镜， 请告诉我， 所有软件中哪一个是最好的

6.3.2 探测深度

6.3.3 涟漪效应

　6.4 我们是否需要一个“大统一工具”

　6.5 吃掉大象的专家指南

　注释

第7章 ELEPHANT EATER的进化

　7.1 棕海的来源

　7.2 棕海与CASE的区别

　7.3 棕海与MDA的区别

7.3.1 为业务分析师赋予了力量

7.3.2 进化， 而不是革命

　注释

第8章 棕海开发

　8.1 敏捷开发与瀑布开发的结合

8.1.1 用敏捷方法来解决一个瀑布问题

8.1.2 转变模型驱动的体系结构的方向

8.1.3 加速棕海项目的交付

　8.2 棕海开发方法

　注释

第9章 Elephant Eater的内部机理

 9.1 观察Elephant Eater的内部

 9.2 第1步：解析视图并识别模式

9.2.1 收获一个棕海

9.2.2 资料库

 9.3 第2步：合并视图

9.3.1 第2a步：识别丢失或不正确的信息

9.3.2 第2b步：转换

 9.4 第3步：创建转换

 9.5 第4步：生成工件

 9.6 第5.1步：测试工件和第5.1a步：识别生成错误

 9.7 第5.1b步：添加和更新信息

 9.8 为Elephant Eater画一幅肖像

 注释

第10章 Eleptlant Eater实战演习

 10.1 向棕海迁移

10.1.1 构建自己的Elephant Eater

10.1.2 为业务变革提供动力

 10.2 迈出第一步

 10.3 构建界面的更好方式

 10.4 构建企业服务总线的更好方式

 10.5 中间件时代是否终结

 10.6 可部署的企业体系结构的演进

6.3.2 探测深度

IT行业和管道业有很多相似之处。这两个行业的人员很多时候都喜欢说：“嗯，我不会那样做的。”或“那将多花费几美元才行”。像许多其他行业一样，他们总是故意用那些难理解的私有语言、缩写词和“秘闻”将自己隐藏起来。

想象一下，有位供热工程师要在一个新扩建的房间中安装一个散热器。他已经看过了计划，并知道如何接入供热管线。根据规格说明，他知道需要什么零件。根据房屋大小、窗户面积和墙的类型等一些非常简单的计算后，他得到了适合安装在墙上的散热器的合适尺寸，这个散热器将为房间提供适当的热量。这项工作最多不超过1小时。

工作很快完成了，他愉快地离开了。几天后，房主抱怨说屋子仍然很冷。在水管工返回现场并检查了锅炉之后，他才发现锅炉的输出现在无法有效地满足房子的需要了。他建议房主订购一台新的33千瓦的锅炉，并安排好了一周之后再回来。

一周后，他回来安装新的锅炉。在开始安装时，他发现旧锅炉是燃油的，而新锅炉是燃气的。这有一点不便，因为这所房屋没有连接到天然气主网上，尽管主网就在房屋旁边经过。

又过了几周，房主为他的房屋连接了天然气。在水管工第三次造访时，已经万事俱备了。然后他告诉房主电路板上没有空闲的断路器插槽来安装新锅炉。一周后，他更换了电路板。锅炉终于安装上了，但另一个问题又出现了。虽然锅炉的热量输出是足够的，但需要一个功率更大的泵将热量送到整个房子。

而这正是问题的实际根源。

在看到整个大象之前不要抽象

从架构师的顶层视图来判断，解决方案看起来是非常明显的。只有当工作已接近完成时，才会发现它是显然无效的。问题的其他方面（天然气供应、泵和电路板）从水管工所接收的Level 0的角度是看不到的，因此他在分析时忽略了它们。

毕竟，从根本上说，水管工的解决方案并没有错误，他只是没有好的问题说明。问题的抽象过程中将其归结为单一的新房屋建筑图纸，这意味着他没有看到在某种程度上更大、更复杂的真正问题。他只是无法从他的顶层看到隐藏的需求（即环境约束），因为这个顶层是错误的问题抽象视图。

不幸的是，抽象本身就总是缺少底层复杂性的细节。散热器是一个好的理论解决方案，但它被当作一个简单的抽象组件来对待，即当它连接到中央供热系统时，将散发出正确的热量值。在这个简单的抽象背后，隐藏着锅炉、天然气主网和电路板的真实复杂性，这些复杂性通过这种抽象的解决方案被漏掉了，并且使得解决方案脱轨。这样的复杂性是否总是在抽象过程中被漏掉，并使得简单的抽象解决方案脱轨呢？

现在，假设抽象是绝对的，而且不能从散热器向后追溯到热源。例如，假设每个散热器的热量来自大量的中央设施，这些设施通过共享的管道提供热量。如果这种布局的复杂性是完全隐藏的，那么如果散热器不工作，我们就不知道向谁投诉。当然，有利的一面是，负责供热的公用设施公司也无法为我们新增的散热器开账单。

这是否是一个可笑的例子？考虑一下当今的包含很多软件层的IT基础设施，每个层都通过隐藏它下面层的复杂性来实现易于维护的目的。当发生问题时，我们应该找谁？问题发生在应用层吗？还是中间件层？或许它是一个由数据库产生的问题？

如果我们与底层复杂性完全隔离，或者只是不知道它，那么当某些事情遇到错误时，我们很难知道发生了什么。这样的方法还崇尚自然，而不鼓励健壮的实现。完全隐藏复杂性的抽象最终将导致问题，因为不知道将会发生什么错误。

不适当形式的抽象还可能导致任何复杂软件体系结构缺乏灵活性。如果向上层公开了错误的元素，那么人们将不得不在体系结构上走弯路，从而损害其完整性。与其说建立正确的抽象是一门科学，不如说它是一门艺术，但是一个“概括的点”（point 0f generalization）并不是好的开始位置，而有可能是最糟的开始。

成功的抽象离不开知识

概括地说，抽象也许是架构师最强大的工具。当慎重使用并且对问题有了深入的理解时，它能够发挥很好的作用。

然而，当今方法的工作方式是从一般到特殊，因此它们本质上鼓励并导致知识的缺乏。因此，当大型系统集成或开发项目开始时，最初的抽象和分解常常被证明是错误的。当今的方法倾向于忽略复杂性（虽然目的是隐藏复杂性）。

6.3.3 涟漪效应

错误的抽象导致了对问题的低估和大量误解。从10000英尺的高空往下看，一切都非常简单。在大型项目中，有一句格言是“所有代价高昂的错误都是在第一天犯下的。”从我们的经验来看，这个观点是非常正确的。

在缺乏信息的情况下工作，可以使得抽象变得简单，但却不准确。

所有的项目在开始时都是最乐观的（正确的）。这些早期阶段缺乏详细信息，因此，人们做出了假设和大的抽象。

只要对假设进行跟踪，它们本身并不危险。不幸的是，人们往往在做出假设后就不再跟踪它们，而且也不理解它们所产生的影响。在某些方面，它们被看作是“永远不会发生的风险”。我们必须总是对假设及其潜在影响保持跟踪和检查，如果它们是错误的，那么必须理解它们。有些假定是错误的，而且它们将导致严重的后果。

我们必须离开这所乐观的并且充满精美图形的“建筑学校”，因为在这里制订正确决策是一种艺术形式的“事后诸葛”，凭借的是多年积累的本能和直观推断。。我们需要一种更科学的方法，它应该只使用更少的假设并避免过度简单化。我的一位同事Bob Lojek说过一句让我们难忘的话：“一旦理解了全部问题，就没有了问题。”

从根本上讲，我们需要在理解问题上投入更多努力，而不是过早地定义解决方案。作为IBM的高级架构师，当客户项目发生错误时，他们经常在请求我们介入这些项目。例如：

一个团队正在使用敏捷开发方法为一家世界领先的信用卡公司开发一种最先进的、基于Web的客户自助服务解决方案。这个团队具有所有相关技能，主管架构师是一位软件工程权威，他了解他们正在使用的现代技术平台，并且过去交付过很多项目。

鉴于新的技术性质，这个团队严格遵守最佳实践的开发模式，并创建了一个技术原型，以确保按他们的要求使用技术。他们的设计非常精致，并且完全符合客户需求。

但是却出现了一个问题。项目顺利度过了6个月，但在开发的最后3个月却停止了。项目的报告系统正确记录了80%的代码已经编写完成并且工作正常，但进度表却停在了那里，无法再前进。IBM被邀请去看一下问题出在哪里。

像往常一样，答案相对是直接明了的。系统的抽象级别（或层次）是根据理论的最佳实践做出的，但它对于要完成的工作来说过于复杂了。体系结构没有通过“奥卡姆剃刀”测试。主管架构师引入了不必要的复杂性，而且他在问题抽象上（在一定程序上，也是问题的分解）所做的关键体系结构决策脱离了实际的客户问题。

其次，也是更重要的，该架构师忽略了解决方案的内在复杂性。尽管用户需求相当直接，并且Level 0的体系结构视角易于理解，但他在很大程度上忽略了自助服务解决方案周围的其他系统所施加的约束。

是的，设计成功地执行了完美而精致的核心概念抽象，它只是没有考虑到其他方面，例如与之相连的系统。结果，前3个月的核心活动可以说是一种“疯狂的尝试”，即把新的解决方案映射到原有系统的事务和数据模型限制上。在将这些新老系统的互不兼容的视图整合到一起的尝试中，产生了巨大的复杂性，这使得项目团队陷入瘫痪。他们不该思考不可想象之事。他们针对错误的问题定义了精致的最佳实践解决方案。在这个过程中，他们忽略了需要施加在项目上的数百条约束。

在项目对这些约束有了一个核心的理解而重新开始时，定义正确的关注点抽象和分离级别变成一个非常直接明了的过程。这提供了一个精致而简单的解决方案，在所有适当的地方都具有灵活性，而没有使得其与周围系统的关系变得复杂化。

——R.H.

作为最后一个“恐怖故事”，我们来看一下为一个重要的政府机构开发的大型客户案例系统（customer case system）：

在一个项目（在另一家系统集成商的手中）经过两年的投资而毫无进展后，我们开始介入。

在这个项目中，客户选择用一个软件包来提供至关重要的客户关怀（customer care）解决方案。在经过慎重的分析之后，这个软件包被认为完全符合业务和用户需求。几乎用于替换复杂遗留系统的每个组件都将是“开箱即用的”。

然而，替换完整的遗留系统是一项高风险的任务。因此，项目决定先对战略解决方案的最终用户元素使用软件包的一半。该软件包要替换的遗留系统充当一个临时的后端（提供一些复杂的逻辑以及端到端解决方案所需的很多接口）。

这个决定的目的是先吃掉大象的一半。从10000英尺的高度看，它（在纸面上）是非常简单明了的。高层分析没有显示出任何问题，并且体系结构的分层和关注点的分离看起来也很清晰、简单。

但是，随着项目的进展，一个非常明显的事实是，遗留系统为该软件包施加了一个非常不同的约束集。尽管从最终用户和数据的角度来看，新老系统是非常类似的，但它们内部模式完全不同，而且这些区别达到数千个（而不是数百个）。

最终，用户需求（这些需求基于完整的新系统的承诺）、新的软件包和遗留系统这三方之间的冲突意味着某一方必须做出让步。需求被认为是战略性的，而遗留系统是无法改变的，因此必须更改软件包。这个决定破坏了前面所述的自底向上实现的第一条规则。

尽管系统按时、按预算交付了，尽管它一直服务到今天，为数以千计的用户和数百万客户提供了服务，但遗留系统的“逆流”使它的实现变得极为复杂。结果，人们发现将系统迁移到软件包的后续主要版本是一种不经济的做法。这样，所需的战略解决方案就变成了一个死角。

——K.J.和R.H.

在这两个案例中，标准的自顶向下方法都没能提供对整个问题所需的更好、更详细的理解。这样的理解有助于防止这些项目遇到的问题。

这三种问题都源自项目团队对项目所做的一个基本的、错误的假定，即他们可以构建一个绿海实现。在信用卡公司，他们坚信这个假定，直到尝试将它与现有基础设施进行集成的时候，才知道它是错误的。在第二个案例中，政府部门没有认识到其原始需求是基于一个完全不同的环境（其中没有把遗留系统考虑在内），从而导致对原有软件包的大规模定制，这些定制被认为是完全符合需求的。  从根本上讲，当今的大型IT项目需要在现有环境的约束下工作。当今的IT架构师首先应该把自己看作棕海的再开发人员，然后才是令人激动和富于幻想的架构师。

尝试将硬件或软件升级到最新水平的一些公司也会经历现有环境污染所带来的相同涟漪效应。尽管现代软件具有抽象和分层结构，并且实施了严格的企业体系结构，但对系统低层的更改仍将对现在的企业产生很大影响。

如前所述，所有抽象都不是完美的，而且在一定程度上，它将在边缘周围发生遗漏。这意味着对任何复杂环境的更改都不可能是没有破坏性的。当环境中一个被认为独立的层（也许是一个数据库、中间件或操作系统版本）发生改变时，涟漪效应将传播到整个环境中。当只支持特定的产品组合时，变更可能像多米诺链一样升级。最终，这些涟漪可能到达应用程序，导致重新测试、修改甚至是重新集成。

因此，为了提供好的和真正的体系结构，我们必须认识到，我们需要更好地理解问题，以便设计正确的抽象；此外，我们必须将问题定义的所有方面（业务、应用程序和基础设施）互相链接起来，以便可以理解约束或变更所产生的涟漪效应何时以及在哪里影响我们正在定义的解决方案。

P95-99

信息技术（IT）是一门神奇的学科，自悄然诞生的那一刻起，就以势不可挡的脚步走入我们的生活，它凭借神秘的力量潜移默化地改变着我们生活的点点滴滴，也改变着整个世界。

然而，在人们惊叹于信息技术的巨大创造力的同时，不应忘记这样一个事实：几乎70％的真正意义上的大型IT项目以失败告终。这些项目要么超过了交付期限，要么成本超支，甚至有些项目尚未完成就被迫取消了。导致IT项目失败的因素有很多，包括全球化因素、组织和规划问题、变更管理不完善、对环境复杂性的理解不够、需求定义不完整等等。本书的目标就是解决这些问题。

本书介绍了一种审视IT项目的全新方式，并引入了一种新的方法——棕海方法。棕海方法的概念来自于建筑业中的“棕地开发”，即现有城市、郊区和乡村土地的重新开发。在IT领域中，棕海开发是指在现有环境中对遗留系统进行重新开发，亦称为重构，由于现有环境可能是被各种复杂性“污染”的，因此棕海开发变得更加困难。与棕海开发相对的是绿海开发，即全新的IT项目的开发。目前我们所使用的大部分IT项目开发方法都是绿海方法，而大多数的项目却是棕海项目，从一张白纸开始的绿海项目已经非常罕见了。为了让大型的IT项目摆脱失败的命运，我们必须从绿海开发迁移到棕海开发。

本书两位作者均来自IBM英国服务部门的IT架构师，他们曾负责IBM的一些大型系统的集成和重构项目，有非常丰富的经验。他们的棕海方法已经在一些IT项目中卓见成效。当作者一步一步揭开棕海方法的面纱时，一幅生动的画卷就展现在我们面前，我们看到了一种全然不同的思想，这种思想是一枚能够点燃无数灵感的火花。

本书共分两部分。第一部分适用于所有读者，它指出了大型IT项目一贯采用的错误思想，并确定了失败的根源。第二部分解释了棕海的技术和实践两个方面。

本书立意新颖，论述详尽，特别适用于CIO、CTO、IT主管、项目执行官、项目主管、首席架构师或主管设计师。那些对成功交付lT项目感兴趣的技术人员也将从本书中获得大量有益的思想和创意。

参与翻译和校对工作的人员有盛海艳、贺西玲、赵俐、马燕新、王善凤、王举华、盛立良、于波、王玲、张延青等。赵俐完成了本书的统稿和审校工作。衷心感谢机械工业出版社华章分社陈冀康先生在翻译工作中给予的精心指导和宝贵意见，同时感谢华章分社编辑所做的大量工作，使本书得以顺利、快捷地出版。由于时间仓促，译者水平有限，译文难免会有一些错误或不妥之处，恳请读者批评指正。

译者

2008年9月

“Richard和Kevin为我们揭示了一个常常被业界忽略的现实，即不断演变的遗留系统的问题，他们将其称为‘棕海开发’。作者认为问题的根源在于复杂性，并提供了一种聚焦于基本抽象和有效沟通的方法，从而一步一步地解决转换问题。正如一句谚语所说：‘大象是要一口一口吃掉的’。Richard和Kevin带领我们来到摆好刀叉和其他工具的餐桌旁，并为我们展示了在房间里吃掉大象的方法。”

——Grady Booch，IBM院士，UML的共同创建者之一

“21世纪的大多数组织都有一些现有的复杂系统环境。现在是IT行业勇敢地面对现实的时候了，我们需要新的开发方法和工具来解决这种状况。本书描述了一种用于开发未来系统的新方法：这是一种结构化的方法，它认识到了棕海开发的挑战，它基于工程原则，并且有适当的工具提供支持。”

——Chris Winter, CEng CITP FBCS FIET, IBM院士，IBM技术研究院成员

“本书从一个全新的视角提供了一个棕海生命周期的、有效的解决方案。Richard和Kevin不仅教会了我们如何吃掉IT大象，更重要的是，他们让我们开始思考如何避免培育出难以吃掉的IT大象，而是要培育出能够跳舞的大象。”

——严成文， 中国软件开发中心Rational 总经理

“在我二十多年的软件职业生涯中，我读过很多软件方面的书。我认为这本著作非常有特色。”

——寇卫东 IBM 软件集团两岸三地大中华区 总工程师

“本书的作者不是这些知难而退者之一，他们不仅对那些庞大复杂的项目进行了定义，而且制定了完整的方法论。在经历了太多的失败之后，作者和他的团队将为数不多的成功者历史有效总结，为后来者铺路。”

——欧阳璟 《程序员》杂志