SOA实施收益分析

标签: IT咨询 | 发表时间:2014-08-18 16:10 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
远行科技自2007年开始即参加了中国移动集团SOA接口平台的建设和实施工作,在SOA规划咨询,建设实施方面有丰富的实践经验积累。对于SOA实施收益,先以某客户的一个真正业务背景进行分析:

业务场景:我们现在的工程项目管理,其规划,立项和工程实施计划在项目管理相关系统;工程物资采购在采购管理系统;审批在 OA系统,财务的信息又在ERP核心系统。做为领导要了解工程项目全貌,需要不断反复登录不同的系统。而且现在还存在同样一件事情要在不同系统多次重复处 理的情况。

解决思路:不实施SOA该问题很难解决。而SOA本身就是基于流程驱动IT的思路构建的平台。在前期数据集 成服务实施后,很容易通过服务组合实现跨越现有IT系统边界的BPM业务流程整合,并且通过SOA提供的管控平台实现流程的集中管理和监控。包括后续根据 业务调整流程也可以通过SOA的流程设计器快速灵活配置。

业务场景:MSS域的ERP系统向采购子系统提出了需要采购订单数据信息的数据集成和接口需求,究竟该如何做?现状是知道如何做,比如开发视图,接口表,或作个WebService,但是按照什么样的规范来做?如何保证接口的稳定和正确性不清楚。

解决思路:SOA解决方案是一整套的SOA服务识别,开发和接入规范,包括后续SOA服务管控机制。这也是远行科技多年SOA实践经验的一线积累。

业务场景:采购,项目管理,运维系统都再向ERP提同一个业务对象的接口需求,各个需求还有差异。同样一个接口反复开发,版本还无法一致。

解决思路:由于点对点连接,重复开发接口的现状是无法避免的,而且后续大量的不同版本的接口管理和运维工作量巨大。而SOA解决方案则是统一在分析流程基础上识别和定义服务,打破原来的点对点连接。

业务场景:ERP核心子系统开放了一个接口视图出去给其它的业务子系统。采购,项目管理,运维系统都在使用。究竟接口被使用了多少次,谁使用了,取走了多少数据,什么时间取走的数据我根本无法跟踪和监控。数据安全性很差。

解决思路:SOA解决方案是将接口实现为服务,对于每一个服务都可以独立进行访问授权和传输数据的安全性加密。通过通过服务运行监控能够看到每个服务的运行时间,输入输出数据等详细信息。

业务场景:ERP核心子系统向采购子系统反馈,上周给过来的一份采购订单数据有错误,采购子系统核查自己系统又反馈是正确的,双方无法确认问题源和责任方。

解决思路:SOA集成平台中,服务的每一次调用SOA集成平台都可以详细记录到调用的时间,调用的业务子系统,调用的具体数据情况。

业务场景:采购子系统不断的再向ERP核心子系统提交接口和数据集成的需求,都是流程走不通了,想到一个做一个。而且经常围绕一个采购订单业务对象不断在开发不同的数据接口。而且一个接口视图往往逻辑复杂,访问多张数据表关联才能够完成。

解决思路:SOA解决方案是通过业务流程的梳理识别和发现服务,确保没有服务遗漏。同时SOA解决方案中识 别的服务既包括了粗粒度的服务,也包括了细粒度的服务。满足流程的粗粒度的服务是由各个细粒度的服务组成的。细粒度的原子服务可以很好的进行复用。因此当 出现流程整合新需求的往往并不会开放新服务,而且组合已有的旧服务。

业务场景:我基于原有的数据接口方式和原有的IT子系统,不走SOA也能够实现流程整合,那么走SOA实现流程整合的收益在哪里?能够解决传统流程整合的什么问题?

解决思路:注意传统方式的流程整合,流程的整合实现是通过IT系统硬编码实现的,暂且不说开发工作量,其本身后续的扩展性和运维工作量就很大。其次流程整 合一般或跨越多个IT子系统,流程的全貌和流程进展情况没有一个地方可以全程跟踪和监控,流程虽然整合了但是流程没有实现可视化得监控。最后,为了流程整 合,需要多个IT子系统配合不断的需开发,实现和测试新的数据接口。而通过SOA方式本身就是流程驱动的服务发现,服务时细粒度的,流程整合需要的服务基 本在前期都已经识别,仅仅是通过对服务的组合,通过BPEL流程设计就可以实现流程整合。

下面再综述下SOA实施带来的业务收益和技术收益。

对于SOA平台项目建设的ROI(投资回报)计算往往是一种定性计算的过程,因为SOA项目的建设不仅仅是SOA集成平台的搭建已经已有的IT系统的改造,同时更重要的实现端到端业务流程的整合和商业变更。具体的项目建设收益分如下几点进行描述:

1.减少固定支出

SOA提供了四种基本收益:减少结合支出,提高资产再利用,提高商业灵活度以及降低商业风险。这四种核心收益会为这个组织的很多层面和部分带来收益,这取 决于这个将SOA应用于哪类商业问题。首选,实行松散结合方法将减少复杂度,从而减少综合和掌握分散环境计算的成本。尽管面对标准接口,如Web服务时, 结合成本将减少一些,但SOA的真正价值在于用粗颗粒,松散结构的服务取代了很小的细致间隔尺寸,从而可以比基于API的综合更方便的处理范围更更大的综 合。

使用SOA来减少综合支出的投资回报计算是相当直接的。SOA实施后我们可以将基于Web服务的SOA中的投资和一种传统的IT系统建设投资进行比较。具体固定支出减少方面如下:

  • SOA集成平台降低了IT资源和人力资源投入成本
  • 基于SOA的流程整合,降低了业务和流程变化造成的改造成本
  • SOA实施进一步优化管理流程,减低了管理本身成本
  • SOA规范和治理体系的建立,进一步降低后续IT系统运维成本

2.提高资产再利用

对于SOA项目的实施,不仅仅是减少企业的各种支出,更重要的是对对现有服务的再利用可以为寻找实施SOA的公司提供附加的投资回报。众所周知,一般企业 在为那些有持续变化的需求的项目构造新设备时花费的时间和预算都很少。缺乏发展新设备的重视的一部分原因在于这些新应用需要频繁产生且与之前已存在的应用 不相关,这会导致一个新的IT问题,这将导致必须综合新的成份,使我们之前提到综合的问题更加恶化。显然,建立新的应用时不仅需要减少开发成本,而且随着 时间的推移保持不变性。

SOA的一个重要收益在于使用者可以产生新的商业过程交与现在的服务进行合成。换句话说,浙江联通可以通过SOA集成平台提供的流程整合功能,不断的重新 整合和编排已有的服务,而不是重新开发新的IT系统和功能,通过复用以达到已有IT系统各种功能和服务的循环利用。由于这种方式可以创造新的服务,并且可 以循环利用,公司可以从他们为合成应用的投资中得到回报。因此,合成应用的开发作为SOA的杠杆的经济性将随公司创造并再重复利用的服务数量的增加而增 加。这有可能使得现在用于综合的70%的资金用于新的开发。公司在实施这种SOA的资产再利用获得的收益不仅仅是简化的综合带来的成本降低,而且改善了从 产品到市场的时间,更敏感的客房服务,总体员工数的减少以及更有能力进行外部采购或产生、实施服务。

3.增加商业活力

减少成本和增加重用为SOA提供了清楚的ROI,与之相比增加商业活力是SOA最有前途的收益同时也是最难量化的。综合简化和增加重用是以技术为中心的收 益,商业用户同时也期望从IT业获取更大的灵活性。与其一开始简单地构建所需的条件然后一头撞在长以月计的实现周期的IT“开发墙”上,商业用户更加想直 接控制他们的运作以便能够迅速地根据市场变化而改变他们的业务。

为计算商业活力所需的ROI方案着力于商业用户直接控制商业过程的精确度和管理的能力。通过面向服务的过程可以实现端到端流程的整合。流程的整合不仅仅是 企业内跨越了原有的IT系统边界,跨越了原有的业务部门便捷的流程整合,更重要的是通过SOA流程整合还能够进一步实现了企业上下游供应商和客户的流程整 合,通过这种方式显著提高了业务效率和业务全流程的管控能力,这些都应该是SOA投资所产生的商业利润。因此,利润不仅影响了底层公司的运作,同时也影响 着它的上游(产业)。增加的商业活力可能以获得浙江联通以前被认为不能取得的收入来源为结果,并且为浙江联通提供不同的途径为他们的供应商或者商业伙伴提 供利润以便获得新的重大的商业机遇。通过将 SOA的区域扩展到商业用户,可以将ROI作为一个整体发展到商业领域,而不是简单地作为IT业的一部分。

但是,计算SOA的商业活力的ROI是格外困难的,因为将要新增的IT资源是天然地不可预计的。毕竟,活力的全局点可能涉及不可预期的变化。因此,将商业 活力ROI限制在一个特定的范围是讲得通的,例如,在产品信息规则变化的情况下,商业伙伴和程序或者其他供应链角色,对应地有规律地修改。

4.降低业务风险

按照规则处理是提高业务活力的一种必不可少的方案,因为这种规则具有随意性,并且会随着时间的改变而改变。现在,像Sarbanes Oxley、PATRIOT 法案以及Base II等规则在一些IT实现的公司内部已经有了改变。如果不服从规则,浙江联通的经济状况以及主管人员的自由将会受到严重的负面影响。许多企业的业务操作并 不透明,所以他们不得不依靠制定一些聪明的决策计划来控制他们的风险,但却无视增加透明性的要求,这种透明性正是他们的规则所必需的。

对于SOA实施带来的技术收益如下:

SOA平台管理模式的优势

  • 采用平台中心集中和节点分布管理的模式,适应机构之间垂直和横向行政管理关系并存的需求;
  • 平台提供系统统一集中远程部署管理、完善的安装、远程服务组件部署、配置、远程监控等手段,保证平台高度的可管理性和维护性;
  • 系统支持多种应用管理模式,如集中控制管理和分级递阶控制管理等应用管理模式,适应机构纵向、横向、分级等多种管理模式的要求。

SOA平台软件架构的先进性、可扩展性

  • 采用完整、先进、成熟的软件技术和产品,充分利用中间件和企业服务总线(ESB)技术,采用完全分布式、事件驱动和面向服务(SOA)的架构设计;
  • 平台底层采用可靠数据传输的中间件技术,节点业务系统之间的交换采用端对端(P2P)的可靠数据安全传输机制;
  • 软件平台在架构方面保证了灵活的可扩展性,当节点和业务增加时,因为数据无须经过中央服务器,从而避免平台的效率瓶颈和中央服务器单点故障;
  • 平台采用可重用的服务组件化设计,服务组件及适配器可重用性高,并支持配置管理和分布式远程部署。

SOA平台的安全性优势

  • 基于底层的可靠数据传输的中间件技术,系统提供任何节点之间的可靠事件传输、断点续传等功能;
  • 系统支持传输数据压缩加密的技术,保证数据的保密性、完整性和有效性,并通过集成第三方提供的CA/PKI身份认证服务,可实现节点之间的安全身份认证。
  • 系统通过服务器备份和服务组件备份的两种备份机制,提供一定的容错能力与容灾能力,充分保证数据安全和系统的可靠性,重要数据的完整性、一致性和可恢复性;
  • 系统具有安全运行管理措施,提供了服务异常告警和安全日志的功能;
  • 系统平台提供了对业务数据(流程)的监控功能,以及使用工具来跟踪查找事件的功能。

SOA平台能够提供很好的互操作性、兼容性,有效地保护现有投资

  • 平台由Java语言开发,支持Windows、Linux/Unix不同的操作系统,并支持主流数据库系统的市场现行版本,包括Oracle、DB2、SQL Server、Sybase等;
  • 平台提供的预制适配服务组件,支持主流的应用服务器(J2EE 和.NET应用服务器等)软件市场现行版本,以及支持主流的消息中间件服务器(MQ, JMS Server)等产品,
  • 平台支持用不同的语言开发服务,如Java、C/C++、VB、C#等,并提供多种语言(Java、C/C++、VB、C#)的API集成接口,满足集成不同委办局异构系统的要求。
  • 平台系统具有强大的对现有各种异构系统的整合能力,有效地支持与各种消息中间件、各种异构数据库和不同语言开发的应用系统整合,最大限度地保护客户现有的投资。

遵循业界规范和开放性原则

开放性体现在平台架构和组件技术上,如采用面向服务的架构(SOA)和JMS、Web Services,JCA等通用组件标准。业界标准和开放性是保护客户投资的有效保障。

提供多种数据传输机制

提供同步传输、异步传输两种数据传输机制。支持多种通讯传输方式如HTTP(s)、异步可靠事件方式(JMS、Web Service等);提供穿透防火墙(逻辑隔离)的数据库、文件传输机制;

可扩展性、伸缩性强、部署机制灵活

随着信息化建设的发展,系统的扩展将是不可避免的,保护投资是系统设计需要考虑的。因此,提高系统的可扩展性、可维护性是提高系统性能、保护投资的重要手 段。 端对端(peer-to-peer)和面向服务(SOA)的分布式软件架构可充分保证平台的可扩展性,因为节点数的增加不会产生中央服务器的效率瓶颈。平 台提供集成一体化的服务组织工具,灵活构建电子商务/政务应用系统。变化是永恒的,集成一体化的流程建模、部署和管理工具,可以动态改变业务流程,适应企 业的需要。

SOA平台的高可靠性

平台系统底层基于成熟可靠的中间件技术,保证其高稳定性和可靠性。除了服务器热备份技术外,系统自动监测服务组件故障,提供服务组件级备份方案。
  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [soa 收益 分析] 推荐:

SOA实施收益分析

- - 人月神话的BLOG
远行科技自2007年开始即参加了中国移动集团SOA接口平台的建设和实施工作,在SOA规划咨询,建设实施方面有丰富的实践经验积累. 对于SOA实施收益,先以某客户的一个真正业务背景进行分析:. 业务场景:我们现在的工程项目管理,其规划,立项和工程实施计划在项目管理相关系统;工程物资采购在采购管理系统;审批在 OA系统,财务的信息又在ERP核心系统.

SOA资料学习

- - 人月神话的BLOG
从对象到组件,首先可以把对象理解为更细粒度东西,而组件是更加粗粒度的模块,对象更多关注技术,而组件应该更加关注业务. 前面我们谈过技术组件和业务组件,在SOA思想下业务组件化的思想就更加重要. 组件本身而言很简单,南向接口和北向接口,或者再有底座平台支撑. 接口通过服务方式来实现,组件通过OSGI等技术实现高度的解耦和可热插拔性.

SOA架构咨询

- - 人月神话的BLOG
对于SOA架构咨询,其核心还是在于组件化和服务化,然后才是服务管控和治理,基于服务化思想对传统软件开发生命周期过程的改进. SOA架构大家刚接触时候很容易将其理解为一种单纯的技术架构,或者更多的人仅仅是将SOA理解为service服务接口,这些都是对SOA方法论很大的误解. SOA咨询一个重点就是业务驱动IT,而非单纯的IT架构咨询,SOA咨询一般都会结合企业架构和云的思想,结合组件化架构和领域服务的思想,高层结合BPM端到端流程整合目标,并对这些内容进行有效的融合.

从流水程序到SOA

- Allen - 阿朱=行业趋势+开发管理+架构
咱就从函数代码开始谈起,更史前的Goto和汇编代码咱就不谈了. 函数和变量写多了,自然也就发现有些函数和变量互相粘在一起很高耦合,而与其它的一些却没多达关系,于是为了显性化让其他的开发人员知道哪些函数和变量确实关联性很紧密,于是创造了类. 面向对象在80年代的国外代码开发界颇为流行. 但接口思想的风潮在90年代刮起了.

eBay开源SOA-Turmeric架构

- - 人月神话的BLOG
参考: https://www.ebayopensource.org/wiki/display/TURMERICDOC/Turmeric+Documentation+Overview. Turmeric是一个综合的、由策略驱动的SOA平台,提供了对SOA服务及其消费者的开发、部署、保护、运行和监控等方面的支持.

SOA面向服务架构

- - 人月神话的BLOG
今年在这点上谈的比较多,也逐步开始落地实施,将SOA咨询和实施方法论从系统间真正的引入到系统内,将面向对象的需求分析方法和SOA思想进一步融合,从业务建模到系统用例建模,从流程分析到服务识别和分析,从业务组件化到系统模块化,这些工作都逐步开始落地实施. 这样做的好处就是进一步的体现SOA可复用组件的价值,真正的做到业务组件化和组件能力化.

[SOA] Mule ESB Linux 部署

- - CSDN博客架构设计推荐文章
本文介绍如何在 Linux 上部署 Mule ESB. Mule 是一个以Java为核心的轻量级的消息框架和整合平台,基于EIP(Enterprise Integeration Patterns,由Hohpe和Woolf编写的一本书)而实现的. Mule的核心组件是UMO(Universal Message Objects,从Mule2.0开始UMO这一概念已经被组件Componse所代替),UMO实现整合逻辑.

集成ESB实现SOA

- - 企业架构 - ITeye博客
  服务消费者,服务提供者, 服务注册中心(UDDI模型). 由于UDDI模型过于复杂,而服务提供者与消费者点对点的进行协作依赖性大大增强,因此产生演变.    服务代理 -- ESB.    基于ESB总线,使得服务请求者统一入口,而ESB管理服务,使得耦合降低,由ESB来应对提供者提供的服务的改变而服务请求者不需要进行任何的修改.

数据交换和SOA服务共享

- - 人月神话的BLOG
数据本身只是一种资源,而服务是一种能力;数据仅限于各种结构化和非结构化的数据资源,对于数据资源提供的能力可以使一种数据服务,而数据资源+业务规则形成的某种业务能力也可以作为一种服务提供,也就是说各种技术,数据,业务,平台,流程能力都可以做为服务提供. 交换本质是资源会从一个系统通过传输的方式进入到多个系统,资源在多个系统中形成多种拷贝.

基于经验的SOA成功原则

- - InfoQ cn
多年以来,我们对 SOA 原则这一主题以及什么会促进SOA成功,什么会阻碍SOA实施等内容都进行过很多相关的报道. 从初期的狂热宣传,到大规模企业的实施、Web服务以及较近期REST带来的影响力. 我们可以通过这7年来的文章,对SOA的演进进行追溯. 然而,在此期间的成功案例却通常少之又少,据一些数据表明仅有 20%的SOA项目获得了成功.