Enterprise Engineering Forum

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

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

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

Excerpt: 从信息工程与信息系统架构切入,简单回顾了过往的一些人和它们的架构框架的发展,分析了由信息系统架构到企业架构这一跨越性转变的必然性和内在原因,综合提出了在过往的研究中形成的一些基本观点,以及在这些认识基础上,可以进一步探讨或开发的课题。

引言

(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部分

Copyright

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

Cite Style

GB7714 style: 余彤鹰. 信息工程与信息系统架构向企业架构的发展[EB/OL]. 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2010-01-p898.html, 2010-01-21[2017-04-24 03:41]

Chicago style: 余彤鹰, "信息工程与信息系统架构向企业架构的发展", 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2010-01-p898.html(accessed 2017-04-24 03:41)

Posted by   2010-01-21(Original)   Hits 9457   Modified 2010-01-25(Locked)
Prev Post: 
Next Post: 

Related Entries:

企业工程浮出水面的时候到了吗?
一个模型驱动企业应用平台架构方案框架
IT语境中企业图景的局限性与片面性
企业应用与信息系统架构及模型驱动系统MDS(一)
信息技术对企业工程的双重作用

4 Comments

  1. 太好了,先收藏了。
    老余这里讲的一步步的认识过程也几乎就是我这些年的思想过程。
    当然,我是在读过和受益老余的许多文章之后仍然经历的思想历程。
    可见,从IT跨越到企业框架是多么难。
    老余在这里的表述非常清楚,非常到位。
    企业工程直接关注是企业本身的运行描述,它本应该属于企业管理的一个基础论题,却偏偏没有适用的语言和方法,这是管理学的一大遗憾,看来应该由我们这些搞企业模型的人来填补了。

  2. 文章不错,呵呵

  3. 今天又读了余彤鹰的文章“信息工程与信息系统架构向企业架构的发展”,十分感慨。从信息模型到企业架构,它与企业模型还有些区分,这里借助文章写作,先着重说一下企业模型不是什么。
    文章做法是超越语言的,汉语与英语写作是一个道理。所以文章做法不是关于语言的,或者说无论是用汇编语言、还是C语言,第四代语言、UML语言都可以完成文章写作任务。
    所以,DFD数据流程图,XML可扩展语言等,它们也都只是模型表达语言,不要把它混同于模型本身。
    SOA是类似成语典故,在文章中引用成语典故固然可以事半功倍,这也是初中生作文愿意玩的花样,但是同样无法能保证文章就漂亮。
    它不是写作工具的,虽然工具好坏决定了写作的快慢,但是文章的好坏可不能决定。用钢笔写不出的文章,很难设想用WORD就能写出好文章。
    各种技术平台从这个意义上讲也是工具,它提供了建构模型的快速方法,但同样还不是企业建模。所以不要与系统的实现技术手段相混淆:从这个意义上讲,SOA、工作流软件等都是实现模型的工具。至于更物理层面的技术开发架构,比如NET、J2EE就更不是企业模型了。
    它不是文章构成要素的罗列,文章是由词句、自然段、细节、情节到主题构成的,有人物、场景、背景和故事,但是这种罗列区分仅仅是开始,好文章不会从这种罗列自然产生的。
    所以,在企业架构分析中,这种太泛的如5W1H之类的分析,还有什么企业信息的几个维度:职能业务维度、信息加工深度、组织部门维度的分解组合罗列,它们还不足以成为如何作文的理论。它也不仅仅是所谓视角,相反它却要回答为什么要有这些视角,它们之间的逻辑关系是什么,不同视角的表现为什么它们是不矛盾的。罗列这些因素不是企业模型的核心问题,回答它们之间的逻辑关系才是最重要的。
    从这个意义上讲,BPM流程管理也只是企业模型的一个因素。它并不能说明你的模型就达到了完备性。

    • 文章这个比喻很好,现在多数的讨论还围绕着语言、纸笔,离“写文章”本身还有很大距离。在软件开发领域,建模方面发展得更充分,但同样还面对很多初级的问题。例如,许多研究和关注要点,还是放在语言的开发上。领域专用语言DSL成了热门概念——似乎每种特定问题都应当建立一门语言——却不见有人对此提出怀疑。

Leave a Response

You must be logged in to post a comment.