Richard Hopkins和Kevin Jenkins 都是IBM英国服务部门的IT架构师。他们也都是IBM英国及爱尔兰技术顾问小组的成员。他们也是描述IBM的Eleohant Eater实现的专利所有者。Richard Hopkins也在IBM的服务部门工作了多年。在这期间，他曾担任全球很多客尸的首席架构师。在过去的11年间，Richard成功领导了很多系统的交付，每天都有数以万计的用户和数百万客户使用他的系统。作为IBM的领导者，Kevin也成功交付了很多用于政府、金融机构和零售业的系统。在这期间，Kevin还对大量项目进行评审，积累了丰富的成功与失败的经验，从而使他得以开发出本书中的概念。

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

    “Richard和Kevin为我们揭示了一个常常被业界忽略的现实，即不断演变的遗留系统的问题，他们将其称为‘棕海开发’。作者认为问题的根源在于复杂性，并提供了一种聚焦于基本抽象和有效沟通的方法，从而一步一步地解决转换问题。正如一句谚语所说：‘大象是要一口一口吃掉的’。Richard和Kevin带领我们来到摆好刀叉和其他工具的餐桌旁，并为我们展示了在房间里吃掉大象的方法。”
    ——Grady Booch，IBM院士，UML的共同创建者之一
    “21世纪的大多数组织都有一些现有的复杂系统环境。现在是IT行业勇敢地面对现实的时候了，我们需要新的开发方法和工具来解决这种状况。本书描述了一种用于开发未来系统的新方法：这是一种结构化的方法，它认识到了棕海开发的挑战，它基于工程原则，并且有适当的工具提供支持。”
    ——Chris Winter, CEng CITP FBCS FIET, IBM院士，IBM技术研究院成员
    “本书从一个全新的视角提供了一个棕海生命周期的、有效的解决方案。Richard和Kevin不仅教会了我们如何吃掉IT大象，更重要的是，他们让我们开始思考如何避免培育出难以吃掉的IT大象，而是要培育出能够跳舞的大象。”
    ——严成文  中国软件开发中心Rational 总经理
    “在我二十多年的软件职业生涯中，我读过很多软件方面的书。我认为这本著作非常有特色。”
    ——寇卫东  IBM 软件集团两岸三地大中华区 总工程师
    “本书的作者不是这些知难而退者之一，他们不仅对那些庞大复杂的项目进行了定义，而且制定了完整的方法论。在经历了太多的失败之后，作者和他的团队将为数不多的成功者历史有效总结，为后来者铺路。”
    ——欧阳璟  《程序员》杂志

    第1章 吃掉大象是一件难事
    本章包括：
    当今的交付方法
    为什么大型项目会失败
    环境的复杂性
    必须审视“棕海”
    注释
    当今的信息技术能够完成纷繁复杂的任务，然而，尽管IT行业有了长足的进步，但有一项统计数字仍然使我们备受困扰：接近70％的真正大型IT项目以失败告终。
    本书的目的就是让这类项目获得成功。
    在过去的35年中，计算机发生了如此巨大的变化，以至于很多时候我们都辨认不出它的原样了，有时甚至看不见它的存在。笔者有一台小巧的计算机，它安静地呆在我的卧室中，可以播放DVD，可以同时录制两个数字电视频道的节目，可以显示我的家庭照片，也可以播放视频和CD。
    计算机遍布每个角落，它们具备强大的功能。当笔者刚刚加入IBM时，主流的Pc机只能在屏幕上显示为数不多的几个窗口。如果幸运的话，你的计算机可以与一台共享的文件服务器进行对话，并且提供一些“可爱的”窗口，在这些绿色的屏幕上，可以看到实际正在做的工作。现在，我的计算机桌面成了一个万花筒，它同时执行着多项任务，包括文档、虚拟世界、视频、MP3、电子邮件和即时消息传递。如此多的窗口做着如此多的不同工作，以至于有时我认为需要另外一台计算机来控制所有这一切。
    ……

第一部分 棕海简介
第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的内部机理
第10章 ELEPHANT EATER实战演习