科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道SaaS 企业为什么不buy in?

SaaS 企业为什么不buy in?

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

如果我们观察这几年来程序语言与开发平台的演进,可以很明显感受到对于以组件为基础的面向对象程序开发相当重视,不论是主流的.NET、J2EE或是PHP,甚至是Python,都特别强调以组件技术来达成软件可再利用的特性。

作者:李宗達【原创】 2007年3月27日

关键字: ESB SOA 企业管理 SaaS 李宗达专栏 OOP Office

  • 评论
  • 分享微博
  • 分享邮件

 

如果我们观察这几年来程序语言与开发平台的演进,可以很明显感受到对于以组件(component)为基础的面向对象程序开发(Object-oriented Programming,OOP)相当重视,不论是主流的.NET、J2EE或是PHP,甚至是Python,都特别强调以组件技术来达成软件可再利用(reusability)的特性。尤其这两年来Web Services/SOA的窜红,更将组件化的观念透过网络的分布式延伸,展开了所谓建构企业跨平台组件储存库(repository)的想法。

很多企业信息技术主管都在思考,组件化技术普及后,信息系统开发的下一步将会出现什么样的变化?在此同时,很多企业主管可能隐约发现:几乎一些知名(不论是工具或是套装)软件供货商,都宣称其产品已经符合,或是即将符合服务导向(service-oriented)的组装式架构,这股趋势逐渐发酵中。

以组装的途径来完成信息系统建构与调整,我们可以通称为「软件组装」的观念,以区别强调开发导向的传统「软件开发」途径。不论这项立意被称作SOA、ESB或是SaaS(Software as a Service),这些炫丽名词背后,隐藏一个共同的特性:软件组装的时代已经开始了。从众多软件原厂所共同揭橥的愿景是:未来的软件系统将不在局限于「需求分析」与「软件开发」的活动,取而代之的将是以「塑模方法」来描述与决定软件将如何被组成,以企业如何有效建构管理内部或外部的「储存库」来供应实际所需的功能组件。

但是从市场供需法则的另一方来看,很多企业主管派员或亲自参与研讨会,以求了解这些趋势的机会与威胁,但在研讨会后除了认识一些新名词与缩写之外,似乎鲜少有企业宣称已经准备导入,甚至大部份企业在短期发展蓝图上,也没有具体的先导计划。

为什么供应与需求会有落差?一套好的解决方案不是应该受到鼓舞与欢迎吗?从我拜访几个大型企业用户得到的响应归纳出,实际的问题不在于相不相信「软件组装」的企业效益,而是—也是真正困难的--配套措施为何。如果不能解决以下几个问题,我们认为企业仍只会停留在观望的阶段,而不会有确切的投入行动:


创新技术到商业应用
为什么软件组装的观念不容易在企业中呈现效果?主要是因为要达到这样的好处,必须要从信息架构上进行一次大幅度的调整,这项调整对象包括一个新的系统架构,以及对于旧系统的处置。换句话说,想要得到未来的综效之前,必须先有一定程度的先期投资(这项投资除了得到基础建设,并没有产生具体的应用系统)。对于企业而言,无法从单一项目就看到成果的这类投资,大概都不是在线经理可以决定,一般会升级到信息长/技术长对于执行长的策略规划建议。

从这样的论述来推测,不论是CEO也好,CTO/CIO也好,他们会更关心对于企业经营绩效的贡献,所以,如果无法预见到因为导入新的信息架构,而带来商业应用模式上的创新,这对于决策者将会是很难的决定。即使新系统导入可以带来些许的成本降低,除非是很大幅度,否则对于决策者而言,仍不足以具有说服力,毕竟导入新架构还是需要一些初期成本与风险。所以,回归到从商业应用角度来检视创新技术的价值与必要性,将会是导入前的首要挑战。


组件技术到塑模方法
过去在组件开发为主的相关技术强势主导下,大部份的发展重点都围绕在组件本身的开发技术、部署方法与维护管理。到了「软件组装」架构下,前述工作当然还是需要,但是当组件的数量越来越多,并且开始从服务导向的观念来因应任何重组新系统的需求时,衍生出来的是:如何透过塑模(modeling)的方法,协助在现有组件的基础上快速与精确重组应用系统功能。目前一些发展中的塑模方法,已经慢慢取得了共识,所以我们也可以看到部份软件原厂也开始供应这种建筑在标准协议基础下的塑模工具,因此,对于企业而言,第二个面临的评估因素是如何开始进行塑模能力的累积,以及评量适合的工具。


开发技术到开发架构
传统上,信息系统开发的重头戏都免不了引入新的技术。但是在「软件组装」的环境中,一些诸如Web Services等技术仍不可免除,不过还有项更重要的核心工作,那就是开发架构(system architecture)。透过一套合宜的架构,不只可以形成开发上的共同遵守标准,同时可以减少开发的工作,这些省略的工作主要是依赖中间件(middleware)的完成,所以企业必须先思考所需要的企业信息架构、扩展能力、支持的中间件,并藉此评估软件公司所提供之中间件产品的实用性,以及在此产品上的技术人力培植。

发展一项新技术来解决企业问题,这是很好的立意,但是对于企业讲究实用的观点来看,光是好的技术或是产品还不足够,更需要整体配套措施,这配套措施包括了前期的评估因素、人力技能的转换与累积、业界支持的标准化程度…等。我相信,企业不会排斥任何有助于经营绩效提升的信息系统,只是在大力推动这些优异的系统前,还是需要多想想怎么说服企业主愿意开始投入评估。有了开始,后续具体行动才会渐次展开。


 

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章