文章
面向服务的架构
| |||
|
通过企业架构实现 SOA 治理
作者：Manuel Rosa 和 André de Oliveira Sampaio
实现全球企业架构愿景，通过提供机制和工具来丰富应用程序、流程和项目组合管理所需信息
2013 年 12 月
下载
Oracle Enterprise Repository
摘要
技术资产的拥有成本可以非常重要，通常情况下的确如此。对集中管理、监视和控制各项技术资产的贡献的需求成为大多数组织的首要职责。
在面向服务的架构 (SOA) 中，管理服务（架构战略的主要组成部分）及其组件至关重要。如果不能正确地分析服务的依赖关系和影响，那么其重用优势很容易被削弱。
使用 Oracle Enterprise Repository 作为 SOA 构件编目的中心点，可以了解整体情况和推进不同 SOA 资产之间的协作，从而实现重用，同时还能够分析 IT 更改对组织的影响。一说到 SOA 域，自然会想到治理问题。
虽然 SOA 治理及其工具是实现任何程度的 SOA 成功所必不可少的，但其价值在大多数组织中仍然不为人所知，主要是因为无法单独了解 SOA 举措。许多问题会影响这些举措的可见性，主要是了解和衡量 SOA 治理及其贡献的价值：SOA 治理工具通常不足以满足技术领域以外人员（业务分析师、项目经理，甚至一些企业架构师）的需求，此问题在高管级别尤为严峻。
治理战略是 SOA 的基础，必须有一个能够提供机制和工具来丰富应用程序、流程和项目组合管理所需信息的全球企业架构愿景才够完整。
通过创建正式的通用表示模型、语言（图形和文本）和标准视角，以及通过扩展 SOA 治理工具的基本功能，我们可以将信息用于更大的分析范围和更多的分析功能（例如，基于时间的分析、依赖关系分析）。
为了应对这些挑战，Link Consulting 在一套完整的 SOA 治理 + 企业架构解决方案中同时采用了 Oracle Enterprise Repository 的主要功能和它自己的 Enterprise Architecture Management System (EAMS)。Enterprise Architecture Management System—Oracle 企业版将这套架构管理解决方案与 Oracle Enterprise Repository 相结合，提供 SOA 治理专用产品。它在一套解决方案中汇集了两个领域（SOA 和 EA）的精华，可助力 SOA 治理项目、举措和计划，并为业务、其他运营领域和项目管理提供了更方便的信息交流机制。
在本文中，我们将介绍组织如何利用最佳 EA 和 SOA 治理实践，并借助适当的浏览工具和通信工具（如 Oracle Enterprise Repository 和 EAMS），来实现和保持 SOA 和 SOA 治理举措所需的质量和可见性水平。
简介
为了确保 SOA 举措的一致性和基本目标，了解和实施有效的 SOA 治理势在必行：
- 开发正确的服务
- 控制开发流程中的成本和风险
- 缩短上市时间
实现这些目标的重要性和难度随着服务数量及其复杂性的增加而陡增。因此，关键是要实施基于规则、策略、程序、标准和最佳实践的战略，该战略支持 SOA 工作的长期愿景和决策流程，并能控制服务设计、实现和维护中所涉及的工作。
虽然 Oracle Enterprise Repository 让 SOA 架构师能够充分利用每个服务，为 SOA 解决方案增加价值，但在正确了解 SOA 治理信息方面，我们还有更多事可以做。
虽然坚实的治理战略是 SOA 的基础，但必须有一个能够提供正确机制和工具来丰富应用程序和项目组合管理所需信息的全球企业架构愿景才够完整。
通过创建正式的通用表示模型、语言（图形和文本）和标准视角，以及通过扩展 SOA 治理工具的基本功能，我们可以增加分析功能（例如，基于时间的分析、依赖关系分析等）的范围和数量。
为了解决这些问题，我们将 Oracle Enterprise Repository 与 EAMS 结合使用，用最简单的方式确保架构表示是最新的。EAMS 可根据从 Oracle Enterprise Repository 收集的信息动态生成组织级的架构蓝图（模型、映射或图表）。
面向更广泛的受众
SOA 治理基于简单、直观的概念，但是很难全方位实现，通常因为组织中并非每个角色都了解其真正的价值或目标。问题在于信息从 SOA 卓越治理中心传递到公司其他受众的方式。
在典型的 SOA 治理方法中，SOA 卓越中心的利益相关方往往具有不同的背景和能力：SOA 治理专家；SOA 架构师；企业架构师、运营、安全、质量保证专家、业务分析师等。每个角色都有不同的 SOA 目标和需求，其重要性也各不相同。
如果此组将 SOA 信息传递给同事时只提交非结构化信息，那么它很容易成为 SOA 和 SOA 治理采用的障碍。信息可能没有存储在信息库中，也可能存储在信息库中，但对于某些受众可能技术性太强；可能需要反复手动创建非结构化模型，这是一个耗时的过程。
作为主要的 SOA 信息库，Oracle Enterprise Repository 可以只提供一些即需即用的信息视图，让某些角色的需求和问题至少部分得到解决。通过常用的采集机制，将技术信息从 Oracle Service Bus、UDDI、直接从服务合同（Web 服务定义语言）、OEM 或其他来源收集到 Oracle Enterprise Repository。但对于企业或业务架构师/分析师或项目经理而言，这还不够，因为他们无法对这些信息进行某些处理，从而导致无法充分利用 SOA 治理实践的优势。
图 1：SOA 信息周期 — 面向角色
从下图可以看出，资产之间的依赖关系网络可能过于复杂，难以检测到标准关系模式。
图 2：Oracle Enterprise Repository 上的依赖关系网络 (Navigator)
显然，尽管它非常清楚地显示了资产的直接依赖关系，但 Navigator 未能满足所有架构师在影响分析方面的需求。成功的 SOA 治理举措更多依赖于信息的质量（至少是我们可以感知的质量）而不是数量。
筛选掉不必要的信息并通过连接模式关联资产可以是更高级别影响分析（如应用程序架构分析）的基础，更不用说某些应用程序可以提供或订阅的服务。
管理项目组合也是同样的情况；如果您能使用每个阶段的估算日期扩展服务生命周期信息，就可以使用该信息来预测不同项目之间的依赖关系和影响。
SOA 和信息架构（通常通过定义一个通用的数据/信息模型）或业务/流程架构（通过业务流程）之间的关系可以对业务分析师非常有用。他们往往要在 SOA 信息库中搜索业务概念而不是技术信息，所以关键要使正在开发的服务与组织的业务概念保持一致，正式确定 Oracle Enterprise Repository 内的这些关系。
图 3：SOA 治理作为企业架构的一部分
建立通用模型
人类沟通可以看作是信息编码（组句）、消息传递（说）和消息解码（听和理解）的过程。成功的通信需要明确的传输渠道和共享代码。如果未能正确释译消息，或消息中存在空白或无关的噪音，将产生误解。信息编码由语法和语义共同实现。在目前情况下，当我们需要确保围绕主题进行有效沟通时，至少需要定义一种通用语言。建立概念、以明确的方式描述概念以及表达概念之间关系的过程就是我们定义语言和模型的过程。
这一步可能显得有些微不足道，但事实远非如此。多年来，我们一直使用一种简单的方法来验证各利益相关方是否真正理解某个概念：我们只是让他们统计一下该概念的实例数（即公司目前拥有多少应用程序）。如果结果差异超过 20%，那么极有可能是沟通问题。该方法假定利益相关方能够统计元素数量，而不是玩猜谜游戏。
这个元模型是沟通的基础，无论是口头的还是书面/绘制的。SOA 模型绝不应该是个孤岛；SOA 有一个周边环境：人、流程、正在进行的项目等。通过结合企业架构整体视图的一部分，我们可以增加价值并扩大 Oracle Enterprise Repository 元模型的基础技术资产的范围，从而为 SOA 举措打下更坚实的基础，并与组织的 IT 转型计划建立更明确的共生关系。
围绕该主题的通信有许多工具，包括涵盖 SOA 相关信息的应用程序、报告、邮件和演示文稿。对扩大受众范围的需求源于不同利益相关方的担忧，这种担忧不仅限于内容，也包括媒体，即信息传输的形式。我们大脑的四分之一用于视觉，比所有其他感官的总和还要多。我们的大脑喜欢以一种可视化的方式接收信息，并且可以高效处理这些信息。绘图和图表往往比文本语言更加简洁、精确地传递信息。Oracle Enterprise Repository 的 Navigator 是一款功能强大的工具，用于表示 SOA 构件之间的直接关系，但不能像图表、蓝图一样提供聚合/结构化的视图。
要利用图表进行通信，我们必须为元模型所包含的每个概念明确地分配一个表示元素。可以用多种标记法和其他手段来规范 SOA 相关信息的表示和结构。
一个有趣的方法是考虑结合 EA 标记法以扩大范围（例如，ArchiMate）。
图 4：符号示例
视图/图表不仅仅是一套符号，它们有规则和视角，建立的不仅仅是视图的构造和查看方式。为每个概念定义元模型并建立表示法之后，下一步就是标识和指定视角。定义好这三个元素之后，我们就有了模型和通信工具。正如下面“使其工作”中所描述的，EAMS 为收集到的信息提供这些类别的视图，这些信息现在编录在 Oracle Enterprise Repository 中。
与时俱进
SOA 资产受时间限制，如果不考虑生命周期、阶段、过渡和变化，无法作出全面分析。采取几乎所有 IT 实践方法，缩写词 SMART 将出现。本例中的关键字母是 T，即时限性。要真正治理 SOA，我们需要全面了解过去/现在/将来。通信必须解决的不仅是过去执行了什么和决定了什么，还需要涉及目前的现状和未来的计划。
当前工具的影响分析可能会让人误以为任何人都可以单靠一个快照在单一时间点评估。通过将通用项目管理实践与服务生命周期阶段进行关联，我们可以全面了解项目及其受影响服务的过去、现在和未来。这非常重要，因为项目可以带来服务生产、重用、退休或更改，从而影响整个组织的 SOA。
在本例中，我们可以发现关于通过 SOA 治理进行项目组合管理的两个不同场景。它描述了对每个项目的服务执行的不同操作如何影响策略，无论是提示未来服务重用，还是创建新版服务并影响当前用户，甚至预测生命周期即将结束的组件的重用问题。
图 5：SOA 项目组合管理
- 黄色：如果能够预测每个服务生命周期阶段的日期，您甚至可以重用尚未开始开发的服务（前提是已定义合同）或者影响其规范。
- 红色：预知服务可以避免重用快退休的服务。
认识到资产的动态特性对资产的充分表示提出了需求。如果图表中描绘的内容本来就不是静态的，我们为什么只考虑类似于静态快照的图表和映射答案包括两个方面：
- 实践无法提供足够的方法甚至准则，以鼓励从业人员捕获必要的生命周期信息。这个论断乍看可能有些武断，但请考虑一个简单的事实，虽然部分人员可能会捕获一些有关资产本身的生命周期时间戳，但始终无法捕获资产间关系的生命周期。从某种程度上说，这不是损害了影响分析结果的质量吗？
- 大多数工具不是为提供和维护资产的动态表示法而准备或设计的。
使其工作
SOA 信息库 (Oracle Enterprise Repository) 是 SOA 治理举措的核心要素。它是一个通用渠道，用于管理和治理任何类型的 SOA 资产元数据。它描绘了连接这些资产的直接关系和相互依赖关系。它提高了影响分析的质量，促进和优化了资产重用。内置采集机制可获取设计或运行时环境，甚至其他来源或目录（类似于应用程序或信息目录）。
要从通用的 SOA 治理实践扩展 Oracle Enterprise Repository 的基本用法和优势，我们需要通过创建新的概念/资产和关系来扩展其元模型；从其他目录（或 Excel 电子表格、CMDB，甚至项目管理工具）捕获更多信息；以及使用具有业务意义的模式。
由于时间维度对于全面了解 SOA 资产的演变也很重要，所以架构师使用其 Visio 技能时不应将模型局限于特定时刻。将此维度与 SOA 相关联的最佳方法是通过 SOA 资产的生命周期自动实现（如果可能的话）。通过保存过去和现在的信息并预测它的未来，可以作出更明智的决策。
如果做到这一切，我们将有一整套详尽的概念，让我们不仅能够提供立体结构化图表和蓝图、有意义的仪表盘和报告，还可以为主要 SOA 治理资产提供独特的时间线可视化。
必须部署 EAMS 以自动生成这些类别的视图和表示法。
图 6：填补空白 — 适合每个人的 SOA
在这里，我们使用 Oracle Enterprise Repository 作为基本和集中的 SOA/SOA 治理点，并利用其采集工具的优势，为您介绍 EAMS 生成的一些常见仪表盘或结构化蓝图的示例。为各利益相关方提供他们利用 SOA 以及 Oracle Enterprise Repository 中的信息所需的视图：
创建新服务最常见的用例之一是来自业务分析团队的请求。
使用此方法，业务分析师可以搜索业务目标相关信息（无论服务还是信息实体）的功能模型分类及其与服务的关系。他们可以轻松发现这些可用服务能否满足其需求，而也只有在此之后，他们才会向 SOA 架构师或 SOA 治理专家询问重用/更改/创建服务的真正可能性。对业务和技术的影响将非常明确，可据此作出最好的决策。
在此周期内，可以方便地向运营团队咨询基础架构是否合适，向安全专家咨询安全问题等。所有利益相关方将会看到某种形式的 Oracle Enterprise Repository 信息，从而帮助他们作出明智决策。下面，我们介绍一系列仪表盘和蓝图，显示 EAMS 为 SOA 治理提供的简单附加价值，但需要记住的最重要的一点是，信息已经存在于 Oracle Enterprise Repository 中。
SOA 仪表盘
列出了所有服务。有关其用户和生命周期阶段的信息提供信息库中信息的常规视图。
图 7：SOA 仪表盘
SOA 投资控制仪表盘
包括所有服务以及与实施成本、开发时间甚至重用收益（通过计算重用次数）有关的分析数据。这些类型的仪表盘可以让您对 SOA 计划 ROI 一目了然。
图 8：SOA 投资控制仪表盘
SOA 控制仪表盘
包括所有服务，并使用分析数据（通常从运行时环境收集）测量和控制其性能。
图 9：SOA 控制仪表盘
服务目录蓝图 — 功能模型
以图形方式表示容器和子容器中所有服务的功能分类的蓝图。每种颜色代表不同的生命周期阶段（选定的时间间隔是从 21-12-2001 至 23-04-2002）（图 10）。
图 10：服务目录蓝图 — 功能模型
与上述蓝图相似，但选定的时间间隔不同（08-10-2008 至 08-02-2009）。此蓝图显示了该时间间隔内哪些服务已退休：红色表示特定的生命周期阶段（图 11）。
图 11：服务目录蓝图 — 功能模型
服务目录蓝图 — IT 分类
以图形方式表示选定时间间隔内容器和子容器中所有服务（业务服务、实体服务、实用工具服务等）的 IT 分类的蓝图。该蓝图还显示了各层服务之间的依赖关系（图 12）。
图 12：服务目录蓝图 — IT 分类
服务上下文蓝图
该蓝图表示中心位置的服务本身及其周边的相关概念，如项目、利益相关方、用户和提供者、信息实体或业务流程。
图 13：服务上下文蓝图
前一个蓝图是关系模式用法的简单示例。大多数工具只呈现了关系链中的每个关系，而没有将其他抽象层或利益相关方所关注的宏观层的东西展现出来。通过 EAMS，我们可以检测关系模式并相应地配置生成的视图。
下图左侧描绘了更加详细的依赖关系视图，始于两个提供应用程序，止于使用者应用程序。右侧示例节选了部分细节内容，呈现了更适合高级应用程序集成视图的信息。
图 14：对包含关系模式的视图中的抽象级别作适应性改变
服务集成蓝图
该蓝图呈现了本例中服务的技术组件，这些组件从 Oracle Service Bus 采集（例如代理服务、业务服务、XSD 或 WSDL）而来，周边是其提供者和用户，按类型划分。
图 15：服务集成蓝图
工具
企业架构管理系统 (EAMS)
企业架构管理系统 (EAMS) 是基于自动化的解决方案，可高效管理企业架构。该解决方案使用经过配置的企业信息库（即本文中的 Oracle Enterprise Repository）为用户提供自动化功能。可以利用 EAMS 创建、自定义和分析信息库数据、架构蓝图、报告和分析图表。
数据
- 对信息库数据的完全访问
- 筛选、高级自定义和集成
蓝图
- 自动创建蓝图
- 根据用户配置文件在各蓝图之间导航
- 批量生成功能
- 基于时间和生命周期的可视化
- 完全可扩展的参数化
图表和仪表盘
- 运行时配置功能
- 轻松扩展
- 支持时间维度、下钻和导航
Office 报告
- 自动生成报告
- 基于完全可配置的模板
- 批量生成功能
Oracle Enterprise Repository
Oracle Enterprise Repository 是 Oracle SOA 治理解决方案的核心要素之一。Oracle Enterprise Repository 提供一系列工具来管理和治理任何类型软件资产的元数据，从业务流程和服务到模式、框架、应用程序、组件和模型。Oracle Enterprise Repository 呈现了连接这些资产的关系和相互依赖关系，以改善影响分析，促进和优化其重用，并衡量其对收益的影响。它提供可见性、反馈、控制和分析，让您的 SOA 有望提供业务价值。特别强调自动化有助于克服采用 SOA 的障碍，并且简化了整个生命周期的治理。
从 Oracle Service Bus 或 Oracle SOA Suite 自动将 SOA 资产采集到 Oracle Enterprise Repository（然后与兼容 UDDI 的系统交换此信息），可确保运行时中的资产也存在于设计时信息库中。此外，还可以从 SOA Management Pack 获取多个运行时指标，SOA Management Pack 允许在单个目录中获得 SOA 治理设计和运行时闭环视图。
图 16：soa 治理工具用例的运行时指标
Oracle Enterprise Repository 核心功能包括：
- 资产管理
- 资产生命周期管理
- 使用情况跟踪
- 服务发现
- 版本管理
- 依赖关系分析
- 组合管理
EAMS + Oracle Enterprise Repository
Link 的企业架构管理系统 - Oracle 企业版（EAMS - Oracle Enterprise Repository 版）融合了两个领域（SOA 和 EA）最优秀技术的解决方案可助力 SOA 治理项目、举措和计划。
该解决方案在共生工具中结合了两个产品的优势和特点，提升了 SOA 治理举措和计划的质量。
通过将 EAMS 与 Oracle Enterprise Repository 相集成，EAMS 使信息库中的所有信息变得可用，同时还增加了功能。
图 17：EAMS 与 Oracle SOA 治理解决方案的集成
从组件级别看，该解决方案由数据源以及蓝图、仪表盘和报告的现成配置组成。
图 18：EAMS — Oracle Enterprise Repository 架构
总结
SOA 治理是 IT 治理的关键所在，所有利益相关方都应该有所了解，因为其实践可以确保创建正确的服务、促进服务的重用和演变；确保提供正确的信息以支持决策的制定；以及确保现有企业资产的可见性。
但 Oracle Enterprise Repository 仍是以技术为导向，无法直接提供某些信息视图。成功的 SOA 治理通信需要一种通用语言、符号集和结构化视角。通过从企业架构获得基本概念和映射实践，可根据各相关人员的需求对 Oracle Enterprise Repository 中的信息进行筛选、组织和利用。作为 SOA 治理信息更高层洞察的提供者，EAMS 提供了一组功能，不仅汇集了 SOA 架构师或开发人员，而且还汇集了业务及 IT 的其他部分。
无论哪个领域，无论成熟度如何，转型举措都是很复杂的。步骤可能很简单，但其执行通常并不简单，因为缺乏足够的工具人力和/或支持。工具必须不断发展才能适应综合的非孤岛式信息库，通过对组织内部的各领域提供价值实现跨组织倡导。对于异构问题，表示法必须能够实现预期目标，并且必须借助自动化机制管理和创建表示法来避免耗费过多人力保持其现时性。
关于作者
Manuel Rosa Manuel Rosa 的职业生涯始于葡萄牙、巴西和卢森堡的企业架构项目，主攻应用程序和业务架构。过去几年，Manuel 协调 SOA 治理计划的发展，同时还负责葡萄牙电信和公用事业行业的主要企业的各种 SOA 治理项目和西班牙的 SOA 项目。他目前是 Link Consulting 的 SOA 治理实践带头人。Manuel 曾在伦敦举行的第五届国际 SOA、云和服务技术研讨会上发表过演讲。他目前是企业架构 I 和 II 的学科助教，该学科是 Instituto Superior Técnico、INESC 和 INOV 针对 POSI 硕士学位提供的一年制科目。
André de Oliveira Sampaio 在位于葡萄牙的 Link Consulting 担任企业架构高级顾问，参与并协调葡萄牙、巴西和卢森堡的各种企业架构项目。作为一名专业人士，André 参与了几个重大改造项目，其中大多数属于金融服务和公共管理行业。André 负责企业架构管理系统的开发，并且出版过企业架构、企业转型、系统理论、面向服务的架构和正式观点等方面的著作。
Printer View