来自杰出企业构架师的不可或缺的技术、过程和业务观点。当前许多企业组织面临着设计、建造和维护大规模分布式企业系统的挑战，以便能够适应不断变化的业务需要。许多人重复着其他人的错误，导致费用超支、完成日期拖延，乃至丧失了机遇。今日的商业环境为IT造成额外的交付负担。不断调整的业务驱动脱离了当前的企业IT系统能力；尤其如果系统是复杂、脆弱，难以容纳变化的。企业架构能有助于今天做出前瞻性的IT投资。企业架构实用指南帮助读者为企业架构的成功实现而建立适应性的架构策略。这本经典的手册超越了理论，基于跨越多个行业立面组织中的实际经验，讲解了企业架构的策略。每个观点、技术和原则之后是由今日最知名的业界领袖提供的丰富知识。几位作者已为金融服务、电信、传媒和电子商务领域中许多全球杰出企业架构了工业级的软件和基础设施。他们讲解了实践指南，对已有的实践进行坦率的评价，并从亲身经验中提供详细的实例。本书前言从前，某位训练有素的科学家在他的实验室里工作，他把盛满试剂液的烧杯放到本生灯上，又拿起另一个烧杯，把内盛的试剂倒到前一个烧杯里。随着温度的升高，混合液的颜色开始变化，随即突然泡腾起来，散发出非常美妙的芳香。“我找到了！”科学家欢呼着冲出实验室，把这个好消息带给他的主管们。“我们一定要将它立即投产！”CEO说，“我们今年就能卖20亿加仑！”于是建筑队受命修建一个200英尺高的本生灯以及220英尺高的基座来安放50万加仑的烧杯，还需要建一个500英尺高的起重机来高高举起第二个烧杯，以便把内盛液体倾倒于第一个烧杯里制成混合液。然而，不行，这样的做法将会是愚不可及的。实验室中的试验和大规模生产相当不同。因此，企业系统若和实验室的原型系统采用同一架构，未免有点古怪，是愚不可及的。企业系统异于诸如“餐厅局域网”式的原型小系统，但是这种差异体现于架构，而不是设计思想。可是架构经常会被混淆于设计。架构表现的是在某类事物中普适的特征、结构、行为和关系。设计表现的是细节，说明某类事物中特定的个体该如何建造。架构和设计总是存在的。但在许多时候，它们埋没在程序员的意识里，踪影难觅。如果现在所有的程序员都是精干的架构师/设计师，如果大家都具备长期卓有成效的企业系统开发经验，如果大家在开发企业系统或其他相关项目时都愿意和其他程序员交流思想，如果在系统开发完成后不需要其他人员做维护、甚至另起炉灶再开发一个新的企业系统，那么架构和设计难觅踪影的状况会一去不返。可惜实际情况并非如此，而是恰恰相反。因而，架构和设计必须分开，并且明确化。架构由知识丰富的专家制造，负责沟通、启发和领导。仅有设计是不够的。企业系统的设计必须适合此类系统的外延功能需求——可伸缩性、完整性、灵活性、可建造性等——这些都是由架构决定的。企业系统经常失败的一个重要原因是架构和设计被合并。其他一些和企业系统同样复杂的人类活动，并没有出现和这些大型IT项目相同的失败率。这是为什么？我的回答是当前IT产业在三个主要方面存在显著欠缺：*企业层的架构（企业架构）。*支持企业架构的工具。*支持企业架构的组织。架构知识的燃眉之需设计一个企业系统是困难的。它要求大量的知识和技巧。在其他产业中，专业人员在开始工作前就被授予许多必要的知识。这些产业可以说是“知识专门化”。知识被划分为各个专门的需求领域。在建筑业里，建筑师知道工厂设计和公寓设计是相当不同的，公寓设计又与教堂设计和办公楼设计不同。又如，工程师明白设计磁盘驱动器和设计飞机是相当不同的（尽管它们都会用到空气动力学）。汽车设计师了解十八轮大货车的设计和家用轿车的设计不同。所有领域都有它自己的架构，设计特定的产品要遵从它的架构。在一个产业中，每个被关注领域以所谓的“架构方法”（architecturalapproach）为特征。（RichardHubert称之为“架构风格”，参见ConvergentArchitecture，Wiley，2002。）涉及不同架构方法产品的项目少有相同之处，相反地，生产含有相同架构方法产品的项目会有许多共同点。因而，项目中所使用的技术和工具也可能是相同的。设计特定的产品有据可查，有章可循，由架构方法规定其中的设计。那些跨领域（有些时候还会跨产业）的普适技术是非常重要的，但更重要的是这些技术对各种架构方法的不同应用。按照客户需求的架构方法，制造产品所需的知识各有差别，客户经常会指定架构方法：亦即，你会听到“我需要一辆家用汽车”，而绝少听说“我需要一辆车”。我们的产业倚重于技术，较少倚靠架构方法。显然，一个单机的图形用户界面应用程序和一个企业系统相当不同，这两者又都不同于一个工厂自动控制系统。这些应用系统都各自体现着不同的架构方法，架构方法服务于相应的那类应用系统项目，这类项目具备大量普适知识。然而，许多IT项目仍然由掌握着一套技术工具的专业人员着手进行，他们并不具备必需的有关架构方法的知识，而不得不在项目开发过程中艰难地逐渐学习。显而易见，因为项目架构师们被迫一边自学一边探索，许多项目无法表达出所需的信息。我们需要掌握有关架构的知识，并使它应用于我们的产业。本书为满足这个需求而跨出了重要一步。架构工具的迫切之需世上计算机化程度最低的组织机构可能是IT应用系统开发机构。不过，等一下！它们不是在每张工作台上都有昂贵的PC和网络连接，并且装配着昂贵的软件开发工具吗？当然，不错。然而它们中相当一部分仍然停留在棉纺产业的工业化水平上。犹如一伙机械工程师被要求用他们的本行工具——焊枪、车床、千斤顶——来制造一种新型汽车。设计方案交予了他们，详细到每一个螺母和螺钉，但是没有针对“这类汽车”架构方法的产品线（或者基础设施）缝合生产过程。他们80%的精力用于建造这些产品线，只有20%的精力用于生产所需数量的汽车。当他们完成时，早已超过了预算经费和期限。他们的产品线也该被丢弃了，因为这是为某类特定型号汽车而修建的。同样，应用系统开发人员也可能具备良好的工具和精深的技巧，但是没有架构方法来教授、规约、定义开发人员的努力。每个项目必须定义它自己的企业架构，并建造自己的基础设施、“粘合”代码、过程定制等（产品线）。当前的工具支持特定的技能与技术，可在多个架构方法间通用。但是，我们没有能够支持特定的架构方法的工具——称为“架构支持工具”。也许这就是我们的开发过程被割裂的缘故：一个可用的过程针对一个架构方法。然而许多通用过程要求额外的缝合和定制。你最近什么时候看到过市面上某个通用客户关系管理（CRM）过程是可以用来解决你的CRM的过程需求的？为了提高效率，过程必须是有针对性的——直到底层步骤。它们必须以制造出你的所需为目的。缺乏此类定位就是当前许多无目标（并且刻意如此）的超重过程被广泛拒用的原因。我们需要支持工具来支持企业系统所要求的架构方法，本书描述了许多对此类工具的需求。对适当组织的紧要之需设想一个IT部门拥有一批经验丰富的企业系统架构师、能干而积极的开发人员，以及出色的工具和过程，包括企业架构支持工具。这样就一切齐备了吗？可惜并不是。企业架构师也需要一个合适的人员组织，架构师在其中能如鱼得水地发挥效用。衡量架构师的效用的标准是应用系统开发项目工作的简化程度。许多IT部门在项目（或产品）基础上进行组织。除了一些基本的通用基础设施，比如硬件、操作系统和数据库管理系统（DBMS），每个项目都要自己决定其余部分。我见过许多创建者以这种方式安排人员和配备设施，但在可能是最困难的部分失败了：人员组织出现了问题。一个解决这个问题的方法是把组织分为两部分。一部分提供开发和运行时基础设施来建立和使用企业应用系统，另一部分则制造企业应用系统。后者尽可能在技术、开发和企业构架方法等诸多方面严格地促进前者。当前业界所采用的组织形式完全不是这样的。无论组织最后怎么设定，重点在于组织是来支持某个特定的活动的。如果组织不能直接支持和启动这种活动，那么就失败在望了。为了让应用系统开发项目成功运作而采用企业架构，需要妥善考虑人员组织。本书将介绍有关企业架构的组织形式。本书的重要性许多企业系统具有相同的架构方法，这已然成为现今企业架构领导者们间一个鼓舞人心的公论——虽然有些人使用不同的方式来表达，但相似的是都陈述了独立于特定应用领域的种种技术、模式和设计，用来有效地制造出反应灵敏的、可伸缩的、灵活的、标准化的企业应用系统。本书的重要性在于从多方面概括了这种共性。本书从数据基础要素（即计算机关机后永久保存的部分）到运行时软件设计，到按关注面进行的架构划分，到可伸缩模式，乃至总被忽略的用户界面，全方位地说明了一个成功企业系统所需的知识，并把许多标准综合起来。本书的价值还在于：它不仅讨论了需要建立些什么，而且谈论了如何去建立从工具和模型，到开发过程和方法学，到产品线方法，到敏捷开发，也包括人员组织的重要问题。此外，本书的闪光点是作者们源自多年经验的、无懈可击的、踏实实践的工作经验和扎实技能。本书包括许多知识点——或者说介绍了许多知识点——采用易读、中肯、不教条的方式讲述，这正是一个成长中的企业架构师所需要的。它是一本基础性著作，可以作为企业架构研究生课程的理想教材。实际上，我预期它能成为在我们这个神奇而生气蓬勃的产业中，企业系统知识领域的重要组成部分。
鄂公网安备 42010302001612号 