Enterprise Architecture 简介

　　企业架构与业务优化有关，后者用来解决企业架构、绩效管理、组织结构和流程架构等问题。它包含对组织的流程、信息系统、人员和业务等单元的当前及将来的结构及行为的描述，以确保上述单元能够符合组织的战略发展方向，可见，企业架构的概念超越了信息技术的范畴。

　　企业架构与信息技术紧密相关。在本文中，我将描述SOA（面向服务的架构）环境中的一种简化的、自上而下的企业架构，重点关注信息技术，目的是实现业务和IT间的最佳看齐。

我将介绍：

1. 自上而下的企业架构方式的不同关注点
2. 企业架构的目标
3. 方法论概述
4. 与 BEA SOA 6 域模型的关系

　　通过本文，您将能很好地理解由业务策略驱动的自上而下的企业架构方式、该方式的优势以及相关的组织方面的考虑。

自上而下的企业架构方式的不同关注点

　　在自上而下的方式中，从业务到IT，很有必要在不同的规划分离业务和IT的不同关注点，进而在二者之间奠定公共的基础。与业务相关的规划被称为业务流程规划，与IT 相关的规划被称为应用规划，而二者之间的规划——也是该方式中最有意义的部分，因为这种方式旨在提供业务和IT间的最佳看齐——则被称为功能规划。若要描述硬件、网络、操作系统、应用服务器和数据库等，则可引入技术规划的概念。我无意详细描述技术规划，因为我的主要目的是推荐一种方式来通过公共的基础实现IT和业务间的最佳看齐。

　　图 1 描述了这些规划以及它们之间的相互关系。我将对其详细加以介绍。

　　

　　图 1.自上而下的企业架构方式的不同关注点

业务流程规划

　　此规划侧重于业务战略环境中的业务流程。可与组织中的不同业务线紧密合作的企业架构从由业务战略定义的业务需求开始，并能为主要的企业业务流程建模。比如，企业架构可通过AquaLogic BPM Designer在设计层面实现这一目的。这将有助于架构师理解企业内全局的主要流程，而且通过让更多的销售代表参与进来还可以推进这种方式。使用AquaLogic BPM Designer，业务分析师可以模拟业务流程，提供在对流程进行反向工程时发生的优化的一种度量。业务流程规划归业务本身所有。架构师的主要任务是获取业务需求并确认可由组织内的不同业务线使用的共同业务服务。

　　以银行业务环境为例，首先要先设计各项银行业务（比如贷款、进/出口操作）的流程。这两项银行业务具有完全不同的流程，但也会共享一些共同的服务。共同服务的确认是通过在组织层面设计流程实现的。在某种程度上，授权系统和会计系统应该能在不同的流程，比如开具信用证（LC）的流程或贷款批准的流程，被重用。两个流程应该能使用共同的授权服务和共同的会计服务。

功能规划

　　设计好组织的重要流程之后，就可用确定主要的功能块了。功能块提供可在不同的业务流程中重用的业务服务。业务服务也是 SOA 理想的构建块。这些服务还应该能被重用和重组，以便提供业务所需的敏捷性。在选择这些功能块以及需要在功能块间共享的数据时，业务线应该提供给企业架构师足够的业务知识，以便整个组织都能重用和理解规范的数据模型、域UML模型和数据存储库。这之后，就需要在规划中加入业务。

　　这种通用的做法应该会带来可在整个组织内共享的通用的语言和通用的分类法。通用实体和通用域模型的定义使其在组织内的含义通用，而且可以被不同的业务线重用。这个规划就像是个城市规划：将功能构建块组织成与组织内不同的业务线相关的区域和地带。

　　通用的语言将十分有助于功能构建块的重用以及数据在这些块间的共享。规范模型应该在企业存储库内被共享。管理考虑应该定义设计、访问、验证和修改这些模型的方式。我将在本文后面的部分对这些考虑事项详加介绍。

　　回到银行这个例子，在这个组织中，应该有一个业务线用来处理付款、外币兑换和抵押，另一个业务线处理贷款，第三个业务线处理进/出口操作，比如信用证（LC）和收款，还有一个水平的业务线用来处理授权、会计、报告以及风险管理。如果用城市规划来做比喻的话，每个业务线都可看作一个特区。

　　进一步观察进/出口这个业务线，还会发现分别与LC和收款相关的功能块。而代表LC 的功能块还可以细分为LC所应提供的不同的服务。这个块应该提供功能（或服务），比如开具LC、修改LC、使用LC和偿还 LC。这些都是LC块的业务服务。这些服务将依赖于由授权块、会计块和付款块提供的功能。

　　授权块将基于客户的状态为客户授予信贷额度。授权块可能会依赖于风险管理块的功能。LC功能也将使用由会计块和付款块提供的服务，而付款块则将会使用会计块和授权块的功能。

　　对功能规划的描述采用业务术语，并加以细分以使它能映射到应用内的应用程序和服务。在银行示例的这个环境中，会计服务和授权服务在组织层面上重用。

　　确定了这些功能构建块之后，还需要定义这些块之间的通信，这就意味着形成规范的数据模型。这个规范模型可使用UML模型进行描述，这就带来了数据的XML表示。这个通用语言应该跨整个组织共享。

　　在银行示例中，不管是在LC块还是在贷款块使用，账户都是一样的，客户也是相同的。账户和客户都是在跨组织的共享业务模型中定义的实体。这些实体由两个规范模型表示，一个用于账户数据，另一个用于客户数据。这些模型可由整个组织共享。它们可通过作为组织构建块的一部分的公共服务访问。这些服务可以是 CRUD (Create Retrieve Update Delete) 服务，也可以是复合服务。定义规范模型的最好的方法是参考业界标准。银行系统使用SWIFT 标准。在 SWIFT标准手册中定义的. MT 消息在业务用例使用消息的层面上定义了银行操作。这些消息可以轻松映射成可在整个组织内使用的 XML 消息。最大限度地遵循标准非常有助于将单个组织内使用的业务操作扩展到多个组织间的B2B 操作。

　　在Quinton Wall撰写的 理解SOA中的服务生命周期：设计时 和 理解SOA中的服务生命周期：运行时 中有关于服务设计、建模和运行时关注点的更多信息。

　　定义了块中使用的功能块和数据模型后，这些资产应该能由企业存储库中的不同业务线重用。BEA AquaLogic Enterprise Repository 可用来共享企业信息资产。

应用和实现规划

　　正如我所提到的，功能构建块是SOA构建块的理想选择。使用自上而下的方式确定的服务将会带来业务需求和IT间更好的匹配。

　　应用规划中的服务实现将取决于服务的类型以及服务与不同的SOA 层间的关系，这些层包括表示和复合层、编排层、业务服务层和数据访问层或连接层。

　　为实现这些块选择合适的产品时，要格外慎重。应该考虑组织的环境，比如现有的应用程序和技术限制，当进行实现方面的选择时，应用规划与技术规划是分不开的。在理想情况下，BEA WebLogic Integration 是系统到系统过程的一种不错的选择。用于业务流程规划中的设计和流程再设计的BEA AquaLogic BPM是人工驱动流程的理想选择。BEA WebLogic Portal 非常适合在整个组织内通过WSRP开发和共享表示层，进而促进表示层和门户联邦的重用。AquaLogic Data Services 是数据访问层的一种理想工具，而AquaLogic Service Bus 则非常适用于应用程序到应用程序的通信。在实际环境中，这些选择取决于组织内现有的资产和需求。另外，应该在组织的环境中考虑使用参考架构。

　　组织的参考架构是能够根据其所属的层和服务提供如何实现每个构建块的最佳实践和蓝图。在参考架构中还会定义和显示服务间的通信。图 2 给出了为组织定义的一个参考架构示例。此图表还描述了通过合适的产品实现组织的功能构建块服务所需的 SOA 层。参考架构的定义通过涉及合适的业务和IT层的流程实现。这种模型可用于在组织环境内针对每个SOA层实现构建块。

　　

　　图 2.组织的参考架构

　　参考架构应能有助于推广由管理团队定义的最佳实践、指导原则和设计原理。此架构应该使用在功能规划中定义的规范的模型和分类法。我将在稍后讨论管理团队的有关内容。

企业架构的目标

　　采用从组织的业务需求开始的全局手段，企业架构的主要目标是借助通用语言构建重用的氛围，如图 3所示。这一目标应该逐渐实现而不是依靠急剧变革一蹴而就，应该有一个管理团队来管理不同的范畴：全局业务和战略范畴、信息系统范畴和项目范畴。应该支持通过合适的工具来促进整个组织内的重用。

　　

　　图 3.企业架构的目标

管理团队

　　管理团队应该创建和维护反映组织当前状态的资产，比如现有的功能模块。在这些资产中，有对当前状态的全局描述，这将十分有助于确定当前信息系统的筒仓（silo）。定义目标状态时还应考虑路线图。

　　要想将路线图应用到目标，管理团队应该在项目之初就介入，为整个组织提供指导原则、实施规定以及最佳实践。

　　指导原则、策略、分类法、企业规范数据模型、数据存储库、最佳实践、可重用资产以及需要由管理团队定义和维护的其他准则会触及所有的业务线以及IT。

全局业务和战略范畴

　　企业架构应该能够协调IT与组织的战略。它应该能轻松适应业务的不断变更。这就要求业务架构和指导原则必须能够最终形成组合和分解业务流所需要的功能构建块。

信息系统范畴

　　企业架构团队引用现有的功能构建块。它也可以定义业务处理所需的新的功能构建块，正如在业务流程规划中的全局业务范畴中定义的那样。信息系统范畴与功能规划相关，并应该能够通过可由业务和IT所理解的语言来提供正确的抽象级别。

　　信息系统资产在功能规划中定义。该定义包括在功能级别应用程序间的通信以及规范的企业数据模型、通用语言、分类法以及数据存储库。应该定义和控制对这些资产的访问。

　　功能规划中的工作应该与应用规划中的应用相对应。各种标准和产品支持应该与每个应用所涵盖的方面联合确定。

项目范畴

　　在运营的层面上，大多数举措都应该以项目的方式实现，以确保成功应用各项指导原则和规则。来自管理团队的架构师应该确保详细的技术要求和项目架构与企业的指导原则、策略以及企业通用语言的使用相一致。若能在投资的早期就向可交付项目应用架构蓝图将能显著增加符合规定、具有更好可重用性的按时、按预算、保质交付的可能性。只有这样，项目才能提供新的可在整个组织重用的SOA构建块。

　　将全局驱动的策略应用到新的项目是一种实现目标的演进式的方案，过程是平滑进行的而非爆炸式的变革。

企业架构存储库管理

　　对企业常规模型定义的访问应该全局可用以便开发一种通用的企业语言，使用通用的分类法。没有通用的语言就无法实现重用。信息系统资产的有效管理可通过使用企业存储库实现。这个存储库应该能由整个组织访问，并由管理团队管理，它应能提供资产和元数据的扩展视图。BEA AquaLogic Enterprise Repository 是可用来支持企业架构的一种优秀工具。

方法论概述

　　设计企业架构的一种优秀方法是描述上述每个规划的当前状态，如图 4 所示。这将有助于评估业务和IT间的差距并确定简仓。然后，可定义路线图来实现目标。方法论实际上就是分析在本文的开始所描述的不同的规划来评估当前状态和定义目标状态。

　　图 4.方法论概述

当前状态（既有的）

　　当前状态的评估可以用自上而下的方式、自下而上的方式或两种方式的混合来实现。当前状态的定义可在每个规划上进行。

　　从业务流程开始，通用的工作应该由业务线和IT共同实现以定义业务流程的当前状态。用AquaLogic BPM Designer对这些流程建模可以为架构师和业务代表提供共同的基础；可使用AquaLogic BPM位业务流程及模拟可能性绘制增强的图形。

　　从现有的应用开始，联合IT，确定现有的功能块。这样，重复的功能才有可能出现，筒仓才会被识别出来。

　　一旦识别了筒仓应用程序，就应该在目标状态定义通过服务公开消除筒仓的方法。

目标状态（应有的）

　　定义目标状态应该采取自上而下的方式。这是推荐的方式，原因是它构建在业务需求之上并能提供可重用的业务构建块。

　　从业务流程开始，与业务线合作，可通过使用AquaLogic BMP Designer对优化后的未来状态流程建模。再下来，确定功能块，提供业务流程的复合和分解所需的服务。请记住，在功能规划中，只有业务和IT联合才能完成共同的任务。

路线图

　　之后，定义路线图来实现中间、认可状态的目标。这个路线图在定义通用语言、规范模型、数据存储库时应该被考虑进去。中间的验证步骤应该涉及业务和IT。

　　参考架构在路线图的某些阶段规划。当然，参考架构的规划可以在任何时候进行，但您不应等到所有企业资产都定义好后才开始准备参考架构。有效的资产应该不断针对新的业务需求进行调整（新的功能块会涉及新的实现方法）；它的目标是根据目前所存在的企业可重用资产以及应该被采用的技术给出“如何做”的指示。如前面提到的，参考架构处在不断的发展之中，提供了一种在某些时候以增强的可重用性为目标在组织的环境中实现新项目的最佳方法。

　　管理团队是路线图中涉及到的最主要的团队，原因是该团队可在整个新项目过程中借助其所生成的资产全局参与并侧重于提供业务所需的敏捷性。管理团队应该包括一组具有不同专业背景的企业架构师，这样他们就可以在不同程度上关注其中的某个规划。主导管理团队的应该既有侧重于技术的架构师，也有侧重于业务的架构师。管理团队可以由源自不同业务线的资深架构师和源自IT的资深架构师混合组成，这就使团队具备了领导全局的必要资质。

　　管理团队的任务在某些环境中实现起来很困难，所以应该提供强有力的协助。管理团队的角色多少有些像炼金术士，致力于寻找正确的“配方”以催生合适的转变。在这方面，有很多文章可以参考，比如David Groves 和 Steve Bennett 所著的 成功规划SOA 、成功规划SOA：构建您的SOA路线图，以及 成功规划SOA：进行长期SOA规划。请注意在应用路线图之前务必要考虑变更管理。

与BEA SOA 6 域模型的关系

　　这里所描述的方式以业务策略和流程为起点，通过功能构建块构成应用，所有这些都可通过通用的企业语言以及可为新项目和应用提供蓝图的参考架构实现。在功能规划中，我介绍了为了维护结构化的视图和成功公开可在整个企业共享的资产需要由组织处理的各个方面。

　　在使用SOA作为企业架构的环境中，资深的SOA架构师需要避免代价昂贵的常见缺陷。这些架构师应该与组织的管理团队协作来提供所需的技能并帮助管理团队建设成功的SOA。SOA可以以企业方式全局驱动，也可以在项目中局部驱动。采取全局的方式可以为项目提供管理和指导，进而可以为SOA提供更高的一致性和更好的投资回报。它会减少生产中的应用程序的维护费用，增强其可重用性。

　　BEA 提供了一种域模型，可用来处理企业架构。这一模型通过六个方面涵盖了之前所描述的规划（以及更多），提供了一种成功实现SOA的途径，如图 5所示。

　　图 5. BEA域模型

　　BEA SOA方式是一种注重实效的企业架构方式，它触及了信息技术的各个方面。BEA 提供了针对所有六个方面的服务和培训，而且进行了有效的组织以让您能够实现SOA来满足您组织自身的需求。

　　开始时，不妨参考一下BEA SOA Readiness Assessment Report。它可帮助您定义当前的状态，是在组织中引入SOA的一个很好的起点。通过在 SOA Resource Center 参加一个调查就可以收到SOA 的评估报告。

结束语

　　本文展示了自上而下的企业架构，介绍了获得跨组织的全局可重用性所需要的管理关注点，强调了组织的参考架构的必要性，定义了企业存储库以促进这种全局方式。

原文出处：http://dev2dev.bea.com/pub/a/2006/03/enterprise-architecture.html

作者简介
Gabriel Bechara	Gabriel Bechara 已经为BEA咨询服务部门工作两年多了。Gabriel帮助客户使用BEA的产品，比如WebLogic Server、Portal和Integration。Gabriel的兴趣包括定义软件架构的方法、在开发团队中使用产品以及提供将应用程序推向生产的最轻松方式，主要关注WebLogic Integration以及与SOA相关的方法。Gabriel加入软件行业已有15年多了。Gabriel与妻子及两个孩子居住在巴黎唐人街。