加载中…

加载中...

个人资料
人月神话
人月神话 新浪个人认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:4,201,213
  • 关注人气:5,927
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

Oracle-SOA治理关键杠杆点

(2011-05-17 21:42:28)
标签:

oracle

soa

治理

分类: 转载文章
Oracle-SOA治理关键杠杆点

MIT 的 Peter Weill 将 IT 治理定义为“指定决策权和责任框架,以鼓励在使用 IT 过程中所希望的行为。”换言之,IT 经理必须使用决策、流程和策略来鼓励通向成功的行为。IT Governance Institute 对该定义进行了扩展以包括“……确保企业的 IT 可以支持并扩展企业的战略和目标的领导力、 组织结构和流程。 ”   如果采用 SOA, 则可将 SOA 治理定义为策略(做什么)、决策者(谁来做)和流程(如何做)之间的交互以确保 SOA 成功。

企业体系结构 (EA) 是一项计划、治理和创新功能。EA 的目标包括以下三个方面: 通过转换为企业 IT 更改提供动态流程;不断开发业务功能以增强企业竞争力;为转换计划确定人员、流程和技术方面的投资计划。这些目标应驱动 EA 中的所有事物。EA 的交付物是一个基于清晰业务需求构想的目标企业 IT 体系结构,以及一个可以通过定义、计划和执行良好的转换实现构想的管理模型。

SOA 是企业体系结构 (EA) 中的一个原则或框架,其目标与业务和业务目标一致,包括  
  • 降低总拥有成本 (TCO)  
  • 缩短上市的时间  
  • 实现业务敏捷性  
  • 促进创新  
  • 支持合规性  
  • 增加收入  
  • 增加客户满意度和忠诚度 
  • 全球扩张

此外,SOA  日益成为 EA  的典型(重要)部分并隐含 EA 的关键内容。  

  • 业务体系结构 —业务流程定义的基础是业务服务和业务事件。  
  • 应用体系结构 —其基础是服务、服务使用者和绑定到用户界面的组合。  
  • 信息体系结构 —其重点是数据模式标准化、数据服务和数据质量。  
  • 技术体系结构 —随新的 SOA  基础架构、工具和共享平台的发展而发展。 

实际上,SOA 通过服务组合(可以洞察 EA 构件)和服务信息库(成为支持业务体系结构的流程和系统基础)来支持 EA 战略。这有助于创建一种企业用于实现和维护企业敏捷性的方法。

为了实现业务、EA 和 SOA 目标,必须在不同业务领域制定策略:体系结构、技术基础架构、信息、财务、组合、人员、项目(或项目的执行方式)和运营。这是治理的角色:即策略,需要设计并制定策略以确保一致性。策略的格式和介质可能不同 —可以用技术捕获并执行一些策略,例如,注册表/信息库有助于执行服务生命周期治理,Web  服务管理解决方案在运行时实现了对服务应用操作策略。

体系架构

体系结构策略提供了 SOA  的基础和框架,使您可以用更低的成本、更好、更快地进行构建。必须构建每个系统,这样既适用于现有的环境,也反映了组织的未来构想和SOA 战略。最好使用设置一组最少约束条件的体系结构方法来构建 SOA  以支持更改,从而实现服务实施一致性、改进的互操作性、利益相关方的创新以及最小限度开发应用程序的支持,还提供了对其他应用程序有用的通用功能,并利用和增强了共享的基础架构。

许多公司面临着“孤岛”业务模型,即 LOB 间没有共享的设计、策略和流程。这些公司通常努力创建与业务合作伙伴的无缝集成,而非整合自己内部的各个孤岛。但公司内部必须遵守体系结构原则,否则无法获取最大的 SOA 收益(如服务重用和降低的维护成本)。

Oracle 推荐公司创建在整个企业实施的、单一、整合的体系结构。通过保持企业体系结构构件尽可能简单,您可以增加受众和项目团队理解它们的机率,还能够在将来有效地执行和更新这些构件。

技术基础架构

和其他 SOA 组件一样,技术也必须进行识别、引入和管理,它不是一次性“自动导引”决策。因此,需要制定策略以确保:

  • 提供消息处理、安全性和其他服务(有时称作实用程序服务)的技术基础(通常称为战略 SOA 平台或端到端 SOA 平台)集中资助、可供所有项目利用    
  • 治理平台是 SOA  平台的一部分,如果条件允许,可启用策略自动化    
  • 建立共识时考虑了原有系统和平台到 SOA 技术的迁移    
  • SOA平台增强与项目组合计划和业务服务组合计划一致    
  • 共享的基础/实用程序服务的设计和实施是 SOA 基础架构的一部分

如今许多体系结构成熟的企业都有专用于软件和硬件治理的组织和流程,需要利用它们来构建 SOA 基础架构。

如果无法在技术和软件基础架构上制定策略,会导致服务不兼容、互操作性差,从而不适于在企业范围内使用。如果每个项目团队使用各自的 SOA 基础架构 — 不与其他团队集成或共享组件,也不使用基于标准的体系结构来确保互操作性 — 有可能构建安全可靠的组合应用程序吗?

信息(数据架构)

开发人员经常会创建延续较差数据访问方法的服务接口,这会抵消创建可共享数据的服务的好处。要为面向服务的应用程序奠定一个健壮的基础,必须解决数据质量和互操作性问题。任何 SOA 计划的目标都应是创建数据标准以消除原有的、ERP 和其他系统在数据表示方面的分歧,并创建一组服务作为访问高质量企业数据的权威方法。企业数据环境应该:
  • 为关键企业实体(如客户或产品)创建单一逻辑源
  • 消除定制接口和专有数据格式
  • 提高企业内的数据质量
  • 在数据服务层实施数据标准
  • 使数据易于发现、访问和互操作
  • 实现数据服务由策略驱动的安全性
 
需要通过企业管理功能解决的特定数据治理问题包括

  • 定义数据所有权和管理权,包括数据使用者和生产者的角色和职责
  • 建立一个数据服务体系结构
  • 建立遵循企业选择的数据标准的策略和原则
  • 要求使用特定模式作为交换主数据(客户或订单)的模式
  • 建立异常、标准更改和版本管理等流程
  • 要求使用特定数据服务作为所服务的数据系列的单一信息源
  • 执行策略以确保数据服务符合数据质量量度
  • 定义并实施应用于数据服务的安全策略
  • 定义企业数据服务必须遵守的服务级别协议 (SLA)

如果无法解决信息相关问题和对其应用适当的策略,会导致 SOA 中的数据服务提供低质量、不一致的数据,从而导致较差的分析和业务流程,无法满足要求。

财务

未使用 SOA 时,预算分散在项目、小组和部门级别上。另一方面,SOA 将功能作为服务共享并利用企业内的资产。因此,SOA  需要新的策略和过程(包括拖欠款项模型)以资助服务和体系结构。理想情况下,这些策略应有助于:

  • 共享作为企业范围内 SOA 支柱的硬件和软件基础架构
  • 资助多个部门共享的业务和技术服务
  • 资助不作为现有项目的一部分提供的 SOA 相关功能  
  • 资助活跃的企业体系结构小组和 SOA 研发中心(这通常发生在 SOA 之旅有条不紊的进行过程中)。

越快地平衡服务提供者(支付生产服务的大部分成本)和服务使用者(支付较少服务使成本)的利益,获取的重用就越多!SOA 通常在最初阶段花费较多成本,因为首批项目构建的服务和基础架构以后将为其他领域所用,但随着时间的推移,收益会逐渐增加。当公司停止尝试最大化本地 (孤岛) 投资而开始最大化整个企业内所有资产时, 将体现SOA 投资的最大好处和回报。
 
如果无法解决财务问题,尤其是为可重用服务提供核心资金的问题,会导致重复的技术基础架构和服务功能,以及只能满足个别项目需求而无法在部门间重用的低质量服务。

组合

需要为三种类型的组合制定策略:业务和技术(实用程序)服务组合、项目组合以及企业应用程序(原有的、ERP、打包的和自行开发的)组合。策略应该 :

  • 确保应用程序生命周期(升级、增强、维护和报废)与 SOA 战略和企业体系结构一致,尤其是与构建互操作性时基于的 SOA 标准一致
  • 确保软硬件日程和计划与 SOA 和企业战略一致
  • 创建项目以使应用程序和基础架构与 SOA 规划的里程碑和目标一致
  • 计划业务服务和基础/技术服务组合,这样可以逐步引入与使用它们的项目同步的服务
  • 确保在业务服务组合中使用的打包企业应用程序(潜在服务源)和有关新打包应用程序的决策与 SOA 战略和 EA 发展方向一致
 
人员


采用 SOA 不仅需要技术转换。 在员工中鼓励所期望行为的策略也必须是 SOA  治理的一部分。需要考虑的具体领域包括:

  • 指派负责驱动流程改进的员工(通常称为流程专员)并对其授权(SOA 是用来改进业务流程的,因此需要有人负责流程改进。)
  • 为设计、构建、测试和部署服务以及面向服务的应用程序开发所需的功能
  • 创建鼓励构建可共享服务和重用现有服务的奖励机制
  • 成立企业体系结构小组以推动采用 EA 原则,尤其是 SOA
  • 建立一个专门治理 SOA 规划的小组
 
SOA 治理小组通常由来自 EA、不同业务线和财务的代表组成。如果无法解决组织和更改管理问题,将导致缺少一致性的缓慢 SOA 采用过程,因为没有通过组织结构、培训和奖励机制对员工授权,员工不会对实现 SOA 益处负责。

项目执行

SOA  对项目执行方式有明显的影响。并非所有项目都与 SOA  技术兼容,即使专为 SOA  设计的项目也一定有一系列额外注意事项以及需要针对它们应用的额外策略。应用策略是为了
  • 确保所选项目适合应用 SOA 技巧和技术
  • 确定项目的优先级并使它们与 SOA 战略和 SOA 规划保持一致(例如,确保项目考虑了逐渐联机的服务,如业务服务组合计划中所述)
  • 满足服务投资、所有权和管理需求,包括确保服务满足现有和未来的业务需求。如果服务所有权、服务设计和治理在服务过渡到服务所有者且尚未进行服务建模和设计时完成,这将很有帮助。
  • 推动服务实施的一致性,确保设计和部署共享服务以促进和实现共享(其中一些策略也是专门针对体系结构的)
  • 满足共享 SOA 构件的创建、存储和检索需求
  • 正式定义服务、业务流程和业务规则的生命周期治理,包括服务识别
 
好的治理做法通常与成功的开源项目遵循的做法类似:社区自行决定其治理方式。得不到团队认同就传下来的治理模型通常都有损自身利益。团队需要看到治理模型和改进结果之间存在明显的关系。换言之,治理模型应该权衡重要事件,并就影响整个团队结果的事件追究团队成员的责任。
 
谈论 SOA 治理时,人们通常关注针对服务生命周期或服务生命周期治理的策略。服务生命周期治理涵盖了服务的各个方面,包括服务识别、企业服务审批、服务设计(包括界面设计、创建原则和最佳实践)、服务发布、更改请求管理、版本控制、报废、部署和操作。适当的服务生命周期治理是 SOA 成功的一个重要因素。如果没有适当的生命周期治理,服务最终也许只能满足本地项目需求:您可能拥有服务和 SOA 技术,但您几乎肯定无法实现企业面向服务的体系结构的优势。
 
UDDI 注册表和信息库等技术有助于实施服务生命周期策略, 集成的业务流程管理套件提供了管理业务流程生命周期的功能。 但是, 每个企业必须定义并实施自己的最佳实践,以确保遵循了服务生命周期策略。
 
如果不能以项目的执行方式应用相应的策略,将导致重用性不佳。重用是 SOA 的一个主要优势,众多企业求之不得。 同时,策略应该确保使用 SOA 原则构建的项目可为业务服务组合提供服务,其他项目也可从中受益。不以组合的观点看待 SOA  会导致重复劳动,因为部门间实施了重复的服务,打包的应用程序得不到有效利用,SOA  原则也无法应用于合适的项目。而且,无法实现SOA 改进的重用和互操作性等优势。

操作

企业部门间共享的服务具有需要捕获为策略的操作暗示。操作策略的运行时实施也是SOA 治理的一个方面,并受到很多人的关注。这些策略必须满足以下需求:

  • 服务的操作模型,包括服务级别提升时由谁支付额外的资源费用
  • 能力监视和计划,确保依赖共享服务的关键业务流程受到监视,并且支持这些业务流程的服务能够处理负载
  • 处理策略异常和违规
  • 服务执行,包括定义和实施运行时策略(如安全性、访问权限、日志记录和计费策略)和服务可靠性。SOA/Web 服务管理解决方案可以帮助您将运行时策略应用于服务
 
如果无法将操作策略应用于服务,将导致出现莫名其妙的SOA。在这些SOA中,重用难以实现且安全性实施效果低劣僵化。

0

阅读 收藏 转载 喜欢 打印举报/Report
  

新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

新浪公司 版权所有