——普元软件副总裁刘尔洪
从SOA的目标说起
SOA作为一种企业架构,其终极目标是提高业务的灵活性,从而实现敏捷企业。过去,我们企业在很多年的IT建设过程中,通过不断积累,形成了一大堆的IT系统,僵化的架构,重复的功能开发,不仅使得企业应用定制起来耗费时间,成本昂贵,而且已经影响到企业在面向竞争环境能否做出快速的响应,这对于经营管理依赖IT支撑的行业尤其重要。有一个数据统计,我们现在IT支撑能力,响应变化能力,实际上落后于我们实际业务变化能力的7到20倍。
而SOA提供了IT架构的灵活性以及IT资产的复用性,简单来说,实际上就是把企业的IT作为一种资产,并且通过重新编排业务流程可以在这个基础上快速的组合成企业的新业务和新的运营模式,从而形成对业务支撑迅速响应能力。
仅仅“ESB+BPM”无法实现SOA理想
SOA的一个理想图景,如下图所示:
现在很多人解释SOA解决方案的时候,基本上和这个图大概类似。就是原来有很多的遗留系统也好,新建系统也好,进行服务化的分割包装,通过ESB注册管理起来,ESB主要完成消息转换、路由等通信机制,最后通过BPM进行流程编排,从而把一些服务组装成一个新的业务。在业务需求变化的时候,只要通过上层的业务流程的调整,即可快速实现对新业务需求的支持。
实际上,这是一个非常理想的状况,把问题简单化了。仅仅ESB,或者在ESB上加上BPM,显然不能解决我们说的目标当中要实现敏捷型的企业。下面我们将通过一个例子来进一步分析和阐述。
从案例体验服务构造和业务化流程重要性
这里讲一个电信运营商随着精细化管理的演进而产生的问题的例子。作为电信运营商,在激烈的竞争环境下,运营商对差异化营销和精细化管理要求越来越高,引入SLA(Service Level Agreement,服务等级协议),通过对不同类别的客户提供不同等级的服务质量可以提高运营商差异化服务能力。实际上SLA并非只是电信运营商需要,它在所有的自由竞争市场都需要。
这种管理模式的转变,首先会引起电信产品销售流程的改变。拿一个具体的电信业务例如DDN(数据专线)的销售流程,之前只需要提供源点和终点地址,电信运营商就可以通过一系列链路配置开通这个服务;增加了SLA之后,客户可能会要求接通率、开通时限、是否提供备用电路等质量指标。这样代理的变化是在运营商产品销售之前需要客户经理与客户充分沟通,与客户就SLA保障指标和商务达成一致,而且,由于要在各个环节支持SLA合同的落实,对于后台的支撑系统带来非常大的影响。经过我们对流程和后台服务的梳理分析得到如下结论:
流程中存在大量的人工处理环节,人工处理尤其在中国远远比自动活动(服务)在流程模式的处理上要复杂得多
对于自动活动(即服务),又存在如下问题:
53%的服务需要改造。因为我这个服务不合适了,要去调整这个服务
20%的服务需要重建,原来不存在
只有27%的服务可以完全重用
从这个例子里可以看出,在管理流程演化的时候,作为支撑的IT系统,不是简单经过自动服务的重新编排就能快速满足的,所以实施SOA的挑战在于:
实施SOA的最大业务阻力来自企业管理层对于业务流程的认识,因为SOA对管理流程要求高,当然也包括企业组织是否健全,是否稳定等等
管理精细化要求业务流程不断优化,业务流程不断优化意味者需要服务粒度不断由粗变细,在这样一个变化的环境下,很难定义多大的颗粒度的服务是合适的,所以必须要有灵活的架构来支持服务的构造是非常重要的问题,也是难点
管理流程需要不断演进,很多流程是基于人工活动的流程,如果要让IT能够跟上经营管理的变化,在技术上这就需要业务流程平台,这个业务流程平台需要有强大的在业务层面配置流程的能力,并能满足中国国情的特点,尤其在人工活动处理能力上,例如:我们在工作代理上就存在多种模式,我可以让他人在一段时间内代理我所有工作和部分工作,也可以让他人代理我的部分职责,还可以由我的上级指定在一定的情况下由某人代理我的工作等等,这些显然是在中国环境下经常会碰到的业务场景,单靠BPM很难解决
服务构造的技术难点与解决之道
首先SOA服务颗粒问题难以通过规划解决。目前做SOA实施无非是两种模式,一种是自上而下的模式,一种是自下而上的模式。自上而下是说从企业愿景、战略目标到组织结构到管理体系最后到IT规划,通过IT的规划抽取合适的服务。中国市场的特点在于其处于不断的市场化进程中,还有很长的管理上的演进路线,未来两年到底会发生什么无法预料,比如中国的电信行业,经历了多次分拆重组,即将跨入3G时代,现在将铁通并入中国移动,联通CDMA网并入中国电信,剩下的中国联通和中国网通再进行合并,这样的变化在2年前可能是很难预测的。
而所谓的自下而上的模式,就是我先看我现在看得清的一些问题,比如我现在要加强客户关系管理要实施CRM,对于这个应用应该提取哪些公用服务,比如产品管理可能和我其他系统都有关系,那么我就重点梳理一下产品管理相关的服务,这种方式从投资收益的角度,投资回报率要更高一些
无论用哪种规划方法,实际上都无法解决服务构造本身的颗粒问题。原因在于它是一个渐进的演变的过程,至少目前是很难通过规划的方式去解决的。
其实,我们现在建设应用系统时也有很多的体会,构造服务的时候一样会存在这些问题,比如:
越大的项目达不到预期的概率越高,客户满意度越低
项目实施周期和质量都不可控,常常拖延工期和发生质量问题
技术人员很辛苦,但价值得不到体现;软件企业管理代价高,人员流动性大;而项目质量取决于参与的每个工程师个体能力和素质
难以进行知识转移和知识承接,知识积累困难
服务构造的标准化问题
这些问题源于3个方面:软件规模和生产率的矛盾;可扩展、快速变化和高质量的矛盾;三是软件生命周期全程可管控问题。
有效解决这些问题,首先我们需要建立适合的SOA服务架构,我们能不能把复杂服务,分解成稳定的单元,有限的收敛单元是很重要的,如果我们今天统一都用汉字,大家知道中国常用汉字就5千个,汉字上组成词组,汉字和词组组成文章,这样就可以做成每个人可以理解的文章。其次建立统一封装的平台化架构。平台的一体化和完备性是解决灵活、管控的必要条件。最后我们需要一套建立在可管控的工具基础上的项目管理方法。
业务化流程的技术难点与解决之道
任何管理体系的建设,都需要从流程、组织、人、KPI四个要素方面去考虑。大家可以看到,在管理上,无论流程也好、组织也好,人也好,KPI也好,都会经常不断变化,今年可能和去年都不一样,所以我们在去实施SOA的时候,要敏捷地支撑这样的变化,让我们的管理演进与同步起来,必须要一个流程平台支持这样的变化,而除了本身的系统特性(比如性能、稳定性等)外最重要的特性就是能够在业务层面上能很好的去配置我们刚刚讲的四个要素的灵活变化,并且要很好地解决复杂的中国国情下的人工处理活动。
业务化流程的解决之道,就是“让业务人员和技术人员能够更融洽的协同工作”。传统的“流程分析——流程梳理——技术实现——流程部署”实现方法带来很多弊端:技术人员很难理解业务人员的设计;技术实现周期长;当业务变更时,很难快速响应。
业务化流程就是将流程让业务人员更多的参与到“流程设计、流程组装、流程测试”中,才能快速应对业务流程的变更。而传统的BPM产品也很难解决这些问题。
所以我们在看任何一个新的技术概念的时候,应该更多地从其要解决的客户问题本质入手,而不是人云亦云,只有了解了本质问题,我们才能从企业今天解决问题的实际绩效入手选择适合自己的解决方案和产品。
原文出处:http://gocom.primeton.com/modules/newbb/item53767_53767.htm
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
事件驱动框架和SOA在空军的应用
空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。
-
揭秘New Relic APM技术细节
New Relic应性能管理(APM)套件主要用于Web软件开发。它允许用户在面向服务的架构(SOA)上跟踪关键事务性能,并且支持代码级别的可见性来评估特定代码段和SQL语句对性能的影响
-
仅凭SOA和云无法解决业务数据管理风险问题
SOA和云可以是某些恼人问题高效的解决方案;这一点我们已经知道了。但是也要记住它们并不是所有事情的直接答案,特别是当你的问题是业务数据管理风险,而不是技术问题时。
-
如何避免云计算与SOA冲突