平庸与杰出=加法与减法

思考其乐无穷 IT剩者为王

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  29 随笔 :: 1 文章 :: 145 评论 :: 3 引用
上篇《乱弹SOA》是乱七八糟的说了一堆,没个主题也没结论,没想到阅读量还挺高,窃喜;没有多少同仁留言回复,稍有不爽。不过没关系,只要同仁喜欢俺就继续献丑继续乱弹。

下面就从业务敏捷之定义-〉 为何需要业务敏捷-〉SOA如何支持的思路探讨SOA之业务敏捷,如有不妥之处请同仁手下留情,慢慢拍来。

业务敏捷既是对软件使用者(企业)又是对软件提供者(厂商)的要求。
企业发展是一个循序渐进不断演化的过程,企业的经营项目、经营模式都在不断地变化中,可以说企业的发展是一个动态的过程,只有变化才能跟上时代的发展不至于落后。从这个方面来讲,企业需求分为两个方面一个是当前需求,另一个是未来需求;当前需求基本是当前管理模式或者管理制度的副本,而未来需求具有极大的不确定性,这些不确定的需求包括对已有需求的变革和增加新的需求。这就要求软件系统能够及时响应企业需求变更。

业务敏捷就体现在这个“及时”上,物流强调的是在适当的时候送达适当的地点,而业务敏捷要求软件系统在适当的时候实现适当的需求。这个适当的标准就是及时,不能因为软件不能适应业务需求而耽误企业业务进行。如果厂家不能及时实现,那么厂家就是企业业绩不佳的罪魁祸首,这套软件就属于被替换目标,厂家就少了一个或多个客户,多了一分批评。

这个“适当”看起来简单做起来却相当的困难,首先要求企业能提出适当的需求模型,然后软件根据这个模型调整流程或者开发新的插件。长期从事在软件行业第一线的需求调查人员、实施人员肯定感触颇多,企业的一个句话可能包含一个相当有趣的需求,或者是一个根本没有前景的需求。而作为软件提供商需要甄别这些需求,对需求进行整理、建模,这个过程可快可慢,主要看双方的经验以及沟通效率(关键在需求调查人员的水平)。需求确定后主要看软件提供商的执行效率,而执行效率的高低却要看软件的设计是否合理(包括可扩展性、健壮性...).

下面详细论述如何实现这个需求。

大体上企业信息化是先从内部管理开始(传统的MIS)到现在的覆盖整个分销体系的供应链管理系统,期间还穿插着一些OA、CRM等信息化过程,简单来说可以分为内部管理和外部管理,是一个从简单到复杂、从内网到外网的过程。

在八九十年代,我们要实现一个需求很简单,加几张表改一下程序,甚至连setup都不需要,但是现在这样肯定是不行的,咱们就不去论述传统软件的缺点了,毕竟批评别人不是光彩的事情,另外咱们也都是那个时期过来的么

我们将企业的需求放到以下几个场景(类别)中,这样便于理解,但有个缺点是不够全面(缺少的请各位补上来),这里假设的场景都是针对“大型、复杂”应用,比如OA、CRM、DRP、SCM等。另外将需求粗略分为服务使用者和服务提供者。

场景1:范围扩展--从传统的内部管理向外部管理扩展,这就要求已有软件能支持web应用或者能够提供远程访问。但是传统软件在这方面是个软肋,既是勉强实现也需要高昂的代价,包括时间和费用;但是基于SOA(服务)的软件系统可以非常容易的构架在internet上,提供远程访问。可以说,soa可以很好的保障企业在信息化方面的投资。

场景2:业务协同--内部协同和外部协同,协同最近这两年也是相当的火,虽然火却没有明确的定义,各大厂商也有不同的定义,但归根结底协同的目标就是让组织中的机构或者成员能够有效沟通,提高效率,至于协同的对象就看企业的需求了。试想两套传统软件要实现系统需要做那些工作,大家肯定首先想到的是eai,的确eai就是为了解决协同而生,但是从eai这些年的成绩单来看,相当的不理想,距离业务敏捷相当的遥远。当然这不是eai的问题,而是传统软件的先天性缺陷造成的,后天的补丁,怎么补都不牢靠。但是如果两套系统都基于soa架构,这个协同就变得轻而易举(有点夸大了)。轻而易举的原因在于服务,只要实现两个系统间的服务调用,就可以互相访问彼此的数据,您看是不是比较好实现?

场景3:流程变更

场景4:需求变更

今天累了,明天继续弹


posted on 2007-09-24 12:49  我是蚂蚁  阅读(1634)  评论(7编辑  收藏