建设SOA需从企业架构开始

建设SOA需从企业架构开始

企业总体架构（EA）是对企业多角度的一种描述，并综合反映企业中的人、流程以及技术，为企业中的不同参与者提供不同的视图，并用他们易于理解的方式和语言反映企业的状态。

然而，目前国内的现实应用情况是，很多企业都是随着业务的发展设立并开发很多分割的部门、流程和系统，而它们之间却无法进行有机的合作，并且还会经常出现信息与业务报告不准、部门之间无法衔接等问题。更可怕的是，企业没有方法和工具来解决这些问题。

根据国际和国内的经验，通过企业总体架构的方法可以解决上述这些问题。目前，国内对企业架构设计的使用还主要集中 在IT层面，业务人员还没有开始利用这类工具进行业务的设计和规划。其实，企业总体架构是一个涵盖业务、IT的全面企业蓝图设计工具，可以帮助企业的管理 者了解企业的构成，发现问题并不断改进。

事实上，架构设计经过漫长的演变到现在，已经成为现实生活中必不可少的工作。比如，要建一栋房子，就需要进行很多 的架构设计工作，首先要进行外部架构的效果设计，在客户满意之后进一步设计内部结构，并进行相配套的包括线路和上下水等多方面的设计。这就好比我们谈到的 企业架构设计一样，是从不同的层次和角度去描述一个企业的特征。

项目建设和施工没有架构图就开始进行是很不可思议的一件事情，但是在企业内部管理方面，却完全是另外一番景象。很 多公司虽然运转了一段时间，但是一直没有明确的企业架构和蓝图，或者说并不是很清晰，从而导致了很多运营中的问题，比如部门之间的职责界定不清晰、配合不 顺畅; 运营的效率较低，很难提高客户满意度; 流程改进的效果不明显; 业务部门与IT部门之间的关系紧张、系统问题比较多等。如果这些问题在企业中非常突出，那么，企业就应该考虑总体架构的方法，因为企业总体架构能够帮助企 业有效地解决这些问题。

谈到企业总体架构设计，我们首先要澄清几个概念: 框架、方法论以及方案等，企业只有深刻理解了这些概念，才能建立有效的企业总体架构。

首先，框架（framework）定义了解决一个问题的相关因素以及它们之间的关联关系，并描述了这些关联因素是如何设计的。在实际应用中，框架会结合不同的方法论和方案来解决问题。一般，一个好的框架会支持多种方法论和方案，比如SOA框架、Zachman框架、DoDF框架等都是解决问题的框架。框架涉及的范围一般都比较广，但又都不是很具体，只是起指导作用，因此在具体实施的时候，可以采取不同的路径。

其次，方法论（methodology/method）是由一系列相关的流程、任务和活动组成，也是如何达到一个 特定目标的理论。一般包括谁（who）、做什么（what）、地点（where）、何时（when）和为什么（why）等要素。很多时候也会包括一些标 准、政策、规则等方面的内容，比如IT规划方法论、系统开发方法论以及CMM方法论等。

最后，方案（approach）则是面对一个具体的问题，如何去解决它，比如有全面质量管理（TQM）、流程再造（BPR）等。

在企业的信息化建设中，需要用方法论定义什么是获得成功必备的系统。方法论是指如何从现有的状态通过一系列的项目建设达到目标的状态; 而方法则是指企业如何开发和改造各个系统。

现在，企业架构设计在国内的应用还并不广泛，也没有明确的定义，不同的公司和专家有相近但却又不同的看法，还并没 能形成一种相对统一的认知。比如，有人认为，企业架构是定义企业各组成部分是如何构架的及它们之间的关系、它们设计和演变的原则和规定; 也有人认为，企业架构是企业的逻辑蓝图，定义了企业的结构以及如何运转，使企业能够达到现有和未来的目标。

追本溯源，全球第一个总体架构的框架理论是由John Zachman在1987年创立的。到今天，这个架构还是最被企业和组织所接受的理论，国际上通称之为Zachman总体架构框架。

的确，尽管在IT业界有几种比较流行的总体架构框架理论，比如TOGAF、DoDF等，但Zachman总体架构 框架被公认为是最为完善的，在企业领域的应用也最广。Zachman的著作《信息系统架构框架》（Framework for Information System Architecture）直到今天也在业界普遍被认为是一个权威的框架。（如表1所示）

在Zachman架构框架中最有代表性的是6列5行、共有30个元素的矩阵图形。架构框架图形以最简单的形式描述了总体架构内的元素及其关系，说明了这些元素在设计中的功能和作用。而Zachman框架矩阵中的行是架构的层次和相关人。

第一行:规划人员（Planner）

第二行: 属主，通常是业务属主部门（Owner）

第三行:设计人员（Designer）

第四行:开发实施人员（Builder）

第五行: 厂商/承包商（Contractor）

不过，Zachman架构框架还是比较侧重在IT层面。然而，随着企业架构的不断进化，企业架构理论越来越与战略和业务相融合，图1展示了近几年来很多企业架构的层次和内容。

可以看出，图1中的企业架构由四个部分组成。

第一层: 在架构的最上层是企业的战略思想，其清晰地定义了企业的愿景和目标，描述了未来企业发展的战略方向、外部环境的影响和竞争策略，以及如何建立核心竞争力、如何衡量企业未来的业绩、是否成功达到目标等。

第二层: 中间一层是业务架构，业务架构是各个层次中最有影响力的部分，它定义了企业的业务流程以及信息系统应该如何支持业务的需求。其是将高层次的业务目标转换成了可操作的业务模型，并描述了业务应该以何种方式运作才能满足企业成功所需要的能力和灵活性。

第三层: 业务架构下面一层是信息架构，信息架构是一个广义的概念，包含了信息的定义和内容，以及与信息结合的数据的定义和内容。

第四层: 最下面一层是IT架构，IT架构包括了应用架构、技术架构和底层的基础设施等，是总体架构的最底层，也是实现企业运营的基础。

对于企业来说，企业运营模式也是非常重要的，并且，运营模式与企业架构还有着非常紧密的联系。企业的运营模式主要包括了三个方面的内容，如表2所示。

业务架构（EBA）

业务架构定义了企业是如何创造价值以及企业内外部的协作关系，描述了企业如何满足客户的需求、进行市场竞争、与合作伙伴合作、建立运营以及培养员工等信息。

可以说，业务架构建立了企业战略与日常运营之间的关联关系，通过运营对战略的支持，才能达到企业建立的业务目标。 同时，业务架构也是通过战略影响其他一系列企业组成的工具，因为十分宏观的战略需要通过业务结构进行分解，从战略范畴转化到战术范畴。比如，从降低运营成 本20%的战略措施，到提供网络自助服务、裁减客户服务人员40%等。事实上，IT、组织、流程等都是由业务架构进一步推导出来的，如果没有业务架构而直 接进行企业细节的设计，就会出现与战略不一致的问题。

信息架构

在欧美的很多企业中，数据架构与信息架构在涉及到总体架构的概念时，常常被交互使用。这里的信息架构和数据架构是一个广义的概念，包含了信息的定义和内容、与信息结合的数据的定义和内容。如果遇到某些理论中提及信息架构时，其实与这里定义的数据架构是一致的。

信息（数据）架构包括数据实体和数据的交换与流动，保证数据有效地共享和交换是企业总体架构的主要目的之一。信息架构描述了企业现在和未来是如何使用信息和数据的，主要包括信息的分类和定义、与业务模块结合的信息内容和信息流、数据的采集、存储、转换、发布和传输、企业的数据库设计和使用、数据标准和格式，以及数据字典、数据管理、知识管理、数据仓库、数据集市、数据挖掘等与数据相关的应用系统等。

IT架构

IT架构包括应用架构、技术架构和基础设施。

应用架构

应用架构描述了支持企业运作的系统，比如财务系统、交易处理系统、人力资源、办公系统等。应用架构可以采用多种方式来表达，通行的架构有客户机/服务器(C/S)模式、浏览器/服务器模式（3层架构或者4层架构）等。在应用架构中有许多行业标准，比如J2EE和.NET等，它们都体现了模块化和集成化的思想。

技术架构

技术架构是定义企业IT的科技管理和技术标准，从最高层次的政策（Technology Policy）、原则(Principles)、指导纲要(Guideline)到技术领域的技术标准化（Technology Standardization）、技术选择（Technology Selections）和技术组件(Technology Components)。

可以说，制定技术标准和推广标准化是企业的两项重要任务。围绕着技术标准化，有一系列的流程与管理。技术元素包含 了一系列的总体架构技术组件，这些组件可以是一个可重复应用的系统或模块，也可以是最小的可独立在架构中使用单个技术的组件，比如一个安全软件、一个插入 的外围设备等。完整的企业标准技术架构是涉及了信息架构、应用架构和基础设施等层面的标准。

基础设施

基础设施是整个企业IT系统的基础，是包括硬件、操作系统、数据库系统、网络系统等企业数据和应用程序可以运行的环境，同时要满足企业的数据量、用户数、反应速度、在线率等要求。企业70%的IT投资都花在了建设基础设施上，对分布在企业各个部门、地区的IT资产的了解可以降低资源的浪费，并提高系统的利用率。

而基础设施标准的定义是: 一系列技术和服务的组合，提供了一个稳定的、低成本的数据和信息的采集、录入、处理和传送的物理及逻辑设施。大型企业可以根据基础设施的种类不同进行分 类，如数据中心、网络、指挥中心、服务器组等。而具体的业务应用，如财务、HR、销售、采购、研发、制造系统等为非基础设施的IT应用，它们是运行在企业基础设施之上的应用系统。

目前，被越来越广泛使用的SOA系统规划和开发方式改变了以前的旧有方法，使得IT系统变得更加灵活，并能够重复 使用。SOA模式不仅要求IT要采用组件化的开发，而且要求业务也要同时使用组件化和服务化的运营模式。图2展示了如何从业务的组件化中提出SOA的需 求，并实现IT的组件化。

在业务范畴之内，由流程/子流程能够归纳出业务组件。而业务组件可以提供一系列的服务，在提供服务的同时，也需要 使用其他组件的服务，这就是SOA业务服务化的重点。在系统范畴之内，系统组件是提供服务的单位，它提供的服务与业务的服务是一一对应的。这是在SOA框 架下，业务与IT的紧密连接之处。系统组件是由多个组件组成的，这些组件可以分成功能性组件和技术性组件，并且，系统组件组成了子系统合系统。

在实际的业务服务设计中，一般会对业务组件和业务组件内部的活动进行定义，如下图3所示。比如，在保险业务的理赔 业务中，接报案是一个业务组件，组件内部的活动有接听报案、查询信息、记录、案件分类等，接报案组件能够提供的服务在表格的右边; 接报案需要的其他业务组件提供的服务列在表格的左边。

当设计好业务服务的架构以后，能够很容易地开始SOA在IT阶段的开发; 这也从另一个角度说明，SOA的建设是需要从业务开始的。

总之，如果企业总体架构的理论和模型可以被企业管理层、CIO、规划部门、IT分析人员和开发人员理解并使用，就可以规范并提高国内IT管理和规划的水平。当然，先进的管理理念和方法的采纳及运用需要一段时间，而一旦能够得以实施，会给企业带来很大的效益。