Enterprise Engineering Forum

企业工程论坛
Categorized as: 企业架构(建构学),系统架构   Tagged as: ,, , , , ,

Architecture(架构/体系结构)与营造法式:一个简单的理解

Author: 余彤鹰,  Source: 企业工程论坛,  Published: 2011-01-18

Excerpt: 本文主要以软件、企业工程为背景,讨论了architecture这一概念的独特性和理解的基本要点,并提出有效地营造复杂系统的两项基本原理:设计与实现关联原则、部件或构造通用原则。这是理解architecture这一概念独特性与重要性的关键。在现代汉语中,用“架构”或“体系结构”对应architecture是字面错误、误导极强的译法。古汉语建筑领域,早已有同样的概念,即“营造法式”,如需简称,推荐采用“法式”。它与英文的architecture具有相似的本意。

引言

yingzaofashi-1

营造法式卷三十一插图

在企业应用(信息系统或软件)和企业工程领域,”越来越常见,但这个词的使用也常常显暧昧或矛盾。在多数情况下,我们会尽量使用其它简明而常见的词语,例如:涉及系统本身有“结构、构造、组成”(structure, construct, component)或“结构框架”(structural framework)、“结构类型”(structure type),以及系统的“类型、分类”(type, catagory)等,涉及建构/实现有“方法、过程、程序、方法学”(method/approache, process, procedure, methodology),涉及系统描述或规定有“建模、模型、参考模型、元模型”(modeling, model, reference model, metamodel),还有系统的“规划”(plan),“设计”(design), “工程”(engineering),等等。这些,加上些诸如“结构规范/标准”、“设计规范/标准”、“实施规范/标准”、“参考模型/框架”等等,似乎足以说明关于某种复杂人造系统的各种事情。那么,为什么我们需要“”这个词?它为什么愈发流行?我们是否可以用奥卡姆剃刀[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],恰恰是非常“不靠谱”的译法。它是最不好的那种翻译:没有找到对应词语,选择了一个与原概念既不等而又部分相关的词语来指代,这样最容易造成误导和混淆。理解了上述要点,就容易体会到为什么这样说——它们的字面意思都是错误的。

yingzaofashi-2

南宋绍定重刊绍兴十五年平江府刊本《

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

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

小结

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

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

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

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


[1] 一种表述为“若无必要,勿增实体”,可参考维基百科奥卡姆剃刀条目。
[2] 有人刻意地颠倒使用“构架”,也许是想以此避免“架构”的强烈误导,但我认为这没什么两样。

Copyright

  本发布物版权归原作者所有,经原作者许可在企业工程论坛(EE-Forum.org)公开发布,并允许个人及公益性机构非牟利性使用及传播。传播中需保持从标题、署名到各项内容及此声明包括链接地址等完整内容不变。引用或摘编文中内容或观点应符合公认准则。其它机构,或牟利性使用,请预先取得作者许可。保留一切未说明的权利。
  详细说明见: http://www.ee-forum.org/about/copyright ,管理者电子邮箱:admin(at)ee-forum(.)org

Cite Style

GB7714 style: 余彤鹰. Architecture(架构/体系结构)与营造法式:一个简单的理解[EB/OL]. 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2011-01-p2398.html, 2011-01-18[2017-09-24 10:06]

Chicago style: 余彤鹰, "Architecture(架构/体系结构)与营造法式:一个简单的理解", 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2011-01-p2398.html(accessed 2017-09-24 10:06)

Posted by   2011-01-18(Original)   Hits 20032   Modified 2011-01-23(Locked)
Prev Post: 
Next Post: 

Related Entries:

企业工程之屋0.92版
阅读札记:以简单的架构应对复杂的企业
简·迪茨的企业工程研究
企业工程的内容与企业架构的定位
阅读札记:OMG的业务架构概念与策略

14 Comments

  1. “我们归纳出了这一概念涉及的两个最基本的原理,即设计与实现关联原则、部件或构造通用原则,它们是有效地营造复杂系统的两项基本原理。”
    ==================================
    又一次感受到余兄对于用词的细微考究。
    “营造法式”这个词我还是因为迷恋才女林徽音和梁思成的事迹第一次接触到。

    我对余兄上述的细微之处可能还是认识不足,其思想大概还是停留在被批判之列。
    我从“构造表达”角度来理解问题,构造首先要确定部件(相当硬件)和构造方法(相当于软件),然后通过软硬件的构造来实现我们要表达的对象。比如,对于一级汉字库,一共3000个汉字,我们可以采用全拼,双拼,五笔,自然码等不同的编码方案来输入汉字,他们的硬件基元不同,构造方法也不同,但是都能完成一级汉字库的表达。可以说他们的结果是一样的,但是结果的体系结构是不一样的。我以为构造方法(就是软硬件的划分方法)自然就决定了他们成果物的体系结构,即设计与实现关联原则。我把这个动态的构造与静态的成果体系结构看作是必然联系,比关联意义要强。从这个观点理解architecture,构造的法式与构造结果的体系结构就是一样的了。所以,第一条原则和第二条原则就大致是一样的了。

    • 软件领域使用arcitecture,在相当多的场合都把重点放在了结构、构成上。那么,为何不直接使用structure, construction,包括framework等等,而要architecture?

      简单地说,可以表现为一个知识体的某种architecture,不能单单讨论某些具体的结构,而更注重结构的类型(风格),和结构的“要点”,还有这些结构/构造(要素)之间的搭配/选择原则,以及实际实施的方法。(例如你举例的肖先生的文章,主要讨论了构成要素,那么并非完整意义上的architecture的讨论)。

      又如,中国古建筑体现出一些显著的风格,这不仅仅是静态的外形和结构,还关联/包含着从材料到施工的完整的方法体系。它们是不可分割的,所以,architecture的概念才是必要的,否则我们就老是要拖着类似于“结构体系/风格和其设计、实现方法体系“这样的复杂句子来指称这个概念。

      • 软件领域使用arcitecture,在相当多的场合都把重点放在了结构、构成上。那么,为何不直接使用structure, construction,包括framework等等,而要architecture?
        ====================================
        我的理解(猜测)是:structure, construction是表达客观结构吧,比如物质结构(分子结构),而framework、architecture表达的是人为结构,它就与构造方法(或者称为解析方法)有关了。比如句子分析可以有许多方法,比如主谓宾定状补,还有中心成分分析法,短语分析法等等,它们都能达成对一个句子的分解组合。同一个句子对于不同的分析方法而言,它表现为不同的结构形式。这个例子与一级汉字库的例子的意思是相同的。这里的结构(架构)没有客观性,具有人为性,这大概也是字头 ar前缀具有人造的含义吧。
        虽然架构有许多方法,我完全同意当选定了一种架构以后,它就是一种特定的结构了。

        • 看来余山的讨论偏重“解析”的角度。
          这个概念本身就是建构——营造的立场提出的,“人造”是不言而喻的基本前提。
          从建构的角度看,architecture不会完全决定最终结构,但特定的architecture包含某种结构风格或结构的“框架”,其程度深浅可以很不同。

    • 我可能不完全理解你在这个例子背后的思想。如果建构方法确实“决定”了最终的构造,(这会令两个法则同效吗?)但这是少数情况。

      对architecture/营造法式这个概念,是从另一种不同角度理解的,即主要从“缩小设计与建造的自由度(可能性)”角度理解。即,承认可以有无限的结构和实现方法的选择,但一种架构,是在这个无限空间内划出的一个小小子集(我本来准备画出这个插图的,后来免了,打算再另一篇里抛出这个图)。它是一个“多维”的概念,最重要的两个维度,就是静态(目标系统)的结构维和实现方法维。

    • 今天看新浪正好有一篇文章:“一百年前的领导干部”http://blog.sina.com.cn/s/blog_48b0d37b01017fn8.html?tj=1
      现摘录一段,作为“营造法式”一词的背景:

      看草姐姐的纪录片才知道,梁思成与林徽因的一生,与一个人关系巨大。
      1928年,他们选了3月21日结婚,选这个日子,因为是宋代建筑大匠李诫墓碑上刻上的日期。 惭愧,我只知鲁班,不知李诫。
      李诫的书《营造法式》是梁思成的父亲梁启超寄给他们的,信中写“此一千年前有此杰作,可为吾族文化之光宠也。己朱桂辛校印莆竣赠我,此本遂以寄思成徽因俾永宝之”。
      这本书影响梁林终身。
      他俩回国后加入“营造学社”,梁是“法式部”主任,一大任务是研究此书。他们的儿子叫“梁从诫”,意思是“师从李诫”的意思,这两个字里有极深的寄望。粱从诫后来差两分没考上清华的建筑系,当时他父亲是系主任,“不置一词”。梁从诫晚年时说起这事,脸上仍是羞惭“(我)没出息”。可见《营造法式》在这两个人心里的重量。
      象我这样对建筑无所知,对梁林往事只知八卦,模模糊糊猜—–营造学社?这是清华大学或者东北大学的吧? 看纪录片才知道,这一研究完全是个私人机构。
      创办人就是梁启超信中说的赠书者“朱桂辛”—–朱启钤。

      朱启钤,………,但路过南京时,在藏书家陶湘那里淘到《营造法式》,这才见到最为完备的中国古代建筑的记载。 中国古代汉语中,一切土木工程都叫“营造”,这书是中国法典式的建筑手册。 写书的李诫生在北宋,北宋的建筑正是颠峰。李诫的纪录“上可以溯秦汉,下可以视近代”,象一个剖面,能看到什么是进化。什么是退步。什么为固有,什么是输入。建筑是一个国家文化史的演进,“移身换形,跃然可见”。

  2. 如何评价这些编码方案的优劣,就是对“构造”法式的元评价,对于编码方案应该是编码长度尽量短(比如双拼是两个键组合成一个字,拼音码平均是4到5个键组合成一个字)重码率低(五笔重码率低,拼音重码率高)输入速度快(构件容易识别,比如五笔不容易识别,编码方案容易记忆,比如拼音对于说普通话的人容易记忆等),那么这些准则是否也应该属于architecture呢?

    • 当然,可以总结一些每种可能的方法都“可以有”或“必须有”的基本元素、一些选择、设计和实现的准则等等,它们自然就是“汉字编码方案的营造”的“法式”了。

  3. 还是回到软件开发的例子来讲。
    比如,这个网站上肖建国先生的“面向服务体系架构(SOA)和业务组件(BC)的思考系统”,就是一个关于架构的好例子。它是关于基于面向服务体系架构(Service Oriented Architecture,SOA)下,如何实现组件化开发的构造法式的讨论。

    其中给出的主要构件是:
    系统(每个企业只有一个系统)、应用(比如人力、财务等)、业务组件(BC)、模块和SCA组件(粗粒度服务)。

    肖先生同时还给出了评价组件粒度的元指标:
    业务组件粒度太小,造成组件数量多,组件之间交互多,管理困难,性能低下;业务组件粒度粗,功能复杂,功能之间关系紧密,升级困难(可以独立升级往往会作为确定一个业务组件范围的重要因素),很难实现重用。因此找到一个合适的业务组件粒度是很重要的事情。
    找到合适的构件,如同前面所说的汉字编码方案一样,也就是Architecture的主要任务。

    这种组件化的开发区别于传统的系统开发。传统开发是概要设计、详细设计、编码、测试阶段等等。而组件化开发则是尽量利用重用服务在搭积木。虽然它们最后完成的功能可能一样,但是其功能的构成结构则是完全不同的。

  4. 理解的要点,正是在于这些要素的关联——而其中的关键,是系统的结构或结构特征、风格与其规划设计、建造、改造或演化方法之间的关系。更明确地说,复杂的系统的设计(指结果)与设计、建造方法与手段之间具有密切的关系。在涉及具体系统建造(实现)的语境中,单纯地讨论复杂系统的结构、结构特征通常是不切实际的,我们必须知道它们能否实现、怎样实现,甚至包括是否能够有效地维持其运作及根据需要作出改变。同时实现(及维护治理与改变)的手段、方法本身也制约着设计者对于结构或风格等的选择。

    ~~太精辟了。这几年我也看过不少有关的文章,但对于体系结构概念,特别是与系统结构或框架的区别等一直有困惑,看到这里有豁然开朗的感觉。余老师在这里的解释是最透彻的,谢谢您的分享!

  5. 讲得很到位,特别关于这个概念必须的这一点,现在对企业架构的解释有很多,很多也是一人一个样,不少都与规划和蓝图还有设计等等难以区分

Trackbacks

  1. Understanding Architecture | THINK IN MODELS

Leave a Response

You must be logged in to post a comment.