商业流程(BP)与信息技术（IT）之间的一致性是很多组织关心的内容，因为它直接影响到组织对于商业变化的灵活应变性。在今天，一致性的要求是由“系统架构”来实现的，它将商业和IT技术整合到一起。这篇文章的重点就是说明商业和IT技术之间的一致性是如何用企业架构中的组件来实现的。
本页内容
介绍
企业架构框架
从整合角度定义企业架构组件
整合方法推理
尾言
参考资料
介绍
商业流程(BP)与信息技术（IT）之间的一致性是很多组织关心的内容，因为它直接影响到组织对于商业变化的灵活应变性。在今天，一致性的要求是由“系统架构”来实现的，它将商业和IT技术整合到一起。
现在有很多种企业架构框架，它们着眼于不同的方面。每一种企业架构框架都有自己的概念、组件以及组件抽象方法。但是，当一致性是主要关心的问题时，我们可能应该考虑用一种尽可能简单的框架，因为确保一致性才是目的。
这篇文章的重点就是说明商业和IT技术之间的一致性是如何用企业架构中的组件来实现的。
在下一部分中，将会简单得介绍三种最为流行的企业架构框架，分别是：Zachman框架, Capgemini的集成架构框架和微软企业架构。
然后会略过每种框架的特殊之处，介绍它们的一些共同概念和属性。我们将考虑一个企业架构的四种基本组件：商业架构、信息架构、应用架构和技术架构。
最后，我们会讲述怎样从基本组件上将商业和IT技术整合在一起。我们将根据架构组件来陈列一般的推理和一些正在进行的工作。我们不会重点讲述技术架构，主要是因为技术上的整合依赖于技术本身。
企业架构框架
Zachman 框架
Zachman框架为企业提出了一种用来组织描述型数据及为其分类的逻辑架构。它包括六个维度（如图1所示），可对它们从不同角度来分析；行表示这些角度，列表示对应的维度。
这个框架的架构是针对不同的用户计划、设计、建造、维修一个企业的信息系统来设计的。
- 范围（从用户角度来讲）：计划者关心的是组织的战略方面的问题，因此选择了相关的环境和范围。
- 企业模型（从拥有着角度来讲）：拥有者对组织的商业方面感兴趣，怎样传输怎么使用等。
- 系统模型（从设计者的角度来讲）：设计者关心的是确保组织的系统能满足业主的需求。
- 技术模型（从建造者角度来讲）：建造者关心的是用来支持系统的方法和组织的营业如何。
- 详细描述（从转包商德角度来讲）：将被转让给第三方时关于系统组件的规格描述。
行代表组织使用者的各个角度，列关注的是各个维的情况。
- 数据（什么？）：列的每个单元都表示组织的信息，它们应该对企业的数据和这些数据怎么被使用都有所理解。
- 功能（怎样？）：功能列中的单元描述将组织的任务转化为商业交易继而成为实现这些任务的更详细的解说。
- 网络（哪里？）：这些列针对的是组织活动和成果的地理分布以及它们如何与组织的其他方面相关的。
- 人（谁？）：这些列描述的是谁与组织的每个成果相关，即交易过程、信息和IT等。在高层次的单元中，“谁”指的是组织的单位，而在低层次中指的是系统使用者和用户名字。
- 时间（何时？）：这些列描述的是在每一方面中组织的成果与时间的关系。
- 动机（为什么？）：这些列针对的是每一行中的目标向更低行中的行为和目的转换。
图 1 ： Zachman 框架， ©
John A. Zachman International
图 2 ：集成架构框架
Capgemini 的集成架构框架
Capgemini 提出的分析、改进企业和工程层次架构的方法被称之为集成架构框架（IAF）（如图2所示[AM04]）
IAF将整个问题分解成一系列相关的问题，包括：交易（涉及到的人和过程），信息（包括知识），信息系统和技术基础，还有另外两个特殊问题是对前面所说问题都有涉及的管理和安全方面。对这些问题的分析被分为四个层次：环境的、概念的、逻辑的和物理的。
环境层次显示的是组织的所有成果，并且描述了环境上下文。它和Zachman的计划者方面很相似。
概念层次描述了要求是什么和解决问题的方法是什么。逻辑层次描述的是这些要求和解决方法怎样来满足；物理层次描述解决方法的工具是什么。
这些层次架构和Zachman的观点没有直接联系，因为在IAF中，交易活动、信息、信息系统和技术基础都是架构的工具，而在Zachman框架中，这些却作为一个个层次。
微软企业架构
微软企业架构（如图3所示）是一个两维的框架。它涉及到4个基本的方面（商业、应用、信息和技术）和4个不同层次的细节（概念、逻辑、物理和执行）。
商业方面描述一个交易怎样运作。它包括一些将组织从现处状态带入一个光明未来的决策和计划。
图 3 ：微软企业架构层次
图 4 ：将商业和 IT 技术的整合分解成架构组件
应用层次以应用为中心，定义了企业应用的范围。它还可能陈述交叉组织的服务、信息和功能，不同技术和工作功能的使用者团结起来以达到共同的商业目的。
信息层次描述了组织为了运营商业活动需要知道些什么。还有数据是怎样绑定到商业活动的，包括架构存储型数据如数据库和非架构存储型数据如文件、电子数据表和在整个组织中都存在的一些陈述型的数据。
技术层次提供了一些逻辑的基础和支持应用和信息层次所不需得系统组件，这些卖主不必担心。它是执行商业任务所需要的一系列技术标准和服务。
以上这些方面都有一个概念层次、逻辑层次和物理层次。物理层次同样也有应用层次。微软企业架构的详细描述可见网页http://msdn.microsoft.com/architecture/
enterprise/
来将微软的企业框架和Zachman的框架作一个对应：微软的商业层次相当于Zachman的计划者和拥有者层次；引用层次相当于设计者层次；技术层次相当于建造者和转包商；信息层测相当于Zachman框架中的数据列。
从整合角度定义企业架构组件
正如我们从前面几节中所见的，不同的企业框架有不同的方法来模拟企业成果和描述它们所存在的角度和层次。
企业框架描述了很多的问题，因此它比仅仅实现商业和IT技术的整合这一单一目的要复杂得多。因此我们可以简化这些模型、仅仅考虑一些有共同点的子架构，全面地研究和修正企业架构框架中的这些概念已超出了本文讨论的范围。如果将整合作为主要目的，一个企业架构有四个基本组件：商业架构、信息架构、应用架构和技术架构。这并不是新提出来的，这个观点已经被企业架构公共组织接受了（参考www.eacommunity.com）。
我们将陈述基于这四种架构组件的整合的相关问题。架构所拥有的组件越多，整合就越复杂，因为有更多的规则和推理需要考虑和管理。因此为了完成整合，首先要弄清楚的是各个架构的组件。
至于技术架构的整合，主要取决于技术本身。我们正在研究面向服务概念怎样去与以前的架构交叠，怎样来实现在模型中整合的形式化的问题。这是在研究的问题超出了本文讨论的范围。
商业架构
商业架构是定义商业决策、步骤和功能要求的结果。它是规定信息系统要求的基础，通常包括以下内容：企业高层次的目标；企业整个或至少是重要的商业运作步骤、商业功能的实现；主要组织的架构和这些内容之间的联系等。
在此文中，我们考虑一个简单的情况，即商业架构仅包括商业活动过程。每个商业活动过程由一系列商业活动组成，而每个商业活动又与信息、时间和人相关联。商业活动过程具有危急性、安全性、有延时性、在线性等一些属性。
信息架构
正如在商业架构中所讲述的，信息架构描述组织为了运营商业活动需要知道些什么。它提供除了IT数据库以外的商业信息。在信息架构中，商业信息以信息实体的形式组织着，它们每一个对于管理和执行诸如查询、分类、质量控制、显示、分布、评定等操作，都有着各自的责任。
信息实体必须都有一个从商业角度定义的标识符、一组描述和一系列属性。属性和使用或制造它们的商业活动过程、创建、阅读、更新和删除它们的应用程序都相关，它们的分类根据的是不同的性质，如安全性、可用性等。
比如：客户和雇员都是典型的信息实体。雇员有“所修课程”、“能力”、“意外事故”、“职位”等属性。这些属性都可以由一个复杂的数据库模式来提供物理支持，这个数据库模式可被用于不同的数据库中，被一些不同的应用程序来使用。
应用架构描述了为达到以下两个目标所需的一些应用程序:
- 支持商业要求
- 支持对信息实体的有效管理
应用架构通常源于对商业和信息架构的分析。
应用架构通常包括：对支持商业活动的自动化服务描述；对组织应用系统的交互和接口的描述；对开发新应用程序、以达到企业目的而需进行的对旧的应用程序的修正和相关技术平台的描述；
应用程序也有必需的属性，如可用性、可扩展性和基于固定模式的可访问性。
整合和架构组件
在定义了主要的架构组件之后，我们将要讲述这些组件和它们之间整合的关系。
商业和应用之间的整合
如果商业和应用架构高度整合，那么工作人员所花的时间和所付出的努力都仅仅用在值得的功能上；反之，在以下这些事情上工作人员将会消耗额外的工作：
- 多次在不同的应用中插入相同的数据
- 每次为了一个应用，都必须登录一次
- 从多系统的失败操作中恢复，恢复到正常的状态需要细心的人工分析
- 需克服不方便的应用功能。如因为没有多份打印的接口而只能一张张打印发票。
- 注意：上文中商业和应用架构的整合并不是指一个灵活的IT架构，事实上，对灵活的IT架构的度量是人们为了在商业活动变化的情况下仍保持商业和应用架构整合的结果。下面将要讨论这一主题。
信息和应用的整合
在信息和应用高度整合的架构中，IT工作者仅仅在商业功能和逻辑的编程上花费时间和精力。反之，IT工作者必须为以下事情做一些额外的编程工作：
- 因为被多个应用程序更新，需对同样的数据保留复制多份。
- 需保证多交易操作的一致性，因为单个商业活动涉及到多个应用程序。
- 从多系统中收集信息，为了保持组织商业信息一致性而编写规则。
- 当数据在应用程序之间迁移时需转换数据架构
在更改这两种架构是额外的代码始终是必须的，但是运行信息架构的关键信息比支持应用架构的应用程序要稳定得多，所以实际上大部分精力都花在应用程序的更改上。
商业和信息架构的整合
当商人拥用运营商业活动所必需的信息时，信息和商业架构就整合在一起了。这些信息是指准确的，足够详细的和及时的信息。不像以前的不协调架构，这里关键不是时间或是努力，而是得到足够多的与商业相关的信息。
例子有很多：一个执行总裁想得到一份销售额按服务类型分类的报告。假设总裁想得到的这份报告或者是目前的商业，或者是将来的商业，能或不能完成这样一份报告分别是信息和商业架构整合或不整合的证据。为了完成这份报告我们必须有足够多的基本数据和数据挖掘的应用程序，因此这件事应该由前面的整合（信息和应用以及商业和应用的整合）处理。
整合方法推理
我们提出整合的推理作为一组公认的规则，对我们为完成商业、信息和应用架构的整合而找一条捷径很有帮助.
这份关于商业、信息和应用架构整合的推理是我们经验的结晶，包括在大学的教学生涯、专业的顾问服务等。我们认为在综述中给出简述和结果应该更有价值。
在商业和应用架构的整合过程中主要推理是：
- 每个商业活动都应该被最少的应用程序支持。这简化了应用程序的用户接口，减少了应用程序整合的需要，同时也在商业活动变化时最小化了所需修正的应用程序的数目。
- 商业行为应该由单个应用程序支持。这减少了应用程序间的分布式处理的需要。
- 关键的商业活动应该由具有可扩展性和高可用性的应用程序支持。
- 关键的商业活动或行为应该比非关键的活动或行为更应该由不同的应用程序支持。这将保持关键硬件和持久的维修组能足够小。
- 每个应用程序的功能都应该支持至少一个商业活动或行为。否则，它将在商业中没有作用。
- 关键活动所必需的信息也需由具有可扩展性和高度可用性的系统支持。
- 在线所需的商业活动应有运行在不同基层组织上的应用程序支持，更能适应操作系统的转变。
在应用和信息架构的整合过程中主要推理是：
- 一个信息实体仅由一个应用程序管理，即实体需由同一个程序定义、创建和再生。
- 当标识符被分配时信息实体便产生了，即使他们还并没有已知的属性。例如：客户端的信息实体可能就在他的名字、地址和其他属性已知前就已经被创造了。同时，管理客户端信息实体的应用程序业必须是管理他们ID的应用程序。
- 管理信息实体的应用程序应该使用已同意的协议和格式来提供使实体信息在组织间分配的方法。
- 应用程序应该利用“数据存储”而不是一个点对点的应用程序来在组织间导出和分配信息实体。应用程序在管理一个信息实体时，如果它的内容改变了则应改把它的内容导出到数据存储处。应用程序请求一个信息实体时应该查询数据存储处以更新信息。这些规定有利于应用程序间的相互独立，而且有可能在不知道从此应用程序请求信息的其他应用程序的速度的情况下来指定HW的大小。更深入的，如果此应用程序损坏了，其他的程序还是可以在可能的数据上操作。
不管什么时候，应用程序应该管理在同一个安全层次上管理信息实体。这将简化在安全策略下的控制和程序的执行。最后，在商业和信息架构的整合过程中主要推理是：
- 所有商业活动或行为都至少创建、更新或删除一个信息实体。
- 所有信息实体的属性都至少被一个商业活动或行为使用。
- 所有信息实体都需有一个能被工作人员理解的标识符。
- 所有信息实体都须有一种能用企业标准应用程序和工具来呈现给适当观众的方法。
- 所有信息实体都须来自已知来源，而且须有对其一致性、准确性、诚恳读和质量保证的商业责任。
- 所有信息实体都必须在信息架构中分类和命名。
- 对于每个信息实体，工作人员都须为信息的可用性、利益以及维持他的后继价值负责任。
尾言
以上推理在实际项目中经过了验证。在某些情况下，不同的方法提出相反的建议，这意味着我们必须寻求一个复杂的解决方法。在其他情况下，这些方法并不提供工程意义上的最优解，因为最优解通常不会考虑灵活性和可变动性。
如上所述这些推理是为了验证架构间整合的，但是假设了每个架构自身是很好的整合在一起的。我们并不理会假设成立与否，如对于商业架构，我们就认为它具有一个好的一致的商业运行模式。同样，我们也不追究应用架构是否有意义。这样需要更复杂的模型，如开始所讲述的那些框架（Zachman、IAF和微软架构框架）。
如上所述的工作是用Zachman框架作为常用方法来开发的，但是强调的重点在整合方面。我们已经用模型工具（PopLin软件中的System
Architect）编程实现了如上所述的大部分推理，同时我们也衍生出一种评价商业、应用和信息架构之间整合程度的测量方法。这些方法已经开始放入Microsoft
Visio中了。
我们认为这些推理是有价值的，因为它们迫使建筑师们去思考是否应对他们所作的决定进行修正以建造更好的、更牢固的架构。
参考资料
[AM04] Andrew Macaulay, Enterprise Architecture
Design and the Integrated Architecture Framework, JOURNAL1:
Microsoft Architects Journal, Issue 1, January 2004.
| 
返回页首