Enterprise Engineering Forum

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

阅读札记:OMG的业务架构概念与策略

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

Excerpt: OMG当前在企业架构(EA)发展方面的一个重要战略,是强调业务架构的重要性。它们提出了2010年代的EA愿景,要大大加强业务架构,使之与技术架构均衡。业务架构和企业架构概念类似,都存在着泛化、界定不清、不一致问题,这些问题虽然可以理解,但始终应该克服。它们也都是由IT人发明,而希望成为基本的管理概念——这终归要“管理者”认账才行。发现业务架构太“弱”,这无疑是进步,但目前提出的图景,仍然有批评的余地:IT与业务的关系并非平行的,终究是服务与被服务、支持与被支持的关系。

OMG的业务架构基本愿景

商业领域风头最盛的企业架构()框架是Tho Open Group的TOGAF,它将EA划分为四个部分,即业务架构、数据架构、应用架构和技术架构。OMG是软件开发方面最具影响力的组织,她在涉及到诸如企业/业务架构的课题时,也是以TOGAF为基本背景的。OMG下的SOA Consortium有一个EA2000工作组,对EA进行专门的讨论,其中的一些观点很有代表意义。

在以前的多篇文章如《信息工程与信息系统架构向企业架构的发展》等,讨论过,当前的企业架构基本上是从信息技术(应用)架构发展而来,并且实际上仍然是一种IT人眼中的,为IT服务的东西。立场决定观点,这带来诸如IT语境中企业图景的局限性 与片面性问题。用EA2000的观点,技术架构与业务架构目前是失衡的,因此,他们提出的一个基本的策略,就是希望达成业务架构与技术架构之间的均衡,也就是要大力强调、加强业务架构的观念和实践。这是一个典型的发展愿景,如图所示。这个愿景本身是非常合理、积极的。但重要的问题,涉及到所谓“架构”概念本身,以及IT人与企业经营、管理者完全不同的立场。就我个人的立场,对此观点表示赞许的同时,仍然要提出批评:这仍然不是企业架构概念最合理的图景。IT和业务之间的真实关系,不会是这种平行、并立的关系——而终究是服务与被服务、支持与被支持的关系。即使IT在一些情况下,能够扮演变革驱动者的角色,始终无法改变这一根本。而从具体的方法学角度看,不同的立场(需求),一定会导致不同的世界观及倾向性。在《IT语境中企业图景的局限性 与片面性》一文中,就讨论了这个观点。

业务架构概念的理解

根据TOGAF9,(Business Architecture)“定义业务战略、治理、组织和关键业务流程。”,这是说它的用途。而正式的定义看起来并非更加清楚:

The business strategy, governance, organization, and key business processes information, as well as the interaction between these concepts.

不清楚在于,你使用“业务架构”这个词,究竟是指列举的这些要素,还是这些要素的描述(模型),或者这些要素相关的规律/规范,还是设计、实现、治理这些要素的过程,抑或对“设计与实现过程”本身的规划、治理?参考其“架构”(aruchvecture)正式定义:

1. A formal description of a system, or a detailed plan of the system at component level, to guide its implementation (source: ISO/IEC 42010: 2007).

2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.

是否更清楚了呢?不见得。举例而言,具体完成的业务模型(比如:业务战略文本或图示、流程模型、组织机构模型),到底是“业务架构”作为一种过程的产物,还是所谓“业务架构”的组成部分?这些疑问恰恰可以从上述正式定义中产生:从较为严格的逻辑性定义角度看来,无论作为内涵说明、外延说明或类型划分,都不是特别明确。这就是当下流行的所谓“架构”(archivecture)这个概念令我最不喜欢的地方:太泛了,既可以指知识体,又可以指方法、过程,还可以包括方法及过程产生的结果。其实,真正清楚、可操作的,只有那些更具体、狭义的概念:业务,业务的规划(设计,包括分析),规划的结果(文档、模型)、规划的方法、准则、规范、参考模型、参考框架、工具——而狭义的架构(我提议称为“营造法式”,参见《企业工程的内容与企业架构的定位》等文),正是指规划的准则、规范(包括一些方法)部分。不论架构顾问们怎么忽悠,执行者最终都得落实到上述操作性的概念上。

上面的评论,似乎有点对TOGAF大不敬。但OMG一个分支的工作组今年公布的一份资料中,也没有采用上述TOGAF9中的“正式定义”,而是另外给出了以下定义:业务架构为“业务设计的形式化表达和活动管理,进一步扩展这个定义,业务架构是为业务专家评估和实施业务设计与业务改变的规例(practices)、信息的形式化集合。”

这个定义明显比前面引述的TOGAF9定义更具逻辑性。它的基本定义部分,解决了前面提出的部分疑问——业务架构不是业务设计本身,而是业务设计的表达,以及对“业务设计”这个过程的管理。进一步的扩展,则说明了用于业务设计、业务变更过程的特定知识、方法、工具方面——这比较符合我对架构的理解(见上面说的狭义的架构)。

上述定义中,仍然留有疑问。例如:所谓的“业务设计”,究竟是指“业务设计的过程”,还是指“业务设计的结果”,抑或兼而有之?再看更多的具体叙述,在接下来,对业务设计、形式化表达概念的解释中,又明显地落到了业务设计的结果方面:“业务架构通过下列多种成果形式化表现,包括:业务动机模型、能力映射、价值链映射、流程模型、策略文档、组织机构图、产品目录。”——还是那句话,本来,过程就是过程,结果就是结果,方法就是方法,对过程的规定就是规定。业务设计的过程,使用多种建模方法、遵循规定,产生设计结果——业务模型。所谓的“架构”呢?它提供设计方法和设计准则、工具,帮助我们更好地完成业务设计。这样叙述,是否更加清楚?这不是IT人不理解,而是不感兴趣——因为他们的立场是IT,卖IT,用IT。这是很正常,问题在于他们“we strongly believe that business architecture is a business thing”(我们坚信业务架构是业务上的事)——IT人坚信是不够的,得让企业经营管理者本身坚信才成。

结语

在结束这一段讨论时,回到更为一般性的问题来。企业架构,基本上属于IT领域制造的众多概念之一;在从IT架构向企业架构扩展的时候,就明显体现出再造一个新“管理概念”的意图(从工作流到业务流程管理BPM也是这么个范),这些,最终都必须企业经营管理者“认账”才算成功。扩大和重视业务架构,使之与技术架构“均衡”,这是IT人当前的愿望。至少眼前看来,有关领域(包括企业架构、业务流程管理),还是一派外行谈管理的景象——一些地道的IT专家,在大谈管理的理念与方法的问题,在强调“那不是技术问题,而是业务与管理本身的问题”。过去20多年,IT作为催化剂、战略改造工具,为管理变革提供了新思路、新思维、新观点,业务流程再造工程(BPR)是其中的代表。新观念由旧“体制”外的人——IT人提出,很符合革命、创新的一般规律。然而,如果历经了20年后,仍然是体系外的人奢谈体系内的事情,这里是不是存在问题呢?EA、BPM等看来似乎都有点这样的苗头。发现业务架构太“弱”,这无疑是进步,但目前提出的图景,仍然有批评的余地:IT与业务的关系并非平行的,终究是服务与被服务、支持与被支持的关系。

这一篇文字,具体针对于“业务架构”,但讨论到的一些基本问题,放在“企业架构”这个概念上也同样适用。文中提到的概念界定不清和泛化使用,不仅仅是某些“主流专家”认识不清。这正是热衷于制造、炒作概念的IT业和傍着IT生存的咨询行业的典型风格,也可以将它看作一种生意的策略或模式。这种问题,虽然自有其来由,可以理解,但始终属于应该克服的范围。对于研究和实践者而言,应该明察。

 

参考:

EA2010 Work Group, The Missing Link between Business Strategy and Enterprise Architecture, OMG’s SOA Consortium, Jan 2010, http://www.soa-consortium.org/EA2010_Business_Architecture.pdf

(修订:2016-08-02

Copyright

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

Cite Style

GB7714 style: 余彤鹰. 阅读札记:OMG的业务架构概念与策略[EB/OL]. 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2010-05-p1441.html, 2010-05-24[2017-09-24 09:46]

Chicago style: 余彤鹰, "阅读札记:OMG的业务架构概念与策略", 企业工程论坛, http://www.ee-forum.org/wp/pub/ty/2010-05-p1441.html(accessed 2017-09-24 09:46)

Posted by   2010-05-24(原发)   Hits 9542   Modified 2010-11-16(Locked)
Prev Post: 
Next Post: 

Related Entries:

企业工程浮出水面的时候到了吗?
阅读札记:以简单的架构应对复杂的企业
简·迪茨的企业工程研究
过程与流程到底有什么区别?
信息技术对企业工程的双重作用

4 Comments

  1. 一个比喻是:汉字输入法。键盘的基元规定(比如五笔和双拼)和组合出汉字的方法。这个架构的工作结果则是6千多个常用汉字。
    我在《表达》中研究了构造表达,其中软件和硬件的选择就是架构,达到两者的最佳平衡,就是架构要完成的任务,也是表达要完成的任务。
    从构件与构造方法这个意义上讲,它与语义框架非常接近,它与制定企业模型的表达语言也非常接近。

  2. 就我个人的立场,对此观点表示赞许的同时,仍然要提出批评:这仍然不是企业架构概念最合理的图景。IT和业务之间的真实关系,不会是这种平行、并立的关系——而终究是服务与被服务、支持与被支持的关系。
    =================================================
    就像建筑图纸的效果图,它与建筑工程力学的关系。
    建筑家给出的图纸不是施工图,是要达到的效果图。建筑土木力学是为它服务的。
    现在把企业模型看成是施工图,包括我们目前所做的规划,是总体设计,归根到底是为实施应用系统服务的。这个关系正好被颠倒了。
    企业模型并不是施工图,它的任务就是把企业业务本身说明白,而这正是企业工程的目标。相反,它是应用系统实施的最终目标,应用系统要想方设法实现它。

    • 我喜欢采用更一般化的理解,即“企业模型”是泛指,它可以包括总图、结构图或效果图等等,甚至到某种层次的“零件图”。比如关于应用系统的某种模型,可以看作是一种“低层次”的零(部)件图。不过,这种类比也有我非常不喜欢的一面,虽然这在“正统”中甚至还很流行:它会引入强烈的机械还原论思维。

Leave a Response

You must be logged in to post a comment.