随笔 - 0 文章 - 42 评论 - 58 引用 - 0 收藏 - 4

    本文是笔者对企业管理软件业未来走向的一个大胆猜想,也许真正实现这个境界可能需要100年、200年、甚至更长的时间。

 

什么是SOA

到目前为止,业内关于SOA还没有一个统一的、被广泛认可的定义,e-works在总结其它定义的基础上,认为:SOA是一种软件架构思想,通过使企业中一个个细化的服务标准化,来达到企业的IT系统跟随企业的动态变化的目的。

其核心为:

1)         SOA是一种软件架构思想,并不是一种产品。

2)         SOA的重点是面向服务,此服务包括企业的内部与外部的每一个业务细节,比如企业中财务应收发票的处理就是一个服务。SOA的思想是把这些服务从复杂的环境中独立出来——组件化封装,然后通过标准的接口使不同的服务之间相互调用。

在此过程中需注意以下两点:

         每个服务有一个明确的界限,其他服务只能通过接口来调用服务。

         每个服务是独立自主的,每个服务不必依赖于其他的系统而存在。

SOA的实现

要真正的实现SOA,市场上必须要有以下四个因素[1]:服务消费者、服务提供者、服务注册中心、合同。

1实现SOA的四个要素

u  服务提供者:通俗的讲就是我们常说的软件供应商,它通过在服务注册中心将提供的服务与要求的合同注册并发布出来。

u  服务消费者:即企业与其他消费服务的组织,它们通过服务注册中心寻找符合自身的合同与服务。

u  服务注册中心:相当于一个服务信息的数据库,为服务提供者与服务消费者提供一个平台,使两者可以各取所需,同时服务注册中心要有一个通用的标准,使服务提供商提供的服务符合这个标准,这样,服务消费者使用的服务才可以跨跃不同的服务提供商。

u  合同:是服务提供商与服务消费者之间的一种协议。

引入SOA以后,企业管理软件的未来将要发生巨大的变化,笔者认为的显著变化如下:

软件厂商的变化

SOA 架构下,管理软件厂商将成为“服务提供者”,改变以往的软件提供模式,他们按照一定的标准开发完成每一个“服务”后,将其发布到注册中心。

这意味着SAPOracle等企业管理软件厂商,未来很可能变成一个很小的公司(规模小,而不是营业额少),他们将不再提供一套大而全的软件,会把自己目前提供的庞大的软件系统全部打散,变成一个个很小的“服务”软件粒子,比如处理应收账款流程的软件粒子、处理物料入库的软件粒子。

另外,在这个模式下,SAPOracle很可能会将软件开发等业务外包出去,自己只提供软件要求和负责最后的测试,而外包公司需要根据他们的要求来开发一个个细小的软件粒子。

企业的变化

企业将改变现在的软件购买模式,目前的多数企业在购买软件时往往是是成熟性软件,需一个模块或一个系统的购买,企业在购买时往往无法将那些企业不需要的功能剔除出去,这样,企业就不得不为此多付出资金成本、培训成本等许多不必要的成本。未来企业只需要根据需要,到注册中心去寻找适合自身“服务”的软件粒子,因为所有在注册中心的软件都是遵循一定的标准,所以软件可以实现无缝集成,这样,就真正实现了松散耦合型架构。企业不用再为了软件系统而付出高昂的成本,尤其是为那些企业根本用不着的功能而付费。

而企业随着业务的发展,一些业务模式的改变导致企业需要更换软件系统时,企业只需要到注册中心寻找到符合新业务模式的软件粒子,把旧的软件粒子替换就可以了,而无需像现在的企业业务一变化动辄更换整个软件系统。

在这种模式下,企业的人员不需要再特别关注IT技术的发展,而更多的去考虑企业的业务发展。

 

渠道与咨询机构的变化

渠道与咨询机构在未来将不再以买软件为生,他们未来的生存模式将以帮助企业梳理业务流程为主,同时帮助企业挑选合适的软件粒子。这样,他们将打破现在以某一家软件厂商的产品为主来销售产品,摆脱厂商的限制,而真正变成了一个平台,在这个平台之上可以按照企业的需要提供任何一家厂商的软件粒子,真正变成了企业与软件之间的桥梁。

 

笔者希望这种软件模式可以早日实现,因为对广大的制造业企业而言,无疑将带来巨大的益处。但真正要实现这一步,还要有很长的一段路要走。

“前途是光明的,道路是曲折的”!

 

"如果SOA像它说的那样好的话,通过它相互沟通很容易,插上去都能通用了,应该是很有前途的,但到目前为止,坦率的讲,好像还没有哪一个可以这样做到的”——QAD总经理缪青。



[1] SOA治理:动成长企业的关键要素》,Ben Brauer(Hp).Sean Kline(Systinet).

发表于: 2007-06-08 17:26 喜欢仰泳的鱼 阅读(2749) 评论(6)  收藏(0) 好文推荐

作者该类其他文章:

# re: SOA架构下企业管理软件业的未来猜想
2007-06-09 23:44
Sempron
听起来和当年的asp多么相似。

作梦而已

# re: SOA架构下企业管理软件业的未来猜想
2007-06-21 09:49
linbojlepc
不太现实

# re: SOA架构下企业管理软件业的未来猜想
2007-08-13 15:59
shaw4672
SOA?  It's only mater of time !!

SAP 强调它有 best practice , 它最懂管理,要求使用者从系统几种既定的流程择一,来经营企业 !!

然而每一个经营成功的公司背后,必然有其管理上独到之处,才能在市场上竞争;即使是同一种产业中 ,因为规模 、资源强弱不同等 ,各公司经营策略必各自不同,同时也会随市场变化,随机调整,一双鞋子每个人都合脚 ,解释上就狗屁不通 !!

Best practice 的神话,刚开始时透过强力行销,确实锐不可挡,在 4GL 时代 , SAP 确实已将 ERP 发挥到淋漓尽致 ,但问题是这就是 ERP最高境界 ?

# re: SOA架构下企业管理软件业的未来猜想
2007-08-13 16:28
shaw4672
SOA = SOAP + WSDL + XML , 但 SOA ERP =  ??

SAP   说 SOA ERP  = ERP + Netweaver ??  No , No , No 
Oracle  说 SOA ERP  = ERP + Fusion ??  No , No , No
It’s  all  very  laughable !!  Trick !!  Lier !!

SOA ERP =  Object Oriented Component Assembled ERP

Service Oriented 其实分两大块 :
 Intrinsic integration ( 内部服务整合) , 同一套 ERP 的服务整合
 Extraneous integration ( 外部服务整合)  , 与别套 ERP 的服务整合

目前的系统都是在 Procedure Language base的 ERP , 包上一些 SOAP + WSDL + XML 的外衣, 那说穿了只是资料交换的新名词, 也就是说那顶多是 ERP + SOA Coating ,不等于 SOA ERP ,只是一种商业技俩

# re: SOA架构下企业管理软件业的未来猜想
2007-08-13 17:31
shaw4672
Can Object Oriented Component Assembled ERP Really make difference ?

服务的重点在提供速度、弹性、友善

产业及角色造成差异         Object Oriented Programming
信息人员                由服务的组件功能说明了解系统
系统导入顾问            由少样的底层服务组合出多样的使用服务,可塑性大
系统使用客户            由服务趋动之单一接口无缝整合

Procedure Oriented Programming
信息人员              由数据库的表格了解系统
系统导入顾问          由多样的作业表中挑选出少样的使用作业表,无可塑性
系统使用客户          由参数设定串接多层划面整合


# re: SOA架构下企业管理软件业的未来猜想
2007-08-13 18:12
shaw4672
国外ERP 公司的左右为难处 , History repeat itself again & again 

对象导向的 ERP 既然好处多多,难道 ERP 公司不了解 ?
当然了解,以本文版主缪总的 QAD 而言 , 早在 1999 年LOPKER就曾尝试以 FORTE 重新开发所有程序改为对象导向,但因为时间过早,EJB上不成熟,J2EE 许多标准未定,以失败收场,实为非战之罪。最后改以 .NET 开发前端,后端仍沿用 PROGRESS Open Edge Server ,可以包成 .WAR 做 Web Service ,但仍非 J2EE 架构,应该以后会逐步将后端再改上来。

SAP 在 2002 年开始 ,由于 EJB 2.0 较成熟 , 交Shai Aggasi 领军,实做对象导向的 SAP,这是SAP 全球每年 Summit 的报告重点,一些因素造成Project 并不顺利,Aggasi 今年 4 月离职 ,原因是 Aggasi希望釜底抽薪彻底改,否则会失去市场先机,而老板 Plattner希望以较和缓的做法分阶段改。

纵观 JE22的发展从1996 年到 2007 年,以逐渐成型,在非 ERP领域也有许多成功案例,但要将 Procedure 导向的系统,将其错综复杂的逻辑,抽丝剥茧规划成逻辑 decouple 的 Service导向系统,System Analysis 才是瓶颈,技术已越来越不是问题,而系统越大的公司包袱越重,也越难改 。

但SAP 以前以 4GL 成功打败 Cobol base 的一些 ERP 巨人,不也正因他们的包袱太重,让 SAP 乘虚而入 ?


标题  
姓名  
主页
内容   
请输入验证码:
*
(如果看不到图片,请多刷新几次页面)
  登录   Top
[使用Ctrl+Enter键可以直接提交]