业务平台--摸不准的理念?
2006-11-30 22:29
267 查看
在应用软件领域,最近一直被吹捧的技术就是平台。但是,对于平台的理解,却不是很统一。各行各业也没有一个准确的定义。基本上每个稍微有点实力的公司都推出了自己的平台。
可是,平台到底是什么呢?
回答平台是什么不是很容易。不过可以从它产生的目的开始探讨。说得高一点,平台的出现,是剩余价值追求的产物。换句话说,就是要提高开发效率,减少人力成本。使得开发一个新的项目、产品,可以很容易!
平台的诞生,是要解决两个问题。
第一、 二进制级别的复用。在无需重新编译的情况下,重复利用已有的成果。
第二、 业务模块级的重用。将能够解决用户核心业务问题的模块,封装成可以直接复用的平台基石。并可以在这些基石上重新构建完全客户化的新产品。
为了达到这两点,平台还必须拥有一些特性:
第一、 表现模式必须可以配置。这是基于二进制级别使用的必备条件。否则,丰富的客户表现基本是不可能的。
第二、 业务模块易于扩展。平台的扩展性可不光是针对客户的表现,自身的扩展更是重要,它是平台的生命周期生存的根本。
为了更容易理解平台的概念,我想以Microsoft的Share Point Portal Service为例,来描述平台都完成了什么。
我们用它是来为不同的Team建立项目网站。在建立这个网站的过程中,我们可以自定义版式,可以选择SPS为我们提供的列表、文档、投票等等模块,来满足我们Team的各种功能要求。在这过程中,我们不需要微软为我们修改一行代码。再加上其易用性较高,基本不需要参考帮助文件就可以完成项目网站的定义过程。
基本上,微软提供的SPS平台,对业务的支撑做得非常好了。我唯一感觉,里面缺少了一个论坛的模块。不过,相信其扩展非常容易。期待中。
这让我们有个感性认识,平台不需要我们新的代码,其二进制的复用特性,保证了系统的稳定性。各种业务模块满足了不同的业务需求。如果不满足的话,还可以很容易扩充。
在软件工程的发展过程中。开始是基于工具类的重用,基于组件的重用,基于框架的重用。但是这些都是基于代码的重用。而且都不和具体业务相关。属于基本框架。这些一般都是微软提供的Windows API及各种语言提供的框架.NET Framework、VCL、MFC等等。
也就是说在业务模块复用的这个断层上,并没有一个统一的供应商存在。往往是各自业务领域自身发展。而且由于其竞争关系,这些业务模块往往不能进行共享,导致一些中小企业在业务平台上的发展缓慢。
受流行框架的影响很深,很多平台开发者,往往基于框架做框架。虽然说这些框架式的平台不是真正的平台,但不管怎么样,在平台的发展过程中,必然要有个积极积累的过程。而这个过程迟早会结束!
在平台开发过程中,应该重点放到业务模块的抽象和设计。没有了编程,才没有业务。一些所谓表达式,都是业务的影子残留。
希望,中国的平台全盛时期早点到来。
可是,平台到底是什么呢?
回答平台是什么不是很容易。不过可以从它产生的目的开始探讨。说得高一点,平台的出现,是剩余价值追求的产物。换句话说,就是要提高开发效率,减少人力成本。使得开发一个新的项目、产品,可以很容易!
平台的诞生,是要解决两个问题。
第一、 二进制级别的复用。在无需重新编译的情况下,重复利用已有的成果。
第二、 业务模块级的重用。将能够解决用户核心业务问题的模块,封装成可以直接复用的平台基石。并可以在这些基石上重新构建完全客户化的新产品。
为了达到这两点,平台还必须拥有一些特性:
第一、 表现模式必须可以配置。这是基于二进制级别使用的必备条件。否则,丰富的客户表现基本是不可能的。
第二、 业务模块易于扩展。平台的扩展性可不光是针对客户的表现,自身的扩展更是重要,它是平台的生命周期生存的根本。
为了更容易理解平台的概念,我想以Microsoft的Share Point Portal Service为例,来描述平台都完成了什么。
我们用它是来为不同的Team建立项目网站。在建立这个网站的过程中,我们可以自定义版式,可以选择SPS为我们提供的列表、文档、投票等等模块,来满足我们Team的各种功能要求。在这过程中,我们不需要微软为我们修改一行代码。再加上其易用性较高,基本不需要参考帮助文件就可以完成项目网站的定义过程。
基本上,微软提供的SPS平台,对业务的支撑做得非常好了。我唯一感觉,里面缺少了一个论坛的模块。不过,相信其扩展非常容易。期待中。
这让我们有个感性认识,平台不需要我们新的代码,其二进制的复用特性,保证了系统的稳定性。各种业务模块满足了不同的业务需求。如果不满足的话,还可以很容易扩充。
在软件工程的发展过程中。开始是基于工具类的重用,基于组件的重用,基于框架的重用。但是这些都是基于代码的重用。而且都不和具体业务相关。属于基本框架。这些一般都是微软提供的Windows API及各种语言提供的框架.NET Framework、VCL、MFC等等。
也就是说在业务模块复用的这个断层上,并没有一个统一的供应商存在。往往是各自业务领域自身发展。而且由于其竞争关系,这些业务模块往往不能进行共享,导致一些中小企业在业务平台上的发展缓慢。
受流行框架的影响很深,很多平台开发者,往往基于框架做框架。虽然说这些框架式的平台不是真正的平台,但不管怎么样,在平台的发展过程中,必然要有个积极积累的过程。而这个过程迟早会结束!
在平台开发过程中,应该重点放到业务模块的抽象和设计。没有了编程,才没有业务。一些所谓表达式,都是业务的影子残留。
希望,中国的平台全盛时期早点到来。
相关文章推荐
- 业务平台--摸不准的理念?
- 业务平台--摸不准的理念?
- 业务平台--摸不准的理念?
- 业务平台--摸不准的理念?
- 业务工作流平台设计(一)
- 业务工作流平台设计(三)
- 银行中间业务平台的几种性能测试方案
- .Net业务平台的数值精度陷阱与解决方法
- 马哥linux运维公开课第二季—《自动化运维平台的设计理念》
- 通用办公业务平台开发框架研究系列(1)-设计思路-层次划分
- 通用业务系统基础平台(四) 行政管理
- RDIFramework.NET ━ .NET快速信息化系统开发框架 ━ 工作流程组件Web业务平台
- RDIFramework.NET ━ .NET快速信息化系统开发框架 ━ 工作流程组件WinForm业务平台
- RDIFramework.NET ━ .NET快速信息化系统开发框架 ━ 工作流程组件Web业务平台
- 业务架构平台的技术实现环境
- C#.NET 大型企业信息化系统集成快速开发平台 4.2 版本 - 总部业务部门主管管理整个集团分公司的某项业务
- 浅议政府应急指挥平台的业务流程集成
- 业务架构平台的技术实现环境
- Lotus Mashup - 业务数据的聚合平台!
- SAP宣布58亿美元收购Sybase移动平台和数据库业务