介绍了Cap Gemini Ernst & Young的集成结构框架和一个企业结构的模型，它有助于软件工程师们理解与何将业务当作一个整体来看待。

本页内容

• 企业结构在上下文中
• Cap Gemini Ernst & Young的集成化结构框架
• 交流和结构管理
• 连接结构和设计
• 总结
• 深入阅读
  　

企业结构在上下文中

在过去的几年里，随着软件和系统工程的逐渐成熟，越来越需要用一种结构的观点来看待整个系统。这种需要源于整个系统和系统在业务之间的交互变得越来越复杂。而且对于降低IT投入，带来可靠效益的压力也不断加大，这些都需要我们更加深入的了解系统如何才能支持业务。

系统（业务和IT系统）的结构化观点在ANSI/IEEE1471-2000标准中是这样定义的：“它是一个系统的基本组织，包含在它的各个组件里，这些组件之间的关系里，系统所处的环境中，以及指导它的设计和发展的原则中。”如同在建筑设计中有不同级别的结构（城市设计、地区设计以及建筑物设计）一样，对于业务和IT结构，也非常有必要将它们分为不同层次：

企业结构它在整个企业（包括合作者和相关的组织）范围内定义了系统（业务和IT）的整体形式和功能，为项目级别的结构提供一个框架，一套标准和指导。着眼企业结构有助于开发一个在整个企业范围内都协调适用得系统，可以随时随地的支持业务间的合作与整合。

项目级别的结构它为一个项目中的系统（业务和IT）定义了形式和功能，但它不能使系统脱离企业结构而孤立存在。项目级别的结构是企业结构的一个精简版本，必须符合企业结构，在企业机构中发挥作用。

应用结构它定义了用来实现系统功能的应用的形式和功能。有一些应用结构需要定义在企业和项目级别结构的内部（作为标准和指导）来优化性能并保证整个结构的一致性。

传统的应对业务变化的方法是用自顶向下的方法，从人力和业务流程两个方面调整业务。但是，传统的软件和系统工程关注的却是如何实现特定功能使一项任务可以自动被完成。至于变更后的系统如何与其它系统交互，如何与其它业务合作以实现更大的效益，就更被忽视了。结果，高级业务结构与用来支持它的系统之间总是存在距离（换句话说，业务与IT之间的一致性很差）。

要消除这个差距，很多组织都利用企业结构，从整体的角度定义系统（手动的和自动的）要如何支持业务。一个有效的企业结构可以涵盖一个业务各个方面，包括它的驱动者、发展前景、策略、实现策略的组织和服务以及用来实现这些服务的信息、系统和技术。（见图1）

图 1 业务和系统的一致

定义一个企业结构是很复杂的，因为它必须包含整个企业内部的所有系统。为了简化企业结构的定义，通常把一个业务或系统看作是一系列的相互作用的组件（或者服务），而忽略各个组件之间的具体设计设计细节。

组件和它们之间的内部联系都必须根据它们实现的服务以及这些服务的特点，比如安全、测度、性能、集成性等来划分。这样划分出来的组件可以依据服务特点、分布性、功能以及其他业务驱动的方面来进行分组。

虽然理想情况下，系统结构应该使用自顶向下的方法进行设计，但是很多组织受财力所限，只能放弃这种无法在短期内带来可靠回报的策略，让企业结构服从某一启用的大型项目。一旦时机合适，还是有很多机会去对它进行改进，体现企业结构的指导价值的。

Cap Gemini Ernst & Young的集成化结构框架

在过去的十年间，Cap Gemini Ernst & Young开发了一种对企业和项目级别结构进行分析和发展的方法，称为集成化结构框架（IAF）。这个方法现在已经出了第三个版本。它是基于工程师Cap Gemini Ernst 和Young的多年实践经验并结合理论基础形成的。在全球范围内，IAF已经被成功的应用于很多工程中。

IAF将一个问题分解成很多相关的部分，包括业务（人和流程）、信息（包括知识）、信息系统以及底层技术，然后使用两个专门的部分解决上述所有部分的管理和安全问题。每个部分都可以被分成四种层次的抽象：上下文环境、概念、逻辑和物理，如图2所示。

图 2. 集成结构框架

这种多层抽象的方法使得这个框架可以被应用在很多不同的情况下。这种灵活性将传统的流程化带来的影响降至最低，并且确保了各个部分的一致性。比如说，一个使用IAF的工程结构，在很多情况下，只需要充分利用业务和信息部分就可以为整个工程提供上下文环境。一个企业结构可能只关注上下文环境，概念和逻辑层次上的事情。

上下文环境层次将业务和其他驱动、策略以及它们的优先级统一到一个规则集合里。这个综合的声明集在各种策略决定上发挥作用，为那些业务驱动和策略等提供查询依据，展现出业务系统的一致性。

虽然这项工作的很大一部分都仅仅是数据的收集，但是却不能忽视它的重要性。它将为整个结构设计提供基础。

概念层在上下文环境层中定义的规则的支持下更加详细的描述服务以及各个服务之间的关系。由于概念层是面向服务的（也就是说他不设计任何特定的产品和服务），除非业务本身发生根本性变动，比如改变范围和目标，它都将保持稳定。这为逻辑结构的生成奠定了稳固的基础。

这个层次上的关键决定包括：

• 在业务的那些部分使用IT进行支持？
• 使用哪种整体的业务结构？
• 系统如何反映组织或业务结构的意图？局部系统如何用一组核心应用来实现出来并且保证一个完整的服务内局部系统之间的灵活性。

逻辑层对服务和组件之间的整合和合作合同进行了清晰的定义。由于它依然保持与产品的独立性，这个结构层是相对稳定的。它可以反映自顶向下的变化，比如新的业务模型，和自底向上的变化，比如说技术可行性或者技术实现上的基本变化。通过它，可以清楚地看到业务部分和技术部分的变化。

这一层的关键决定包括：

• 逻辑组件如何被分组？
• 逻辑组件怎么在系统范围内被共享？
• 如何使用一个中央集成转换器支持各种业务系统？或者说通讯工具如何和数据库应用一起支持虚拟的团队？

一般来说，在逻辑层存在不止一种的解决方案（反映出了驱动的种类多样，比如说价值、灵活性、安全和管理能力）。在这一层的关键决定就是选择出一种解决方案可以在实现业务需要的同时，最好的反应指导原则。

物理层进一步说明了设计原则、标准和指导，包括关键部分中组件的分组以及应用模型。它为详细的设计提供了框架，也为需要开发和购买的产品提供了选择标准。

就是在这一层。框架解决方案和结构比如说微软系统结构（MSA）才能被用来加速物理结构的开发，改进结构的质量并、减低工程风险。

这一层的关键决定：

• 那些物理组件需要被加入到解决方案中？
• 这个解决方中还需要那些组件，以及开发这些组件的标准、指导（比如说语言、工具等）？
• 底层设备的标准和详细的挑选标准是什么？可能有很多候选的供应商和产品。

交流和结构管理

由于有大量股东的存在，企业结构需要使用合适的视觉表现手段和语言进行多种层次的交流。比如说对于高级管理层，结构必须告诉他们业务目标和动力是如何被支持的以及利益如何产生。而对于业务使用者来说，更关心的是他们的自己的业务领域。而IT管理者和工作人员关心的是技术组件。工程层的设计师们更关心标准和规则，因为它们可以提供充用的机会或者对他们的设计进行限制。

项目和工程必须与企业结构保持一致，这样业务利润才能实现，系统和软件工程师们才能从企业结构中获得指导。而且，所有的结构一样，企业结构需要不断的维护，特别似乎物理部分，比如说技术标准。这样企业结构才能跟得上业务的变化。企业结构必须在一个企业范畴的管理部门的控制下，这样才能确认它与现行系统的一致性。即使是由于某种业务原因，没有实现一致，这个部门也可以更好的发现不一致的系统究竟带来怎样的后果，比如说持续增长的投入和缺乏灵活应变的能力。

连接结构和设计

现在， “ 结构 ” 这个词已经越来越多的在商业和IT业中被使用，这里可能存在很多混淆。比如说，在很多组织里，结构和设计被看成是相同的。但是Cap Gemini Ernst 和Young不是这么认为的，因为设计和结构为解决方案提供的是不同的视角，确切的说，使互补的视角。Cap Gemini Ernst 和 Young使用IAF和Rational Unified Process (RUP;一种软件开发方法)将一个设计从结构变成了代码。表1表示出了结构（IAF）和设计（RUP，包括应用结构）之间的区别。

表 1. 对比结构和设计

就像建筑物的结构一样，软件结构和（详细的）设计事实上都是一个完整的设计集的一部分。结合IAF和RUP过程提供了一个综合一致的框架来支持这个设计集。而且，企业结构会为工程结构提供了很多环境参数，而同时工程结构也满足了方案的特殊需要。

那些具有很大风险的工程，特别是复杂的大型工程，利用工程层次的机构方法可以保证对整个方案有一个全面清晰的理解，包括外部系统和影响方案的各种因素，从而降低风险。

利用IAF，工程层次的技术结构与企业结构使用的基本方法是一样的，只是在细化程度上有所区别，更多地关注于信息、信息系统、底层技术、管理和安全领域的逻辑和物理层（使用在企业结构中定义好的上下文环境和业务结构）。

因此，企业结构的输出可以直接作为工程层次的技术结构的输入。从特定工程的技术结构中，可以得到具体的设计原则、指导和标准以及限制，它们会为软件和系统工程的设计提供指示。在IAF的例子中，工程层次的技术结构的输出之间被映射到了RUP设计中的具体事务上，比如说业务使用、系统使用以及非功能说明。一般来说这些映射都不是一对一的，但是它们能够提供从结构到具体物理实现的可跟踪性，借此可以加快开发速度。

图 3. IAF 和 RUP

总结

随着各系统和业务之间交互操作复杂性的不断增加，对于业务系统一致性以及有效利用信息技术实现企业利益的需求的增大，企业结构变得越来越重要了。企业结构（和工程层次的技术结构）通过帮助工程师总体的了解业务，为应用结构和具体设计提供了输入信息。

企业结构的关键目标是理解：

• 整体业务的相关部分，在上下文环境中（比如说，外部合作者）
• 终端到终端的流程（包括外部流程）
• 非功能的需求（包括安全和管理）

对方案产生影响：

• 满足非功能的需求，可能需要特定的组件支持。比如说特定的跨区域安全需求或者用基于服务的方法提供灵活性。
• 在整个业务的上下文环境和终端到终端的流程中是否体现出，比如说服务层次的目标可能存在于整个业务处理时间里，而且会往来与多个业务之间
• 与业务原则联系起来，这样设计阶段的一些变化所带来的影响可以在业务层面上进行评估。
• 推动和限制设计。为了完全的实现方案，包括非功能需要，对应用和底层的设计需要受限于结构。
• 是否对于每个元素的定义和功能都有了一个清晰的理解

而且提供基本原理

• 为支持业务目标和动力的决策、标准和产品选择

深入阅读

Cap Gemini Ernst & Young Technology Services

Services Architecture

Adaptive IT