信息工程与信息系统架构向企业架构的发展

作者：余彤鹰， 来源：企业工程论坛 ， 发表时间：2010-01-21

引言

信息工程（information engineering）这个词，现在即便不算销声匿迹，也早已式微了。但这个思路里有一些东西，是不应或不会被丢弃的，它们实际上已经发展壮大了。如果 把视野放宽一些，我们首先可以留意的，就是信息系统架构（框架）这个话题，再进一步，就直接联系到当今正在升温之中的企业架构话题。这是一个很好的思考切 入点。从这里出发整理一下思路，有助于我们理解一些今天企业应用领域的发展趋势，以及找到有意义的、有价值的发展课题与切入点。

对信息工程与信息系统架构发展的一点回顾

在几年前，与欧阳余山、林星等，就相关话题有过一个粗略的讨论^[1] ，我曾提出这样的观点：信息工程没有真正解决信息结构与最终面向用户的应用软件之间的关系问题，我的答案就是模型驱动，以及信息工程走向企业工程。这是比较笼统的表达，是我个人思考的阶段性结论。这中间有大段“文章”。

信息工程这个概念，是1980年代初，由James Martin与Clive Finkelstein提出的^[2] ，他们二人被并称为“信息工程之父”。追踪此二人的思路，对理解信息工程的发展应当有直接的帮助。

Finkelstein在2001年曾论述“企业信息架构”（Enterprise Information Architecture），其中，也运用了企业架构的概念，并包括一个企业架构框架（Enterprise Architecture Framework），这是一个二维矩阵，水平方向将要素划分为环境、数据、过程、基础构造；垂直方向将要素划分为业务规划、业务需求、业务模型、系统设 计、信息系统。这个框架的用途，就是要将企业的战略规划、业务规则、绩效度量等，落实（或者说连接）到对信息的精确需求上，最终落实到数据模型上。稍微比 较一下就知道，这和Zachman框架的初期发展，大有异曲同工之处。在1990年代的一些资料中，Finkelstein还倡导过另一个概念，称为 BPE（Business Process Engineering）^[3] 。

James Martin在信息工程之后，发展了CASE（computer-aided software engineering），还有RAD（rapid application development），二者都比较侧重于系统开发的方法学及其技术支撑与工具实现。另一方面，进入1990年代，他同样关注、结合了BPR的思想，并 在90年中期出版了企业工程的专著^[4] 。

前面提到了Zachman的工作，正如他自己所总结的，是在信息系统开发实践与研究中提出的，最初就是信息系统架构框架，在经过10年的实践、发 展，蜕变成为企业架构框架，并且从认识上发现，有必要摆脱最初的、强烈的信息技术烙印，首先把它作为企业的问题，而不是IT的问题来讨论^[5] 。

相关领域上还有一个重要的例子是ARIS。也许现在许多人见到这个符号，首先想到的是建模与分析的软件产品，甚至一种商业符号，但我们在这里要关注 的是，它首先是一个企业信息系统架构方面的研究结果，正如ARIS这个名字的含义，所谓“集成信息系统架构”。它的提出和发展者，德国的Scheer教 授，不仅提出和发展了信息系统建模框架，同样发展了相应方法学，他提倡的一个重要的概念，就是业务工程（business enginieering）。以前企业工程论坛上，曾将企业工程的思路与对此做过一个对照^[6] 。可以看到一些资料中笼统地把ARIA列入企业架构或建模的各种体系中讨论，这即有“误解”，也有道理。这里不谈ARIS符号后面的软件，只谈建模与分析的方法学。ARIS的不断充实发展，以及它应用的趋势，同样体现了由信息系统框架向企业/业务框架演变的规律。

分析

上述例子，展现了计算机应用，由最初的数据处理（DP）发展到信息系统层面之后，人们开始从信息系统规划的角度，认识变化的企业环境所带来的问题， 从最初着眼于数据输入输出和计算，进而变为完整的信息规划、对信息表达方式的规划，再进一步，就要从方法学、表示法、内容的基础要素和关系、规律角度，全 方位地认识和掌控。架构（architecture）也就油然而生。以实质性需求分析与研究（ERAR）^[7] 的观点，这是需求分析深入的必然结果，在这个层次上，需求分析活动的重要特征，就是寻找隐藏在变化的企业信息需求表象背后的模式或规律，框架，就是典型的结果。

然而，即使上升到搜集、归纳信息模式的层面，有了精良的搜集（包括交流）、建模、维护的方法学，仍然不够。例如，信息工程揭示的基本规律之一，是信息结构的相对稳定性^[8] 。 但即使从这个基础上看，不同企业、不同时间最重要的变化，并非纯粹的信息表达模式或结构标准，而是企业/业务本身的模式或结构，这些东西既体现在信息的数 据结构上，也体现在数据/信息之中，并且可能不在预先确定的结构中。面对这样的动态、多样的企业实际情形，停留在信息需求层面，即使很好地控制着获取与表 达的过程与模式，仍然是被动、应付的。到这里，一个重要的认识就浮出来了：对“需求信息”的有效规划或者说掌控，本质上就是企业/业务规划本身。换言之， 要想使信息系统需求真正与企业需求动态衔接 ，必须直接结合、参与到企业/业务本身的规划和设计和表达中去。这就是从“信息系统架构框架”转换到“企业架构框架”的内在原因。

注意，由作为“需求”的信息表达、信息内容，到企业/业务本身的表达，是认识上的一个跨越——其实，无论信息系统或IT应用是否存在，企业/业务本 身的表达问题、表达形式问题，都是可以独立存在的独立课题，只是在没有涉及信息系统应用时，人们没有那么在意——尤其是在表达的形式、规范上，包括获取过 程上的方法学。跨进这个门槛，由信息架构框架的研究，变成企业/业务架构框架的研究，事情的性质已经发生了变化，再展开，自然就是企业/业务工程了。

这种认识的跨越，看清楚了，就像捅破一层窗纸，但局中人却往往很难摆脱旧的立场。这就是为什么，我忽然对Dorian Pyle业务建模的认识论大为感叹^[9] 的 原因。前一节，我回顾了一些实际发生的，有代表性的例子，在那种实际发展背景下，无论是技术性地看其用语习惯，还是实质性地分析其认识框架、侧重点，都不 可避免地带有强烈的信息技术烙印。在这些思路发展的集大成的工作，汇集在TOGAF中，也不可避免地体现出我所指出的，IT语境中企业图景的局限性与片面性 问题。我看到，有人意识到了这一点，但更多的人对此缺乏感觉，或者是不以为然。

这是我们看到部分现实：从信息技术（信息系统或应用系统）立场一步步“提升”发展到企业架构的层面。但这种IT语境中的“企业/业务规划”，与传统 的（假设为无计算机环境下、纯粹管理/业务立场的）企业规划相比，至少有两个基本的不同：首先，它的出发点是信息/数据需求，因此，始终保持着可操作的、 精密的记录方式，常常是计算机可直接处理的；另一方面，也就意味着实质保持着与计算机应用实现之间的紧密耦合^[10] 。其二，由于认知框架所带来的限制，这种所谓的“企业/业务框架”是局限的，从真正企业经营管理者或业务人员立场看，是先天不足的。这种局限既会体现在建模语言、术语或表示法的层面，也会体现在内容和方法上，例如关注点与取舍的问题、对企业/业务的理解问题等等。

最近SOA联盟发布了一份技术白皮书^[11] ，这是在一群企业架构的提出与实践者的讨论基础上提出的，其中特别强调了业务架 构（business architecture）概念。在比较宏观的层面上，我们可以将此理解为对企业架构内容的一种充实。尽管他们强调“业务架构必须要从业务设计人员和业务 所有者的视角反映整体业务设计，而不是从IT解决方案交付的视角”，并且建议“将业务架构作为业务专家用于评估并实现业务设计及变更的正式的实践、信息和 工具”，但它的基本出发点或企图，仍然是为IT解决方案提供输入，取得IT系统与业务的一致（这是个别扭的流行的词语：align），“帮助企业清晰地定 义技术要求和功能”——这是个关键的叙述，由此我判断他们对某些关键点仍然缺乏意识。如果保持这样的思维模式，就将很难摆脱我前面所说的桎梏。

此外，从实际情况看，业界把更多的注意力放在了业务和流程上。我始终认为，完整意义的企业是包含业务于其中的，虽然在实际的工作中，我们大部分时间 面对的 是具体的“业务”问题。同时，从建模角度，企业建模的原理和业务建模范围和内容不同，但背后的基本道理一样的。按照当今的基本认识，人们基本上把有关“过 程”的事情，都放在了业务的话题中，使得业务建模，几乎就是流程建模的同义语，这里是隐含着问题的。总体说，我的基本观点是，企业建模就应该包括静态要 素、动态要素（过程）等等，是全方位的。

我的思考，虽然也是从企业应用系统如何适应多样与变化的企业需求开始，但很早就认定企业建模的独立性和模型驱动的必要性^[12] 。 明了模型驱动机制之后，就从更深入的层面上厘清了企业建模（包括业务建模）的定位、形式要求、独立性乃至对IT支持与实现方式的要求、相关的人的角色等各 个方面。这样，就可以安心地把企业建模的内容问题（所谓企业架构框架的核心内容之一，就是企业模型的框架）、企业建模与应用系统建模的关系、模型的表达与 模型的实现问题、模型的使用（最终企业用户的使用、应用系统规划或实现者的使用等）、应用系统的实现（技术架构与实现技术）等，分开来考虑，而不担心它们 会冲突或失配^[13] 。在这样充分解构的基础上的再构建，会给我们带来全新的图景。

总结

在这篇文章中，通过对信息工程与信息系统架构（框架）到企业架构（框架）一些具体人物/事例的回顾，引出他们背后一种共同的发展轨迹，就是从数据/信息模型，上升到信息（系统）架构框架，再跃迁到企业架构框架。在此基础上，做了进一步的分析，主要提出了以下观点：

• 从信息系统架构到企业架构，是一种实质性的跨越。跨入新的门槛后展开，自然会打开企业/业务工程的空间。
• 对“需求信息”的有效规划或者说掌控，本质上就是企业/业务规划本身。要使信息系统的需求真正与企业需求动态衔接 ，必须直接结合、参与到企业/业务本身的规划设计和表达中去。这是从“信息系统架构框架”转换到“企业架构框架”的内在原因。
• 从信息技术立场提升发展的IT语境中的“企业/业务规划”，一方面保持了记录的精确性以及与IT实现的紧密耦合，一方面是局限的、先天不足的。
• 在认清企业建模的独立性、必要性和模型驱动机制这些前提后，我们可以更清楚地认识企业/业务建模、模型的表达与模型的使用、企业模型与应用系统模型、模型与应用系统、相关的人员角色等要素，并分而治之，不担心其失配。在充分解构的基础上的再构建，会给我们带来全新的图景。
• 在前面的一些分析和讨论中，还体现了我提出的“实质性需求分析与研究”（ERAR）的一些精神。从数据与信息的建模，到信息架构框架，再到企业架 构框架，就是ERAR中所揭示的，从需求分析的第一层的客观描述与记录向第二层，模式归纳与发现的跃迁。而关于“模型驱动是一种功能性需求”，乃至模型驱 动机制的认识，则体现了第三层模式分析与创新的特征，以及在ERAR中所揭示的，对于需求产生、变化的规律性的认识。

在这些讨论的基础上，我们就可以将进一步接触更实质的问题，例如：

• 在整个的问题领域（企业信息技术应用或信息化）上，应该分解出哪些关键要素或相对独立的领域（例如前面提到的《新一代企业信息系统研究与开发纲要 》，还有《企业工程之屋 》，都是这种认识的体现，这里许多深入的、操作性的工作要做。
• 与上述问题相关的生命周期（各种模型、应用系统等）的问题、角色分工问题等。
• 在澄清与IT的关系的前提下，以及在模型驱动机制的基础上研究企业/业务模型的表示法（包括语言等）问题。例如，在BPM领域围绕BPMN的许多争论，我们可以将在这样立场下得出新的、建设性的观点。
• 企业模型的内容问题，也就是纯粹的、完整意义的企业表达问题。我在这样的背景和基础上，研究了“一般企业建模框架”。
• 企业/业务模型与系统模型的区别与关系问题。多年前，曾经看到国内实践者提出了这个问题，我曾特别予以强调^[14] 。这背后隐藏着丰富精彩的内容。
• 企业/业务模型的工作机制问题，如许多人关心的，模型驱动机制，到底怎样驱动的问题。例如热点领域BPM中的许多问题，实际上可归结于此。
• 应用系统的技术架构问题。如果从纯粹、完整的企业架构本身去要求应用系统的技术架构，将是什么情况？这与目前IT界的“主流”思路恰恰相反。
• 数据库的地位问题，与面向对象的关系问题。这是在IT领域迄今有许多争论的问题。如果我们首先基于对实质性需求的认识（其中就包括需求模式、需求规律的认识）之上，先建立应用架构，再寻找合适的技术，将是一种什么情景？
• 联系到当前的热点，就是SOA与EA，还有BPM与此二者，特别是与完整意义的综合企业应用系统的关系问题。
• 等等。

对于上述课题，我们都已经在过去的研究中形成了自己的立场或答案。也许有人觉得，这篇文章分析的对象，大多是古老过时的。除了企业架构，似乎与当今 的主流技术或应用模式无关，例如相对成熟的应用概念ERP、CRM、PLM之类， 新一些的BPM、SasS、网络协同、社会化应用、Web x.x 或 Enterprise x.x等，又或者开发与技术层面的DDD、RUP、敏捷，还有SOA、MDA、云计算，甚至更具体的J2EE、ORM、Hibernate、Entity Framework等等——对这些东西，我保持着适度的关注，并将它们摆在框架里适当的位置，与这个讨论有关的，不是一些表面化、容易看到的东西，而且也 不适合笼统、泛泛地讨论。我们首先要做的，是将它们分得清清楚楚，厘清企业应用的实质性的需求与规律性的东西，再由应用架构决定技术架构。具体的实现技 术，将是最后的选择。

注释

[注1] 探讨一下信息资源管理（IRM）与信息工程（IE）

[注2] 可参考维基百科上的相关内容

[注3] 这里我参考了几年前从他所在企业网站上面看到的一些资料。企业工程论坛部分早期追踪情况参见《企业工程发展追踪 》

[注4] 参见《显现中的企业工程 》及其它对企业工程 的讨论

[注5] 参见《谈谈企业架构（EA） 》等文。严格说，“信息系统架构”和“信息架构”是不同的，基于本文的讨论层次，没有特别去区分这一点

[注6] 参见《业务工程和企业工程 》

[注7] 参见《实质性需求分析与研究（ERAR） 》

[注8] 在[注1]的讨论我曾经指出，相对稳定里的那一点变化，仍然足以使建立在这个基础上的应用软件崩溃。用习惯的说法，只要数据模型和功能软件高度耦合，那么 就无法容忍运行期的数据结构变化。这个问题，我的基本答案已经给出了。现在某些“主流”技术，并没解决这个问题，相反某些方面甚至加剧了，这是以后可以展 开讨论的话题。

[注9] 见《IT语境中企业图景的局限性与片面性 》 中的讨论，几年前我就读了他的书。但最近重读，结合这些年的感悟，才真正体会到他所强调的，在先的认识框架（观念）对于分析与建模，结果的决定性影响，是 多么现实和沉重。在这里引申一点，就是既有的技术、认识、风格，对于新技术、认识的限制。在三界之外看来似乎就是一层窗纸，却常常像一张看不见的犀牛皮， 坚韧无比。

[注10] 这是很现实、也很必然的。但是它同时也就是桎梏，固化了一些根本的问题，掩蔽和阻碍了新的可能性。这是将来需要讨论的另一要点。

[注11] 参见《业务驱动的SOA 》，本站“网络书签”栏推荐了这个链接。

[注12] 注意，这与IT界的模型驱动架构（MDA）的出发点完全不同，虽然原理都可以归纳到我提出的模型驱动机制 （MDM）。我观察到，模型驱动架构MDA提出10年了，仍然很少有人，把“模型驱动”看作企业应用的一种功能性的实质性需求，或者真正理解与重视这一点。IT“主流”从一开始，就着眼于代码重用、系统集成及互操作性，迄今也没有实质变化。

[注13] 在这些方面的一个具体展开，可参看《新一代企业信息系统研究与开发纲要 》，这几年，在许多方面都有深入或新的收获，但这个基本框架并没有多少实质的变化。这个展开的价值并不是表面上的问题方面的罗列，而是内在的系统思想。

[注14] 见《企业建模的目的、范围及“模型驱动系统”（MDS） 》，认识超越的关键点——怎样一览众山小 TY 2005-06-05部分

版权声明

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

 

（转贴来源：http://www.ee-forum.org/pub/ty/2010-01-p898.html）