作者: 余彤鹰,  来源:  企业工程论坛,  发表时间: 2011-01-18
 

引言

在企业应用（信息系统或软件）和企业工程领域，术语“architecture”越来越常见，但这个词的使用也常常显暧昧或矛盾。在多数情况下，我们会尽量使用其它简明而常见的词语，例如：涉及系统本身有“结构、构造、组成”（structure, construct, component）或“结构框架”（structural framework）、“结构类型”（structure type），以及系统的“类型、分类”（type, catagory）等，涉及建构/实现有“方法、过程、程序、方法学”（method/approache, process, procedure, methodology），涉及系统描述或规定有“建模、模型、参考模型、元模型”（modeling, model, reference model, metamodel），还有系统的“规划”（plan），“设计”（design）， “工程”（engineering），等等。这些，加上些诸如“结构规范/标准”、“设计规范/标准”、“实施规范/标准”、“参考模型/框架”等等，似乎足以说明关于某种复杂人造系统的各种事情。那么，为什么我们需要“architecture”这个词？它为什么愈发流行？我们是否可以用奥卡姆剃刀[1]将其剔除？

理解要点

Architecture一词本源于建筑领域，它与建造有关，同时又涉及建造的方法，以及建造的设计方法及设计结果——目标系统的结构或风格。虽然在具体的使用中，有时会侧重于其中的某个方面，例如建筑的风格，软件的结构特征，企业的规划与治理等，但显然architecture并不是单纯指风格、结构或规划、建造（实现）的方法学等——当我们需要明确地谈论这些单纯的方面，不必放弃简明的词汇，去使用一个暧昧、多义的词。

理解的要点，正是在于这些要素的关联——而其中的关键，是系统的结构或结构特征、风格与其规划设计、建造、改造或演化方法之间的关系。更明确地说，复杂的系统的设计（指结果）与设计、建造方法与手段之间具有密切的关系。在涉及具体系统建造（实现）的语境中，单纯地讨论复杂系统的结构、结构特征通常是不切实际的，我们必须知道它们能否实现、怎样实现，甚至包括是否能够有效地维持其运作及根据需要作出改变。同时实现（及维护治理与改变）的手段、方法本身也制约着设计者对于结构或风格等的选择。例如，我们似乎可以按照自己的想象，把一栋大楼建设成任何样子，唯一的约束是物理学定理——但实际的情形并不是这样：要想设计一幢能够可靠地建成的建筑，除了物理学定理之外，我们还要受到许多限制，例如来自我们所拥有或可行的方法、手段或工具、材料等的限制，当然也包括某种式样或风格的限制。而且，目标系统越复杂，限制越多，也越有必要性。

另一方面，假如我们每一次都从零开始，仅仅根据力学原理来设计一栋大厦，那么，我们面临的是，一方面我们需要从最基础的要素——每一块砖的结构开始设计，将导致每一次的设计都异常繁琐而且是不可靠的，而另一方面，更重要的是，最终我们也许得到一个非常独特、完全符合物理学定理的设计方案，但没有人能够有效、可靠地实现。在设计和实现复杂系统时，人们必然地要大量地采用已有的、逐步积累的结构或部件。

在稍微成熟的、复杂系统营造的领域，人们会不断地总结、积累各种结构或结构风格，以及关联的设计、建构或实现的准则、方法与手段。对于复杂系统的营造，这些方面必然地关联在一起，构成一些不同的体系。这就是为什么有必要用architecture而不只是用structure或structure style/type和approaches/methods等的理由。

进一步，我们可以归纳出有效地营造复杂系统的两项基本原理（two basic architectural principles for complex systems），它们也是理解architecture概念独特性与重要性的关键：

1）  设计与实现关联原则：复杂系统的设计方案，如结构或结构特征的选择必须受可行的实现方法与手段的约束。

2）  部件或构造通用原则：复杂系统的设计与实现，应尽可能基于具有通用性、适用条件已知、可靠性经过验证的通用部件或构造。

这样，就得到在诸如软件、企业工程等领域使用architecture概念的基本理解：它的基本语境是“复杂人造系统”，涉及一系列相互关联的设计和建造（有时还包括维护/治理和演化/转变）相互关联的（系统性的）方法、手段和准则。

另一方面，我们还可以理解到，在诸如软件等领域，architecture越来越多地使用，正是人们对它的建造与实现规律日益加深，迈向成熟之的一种标志。

在这些理解的基础上，再回头看软件、企业工程等领域五花八门的定义，就比较容易解读了（包括一些较为偏颇的解释）。

例如ISO/IEC 42010:2007与ANSI/IEEE 1471-2000所给的定义：

“指系统的基础性组织，体现于其构件及它们的相互关系、与环境的关系、和它们的设计与演化的治理原则。”

因为它的基本语境是软件，因此使用了“构件”（components），对于一般系统，也可称为构成、构成部分、成分。而之所以强调“构件及其相互关系”而不是简单地用“结构”（structure）这样的表述，也顺应了前述“部件或构造通用原则”。同时，从“设计与实现的关联原则”，我们就可以更好地理解这个定义的后一部分——它与前面部分并不只是简单并举的关系。尤其是，它不应只是包含基本构成要素及其关系、结构或构造，还应当包括这些要素的运用、实现甚至治理的准则。

又如，来自欧洲的企业工程系统研究者简·迪茨这样界定企业工程中的architecture：

“Enterprise Architecture是设计自由度的规范性约束；实际上，它是一个协调一致的准则集合，用以指导企业的设计、工程和实施。只有应用Enterprise Architecture，才能将企业高层次的方针（使命、战略）一贯地实施于该企业的运作。”

在他的讨论中，也曾特别指出这一概念常见的引起混淆的不恰当用法，例如将EA仅仅理解为一种结构框架或蓝图。同样，结合上述理解要点，就能更好地理解他所说的“规范性约束”，以及为什么要在设计、工程和实施上一贯地加以运用。对于企业工程而言，由于它大部分时间是处于演变/改进过程之中，EA的运用基本上是在一个已经存在的企业运作过程中进行的。

汉语中的对应概念

在前面的文字中，我们有意识地使用了architecture，因为在软件和企业工程这两个基本语境中，architecture这个概念是外来的，而且不幸的是，已经流行的“架构”、“体系结构”等译法[2]，恰恰是非常“不靠谱”的译法。它是最不好的那种翻译：没有找到对应词语，选择了一个与原概念既不等而又部分相关的词语来指代，这样最容易造成误导和混淆。理解了上述要点，就容易体会到为什么这样说——它们的字面意思都是错误的。

实际上，我们可以从architecture的本源——建筑领域找到答案。首先，对architecture较广义的用法，可以指学科（领域）或某种营造知识体系，现代汉语中已经形成的对应词汇是“建筑学”。但将“建筑学”直接借用到其它系统领域，似乎不是很理想（或许是因为中文“建筑”这个基本名词的存在），因而，我认为“建构学”或许是一种比较中肯的选择。例如在企业工程领域，我建议可以采用“企业建构学”（或参照后面，用“营造学”）。

事实上，目前在诸如软件、企业工程领域，architecture并不经常使用在类似“建筑学”的层面上（这可能与领域的成熟性有关），而是指向更具体的设计与建造体系。前面已经提到，目前流行的翻译，是“架构”和“体系结构”（及构架等）。事实上，我在《企业工程的内容与企业架构的定位》已初次指出，在建筑领域，古汉语已经有与architecture对应的说法，即“营造法式”（可参见维基百科营造法式条目）。将这四个字的意义展开来看，它的确精准地体现了我们前面讨论的方面。如果需要一个简称的话，我推荐“法式”——“法”提示了方法、准则；“式”提示了风格、样式，包含着构造/结构，它很好地点明了architecture这个概念的关键的方面，甚至有同样的来源（建筑领域）。事实上，不是我们想要将architecture“翻译”成“营造法式”，而是古汉语中本来就已经有了这个概念的词语，它与英文中的architecture具有相似的本意。（插图：宋建筑学著作《营造法式》页面，取自维基共享资源）

小结

对于复杂系统的设计与实现（包括维护/治理及演化/改变），Architecture是一个重要的概念。可以看到，对于复杂系统的营造，它是一个重要的概念，有独特的含义，并不能用其它常见的关联概念简单取代。我们归纳出了这一概念涉及的两个最基本的原理，即设计与实现关联原则、部件或构造通用原则，它们是有效地营造复杂系统的两项基本原理。

可以从以下方面理解architecture存在的重要性：

• 结合设计与建造方法与手段；
• 使复杂系统的设计与实现可靠、可控、经济；
• 为系统的维护——尤其是改造或演化提供基础，保持系统的策略或目标的连续性、一贯性。

在现代汉语中，“架构”或“体系结构”都是字面错误、误导极强的译法，古代汉语中早已有对应的概念，即“营造法式”，如需简称，我们建议采用“法式”，它比流行的翻译要好得多。

---

[1] 一种表述为“若无必要，勿增实体”，可参考维基百科奥卡姆剃刀条目。

[2] 有人刻意地颠倒使用“构架”，也许是想以此避免“架构”的强烈误导，但我认为这没什么两样。