[SOA征文]从业务驱动看业务端标准化的必要性 推荐
2008-05-20 21:31
267 查看
业务驱动服务,服务驱动技术,一直被作为SOA的一个比较重要的应用思想,在前面,我讨论了在业务端进行标准化或者说SOA化的必要性,今天继续说一点。
这句话比较概括的说明了SOA的工作过程,由业务来决定需要什么服务,再由服务将需求传递到技术端,调用相应的组件完成相应的动作并返回输出结果。从这个意义上说,服务需要调用技术端的什么组件,很大程度上是由业务端来决定的。如果前端业务庞杂无序,那么可能直接对在系统中构造业务所需要的服务造成影响,简单的说,如果服务的粒度较大,则将直接造成服务数量增加,因为不同的业务可能需要完全不同的业务来构造;如果服务的粒度较小,当然可以较好的控制数量,但将增加业务流程构造的复杂度,因为构造不同的业务流程必将需要更多的服务,其结果是增加了复杂度,也相应的大大降低系统效率,占用更多的系统资源。这两种情况,无疑都是不利的。无论是增加服务的数量还是增加业务流程的复杂程度,都会对系统稳定性、可靠性以及可用性造成严重的威胁,而另一方面,也会对于业务的可移植性和成功经验的可复制性造成较坏的影响。
可以用一个简单的例子来说明,把业务端看成是一个输入设备,服务看成类似滤波器或者变速箱一类的设备,技术端则看作是执行机构,可以想像,如果输入到系统的数据有不同的格式、单位等等,既由公制又有市制还有英制,那么滤波器或变速箱的复杂程度无疑会大大的增加,那么故障几率也就呈指数式的增长了。
实际上,在技术端,这样的问题也都存在,SOA在技术上一直存在这不同的技术路线,其一是彻底重新部署,这样技术上相对比较统一,效率也较高,其二则是通过EAI等手段利用适配器等手段对已有系统进行整合,当然这两种方式的特点我们也都非常熟悉了,前者的可靠性统一性等各方面较优,但是成本较大,而后者可能相对部署难度和成本方面占优势;类比到业务端,如果不对业务端进行必要的梳理和标准化工作,那么也就是等同于使用大量的适配器。
如果在业务端进行业务的标准化工作,无疑是在源头上对整个系统的复杂性作出很好的控制,并且对于不同的组织,其可复制性能够得到比较好的保障。
对于很多组织而言,在业务标准化上持保守态度的一个比较重要的原因是在传统的业务中存在有较多的控制点,其源头在于内部控制体系或者合规性等方面的要求,尤其是公共机构如政府机构等,受到较多的法规管制,因此对业务进行变动存在较大的难度。而实际上随着一些技术手段的应用,可以通过一些其他的手段减轻有关限制产生的影响。例如对于很多业务流程所需要的控制点的问题,因为业务电子化程度的提高,可以通过在系统业务流程中设置相应的触发器等各种手段,以旁路监听的形式对业务进行监控,或者通过数据整合后部署BI技术,以业务仪表盘等等形式对业务性能进行管理(即BPM,BUSINESS PERFORMANCE MANAGEMENT),在此情况下,作为业务标准化的另一个优势,对于不同的业务其KPI也得到相应的统一,在BPM上也可以得到统一的应用,反而增加了对于业务的控制能力。
最近几天,因为众所周知的原因,没有心思写这篇东西,有若干次打开文件也完全没有办法继续。今天终于完成了,实际上里面不少地方非常粗糙,在此向大家致歉。
这句话比较概括的说明了SOA的工作过程,由业务来决定需要什么服务,再由服务将需求传递到技术端,调用相应的组件完成相应的动作并返回输出结果。从这个意义上说,服务需要调用技术端的什么组件,很大程度上是由业务端来决定的。如果前端业务庞杂无序,那么可能直接对在系统中构造业务所需要的服务造成影响,简单的说,如果服务的粒度较大,则将直接造成服务数量增加,因为不同的业务可能需要完全不同的业务来构造;如果服务的粒度较小,当然可以较好的控制数量,但将增加业务流程构造的复杂度,因为构造不同的业务流程必将需要更多的服务,其结果是增加了复杂度,也相应的大大降低系统效率,占用更多的系统资源。这两种情况,无疑都是不利的。无论是增加服务的数量还是增加业务流程的复杂程度,都会对系统稳定性、可靠性以及可用性造成严重的威胁,而另一方面,也会对于业务的可移植性和成功经验的可复制性造成较坏的影响。
可以用一个简单的例子来说明,把业务端看成是一个输入设备,服务看成类似滤波器或者变速箱一类的设备,技术端则看作是执行机构,可以想像,如果输入到系统的数据有不同的格式、单位等等,既由公制又有市制还有英制,那么滤波器或变速箱的复杂程度无疑会大大的增加,那么故障几率也就呈指数式的增长了。
实际上,在技术端,这样的问题也都存在,SOA在技术上一直存在这不同的技术路线,其一是彻底重新部署,这样技术上相对比较统一,效率也较高,其二则是通过EAI等手段利用适配器等手段对已有系统进行整合,当然这两种方式的特点我们也都非常熟悉了,前者的可靠性统一性等各方面较优,但是成本较大,而后者可能相对部署难度和成本方面占优势;类比到业务端,如果不对业务端进行必要的梳理和标准化工作,那么也就是等同于使用大量的适配器。
如果在业务端进行业务的标准化工作,无疑是在源头上对整个系统的复杂性作出很好的控制,并且对于不同的组织,其可复制性能够得到比较好的保障。
对于很多组织而言,在业务标准化上持保守态度的一个比较重要的原因是在传统的业务中存在有较多的控制点,其源头在于内部控制体系或者合规性等方面的要求,尤其是公共机构如政府机构等,受到较多的法规管制,因此对业务进行变动存在较大的难度。而实际上随着一些技术手段的应用,可以通过一些其他的手段减轻有关限制产生的影响。例如对于很多业务流程所需要的控制点的问题,因为业务电子化程度的提高,可以通过在系统业务流程中设置相应的触发器等各种手段,以旁路监听的形式对业务进行监控,或者通过数据整合后部署BI技术,以业务仪表盘等等形式对业务性能进行管理(即BPM,BUSINESS PERFORMANCE MANAGEMENT),在此情况下,作为业务标准化的另一个优势,对于不同的业务其KPI也得到相应的统一,在BPM上也可以得到统一的应用,反而增加了对于业务的控制能力。
最近几天,因为众所周知的原因,没有心思写这篇东西,有若干次打开文件也完全没有办法继续。今天终于完成了,实际上里面不少地方非常粗糙,在此向大家致歉。
相关文章推荐
- [SOA征文]关于业务标准化问题的一些讨论
- 面向服务体系架构的业务规划和建模方法系列之三--SOA方法裁减样例 推荐
- 业务架构驱动的需求开发 推荐
- [SOA征文]SOA如何起步? 推荐
- [SOA征文]SOA与救灾的几点思考 推荐
- 面向服务体系架构的业务规划和建模方法之六-SOA项目的导入策略 推荐
- 业务用例在SOA业务建模中的交叉使用 推荐
- [SOA征文]SOA学习启示录:没有规矩不成方圆 推荐
- [SOA征文]举步维艰 SOA该如何落地中国 推荐
- SOA业务规划和建模简介 推荐
- [SOA征文]谈谈资源端的SOA化 推荐
- 使用业务驱动的开发为卫生保健组织开发 SOA 解决方案
- 大数据驱动业务增长:百度外卖商业智能推荐系统实践
- HENXU-SOA的业务规划和建模方法之七——SOA的方法融合 推荐
- 面向服务体系架构的业务规划和建模方法系列之五——SOA项目中IBM产品的采用 推荐
- 项目管理-文档标准化的必要性 推荐
- RUP大讲堂(第七讲)-SOA的业务本质 推荐
- RUP大讲堂(第二讲):业务驱动开发的原则 推荐
- [SOA征文]SOA成为江湖利器的几个关键问题 推荐
- HENXU-SOA的业务规划和建模方法之八——组件化业务模型(CBM)介绍 推荐