在：《企业精简架构》张雄 译，机械工业出版社，2009年5月，ISBN：978-7-111- 26626-6。

原作是Roger Sessions，原名 “Simple Architectures for Complex Enterprises”，这是个很有意味的名字。作者是知名软件架构专家，是“软件城堡架构”（software fortress architecture）的提出者。

书的原名是很有意味的，或可意译为“以简单的架构应对复杂的企业”。作者对于EA的理解，看来是偏于IT的，他的“Enterprise”是那种典型的IT人的，隐隐中有把IT应用系统看作是“Enterprise”的倾 向^[1]。但这并不妨碍本书的主题、也是精华的价值：为架构的复杂性度量和减少复杂性的方法引进数学基础的尝试。

本书着眼点是EA的复杂性。其中举出了一些EA实践中的问题，对于正在引起xx的国内企业，这是很难得的提醒。EA是一种非常复杂的实践，某些方面或许就像早年的BPR，我认为很可能也会成为某种“高失败风险”的项目。但这并不妨碍它的价值：越难采的矿，才越金贵。

在作者举的例子中，最引人注目的无疑是美国xx政府，因为EA宣传者无一例外会将此（也就是FEA）作为经典、标杆。但作者的评语却有些令人吃惊（以下引文中的粗体都是我加的）：

“作为失败的典型实例，我们可以看看美国xx政府。很有可能，世界上没有哪个组织花费这么多的金钱、时间、努力来创建和支撑这个有效地构架。美国政府做得怎样呢？显然，并不算好。”

——“失败的典型”？FEA的应用是“失败”的吗？这很值得研究。不知国内花了很多钱的电子政务研究，有没有对此专门进行过调研？

对类似的系统，简单地作出“成功”、“失败”的评价，往往很困难，甚至会有很大争议。但我相信绝不会是像想象中，或一些咨询顾问作为经典案例介绍的那么美好。有问题是很正常的。看作者列出的一些资料，例如这一段，经验上看，就很实际：

“ 国土安全部（Department of Homeland Security，简作DHS）的问题就相当明显了。在2004年8月的报告中，GAO提到：DHS期望能从一个定义好的构架（例如，业务过程的描述，这些过程之间的信息流，这些信息流相关的安全规则，等等不一而足）中找到所有的关键元素，但这些关键元素或多或少地会遗漏。除此之外，关键元素在初始版本中的表现形式随着构架的发展逐渐变得不一致……结果，DHS并没有必要的构架蓝图高效地引导和约束正在进行中的商业转型和上亿的美金（这些美金用来研究支持IT资产）。”

这里涉及了数据的完整性，版本的问题：非常具体，非常典型。作者认为：

“如果说xx政府企业构架方面xxx的案例，这个领域的确不容乐观。”

作者“深入地”讨论了EA的定义，但这些讨论却看得我一头雾水。相信翻译在这里起了很大的“作用”，有机会必须看到原文，才能准确了解作者本意。

有两处似乎是比较明确的，其一：

关于企业构架，你可能会有些困惑，首当其冲的就是术语”构架”本身。“构架”这个词意味着蓝图。大家知道，蓝图就表明了完整性。如果是盖房子，那么它就包 括所有与盖房子相关的：房顶和墙壁如何连接，管道如何铺设，接线板放在哪儿，等等。

architecture意味着bluepoint？这难道就是坊间流行的EA“蓝图说”的根？这个我实在不赞成。还有相关的表述：

“一个企业构架看起来应该是一些能够引导技术的利用的文档的集合。实际上，它看起来更像一个城市规划，而不是一栋建筑物的蓝图。”

把企业比作城市，在某些方面——比如动态性、人的系统方面——好于比作建筑，这个我很赞同。把“EA”比作“规划”，这比“蓝图”要好一点：规划可以是个动词——不过我仍然不能赞同：我认为，蓝图也好、规划（动词/名词）也好，都只是EA的组成部分。EA的实践是规划、建模、实施或实现的连续、动态、持久的过程，这种“蓝图”说，对理解、掌握EA，危害很大，应该大力批判。

上面提到的“一个企业构架”（原文估计是 an enterprise architecture）也是值得推敲的地方，这反映我们使用EA一词时不同语境中的不同含义：实例和类的区别、方法和方法的“实施及结果”的区别。我想，你只能把具体的应用，称为“一个EA”，比如FEA，严格地说，它是EA的“一个（次）应用实例”。

作者一直（参见注释）把架构看作某种方法学（methodology），尽管有Zachman明确地提醒ZF是分类法不涉及如何做的过程（不是方法学），他仍然坚持。这个不象“蓝图”那么偏颇，但似乎也不是很适合。

依我看，EA可以包括方法和方法学：当从一门知识（学科，或称“建构学”）的角度去理解时，方法学应当是其中的重要组成部分。当从具体应用，或一种技术（比如特定框架、营造法式）角度去理解时，就不必包含什么“方法学”，而应该是具体的“方法”（methods）。

我倾向于把EA称为一种“系统的方法”，这似乎也有点麻烦：方法里面包含方法学好像不合理啊。可在英文这样说似乎就可以吧：EA is an approach and has some methodologies, frameworks, models…

作者引进了非常简明的复杂性度量方法，大致就是基于系统可能的状态数量。系统所有的变元和每个变元各自的可能状态数之积，就可以作为系统复杂性的度量指标。另一方面，减少变元的数量和可能状态数量，就可以降低复杂性。这基本上就是本书的核心思路。

作者用“同态”概念说明了模型与被建模系统之间的对应关系。

通过对“等价类”、“分割”（都是有数学含义的）的应用，即对企业（架构）要素的合理分割、分类，减少复杂度——而前述的复杂性度量方法，可以告诉我们在做了这样一些操作时，复杂度是否降低了，降低了多少。这个思路相当清楚。

作者把它引进数学方法度量架构复杂度和指导对复杂度控制、消减的努力，与关系代数之于关系数据库来比较。这一部分是本书的主体和精华。如果它是有用的，那就不光是对企业架构。任何复杂系统的架构在这方面的基本规律应该是相同的。