《企业架构实用指南年关把》是2005年获清华大学出版社出版的图书，作者是麦克高文。该书超越了理论，基于跨越多个行业立面组织中的实际经验，讲解了企业架构的策略。

• 书名 企业架构实用指南
• 作者 麦克高文
• 译者 李琦郭耀
• 出版社 清华大学出版社
• 页数 247 页

内容简介

　　来自杰出企业构架师的不可或缺的技术、过程和业务观点。

　　当前许多企业组织面临着设计、建造和长修论文亚初座斗维护大规模分布式企业系统的挑战，以便能够适应不断变化的业务需要。许多人重复着其他人的错误，导致费用超支、完成日期拖延，乃至丧失了机遇。今日的商业环境为IT造成额外的交付负担。不断调整的业务火贵儿驱动脱离了当前的企业IT系统能力;尤其如果系统是复杂、脆弱，难以容纳变化的。企业架构能有助于今天做出前瞻性的I道强专量让存T投资。

　　企业架构实用指南帮助读者为企业架构的成功实现而建立适应性的架构策略。每个观点、技术和原则之后是由今日最知名的业界领袖提供的丰富知识。

　　几位作者已为金融服务、电信、传媒和电子商务领域中许多全球杰出雅试陵企业架来自构了工业级的软件和基础设施。他们讲解了实践指南，对已有的实践进行坦率的评价，并从亲身经验中提供详细的实例。

作者简介

　　JAMES MCGOVERN哈特福德金融服务公司(Hartford Financial Service)企业架构师.是畅销书Java Web Service Archi360百科tecture和A胶弱gile Enterprise Architec误收措县剧举龙查ture的作者之一。SCOTT W.AMBLER.Ronin国际公司(RoninInternational)资深顾问.专攻面向对象的分析/设计.敏捷建模和重要系统架构审计。他的畅销书包括Agile Modeling和The Elements of Java Style。MICHAEL E.STEVENS.哈特福德金融服务公司软件架构师，是Develop受弱扬相坏er.com的专栏作家。他是J八攻ava Web Services Archit响ecture的作者之一鲁吸无著实务京征洋已。JAMES LINN.哈..

目录

　　第1章 抓定参才经系统架构 1

　　1.1 卡纳夏引入外来的架构师 2

　　1.1.很脱款世架离价丰消南孔1 基础设施的架构来自方法 3

　　1.1.2 其他关于系统架构的关注点 4

　　1.1.3 工作于现有的系统架构 5

　　1.1.4 系统架构类型 染段封处孔德轻二兵阿6

　　1.1.5 使整用系统架构增强系统价值 12

　　1.2 网络协议 13

　　1.2.1 tcp/ip 13

　　1.2.2 其他协议 15

　　1.360百科2.3 系统架构和业务智能 17

　　1.2.4 服务层协议 19

　　1.3 小结 27

州侵找云　　第2章 软件樱页设捆架构 量29

　　2.1 软件架构的定义 30

　　2.2 软件架构师的角色 30

　　2.3 为什么需要软件架构 31

　　2.3.1 两个极端 32

　　尔担交2.3.2 折中方案 32

　　2.4 系统涉众 居从续温练宪些标减散易33

前言

　　从前，某位训练有素的科学家在他联聚练药立训的实验室里巩己坑促工作，他把盛满试剂液的烧杯放到本生灯上，又拿起另一个烧杯，把内盛的试剂倒到前一个烧杯里。随着温度的升高，混合液的颜色开始变化，随即突然泡腾起来，散发出非常美妙的芳香艺冷田使又照。

　　"我找到了!"科学家欢呼着冲出实验室，把这个好消息带给他的主管们。

　　"我们一定要将它立即投产!"CEO说，"我们今年就能卖20亿加仑!"

　　于是建筑队受命修建一个200英尺高的本生灯皮留了丝附将以及220英尺高的基座来安放50万加仑的烧杯，还需要建一个5布00英尺高的起重机来高高举起第二个烧杯，以便把内盛液体倾倒于第一陆木婷江刻阿体尔个烧杯里制成混合液。

　　然而，后核不行，这样的做法将线活哪铁刻财离会是愚不可及的。实验室中的试验和大规模生产相当不同。因此，企业系统若和实验室的原型系统采用同一架构做前培茶帮波突，未免有点古背淋怪，是愚不可及的。企业系统异于诸如"餐厅局域脚雨题头油集学网"式的原型小系统，但是这种差异体现于架构，而不是设计思想。可部源司是架构经常会被混淆于设计。架构表现的是在某类事物中普适的特征、结构、行为罪遥纸和关系。设计表现的是细节，说明某类事物中特定的个体该如何建造。

　　架构和设计总是存在的。但在许多时候，它们埋没在程序员的意识里，踪影难觅。如果现在所有的程序员都是精干的架构师/设计师，如果大家都具备长期卓有成效的企业系统开发经验，如果大家在开发企业系统或其他相关项目时都愿意和其他程序员交流思想，如果在系统开发完成后不需要其他人员做维护、甚至另起炉灶再开发去享凳一个新的企业系统，那么架构和设计难觅踪影的状况会一去不返。可惜实际情况并非如此，而是恰恰相反。

　　因而，架构和设计必须分开，并且明确化。架构由知识丰富的专家制造，负责沟通、启发和领导。仅有设计设求备是不够的。企业系统的设计必须适合此类系统的外延功能需求--可伸缩性、完整性、灵活性、可建造性等--这些都是由架构决定的。

　　企业系统经常失败的一个重要原因是架构和设计被合并。其他一些和企业系统同样复杂的人类活动，并没有出现和这些大型IT项目相同的失败率。这是为什么?我的回答是当前IT产业在三个主要方面存在显著欠缺:

　　* 企业层的架构(企业架构)。

　　* 支持企业架构的工具。

　　* 支持企业架构的组织。

　　架构知识的燃眉之需

　　设计一个企业系统是困难的。它要求大量的知识和技巧。在其他产业中，专业人员在开始工作前就被授予许多必要的知识。这些产业可以说是"知识专门化"。知识被划分为各个专门的需求领域。在建筑业里，建筑师知道工厂设计和公寓设计是相当不同的，公寓设计又与教堂设计和办公楼设计不同。又如，工程师明白设计磁盘驱动器和设计飞机是相当不同的(尽管它们都会用到空气动力学)。汽车设计师了解十八轮大货车的设计和家用轿车的设计不同。所有领域都有它自己的架构，设计特定的产品要遵从它的架构。

　　在一个产业中，每个被关注领域以所谓的"架构方法"(architectural approach)为特征。(Richard Hubert称之为"架构风格"，参见Convergent Architecture，Wiley，2002。)涉及不同架构方法产品的项目少有相同之处，相反地，生产含有相同架构方法产品的项目会有许多共同点。因而，项目中所使用的技术和工具也可能是相同的。设计特定的产品有据可查，有章可循，由架构方法规定其中的设计。那些跨领域(有些时候还会跨产业)的普适技术是非常重要的，但更重要的是这些技术对各种架构方法的不同应用。

　　按照客户需求的架构方法，制造产品所需的知识各有差别，客户经常会指定架构方法:亦即，你会听到"我需要一辆家用汽车"，而绝少听说"我需要一辆车"。

　　我们的产业倚重于技术，较少倚靠架构方法。显然，一个单机的图形用户界面应用程序和一个企业系统相当不同，这两者又都不同于一个工厂自动控制系统。这些应用系统都各自体现着不同的架构方法，架构方法服务于相应的那类应用系统项目，这类项目具备大量普适知识。然而，许多IT项目仍然由掌握着一套技术工具的专业人员着手进行，他们并不具备必需的有关架构方法的知识，而不得不在项目开发过程中艰难地逐渐学习。显而易见，因为项目架构师们被迫一边自学一边探索，许多项目无法表达出所需的信息。

　　我们需要掌握有关架构的知识，并使它应用于我们的产业。本书为满足这个需求而跨出了重要一步。

　　架构工具的迫切之需

　　世上计算机化程度最低的组织机构可能是IT应用系统开发机构。不过，等一下!它们不是在每张工作台上都有昂贵的PC和网络连接，并且装配着昂贵的软件开发工具吗?当然，不错。然而它们中相当一部分仍然停留在棉纺产业的工业化水平上。犹如一伙机械工程师被要求用他们的本行工具--焊枪、车床、千斤顶--来制造一种新型汽车。设计方案交予了他们，详细到每一个螺母和螺钉，但是没有针对"这类汽车"架构方法的产品线(或者基础设施)缝合生产过程。他们80%的精力用于建造这些产品线，只有20%的精力用于生产所需数量的汽车。当他们完成时，早已超过了预算经费和期限。他们的产品线也该被丢弃了，因为这是为某类特定型号汽车而修建的。

　　同样，应用系统开发人员也可能具备良好的工具和精深的技巧，但是没有架构方法来教授、规约、定义开发人员的努力。每个项目必须定义它自己的企业架构，并建造自己的基础设施、"粘合"代码、过程定制等(产品线)。当前的工具支持特定的技能与技术，可在多个架构方法间通用。但是，我们没有能够支持特定的架构方法的工具--称为"架构支持工具"。也许这就是我们的开发过程被割裂的缘故:一个可用的过程针对一个架构方法。然而许多通用过程要求额外的缝合和定制。你最近什么时候看到过市面上某个通用客户关系管理(CRM)过程是可以用来解决你的CRM的过程需求的?为了提高效率，过程必须是有针对性的--直到底层步骤。它们必须以制造出你的所需为目的。缺乏此类定位就是当前许多无目标(并且刻意如此)的超重过程被广泛拒用的原因。