建立企业体系结构的更佳途径-UML软件工程组织-火龙果软件

摘要：Sessions 提出了如何通过分区迭代（从概率论和作战策略经验得出的流程）来建立有效的企业体系结构的指导原则。

本页内容
　简介
　定义企业体系结构
　企业体系结构的历史
　公共部门案例研究
　私营部门案例研究
　复杂性
　建模复杂性
　分区
　迭代
　分区迭代
　现有的企业体系结构框架
　分区迭代方法的优点
　成功法则
　结论
　术语表
　参考资料

简介
　运行良好的企业体系结构将是找到高效途径来更好的利用技术的一种绝佳资产。如果运行不良，则又会对宝贵的组织资源起到巨大的消耗作用。而人们常常意识到的是后一种情况。

良好企业体系结构所带来的潜在益处是不容忽视的。这些益处包括降低成本、提高收益、改善流程以及拓宽业务机会。但身陷不良企业体系结构所产生的风险同样不容忽视。这些风险包括巨额支出、技术停步不前以及管理可信度降低。

但不要丧失信心：您可以在获得上述好处的同时避免以上的问题。本文将向您阐述如何做到这一点。我将从两个不相关的学科着手讨论有关如何构建企业体系结构的一些重要思路：概率论和作战策略。

我们从概率论学到了有关复杂性本质的一些知识。之所以如此多次尝试建立企业体系结构以失败告终，我认为关键原因是处理复杂性的失败。在建立企业体系结构的现有方法中，鲜有能有效处理复杂性者。同时，当今组织的体系结构也非常复杂。

那么如何处理复杂性呢？答案来自作战策略这一似乎不太可能的领域。通过 50 年前战斗机飞行员设法在空战中存活所取得的经验，您将发现它如何对于我们今天构建复杂企业体系结构蕴含了重要的启示。

最后，我会将所有主题都归纳为一系列指导原则，阐述如何开发一个良好的企业体系结构，使其成为关键性的组织资产而不是令人头疼的巨大负债。

返回页首

　定义企业体系结构
　要论述企业体系结构，最好先对术语企业体系结构的定义达成共识。

根据卡耐基-梅隆大学（该校培养出多位该领域的理论先驱）的结论，企业体系结构是：

描述业务结构及其有关流程的一种方法。[CMU]

虽然定义很简洁，但它既未体现出通常与开发企业体系结构有关的高成本，也未反映经受该流程的业务论证。

Wikipedia 进一步诠释了企业体系结构的定义：

它是一种实践，应用全面、严密的方法来描述组织之流程、信息系统、人员和组织子单元的当前或未来结构，以便其与组织的核心目标和战略方向保持一致。[Wiki]

Wikipedia 的定义更准确地说明了当今众多企业体系结构方法的复杂性。美国政府的 CIO 办公室则给出了更详尽的定义：

它是一种战略信息资产库，用于定义业务、运营业务所需的信息、支持业务运营所需的技术以及实施新技术以适应业务需求变化所需的过渡流程。[Gov]

您是否开始意识到为何企业体系结构会如此昂贵？以下给出了大量要记录的信息。

建立典型企业体系结构所需的支出取决于三个因素：

为了执行全面分析需要制定周密的时限。
该流程将需要大量内部高层人员的参与。
为了论证该复杂的方法系统需要聘用费用昂贵的咨询顾问。

但其实不一定要这样。以下是我对企业体系结构的定义，其中体现了有关如何改善流程的几点提示：

企业体系结构是对组织目标、如何通过业务流程实现这些目标以及如何通过技术更好地服务于这些业务流程的描述。

很多人会认为我的定义不够全面。我不同意这种说法。在我的定义中，企业目标并非要完全记录整个组织中存在的每项业务流程、每个软件系统以及每条数据库记录。相反，我的定义呈现一个更实用的目标：找到利用技术为业务增值的机会。

如果企业体系结构的终极目标不是为实现业务增值，那么投入到建立企业体系结构过程中的精力就严重偏离了方向。如果谁能够不用经历耗时又耗力的过程就能达到这个目标，那么我会说：“这就更理想了。”

我的方法与其他人的方法的部分区别起源于术语体系结构本身。体系结构这个词隐含着设计图的意思。大家都知道设计图具有完备性，它具体说明了从屋顶如何与墙连接，到如何铺设管道，何处安置电源插座等等一切规划。在企业体系结构中不必要也不适合达到这种详细程度。

在思考如何利用技术实现业务增值时，我们需要回答以下问题：

业务的总体目标是什么？
如何将业务组织成自我管理的业务流程？
这些业务流程彼此之间如何相关？
哪些业务流程（或流程间的关系）看起来特别易于通过技术来改善？
进行这些改善的计划是什么？

请注意，在这种方法中，不存在已完成的企业体系结构这样的概念。相反，企业体系结构被视为是指导如何利用技术的一组有活力的文档。它更像是一份城市规划而不是一张建筑设计图。

最初是 Armour 在 1999 年将企业体系结构比作城市规划 [Arm]，对于当今这种高度复杂的组织，这种比喻尤为贴切。

城市规划要解决问题不同于建筑设计图。城市规划要解决如下问题：

在哪些区域（例如，商业区或居住区）允许有哪种建筑？
建筑物如何接入城市基础设施（例如管道设备和用电设施）？
建筑物将对其周围环境（例如，空气质量和交通流量）产生哪些影响？
建筑物的建造是否达标，不会危及其居民（例如，防火和抗震）？

请设想一下，如果某城市的城市规划中包括了在此城市中曾经建筑的每幢建筑物的详细设计图会是什么情形。这样一种规划的设计成本是极其昂贵的，即使它完成了，也会是十分死板和繁琐的。说到这，它与我曾经见过的一些企业体系结构是比较相象的。

返回页首

　企业体系结构的历史
　企业体系结构领域的问世大体上要归功于 J. A. Zachman 在 1987 年于“IBM Systems Journal”上发表的一篇名为“A framework for information systems architecture”的文章 [Zac]。随后，Zachman 将他的“信息系统”框架重新命名为“企业体系结构”框架。现在，这个框架已经被简称为“Zachman 框架”。

1994 年，美国国防部最先提出了“信息管理技术体系结构框架”(TAFIM) 这个概念 [TAF]。TAFIM 被宣称是适用于所有防御工程的新企业体系结构标准。TAFIM 于 2000 年最终废止之前经历了多次修改。

尽管 TAFIM 不复存在，但“Open Group 体系结构框架”(TOGAF) 中吸取了其中的一些精华。TOGAF 是由 Open Group 控制的“开放源”框架，现已发展到了版本 8.1 [TOG]。TOGAF 可能是现今私营部门最普遍使用的企业体系结构框架，然后是 Zachman 框架。

1996 年，美国国会又将企业体系结构的准则向前推进了一大步。美国国会在该年通过了“Clinger/Cohen 法案”，又称为“信息技术管理改革法案”(ITMRA)。该法案授予“行政管理和预算局”(OMB) 极大的权利来强制实行一些标准以“分析、跟踪和评估行政机构在信息系统方面进行的所有大规模投资的风险和成效”。[Cli]

Clinger/Cohen 要求每个行政机构都要设立“首席信息官”一职，除其他职责外，该职位还需负责“开发、维护和推动集成式框架的实施，发展或维护现有信息技术并获取新信息技术以实现机构的战略目标和信息资源管理目标”。[Cli]

令人费解的是，Clinger/Cohen 从来不提及企业体系结构的概念。尽管如此，OMB 将此法案解释为对整个美国政府的通用企业体系结构框架的强制性要求。该框架后来被称为“联邦企业体系结构框架”(FEAF) [FEA]。如今，OMB 已要求从司法部到国家安全部再到农业部的每个行政机构都要开发一个企业体系结构，并要证明如何使该企业体系结构与 FEAF 保持一致。

因此，Clinger/Cohen 的最终结果是：由美国政府执行的或为其执行的所有与 IT 相关的工作现在（至少理论上）将在单独的一个共有企业体系结构的支持下来完成。

返回页首

　公共部门案例研究
　Clinger/Cohen 不仅强制要求使用联邦企业体系结构（或者，至少已经这样解释过），还强制要求定期监控和报告该计划的功效。这就为我们提供了一个重要的机会来了解运转中的大型企业体系结构。

实际上，我们有了一个重要的案例研究，即美国政府这个也许世界上唯一最复杂的组织是如何使用一个包罗万象的企业体系结构 (FEAF)。同时，由于 FEAF 受到 TOGAF 和 Zachmanwe 的很大影响，因此我们同样也可以将从 FEAF 中获得的经验延伸到这两个企业体系结构框架。

美国政府表现如何呢？

显然，不是很理想。政府问责局（GAO，美国政府的一个独立监察分支机构）几乎在不到一个月的时间就会针对至少一个机构的“信息技术”实施情况递交一份尖刻的报告。似乎政府机构越重要，其发生重大 IT 故障的可能性就越大。

2005 年 11 月，GAO 提出了 IRS 存在的以下 IT 问题：

缺少一个健全的财务管理系统（该系统能够产生日常决策所需的及时、准确和有用的信息）依然是 IRS 管理面临的一个严峻挑战。IRS 目前的财务管理系统抑制了其解决财务管理和运营问题的能力，而这些问题会影响其履行作为国家收税机构职责的能力。[GAO1]

国防部已经受到了数次批评。例如，GAO 在 2005 年 6 月递交的一份报告中指出：

国防部在财务和业务管理方面存在大量弊端，所带来的不利影响不仅削弱了其生成可审计财务信息的能力，也削弱了其提供准确、完整和及时的信息以供管理层和国会作出明智决策的能力。此外，由于国防部的所有主要业务领域都缺少适当的问责制度，因此在财政日益紧缩时期造成了每年数十亿美元的资源浪费，并对任务的执行产生了负面影响。[GAO2]

高透明度的国家安全部出现了许多问题。GAO 在 2004 年 8 月递交的一份报告中指出了以下问题。

国家安全部正在部分或全面丧失一个良好定义的体系结构所要求具备的所有关键要素，例如业务流程描述、这些流程中的信息流，以及与这些信息流相关的安全性规则，等等。另外，对于至少部分存在于最初版本中的关键要素，其衍生方式与体系结构开发的最佳实践也不一致。因此，国家安全部还未具备有效引导和约束其正在进行的业务转型工作及其在支持信息技术资产方面投入的数十万美金所必需的体系结构蓝图。[GAO3]

列出的问题不断增多。FBI 已因挥霍 5 亿美元来建立虚拟案卷填写系统这一失败措举遭到了严厉的指责。FEMA 耗资 1 亿多美元建立的系统在卡特里娜飓风的面前却不堪一击。GAO 抨击的其它联邦团体还有人口普查局、联邦航空局、国家航空和太空管理局、居住与城市开发部 (HUD)、卫生和人类服务部、医疗保障部以及医疗补助部。

或许最具讽刺意味的是，被指责未遵守 Clinger/Cohen 的众多部门中竟然有“行政管理和预算局”，而据说就是这家组织负责监督其它机构是否符合 Clinger/Cohen 要求!

如果联邦政府是企业体系结构价值研究中最全面的案例，那么这个领域的情况令人堪忧。

返回页首

　 私营部门案例研究
　尽管私营行业的失败往往不会被大肆宣扬，但大多数私营部门同样完全可能在 IT 问题上难逃失败命运。私营部门的失败似乎在很大程度上归因于企业体系结构方法的失败，其中包括：

麦当劳曾经要构建一个整合其整个餐馆业务的集成化业务管理系统，结果以失败告终。成本：1.7 亿美元 [Mac]
福特公司试图组建一个集成采购系统，结果事与愿违。成本：4 亿美元。[For]
凯马特曾尝试组建一个尖端的供应链管理系统，也未能幸免失败命运。成本：1.3 亿美元。[Kma]

Nicholas G. Carr 最近在“New York Times”发表了一篇文章，得出以下结论：

综观私营部门的情况后发现软件崩溃已是常有的事情。并且项目的目标越高，失望的几率越大。[Car]

“IEEE Spectrum”最近发表的一篇文章中说明了以下令人沮丧的估查结果：

综观过去五年中政府和公司在新软件项目上的总投资，我估计失败的项目至少对美国经济造成了 250 亿美元的损失，也可能高达 750 亿美元。当然，这 750 亿美元中既没有体现超出预算的项目（其实大多数项目都超出了预算），也没有反映延期交付的项目（大多数项目存在的这种现象）。它还没有计入在项目放弃后从头开始的机会成本或者因受缺陷困扰而不得不再三返工的系统的成本。[Cha]

无论是公共部门还是私营部门，我们可以例举出许多未能满足业务需求与技术解决方案的范围广且成本高的企业体系结构。鉴于我们了解到的事实，必然会得出这样的结论，要不就是企业体系结构不值得推崇，要不就是我们用于建立企业体系结构的方法存在大量漏洞。

从直觉上判断，企业体系结构似乎应该是一件好事。让我们重新回顾一下我先前提出的定义：

企业体系结构是对组织目标、如何通过业务流程实现这些目标以及如何通过技术更好地服务于这些业务流程的描述。

对于寻求更有效的方式来通过利用技术达到组织目标这样的想法，我们很难再提出置疑。因此，只留下方法作为我们首要怀疑的因素。

返回页首

　 复杂性
　要了解各种企业体系方法的失败之处，我们需要了解建立企业体系结构的所有失败尝试有何共同特征。像国内税务署的财务管理系统、国防部的业务管理系统、国家安全部的灾难管理系统、FBI 的虚拟案卷系统、麦当劳的业务管理系统、福特公司的采购系统和凯马特的供应链管理系统这些千差万别的系统，它们有何共同特征呢？

这些系统只有一个共同特征。这个特征就是复杂性。所有这些系统都非常复杂。我认为 FEAF、TOGAF 和 Zachman 的主要缺点是欠缺处理管理系统复杂性的能力。

不幸的是，复杂性却又无时不在。我们有信心对 IT 的未来预知到三种情形：

复杂性只会愈演愈烈。
如果我们找不到处理复杂性的方法，我们注定会失败。
现有的方法行不通。

就像 Richard Murch 在 InformIT 上最近发表的一篇文章中简要指出的那样：

任由 IT 基础结构和体系结构变得日益复杂而不采取任何措施是无法接受也不负责任的做法。如果我们只是随便地将技术娴熟的编程人员和其他人员推到这个问题的前沿，则日常工作就会陷入一片混乱。只有 IT 供应商和用户同样解决了复杂性问题，否则同样的问题会重复发生并持续困扰这个行业。[Mur]

返回页首

　建模复杂性
　为管理复杂性，我们必须先了解复杂性。而且，能够建模复杂性可以加深对其的进一步了解。

我所知道的复杂性的最佳模型是骰子。该模型具有直观、形象及前瞻性的优点，且有数学基础。我将此模型的基本原则称为“Sessions 的复杂性法则”：

系统的复杂性是系统自身所处状态的数量的函数。

我们可以使用骰子来阐述该法则的意义。我将比较系统 A 和系统 B 这两个任意系统的复杂性，如图 1 所示。系统 A 由一个双人头像模型组成（即“硬币”）。系统 B 由一个六面骰子（即标准骰子）组成。

　图 1. 系统 A 和系统 B

系统 A 有两种可能的状态：正面和反面。系统 B 有六种可能的状态：1、2、3、4、5 和 6。根据“Sessions 的复杂性法则”，系统 B 比系统 A 复杂 3 (6/2) 倍。即使我们不懂数学，也可以凭直觉判断其大致应该如此。

通常，如果系统中有 D 个骰子，每个骰子有 S 个面，则系统的状态数为 SD。根据该公式，我们可以计算出其他系统的复杂性。

现在，我们来比较系统 B 和系统 C。系统 B 由一个六面骰子组成（同前），系统 C 由三个六面骰子组成，如图 2 所示。

　图 2. 系统 B 和系统 C

系统 B 的状态数仍为 61，即 6。系统 C 的状态数为 63，即 216。根据“Sessions 的复杂性法则”，系统 C 比系统 B 复杂 36 (216/6) 倍。

如果您要预测系统 C 中掷骰子的具体结果，则您预测正确的可能性为 1/216。如果您要预测系统 B 中掷骰子的具体结果，则您预测正确的可能性为 1/6。如果您对这两个系统反复猜测，则平均起来，您猜对系统 B 的次数约为猜对系统 C 的次数的 36 倍。因为系统 B 不如系统 C 复杂，它更容易预测。

返回页首

　分区
　使用基本的复杂性模型，我们可以对如何更好地组织复杂的系统有一些了解。

让我们比较另外两个系统，系统 C 和系统 D，它们均由三个六面骰子组成。在系统 C 中，同以前一样，三个骰子全部在一起。但是，在系统 D 中，骰子被分为三个分区。这两个系统如图 3 所示。

　图 3. 系统 C 和系统 D

假定我们可以单独处理这三个分区（它们实际上是三个子系统，每一个都与系统 B 类似）。

我们已经知道系统 C 的复杂性为 216。系统 D 的整体复杂性假定为第一、第二、第三个分区的复杂性之和。每个分区的复杂性仍按照 SD 规则给出，其为 61（即 6）。因此，整个系统 D 的复杂性为 6+6+6，即 18。

如果您对此不确信，可以检查系统 C 和系统 D 的正确性。对于系统 C，您将需要检查 216 种不同的状态，查看每一种状态的正确性。对于系统 D，您需要检查 6 种不同的状态以确保第一个分区正确，然后再检查另外 6 种状态以确保第二个分区正确，最后还要检查 6 种状态以确保第三个分区正确。

通常，如果系统有 P 个分区，每个分区的复杂性为 C，则该系统的复杂性为 CxP。如果每个分区始终有一个骰子，则该公式变成 S1xD，可以简化为 SxD。

现在，通常我们会将这些经验延用于分区和未分区系统。为简单起见，我们假定分区始终有一个骰子（如同系统 D 那样）。则未分区系统（例如系统 C）的复杂性始终为 SD，而分区系统（例如系统 D）的复杂性始终为 SxD。

因此，问题归结为如何对这两个公式（SxD 和 SD）进行比较。表 1 显示了 S、D、分区公式 (SxD) 和未分区公式 (SD) 的不同值。

表 1. 分区复杂性与未分区复杂性

　利用表 1，您可以看出，未分区的 9 个骰子的系统与包含同样骰子数的分区系统相比，它的复杂性要大得多。其比率为 10,077,696 比 52。用外行的话来讲，太大了！

您可能了解了表 1 的要点。系统的整体复杂性越大，分区对于减小复杂性的影响就越大。

因此，有关如何处理复杂性的最佳线索是：分区。

返回页首

　迭代
　一旦我们使用分区来减小复杂性，则必须做出另一决定。如何分析剩余的复杂性？有以下两种方法：迭代（从左至右）或递归（自上而下）。通过再次查看分区骰子的复杂性模型（如图 4 所示），可以看出这两种方法之间的不同之处。

　图 4. 分区骰子

在复杂性的迭代方法中，我们单独分析每个分区。例如，我们先充分分析分区 1，然后分析分区 2，直到将每一个分区分析完毕为止。

在复杂性的递归方法中，我们分析每个分区的水平层。例如，我们先分析所有骰子作为一个整体的情况。然后，分析第一个骰子是一个整体，其余骰子分为两部分的情况。接着，我们继续进行该分析，直到分析完所有分区的最后一种可能情况为止。

哪种方法更好？迭代还是递归？

要得到此问题的答案，我们必须回到 1950 年，看一看一个名叫 John Boyd [Boy] 空军上校的好奇心。Boyd 对于如何构建复杂的 IT 系统并不关心。他可能从未听说过企业体系结构甚或 IT 系统。他关心的是如何在空战中获胜。

空战是两个战斗机飞行员之间的单打独斗，每一方都试图在自己被击落之前先将对方击落。由此您可以看出空军上校对打赢空战感兴趣的原因。

驾驶喷气式战斗机作战是一件非常复杂的事。飞行员需要考虑许多来自不同来源的信息，与此同时敌机飞行员也正在试图将其击落。看了图 5 所示的喷气式飞机的驾驶舱之后，您便会明白 Boyd 的飞行员必须应对的复杂情形。

　 图 5. 喷气式飞机驾驶舱

Boyd 不仅对所有空战感兴趣，而且尤其对 MiG-15 与 F-86 之间的空战感兴趣。作为一名前飞行员和造诣颇深的飞机设计师，Boyd 对这两种飞机了如指掌。他知道 MiG-15 的性能比 F-86 更为优异。MiG-15 的爬升速度和转弯速度均比 F-86 快；而且，MiG-15 的远视距能力也更强。

所有这些仅存在一个问题。尽管 Boyd 和其他大多数飞机设计师都认为 MiG-15 的性能极为优异，但是飞行员们却更愿意驾驶 F-86。其理由非常简单：在与 MiG-15 一对一的空战中，F-86 十次赢了九次。

这个问题引起了 Boyd 的强烈兴趣。为什么性能差的飞机总是能够战胜性能高的飞机呢？

为了解决这个反常的问题，Boyd 需要了解飞行员在空战中的实际操作方式。Boyd 有这方面的优势。他不仅是曾经一名飞行员，而且还是历史上最优秀的空战员。因此，他掌握了一些这方面的第一手资料。

让我们设想在空战中有这么一名飞行员。我们称他为 Pete。Boyd 提议 Pete 的空战由四个截然不同的阶段组成。第一阶段，Pete 观察 Pete 周围的情况，包括敌机的情况。第二阶段，Pete 根据该情况对自身定位。第三阶段，Pete 计划所要采取的相应行动。第四阶段，Pete 行动。

因此，Pete 先观察，然后定位，接着计划，最后行动。Boyd 将此顺序称为 OOPA（观察、定位、计划、行动）。

（实际上，熟悉 Boyd 著作的读者会认识到 Boyd 将此循环过程称为 OODA，即观察、定位、部署、行动的缩写。但是，我将“部署”改为“计划”主要是出于以下两个原因。首先，科技读者可能会被“面向对象的设计与分析”的首字母缩略词搞糊涂，该缩略词也是 OODA。其次，由于本人拜读过 Boyd 的著作，因此我断定，用于 IT 环境中的“计划”，比“部署”更接近 Boyd 的本意。）

但是，此处有一个关键的事实，Pete 不会仅仅执行一次该过程。他会反复执行该过程。事实上，Pete 一直在不断地重复执行 OOPA 过程。当然，他的对手也是这样。那么谁会赢呢？Pete？还是 Pete 的敌手？如果 Pete 驾驶的是 F-86，我们知道他可能会赢。但是为什么？

驾驶 MiG-15 的敌军飞行员执行 OOPA 这一过程时似乎比 Pete 更为出色。既然 Pete 的敌人能够看得更远，他就应该能够观察得更好。既然他能够更快地进行转弯和爬升，他就应该能够更快地做出反应。然而，Pete 的敌手输了，而 Pete 却赢了。

Boyd 认为赢得空战的主要决定因素不是在观察、定位、计划或行动上做得更好。赢得空战的主要决定因素是观察、定位、计划和行动时的速度更快。换言之，便是一个人的重复速度有多快。重复的速度，Boyd 说，击败了重复的质量。

Boyd 提出的下一个问题是：为什么 F-86 会重复得更快？他断定，其原因是某些没有人认为特别重要的因素。这就是 F-86 有一个液压飞行操纵杆，而 MiG-15 的飞行操纵杆则是手动的。

在没有液压的情况下，移动 MiG-15 飞行操纵杆需要的体力要比移动 F-86 飞行操纵杆稍多一些。尽管移动操纵杆后 MiG-15 即会以更快的速度转弯（或者爬升得更高），但是 MiG-15 飞行员移动操纵杆所消耗的能量更多一些。

每重复一次，MiG-15 飞行员的疲劳度就比 F-86 飞行员增加一些。并且由于他越疲劳，他完成 OOPA 循环过程的时间便会越长一些。MiG-15 飞行员失败并不是因为他被打败。他失败是由于所花费的 OOPA 时间过久所致。

我将 Boyd 的发现称为“Boyd 的迭代法则”：

在分析复杂性时，快速迭代几乎总是能够产生比深入分析更好的结果。

返回页首

　 分区迭代
　所以，现在关于如何更好地管理企业体系结构的复杂性，我们具有两条经验。从骰子的研究中，我们知道分区复杂性是减小复杂性的一个关键。从 Boyd 对喷气式战斗机的研究中，我们知道分析复杂性分区的最佳方法是对其进行迭代，并在迭代的过程中注重速度而不是完整性。

现在，让我们来看一看如何将这两条经验应用于复杂的企业体系结构。假定有一个大型业务管理系统，其类似于麦当劳斥资 1.7 亿美元要创建（但未成功）的那个系统。我将此系统称为 LCBMS，即复杂的大型业务管理系统。假设 LCBMS 需要包含以下功能：

全球人力资源
工资支付
总帐
应付帐款
应收帐款
编制帐单
资产
帐目管理
经费
雇员门户

我们如何将 LCBMS 分区？此列表为我们提供了一个直接的线索。切勿为 LCBMS 创建庞大的设计方案。可以为全球人力资源系统、工资支付系统等创建体系结构。换言之，切勿创建单一、巨大的复杂系统。设计一些小型的简单系统。设计一个，构建一个，然后再开始下一个。分区降低了整体复杂性。迭代提高了成功的可能性。

我们可以假定，早期的体系结构失败的示例（例如 FBI 的失败的“虚拟案卷系统”或麦当劳的失败的 BMS）均以标准的企业体系结构方法论（例如 FEAP、TOGAF 和 Zachman）为基础。这些方法论均是非迭代的。因此，它们全部失败不足为奇。这些失败所付出的高昂代价也并不会令人感到奇怪。

所有企业体系结构方法论均认为必须按照以下阶段来进行：

业务体系结构设计
技术体系结构设计
实现
测试
部署

传统方法论在执行这些阶段时一次执行一个阶段，在彻底完成一个阶段后再开始下一个阶段。如图 6 所示。

　图 6. 庞大设计的设计方法

如图 6 所示，传统方法论以目标系统（例如我们的 LCBMS）的深入业务体系结构为开始。然后，我们创建技术体系结构。接着，我们进行实现。随后，我们开始进行测试和调试。最后，进行部署。请注意，在最后的部署阶段完成之前，项目不会具有业务价值。

该分析还向我们显示了这些组织本应采取的方法。他们本应使用分区迭代方法。

分区迭代方法看起来相当不同。图 7 显示了运作中的分区迭代方法。请注意，我们所遵循的阶段与以前的完全相同，只是我们将逐个分区地执行它们。

　 图 7. 分区迭代

分区迭代方法的结果是不断地向前执行功能。在完成上一个分区之前，我们是不会开始下一个分区的。一般来说，复杂的组织通常会同时有多个项目，但也应将项目数量保存在最小，在早期的迭代阶段尤其如此。同时运行多个项目将会增加共同协作的需要。

返回页首

　 现有的企业体系结构框架
　现有的标准企业体系结构框架（包括 TOGAF、Zachman 和 FEAF）具有相似的历史。它们都深受“面向对象的设计和分析”(OODA) 领域的影响。

这些框架是在 OODA 过程中产生的这一事实非常重要，因为这表明它们早于 SOA（面向服务的体系结构）。今天，多数大型系统都基于通过 Web 服务标准（例如 SOAP 和 WS-Security 等等）的自治应用程序的互操作性的概念。此概念与面向服务的领域有着密切的联系，且在初创建早期的体系结构框架时该领域便已不复存在。

对象技术用于实现应用程序，而不是建立企业体系结构。其最大的缺点是不能管理复杂性。

在 2004 年举行的 IT 复杂性的大型研究中，皇家工程学院和英国计算机协会曾指出：

...目前的软件开发方法及实践无法以合理的成本或项目风险管理日益复杂且全球分布的系统。因此，存在着一个应对计算和通信技术能力的无情增长的重大软件工程问题。[Roy]

需要为大型复杂企业体系结构着手解决的问题是应用程序之间的交互性，而非应用程序自身的实现。认为大型系统可由相互作用的自治应用程序（在技术上相当于分区）组成的观点，在经历了“对象”阶段之后才达到成熟。事实上，这是 SOA 阶段的定义性特征。

使用 SOA 可以帮助管理技术级别的复杂性。恰恰由于必须将业务体系结构分区以将复杂性减少到可管理的级别，因此技术性的体系结构必不可少。迄今为止，SOA 是我们所拥有的完成此技术分区的最佳方法。

OODA 框架经常宣称支持迭代的观念，但是它所支持的迭代与分区迭代中的迭代有很大区别。实际上 OODA 的迭代观念与其说是迭代，还不如称其为递归，如图 8 所示。它将系统复杂性置于字节大小的部分之中进行处理。它并没有减少系统复杂性：它只是将在任一时刻必须面对的复杂程度降至最低。

图 8. 企业体系结构的 OODA 方法

分区迭代在两个重要方面与 OODA 不同。首先，也是最重要的，它通过分区减少复杂性，而不是试图通过递归来对其进行管理。但是其次，分区迭代强调迭代的速度，但却是以详尽的计划为代价实现的。其观念是，我们通过做所了解到的要比我们通过计划所了解到的更多。图 9 显示了分区迭代方法。

图 9. 企业体系结构的分区迭代方法

分区是一种根本不同于 OODA 样式递归的、处理系统复杂性的方法。OODA 解决复杂性的方法是试图将其分为可管理的数量。分区迭代则从正面进攻复杂性。它不是尽力使复杂性变得可管理（OODA 方法），而是将复杂性一起消除。它使用我们之前在骰子的研究中所见到的数学原理：通过将功能分区减少复杂性。

返回页首

　分区迭代方法的优点
　分区迭代方法开始提供价值的时间比递归的 OODA 方法更早。其原因在于我们是分段提供我们的系统。只要我们是出于使每一个区段都包含可衡量的业务价值的目的，来设计我们的垂直片段，迭代便会转变为更短的见效时间 (TTV)。

在业务领域中，TTV 是衡量价值的重要尺度，它甚至比投资回报 (ROI) 更加重要。ROI 是长期目标。任何项目，无论其组织得有多差、超出预算有多高、与业务需求有多么不符，只要其费用能够在足够长的时间内分期偿还，便都可以获得良好的 ROI。问题是，该业务是否能够支撑足够长的时间来实现回报？

TTV 更为直接一些。不同的人对 TTV 有不同的定义，但是我将 TTV 定义为从项目预算获得批准到管理人员认为该项目已对组织的业务产生了积极影响时所经过的时间量。换句话说，TTV 就是资金支出与产生的感知价值之间的时间长度。ROI 与 TTV 毫不相关。

例如，假定管理层批准了一笔用于重组客户支持的 2,000 万美元的预算。您可能会采用传统的递归的 OODA 方法，这种情况下，在 2,000 万美元的项目全部完成（如果您非常幸运的话）之前，将不会产生任何感知价值。或者，您可以利用分区迭代方法，将项目分成几个包含价值的垂直分区。

假定第一个区段是一个包含客户可访问的有用信息的、易于访问的在线数据库。在其他项目远未完成甚至产生正的 ROI 之前，此垂直片可提供感知价值。例如，如果您可以在第一个月内证明该库已使客户给服务台打电话的次数减少 20%，则您便是在显示价值，即使您显示整个项目的正 ROI 可能需要几年的时间。

您认为哪一个项目更可能被取消？是在几个月内即可返回较高感知价值的项目（分区迭代），还是在花费了甚至两年的金钱与精力之后并未返回任何感知价值的项目（递归的 OODA）？

较短的见效时间在项目能够在管理层优先表上具有较高优先级方面，具有重要价值。眼不见，心不烦无疑是适用于 IT 项目的格言。

分区迭代方法的第二个优点是，它可以增加成功项目的整体机会。这是因为您可以将在较早迭代中获得的教训应用于将来的迭代中所要做的工作中。

现在我们回到客户呼叫中心，我们不仅要假定您的直接分区是完成一个新的客户用户界面，而且还要假定您将来要进行的迭代之一是创建一个呼叫中心用户界面。假定您已设想可以在六个人月内完成新的客户用户界面，而新的呼叫中心界面则需要八个人月。但是，完成新的客户用户界面后，您发现所耗费的是九个人月而不是六个人月。显然，您在对创建用户界面所涉及工作量的估计上出现了问题。

现在，您有一个可以从您的错误中学习的机会。假定您确定问题的所在是因为您低估了培训开发人员所需的时间。在处理呼叫中心界面时，您可确保您指派的是经验丰富的开发人员。如果开发工具比您设想的复杂，则可以考虑更换工具。如果只是进度比您设想的要慢一些，则您可以调整余下的项目进度。

问题是，通过分区迭代，您可在问题蔓延于整个项目之前早早发现它们。而且，即使这些问题无法得到解决，至少也可以在由此而产生的延误令管理层大为吃惊之前，将其识别出来。管理层可能不喜欢延误，但其更憎恨吃惊。

有效地管理期望是几乎所有项目的重要组成部分。使用分区迭代方法，您可以更轻松地对潜在的问题做出反应，而且还可以与执行团队更有效地交流现实的期望。

分区迭代的第三个优点是，它占用您的最高级的、最重要（也是最昂贵）的职员更少的时间。这是因为每个分区的设计只需要直接参与此分区的职员的同意即可。在递归的 OODA 方法中，多数职员都会参与大部分的设计决策，这样看似非常简单的设计决策经常会在费尽周折之后才能做出。

分区迭代的第四个优点是，它可以产生能够自然映射到 SOA 的设计。SOA 由众多的小型自治服务组成，而不是 OODA 方法的典型的单一庞然大物。这些小型、自治且可以相互操作的服务在重用、协作、互操作性、灵敏度及自动的工作流方面均比 OODA 的相应方面更胜一筹。

最后，分区迭代方法为功能蔓延提供了比 OODA 方法更完美的解决方案。在减少功能蔓延方面，有三个因素使得分区迭代方法颇受欢迎：

分区迭代方法中的分区数量比 OODA 方法中的分区迭代数量更多。这样便减少了人们认为给定的分区是他们可以将所需的某些功能加以合并的唯一机会的心理需求。
参与任意一个分区设计的人员的数量比 OODA 方法少。这意味着，在任何给定的迭代中，需要询问其对新功能的意见的人员数量会有所减少。
分区迭代重视见效时间 (TTV) 而非投资回报 (ROI)，而后者则是 OODA 所喜爱的。大部分人会将正的 ROI 与功能的丰富程度联系起来。毕竟，更多的功能意味着更多的人可以使用某个特定的应用程序。使用该应用程序的人越多，应用程序所带来的“回报”便越大。对 ROI 的过分关注是功能蔓延无法抗拒的磁石。

而分区迭代方法所关注的 TTV 则强调快速提供。每个人都知道时间盒必须快速提供。时间盒意味着将功能限定为可在给定时间范围内提供的、至关重要的功能。这要求其本身具备集体精神，愿意努力查看请求的功能，然后舍弃那些并不真正需要的功能。

如您所见，组织若实现了从 OODA 企业体系结构方法论到分区迭代方法论的转变，则会为其带来许多重大的益处。其中包括：

更加快速地提供可计量的业务价值。
提高成功完成项目的可能性。
增加从以往的成败中学习的机会。
提高项目计划的准确性。
更加符合技术的面向服务的体系结构。
自然防止功能蔓延。

凡是正在努力寻找其在体系结构所做的努力所带来的真正价值的组织，都会对这些重要优点感兴趣。

返回页首

　 成功法则
　既然前文已向您介绍了一些构建企业体系结构的分区迭代方法的理论和实践背景，下面将为您提供一组法则，我相信这些法则有助于您更成功地使用这种方法。

法则 1：从容易取得成效的目标开始

一旦经过了第一轮行动并确定了您的项目/分区后，您需要决定首先要处理的问题。许多专业人士建议首先处理风险较高的项目。其中的逻辑是：您就可以在早期发现将要出现的问题。我不赞成这种方法。

您在开发企业体系结构过程中要做的首要事情是演示成功。这将有助于推动实现更大目标。这一点对于过去曾受采用 OODA 方法构建企业体系结构所累的组织来说尤为适用。

因此，在早期迭代过程中首要且最重要的目标就是建立可信度。建立可信度最好的方法是取得一些显而易见的成功以能够为组织中的每个人所了解。

表 2 概述了优先执行分区的一些最重要的因素、如何最好地分析每个因素以及各因素对总体优先顺序的影响。

表 2. 分区优先化因素

使用“优先级目标”是优先化分区的好方法，如图 10 所示。在“优先级目标”中，每条轴代表我在表 2 中列出的一个优先级考虑事项。每条轴靠近中心者为有利因素，靠近边缘者为不利因素。
　
　图 10. 优先级目标

创建了“优先级目标”之后，就可以在各条轴上标识您的“机会”。例如，如果该分区风险适中，则在目标黄色区域的风险轴上放置一个圆圈。完成后，您就可以直观地看见应首先处理的候选项目（分区）。

例如，比方说您已经确定了两个项目。其一是开发客户可访问的知识库。其二是创建单点登录过程以提高安全性。您为这两个分区创建了优先级目标，结果如图 11 所示。随即很明显就可以看出“更容易取得成效”的项目。

　 图 11. 比较两个优先级目标

法则 2：利用小规模经济效应

有关企业体系结构常见的错误见解是：您可通过扩大规模能够取得经济效益。这种理论的原理是，如果有足够多人员同时参与足够大的项目，那么就不可避免地会造成许多过剩。消除这些剩余将能够降低开发和维护成本。项目越大，剩余就越多。剩余越多，消除剩余的机会也就越多。剩余消除得越多，项目的总体成本也就越低。

遗憾的是，这一理论忽略了项目管理的最基本法则：削减资源盈利法则。项目中涉及的人员越多，该项目作为一个整体的效率将越低。削减资源盈利法则是著名的“Brooks 法则”的推论。30 多年前，Fred Brooks 首次观察发现，向滞后的软件项目加派资源只能使该项目更加滞后 [Bro]。他因为这一发现和其他观察结论在 1999 年荣获“图灵奖”。

用一个相对较小的成员组来处理一个明确定义的企业分区，可以在合理的时间范围内执行合理的作业。用规模较大的成员组处理未划分的企业必然会发现剩余。但是找到这些剩余、辩论如何能最有效地消除剩余以及尝试达成统一的设计方法所需的成本，几乎总是远远超过了剩余本身的成本。

规模产生经济效益是正确的。但是，真正的经济效益来自小规模，而非大规模。

法则 3：集中互操作性、分散实施

许多组织构建的企业体系结构都过于集中。通常，他们设立一个企业体系结构办公室，并赋予该办公室广泛的决策权。这种过分的集中会导致古板的官僚作风和项目停滞不前。

集中的企业体系结构组织是有必要的。但是中央组织需要专注于正确的问题，而不要陷入不相关的问题上。

一般的经验法则是应集中处理会影响互操作性的决策。影响实施的决策则应该分散处理。不知道具体是哪一类决策是企业体系结构部门常犯的错误。

让我们来看一看在企业体系结构方面出现的一些典型错误：

平台 - 许多组织试图定义一个标准软件平台，经常在使用何种软件平台（比方说 Microsoft .NET、IBM 的 WebSphere 或 BEA 的 WebLogic）方面进行无休止地辩论。这种努力的方向不正确。平台属于实施决策部分，它对这些平台上的应用程序将如何协同工作没有影响。只要平台满足组织的互操作性要求，就应该赋予应用程序小组自由选择最能满足其应用程序需要的平台。
数据 - 许多组织试图定义单个数据层供组织中的所有应用程序共享。结果通常是代价高昂，而且很少会取得成功。数据的存储方式应视为是应用程序的实施细节。
业务智能 - 大多数组织以可交换的方式处理数据和业务智能。但是数据（例如，如何在数据库中存储客户）是实施细节，智能（例如，我们与特定客户从事何种业务）是组织资产。适当的做法是确定如何共享这种智能。但确定（在企业级）应用程序将如何跟踪提供这种智能的数据则是不适宜的。
代码共享 - 许多组织认为通过代码共享可以实现重复使用。尽管失败了数十年，人们仍然坚信能够实现该目标，多少有点令人吃惊。减少给定项目所需代码数量的最佳途径是通过功能委派（如 Web 服务），而不是通过代码共享。
Web 服务 API - 许多组织都正确地认为实现互操作性的关键是使用 Web 服务。许多组织认为这意味着应该标准化应用程序使用 Web 服务 API 的方式。实际上，Web 服务 API 远不比应用程序更重要。应用程序通常使用供应商指定的缓冲层，例如，Microsoft .NET 平台提供的 Windows Communications Framework 层。该层旨在使应用程序无需了解 Web 服务 API 的复杂操作。此缓冲层取决于平台，因此属于应用程序实施细节的一部分。

关键问题在于企业体系结构与应用程序体系结构不是一回事。应用程序体系结构是指应用程序的设计。这些设计应由应用程序所属的小组负责。这是我们实现小规模经济效应（请参阅法则 2：利用小规模经济效应）的方法之一。企业体系结构应关心这些应用程序如何协同工作，并据此向组织提供更高价值。

返回页首

　结论
　企业体系结构可以是一个非常重要的资源，有助于组织找到更好的方法来使用技术支持其关键业务流程。遗憾的是，许多组织花费巨资试图建立企业体系结构，却只取得有限的成效，甚至是消极的结局。无论是公共部门还是私营部门，几亿美元的付之东流是常有的事。

这样频繁的巨额损失有三个主要原因。首先是过于依赖递归式面向对象设计与分析 (OODA) 的体系结构方法。其次是认为建立企业体系结构就意味着开发整个组织的详细蓝图这样的错误观念。第三是未能将复杂结构分解为更小、更易管理的项目。

与所有递归方法类似，OODA 方法管理复杂性的能力有限。面对现代极不稳定的组织，复杂性是主要的难题。

本文提出一个不同的方法来构建企业体系结构。该方法的依据是：纵向划分组织的流程，确定完善这些流程的优先级，然后重复这些流程并密切关注见效时间 (TTV)。此方法称为分区迭代。与递归方法不同，分区迭代直接针对复杂性。

本文介绍了取得分区迭代策略成功的三个法则。这些法则如下：

从容易取得成效的目标开始，将精力集中在见效时间短的目标上。
充分利用小规模经济效应，以灵活的流程为中心。
集中互操作性并分散实施，以通过分区降低复杂性和通过灵活加速迭代为目标。

基于分区迭代建立企业体系结构的方法与基于递归的方法相比具有许多优点。这些优点包括：

更好的使用技术解决紧急的业务问题。
大幅降低构建复杂系统的成本。
加速高商业价值技术项目的交付。
更好的控制整个系统成本。
提高了预测交付日期的准确性。
极大的提高整个系统成功的可能性。

对于描述组织的目标、如何通过业务流程实现这些目标以及如何通过技术更好的服务于这些业务流程，分区迭代是我们所拥有的最节省成本的方法。

换句话说，分区迭代可以最快的速度和最低的可能成本提供高商业价值的技术解决方案。高价值。最短的时间。最低的成本。这就是底线。

返回页首

　 术语表
　.NET - Microsoft 系列产品（包括其 Web 服务基础结构）的总括术语。

灵活性 - 度量实体（例如，企业）对变化的环境条件做出迅速反应的能力的一个指标。

Boyd 的迭代法则 - 在分析复杂性时，快速迭代几乎总是能够产生比深入分析更好的结果。以 Col. John Boyd 命名。

Brooks 法则 - 向滞后的软件项目加派资源只能使该项目更加滞后。贡献人 Frederick Brooks。

Clinger/Cohen 法案 - 请参阅信息技术管理改革法案。

协作性 - 与互操作性相对，通过该过程，不同企业中的两个应用程序可通过编程方式协同工作。

企业体系结构 - 对组织的目标、如何通过业务流程实现这些目标以及如何通过技术更好地服务于这些业务流程的描述。

企业体系结构框架 - 建立企业体系结构的方法。

FEAF - 请参阅联邦企业体系结构框架。

联邦企业体系结构框架 (FEAF) - 美国联邦政府使用的企业体系结构框架，用于描述各个政府机构及其 IT 系统相互关联的方式。

FEMA - 美国联邦应急管理局，美国政府的一个行政分支，负责对灾难采取紧急措施。

GAO - 请参阅美国政府问责局。

美国政府问责局 - 美国政府的分支机构，负责监察美国政府内部不同机构的效率。

信息技术管理改革法案 - 美国国会于 1996 年通过的法案，该法案要求所有政府机构使用有效的策略和框架来开发和维护 IT 资源。

互操作性 - 通过该过程，同一企业中的两个或多个应用程序可通过编程方式协同工作。与协作性相对。

IT - 信息技术。

迭代 - 将整体目标分解成一系列较小的目标来分别实现任何过程。

迭代体系结构 - 通过分阶段设计、构建并部署大型复杂系统来架构系统的方法。

迭代式开发过程 - 灵活的软件开发方法，采用这种方法时，软件开发会经历设计、实施和重新评估的快速迭代，结果得到（据称是这样）更能适应业务条件变化的系统。与瀑布式开发过程相对。

ITMRA - 请参阅信息技术管理改革法案。

复杂性法则 - 系统的复杂性与系统能从中找到其自身的状态的数量有关。常用于比较构建系统的两个不同方法的复杂性。

容易取得成效的目标 - 该术语描述能够以最小计算成本取得最大认同价值的一些选择的子集。

面向对象的设计和分析 - 以面向对象的递归分解为基础的体系结构框架。

OODA - 请参阅面向对象的设计和分析。

OOPA - 观察、定位、计划、行动。最先由 Col. John Boyd 提出的与喷气式歼击机有关的循环过程，尽管他将其循环描述为观察、定位、部署、行动。在 Boyd 的描述中，观察、定位、计划和行动的循环是重复进行的，并且能够更快速重复该循环的实体将能战胜重复更彻底的实体。

分区迭代 - 构建企业体系结构的一种方法，该方法首先将企业分成一系列自治的纵向部门，然后进行迭代分析，最后在适当之处通过使用更好的业务和技术流程进行改进。

优先级目标 - 作为目标靶提出的说明对象的一种直观表示，目标靶中心向外辐射出来的线条代表优先化因素，而沿各轴的“机会”表示此因素相对于说明对象的重要性。将机会放在每条轴上，离靶中心越近表示影响越有利。

Rational 统一流程 (RUP) - 一种开发软件的过程，该过程是 IBM/Rational 工具套件的基础。

递归 - 在分析中，该过程将系统分解为由多个子系统构成,每个子系统也分解为由多个子系统组成，依此类推，直到得到一组无法从逻辑上分解的最终系统为止。

剩余 - 多个系统之间功能上的重叠。

投资回报 - 度量项目商业价值的一个指标（以百分数表示），根据所取得的利润增值（因为增加的收入或减少支出）除以项目的成本来计算。例如，成本为 $100,000 的项目取得 $200,000 利润增值，其 ROI 为 200%。

ROI - 请参阅投资回报。

SOA - 请参阅面向服务的架构。

Sarbanes-Oxley 法案 - 美国国会于 2002 年通过的一部法案，旨在预防企业的审计作弊行为。该法案要求严格审计财务数据，并对未遵守法案的财务官员追究个人责任。

服务 - 请参阅 Web 服务。

面向服务的架构 - 为使构建于 Web 服务技术之上的自治系统之间实现互操作性的架构。

SOX - 请参阅 Sarbanes-Oxley 法案。

TAFIM（信息管理技术体系结构框架） - 由美国国防部开发的结构框架并于 2000 年正式废止。

时间盒 - 严格使用通常较短的交付周期以抵制不断向系统添加新功能的诱惑。

见效时间 - 从项目预算获得批准到管理人员认为项目对组织的业务产生了积极影响时所经过的时间。

TOGAF（Open Group 体系结构框架）8.1 - 由 Open Group 控制的体系结构框架。

TTV - 请参阅见效时间。

Web 服务 - 可通过非专用消息格式和传输协议响应来自其它独立软件系统之请求的自治软件系统。通常是，消息格式是 SOAP。

工作流 - 完成高级任务（例如，处理保险索赔）时，通过组织的工作流程。

企业体系结构的 Zachman 框架 - 一种体系结构框架，在其中将企业划分为三十个单元来建模，每个单元代表一个透视和一种抽象之间的交集。

返回页首

　 参考资料
　Arm - A big-picture look at enterprise architectures，Armour F.J.，Kaisler S.H.，Liu S.Y.，IT Professional 第 1 卷第 1 期，1999 年 1 月/2 月，第 35 - 42 页。

Bro - The Mythical Man-Month; Essays on Software Engineering，Frederick Phillips Brooks。Addison-Wesley，1995 年出版发行的 20 周年版。

Boy - 有关对 John Boyd 著作的详细介绍，请参阅 Genghis John，Proceedings of the U. S. Naval Institute，1997 年 7 月，第 42 - 47 页，Franklin C. Spinney。

Car - Does Not Compute，Nicholas G. Carr，纽约时报，2006 年 1 月 22 日。

Cha - Why Software Fails，Robert N. Charette，IEEE Spectrum，2005 年 9 月。

Cli - 美国第一百零四届国会第二会期“信息技术管理改革法案”。

CMU - 卡耐基-梅隆大学，www.sei.cmu.edu/architecture/glossary.html。

Gov - 此引文可在许多地方找到，例如 www.cio.gov/documents/FINAL_White_Paper_on_EA_v62.doc。

Fea - 例如，A Practical Guide to Federal Enterprise Architecture 中多次提到 FEAF，该文档可在 http://www.gao.gov/bestpractices/bpeaguide.pdf 处找到。

GAO1 - 2004 年 11 月 GAO 提供给美国财政部长的报告：FINANCIAL AUDIT IRS's Fiscal Years 2004 and 2003 Financial Statements。

GAO2 - 在政府管理、财政和审计小组委员会、政府改革委员会和众议院前作证的证词：DOD BUSINESS TRANSFORMATION - Sustained Leadership Needed to Address Long-standing Financial and Business Management Problems（2005 年 6 月）。

GAO3 - 2004 年 8 月 GAO 提供给科技、信息政策、政府间关系及人口普查小组委员会、政府改革委员会和众议院的报告，HOMELAND SECURITY Efforts Under Way to Develop Enterprise Architecture, but Much Work Remains。

For - Oops! Ford and Oracle mega-software project crumbles，Patricia Keefe，ADTMag，2004 年 11 月 11 日。

Kma - Code Blue，David F. Carr 和 Edward Cone，Baseline，2001 年 11 月/12 月。

Mac - McDonald's: McBusted，Larry Barrett 和 Sean Gallagher，Baseline，2003 年 7 月 2 日。

Mur - Managing Complexity in IT, Part 1: The Problem，Richard Murch，InformIT，2004 年 10 月 1 日。

Roy - The Challenges of Complex IT Projects：来自 Royal Academy of Engineering 和 The British Computer Society 的一个工作组的报告，2004 年 4 月。

TAF - 美国国防部。Technical Architecture Framework For Information Management (TAFIM) Volumes 1 - 8，Version 2.0。Reston，VA: DISA Center for Architecture, 1994。

TOG - TOGAF（Open Group 体系结构框架）版本 8.1“企业版”可在 www.opengroup.org 上找到。

Wiki - Wikipedia，http://en.wikipedia.org/wiki/Enterprise_architecture。

Zac - A framework for information systems architecture，J.A. Zachman，The IBM Systems Journal，1987 年第 26 卷第 3 期，第 276 - 292 页。

关于作者

Roger Sessions 是 ObjectWatch Inc. 的 CTO，写过六本书及许多文章和白皮书。他是 International Association of Software Architects (www.iasahome.org) 的董事会成员。Roger 常常是全球事件的主要发言人，并指导以架构师社区为目标的研讨会及培训。Roger 专为企业架构师和 IT 经理编写名为 Architect Technology Advisory (ATA) 的每月时事通讯。ObjectWatch 擅长通过咨询和培训，帮助各种规模的组织实现其企业体系结构的最大潜在价值。有关 Roger Sessions 和 ObjectWatch 的详细信息，可在 www.objectwatch.com 上获得。