Enterprise Engineering Forum

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

Zachman企业架构框架若干分析

Author: 余彤鹰,  Source: 企业工程论坛,  Published: 2010-02-19

Excerpt: 关于“Zachman企业架构框架”(The Zachman Framework For Enterprise Architecture)的介绍很多,本文在前一篇基本介绍的基础上,尽量从不同的立场做了一些分析,内容包括:对象与内容、是什么、知识分析的框架和组织的框架、基本的分析-叙述要素都有哪些、作为本体、ZF与企业工程、框架的实现与信息系统(IT应用)的关系等。

1   对象与内容

北京:鸟巢,复杂的建筑(取自维基共享资源)

Zachman本人和提倡者都十分强调其企业架构框架的“基本性”,并指出这个分类体系实际可以用于任何事物。在他的网站上,除了企业框架,现在还推出了产品框架等另外三种框架。然而,也有一种基本的观念:适用于任何事情就等于没有用途。所以,我们还是集中在特定的话题,企业架构(

对于“企业架构框架”这个名称,仍然有被其分类的对象(内容)是什么的问题。以“建筑”来比拟,对于一幢实际的建筑,例如鸟巢,会有大量的工程资料,其中,一部分直接描绘了这个建筑本身,而数量上更多的资料,是关于如何施工、如何管理、维护它的。哪些是建筑本身,哪些是对建筑的描绘(蓝图),哪些是实现建筑的过程的规划,是很清楚的。而企业的情形则不同。几乎所有企业架构框架的应用,都是针对已经存在的企业,“企业工程”的过程与企业的“运作管理”过程完全是交织的(在大部分企业实践和传统管理学中,基本上不会去考虑这种区分),对资料以及角色——组织与人也同样如此。企业工程与运作管理的“经纬之别”,并不是那么显而易见、自然存在的。

2   是什么

正如Zachman本人所强调,ZF是一个分类框架:由“疑问词”(观察或焦点)和“具体化标志”(由一般到具体的几种典型认知水平,另一种类型的观察视角)两个“维度”构成的正交表,是组织关于企业的知识的二维分类矩阵。在实际应用中,ZF大部分的格子里,所装的都将是关于某个特定企业的描述:书面叙述、各式的模型。

Zachman框架虽然可以“容纳”各种企业模型,即将所有的企业模型组成部分或字模型“放进”框架的某个特定的单元格,但它不是关于企业本身的“企业模型框架”(framework for enterprise model),正如其现在的完整名称,“企业架构框架”(The Framework For Enterprise Architecture),其中的架构(architecture)一词是不应省略的。

虽然他强调,这个框架是一个结构而不是关于企业的具体建构实现过程,不是方法学,但其纵轴(列)的“具体化”层次的展开,自然地对应着企业工程(建构或改造)的基本步骤,与ZF应用关联的,合适的方法学,将不能无视或背离这一点。

3   知识分析的框架和组织的框架

首先我强调,“分析知识的框架”和“组织知识的框架”是两个不同的概念。我们从小就学习过记叙文的基本要素,包含时间、地点、人物、事件等等基本要素,但文章(内容)的组织结构是千变万化的,很少有文章会按照这些基本要素来决定内容的组织结构。然而,在所见有关Zachman框架的基本信息中,并没有明确强调这一点,反而显示出把它作为组织知识的框架推荐的倾向。

我认为,Zachman框架首先是一种分析的框架,当然它“可以作为”组织、归拢分析结果的框架来用。越是从普遍性、根本性角度看,这种区分越是重要和明显:它的根本性、经典性或不可忽略的方面(这是提倡者努力强调的),在作为“分析框架”时,更明显和有说服力;而作为“组织框架”,则未必如此。

例如,许多重要框架,比如FEAF或TOGAF,都与ZF有某种继承关系,但它们的内容都不是按照ZF组织的。理解了以上的区别,才能更好地理解实际框架的这种发展和选择。

Zachman还喜欢将其框架与元素周期表比较,说明它的根本性、必然性。但我们也可借这个比较得出其它的理解。化学元素是可以被单独提取出来、真实的存在的物质类型,是宏观物质的构成要素,基于化学元素的分解、合成,基本上是与观察者无关的,可重复的。对于Zachman框架,如前面分析所指出的,它的根本性主要体现在分析的方式,分析的要点或着眼点方面,它本身基本不反映企业特有的一般性结构(或者说只反映了很少的方面,例如把Who解释为组织等)。它划分的36种基本单元,只有严格限制在分析文档(或模型)的分类时,基于人工的理解,才能说是相对独立的。即使不针对企业本身,而是对企业的“描述”,它们也不具备化学元素那样的客观独立性和严格、可不断精确复现的特性。它不仅是一种分析的框架,其内容划分的方式,也是与观察者的立场有关的分析与描述原则,而不是组织、构成的原则。这层理解对于正确地运用是重要的。

4   基本的分析-叙述要素都有哪些

从分析的角度,Zachman框架是很基本的,但是否就已经是“完备”的?对此也不是没有质疑。5W1H的确是很基本的要素。还记得小学语文老师教的“记叙文”的基本要素,包括时间、地点、人物等,似乎还有更多的要素,但到底是事件、过程还有结果、原因?细究却会发现,许多答案是相似的,但并没有绝对标准的答案。

同样,对于企业架构,5W1H是一些非常基本的问题或着眼点,这应该没有什么疑问,但是否足够?具体含义或内容是什么?实际上很难有标准答案。例如,Graeme Simsion关于Zachman框架的质疑(2005)中就提出了这个问题[1],并指出可以增加第六、第七列:how many, how mach (volume, financial)。无疑,你可以认为,how many就可以被概括在其它列中,例如What,其中包含着数量,也可以包括金钱。但在许多场合,人也是一种“what”。既然What可以包含how many, how mach, 同样可以把when都包含到与之相关的事物中,而无需单独分解出来。另一方面,对这些疑问词本身如何解释(或展开),同样可以见仁见智。例如When,在Zachman不同阶段的框架版本中,其诠释就有所不同。而在如此基本的要素上,理解稍有不同,在实际应用中就可能有巨大差异。再回顾与元素周期表比较,可以体会到它们的差距是非常巨大的。

上述例子只说明,5W1H的确很基本,但其基本性、完备性并非绝对,按照这种方式刻板地分解、组织关于企业或企业架构的知识,并非我们唯一的选择,也很难证明这总是最佳的选择。

5   作为本体

Zachman指出ZF是一种本体(ontonlogy)。我个人认为,Zachman框架的确可以看作一种本体,但从应用意义上看,其所包含的信息量非常少——因为它太“一般化”了。另一方面,作为一个本体框架,我们可以看到,如果比这36种关注焦点再进一步,ZF本身几乎没有提供任何反应了某种企业特有(而不是“事物”特有)的要素或基础结构。

个人以为,在应用“本体”或本体工程的立场上去考察,它是一种非常弱的本体。从具体操作的角度看,如果要作为某种企业或企业架构的本体使用,还需要补充很多内容,而这些需要补充的内容,仍然可能是相当通用的(即可能需要或适于作为本体的一部分提供的)。

6   ZF与企业工程

我一直强调目前流行的“架构”(architecture)一词常常显得暧昧和误导(英文中也有这个问题,但流行的中文翻译则更显偏颇),我宁愿使用企业工程、企业模型与建模、企业工程规划、建模方法、实现方法等直接、明确的概念,在这样构造的概念集合中,并不一定需要“架构”(architecture)这个概念[2],但现实是,后者历史地,流行了。无论用语如何,企业架构(EA)与企业工程都是相当密切(或相当重合)的概念。

如其从信息系统框架转向企业框架的基本解释:要上升到整个企业范围上的工程(to be “engineered” enterprise-wide)立场上。这种站在企业整体视角,针对企业中“可工程化”的事情的立场,正是我们提出企业工程的基本立场。(所谓工程化,可理解为有明确的规划、方法学、以及对其背后的知识与技术的系统开发、整理、传授)。

现有的企业架构框架也就是企业工程的一种参考框架。如果将Zachman企业架构框架比作一个货架,那么,这个货架上摆放的,并非企业的零件,而是企业零件的设计文档、模型。如果从企业工程立场看,再增添或明确一些东西(比如,关于企业工程的过程框架、企业生命周期、相关的方法学等),就构成完整的企业工程的框架。

这并非我的牵强。Zachman在许多场合,也喜欢使用Enterprise Engineering这一词组。它与企业工程的关系,在Zachman的基本著作标题里也清楚地指明了:“Zachman企业架构框架:企业工程与建造的入门读物”(The Zachman Framework For Enterprise Architecture: Primer for Enterprise Engineering and Manufacturing)。

7   框架的实现与信息系统(IT应用)的关系

Zachman早已将框架的目标范围扩展到了整个企业,并强调它与信息系统/IT架构的区别。我们也可以用这个框架去为企业的其他技术基础设施建模:例如,在第一列“什么”(What),去定义流水线范围、类型,在第二行用执行/管理者的语言去描述它(概念设计)……第四行定义工程蓝图(零件图、装配图),第五行定义配置方案……但仔细对照Zachman框架标准对各单元格的界定,也许应该承认,目前这个框架的基本用法,不是这个样子(我相信大多数人也不会这样去用)——“适当的”用法大致会是,在第二行定义了流水线的信息模型(例如,相当于ERP中的工作中心),第三行就是所定义的不同类型的工作重心的数据模型,第四行的所谓“蓝图”,不会是机电设备的工程蓝图,而是在电脑上实际记录流水线(作为“信息实体”)的数据物理模型……第六行的所谓实现,就是具体完成的某个软件(或其部分)。

换言之,对应已经完成的具体“框架”(即,按照框架的36个单元完成了对应的文档或建模),其最直接的“实现”,就是信息系统的实现,或者说,是支持所定义的所有综合性业务、业务资源的IT基础设施的实现。当然,企业框架对于IT的这种“亲和性”,并不能简单归结于“人择”结果。

8   小结

Zachman企业架构框架是一种分析框架,包括了一些最基本的分析要点或关注点、视角,它也是关于企业架构的一种简单本体(通用概念及语义)。它是一个分类调查表,是展开分析,并组织分析所得到结果的一种基本结构。它不是一种企业模型框架,并没有包含多少比“普通事物”更多的“企业”独有的构成要素或结构特征。

虽然它的关注范围是整个企业,但从应用和实现的角度看,它至少是更适合于IT应用领域。它可以用于这样的场景:在清晰地界定企业战略的前提下,清晰、完整地描述企业(业务及资源等),作为“输入”,与企业(业务)IT应用与IT治理的良好地对接(这是随企业发展的持续、动态的过程)。从企业工程立场上看,它是一种初步的、基础性的框架,可以作为完整企业工程框架的基础部分或基础工具。

注释

[1] Simsion (2005) 主要提出了三个方面的质疑,其一是5W1H六个疑问词是否最合适或唯一的选择,指出在法语中how many, how mach也是基本的疑问单词而非复合词。其二是对“建筑”这个隐喻的质疑,指出具有自适应演化特征的“城市”是比建筑更贴切的隐喻。其三涉及Zachman框架是否一种信息系统建构性方法的基本选择,是否有足够的证据或使用效果的评估。他的讨论主要站在信息系统建构方法的角度。
[2] 这里主要是从基本的知识或研究、技术、实践领域划分或构造的角度上看。也许有人会说,存在的就是有道理的。我认为从实践的角度看,一个较为狭义的architecture概念更有操作意义,这个狭义,若偏重实践与技术方面,可以引用中国古代文化中的“营造法式”;偏重知识的方面,“建构学”或许更清楚明了。参见《谈谈企业架构(EA)》、《企业工程的内容与企业架构的定位》等文的讨论。

Copyright

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

Cite Style

GB7714 style: 余彤鹰. Zachman企业架构框架若干分析[EB/OL]. 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2010-02-p1198.html, 2010-02-19[2017-03-28 07:51]

Chicago style: 余彤鹰, "Zachman企业架构框架若干分析", 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2010-02-p1198.html(accessed 2017-03-28 07:51)

Posted by   2010-02-19(Original)   Hits 10956   Modified 2010-02-20(Locked)
Prev Post: 
Next Post: 

Related Entries:

CIAO!将在2011年召开初次企业工程研讨会
企业工程的四项愿景
谈谈企业架构(EA)
企业工程浮出水面的时候到了吗?
欧洲的企业工程研究组织CIAO!

2 Comments

  1. 在实际的应用中,Zachman的操作性并不强。

    就治理角度而言,TOGAF这个在目前大型企业中是主流的。去年,我参与国内某银行的总体架构咨询,100多个已上线系统的治理,纷繁复杂,TOGAF的处理更有优势。

    如果是在白纸上全新规划,对于大型复杂应用,那么DODAF更好。当然,小型应用,就无所谓那个方法论了:)

Leave a Response

You must be logged in to post a comment.