基本信息
- 原书名:Eating the IT Elephant: Moving from Greenfield Development to Brownfield
- 原出版社: IBM Press
- 作者: (英)Richard Hopkins Kevin Jenkins
- 译者: 盛海艳 贺西玲 赵俐
- 丛书名: IT文化系列丛书
- 出版社:机械工业出版社
- ISBN:9787111255215
- 上架时间:2011-5-20
- 出版日期:2009 年3月
- 开本:16开
- 页码:163
- 版次:1-1
- 所属分类:计算机 > 软件工程及软件方法学 > 软件项目管理

编辑推荐
用于管理、演进和转换遗留IT系统的实用的、完整的方法.
适用于每一位IT执行官、经理、架构师、程序领导者、项目领导者和主管分析师...
内容简介
作译者
Richard Hopkins和Kevin Jenkins 都是IBM英国服务部门的IT架构师。他们也都是IBM英国及爱尔兰技术顾问小组的成员。他们也是描述IBM的Eleohant Eater实现的专利所有者。Richard Hopkins也在IBM的服务部门工作了多年。在这期间,他曾担任全球很多客尸的首席架构师。在过去的11年间,Richard成功领导了很多系统的交付,每天都有数以万计的用户和数百万客户使用他的系统。作为IBM的领导者,Kevin也成功交付了很多用于政府、金融机构和零售业的系统。在这期间,Kevin还对大量项目进行评审,积累了丰富的成功与失败的经验,从而使他得以开发出本书中的概念。
目录
第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 克服沟通的复杂性
译者序
然而,在人们在惊叹于信息技术的巨大创造力的同时,不应忘记这样一个事实:几乎70%的真正意义上的大型IT项目以失败告终。这些项目要么超过了交付期限,要么成本超支,甚至有些项目尚未完成就被迫取消了。导致IT项目失败的因素有很多,包括全球化因素、组织和规划问题、变更管理不完善、对环境复杂性的理解不够、需求定义不完整,等等。本书的目标就是解决这些问题。
本书介绍了一种审视IT项目的全新方式,并引入了一种新的方法――棕海方法。棕海方法的概念来自于建筑业中的“棕地开发”,即现有城市、郊区和乡村土地的重新开发。在IT领域中,棕海开发是指在现有环境中对遗留系统进行重新开发,亦称为重构,由于现有环境可能是被各种复杂性“污染”的,因此棕海开发变得更加困难。与棕海开发相对的是绿海开发,即全新的IT项目的开发。目前我们所使用的大部分方法都是绿海方法,而大多数的项目却是棕海项目,从一张白纸开始的绿海项目已经非常罕见了。为了让大型的IT项目摆脱失败的命运,我们必须从绿海开发迁移到棕海开发。..
本书两位作者均来自IBM英国服务部门的IT架构师,他们曾负责IBM的一些最大型的系统集成和重构项目,有着非常丰富的经验。他们的棕海方法已经在一些IT项目中卓见成效。当作者一步一步揭开棕海方法的面纱时,一幅生动的画卷就展现在我们面前,我们看到了一种全然不同的思想,这种思想是一枚能够点燃无数灵感的火花。
本书共分两部分。第一部分适用于所有读者,它指出了大型IT项目一贯采用的错误思想,并确定了失败的根源。第二部分解释了棕海的技术和实践方面。
本书立意新颖,论述详尽,特别适用于CIO、CTO、IT主管、项目执行官、项目主管、首席架构师或主管设计师。那些对成功交付IT项目感兴趣的技术读者也将从本书中获得大量有益的思想和创意。
参与翻译和校对工作的人员包括赵俐、马燕新、王善凤、王举华、盛海艳、盛立良、于波、王玲、张延青等。赵俐完成了本书的统稿和审校工作。衷心感谢机械工业出版社华章分社陈冀康先生在翻译工作中给予的精心指导和宝贵意见,同时感谢华章分社编辑所做的大量工作,使本书得以顺利、快捷地出版。由于时间仓促,译者水平有限,在翻译过程中难免会出现一些错误,恳请读者批评指正。...
译者
2008年9月
前言
大象的生日
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院士
媒体评论
——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、电子邮件和即时消息传递。如此多的窗口做着如此多的不同工作,以至于有时我认为需要另外一台计算机来控制所有这一切。