整合项目的难:业务理解的不一致、系统设计的不一致和协调
2008-10-13 19:09
225 查看
整合项目难做,做过的人都是很容易知道的,这也是为什么整合项目通常要规划很久、实施很久,而且还要花费很大的财力的原因,在之前的blog中曾经写过整合项目难做的一些地方,像数据分析、客户的不够理解等。
随
着对于整合项目实施的逐步深入,碰到的难点在逐步的增多,目前手头的一个整合项目接近完成了,对于这种类型而言的整合项目中的难点估计该出现的都已经出现
了,总结下来除了数据分析这个大难点之外,还有的难点就是业务理解的不一致、系统设计的不一致和协调这三个,其实业务理解的不一致和系统设计的不一致可以
列入数据分析这个范围,但由于这两点对于整合项目的影响较大,会很大程度影响整合项目实现的难度,所以还是单独列出来讲讲。
业务理解的不一致
当
整合两套业务系统时,对于基于服务(web服务/中间标准XML等)提供两套系统的业务功能的时候还好说,因为可以根据业务的需求来制定一个统一的中间标
准,而对于两套系统通过数据库直接连接整合的项目来说,则更为麻烦,直连库的这种在很多的情况下都会以双方的数据库结构说明书为准,这个时候在做整合时会
出现一个很容易忽略的地方,就是两套系统的设计人员对于业务理解不一致的情况,特别是两套功能基本一致的系统时,这个问题会非常的突出,很明显的一个例子
就是在系统A中某个字段是必填项,而在另外一套系统中这个字段则是非必填项,有些可以通过数据库约束来避免这种错误的产生,而有些则不行,例如在系统A中
可能认为当字段B不为空时,字段C也不能为空,而在系统B中可能就不是这样的了,这种现象呢,通常都只有在进入测试阶段时才能发现这样的错误,因为在数据
库结构说明书中通常很少会有写的这么详细的,尤其是这种涉及业务规则的地方,更复杂的就是带业务规则的字段,那就会更麻烦。
这样的现象就会导致整合项目的周期不断的变长,而且错误直到测试阶段才暴露出来,再加上可能错误会不断的一个接一个的逐渐的才能暴露出来,有可能会导致对于用户的信心以及项目成员的信心造成不小的打击。
这种情况通常在建设综合平台、废除原系统的时候容易出现,因为原系统的这种数据库的业务规则可能是很难了解到的,只能随着项目的不断进行才能逐步的暴露出来。
系统设计的不一致
这
种现象对于整合项目而言是非常大的难点,这样的难点通常都出现在通过数据库直连实现整合的项目中,出现这种现象的时候首先是需要尽量协调其中的一家公司看
看能否根据另外一家公司的设计来生成符合设计的数据,如果双方都协调不了的话,整合厂商就只能自己来做了,这个时候就非常的复杂了,需要了解两方的设计,
然后在数据进行交换的时候来根据一方的数据来生成符合另外一方设计的数据。
这种情况对于整合厂商而言,是非常复杂的,完全不夸张的说几乎是超出了做两套业务系统的难度。
协调
厂
商间的协调是整合项目中最难的地方,在整合项目中客户是非常重要的角色,客户能否照顾好各家厂商的利益协调好各家厂商进行配合,很大程度上决定了整合项目
能否成功,如果厂商不配合的话整合项目要成功的可能性非常低,一旦协调不好很有可能会导致整合厂商成为客户、其他系统开发商之间最难受的一方,也会直接导
致整合项目的成功性下降,整合厂商在进行整合项目之前应该首先调查好系统需要涉及的开发商是否能提供配合,如有不怎么配合的开发商的话需要慎重的考虑该接
口的处理。
随
着对于整合项目实施的逐步深入,碰到的难点在逐步的增多,目前手头的一个整合项目接近完成了,对于这种类型而言的整合项目中的难点估计该出现的都已经出现
了,总结下来除了数据分析这个大难点之外,还有的难点就是业务理解的不一致、系统设计的不一致和协调这三个,其实业务理解的不一致和系统设计的不一致可以
列入数据分析这个范围,但由于这两点对于整合项目的影响较大,会很大程度影响整合项目实现的难度,所以还是单独列出来讲讲。
业务理解的不一致
当
整合两套业务系统时,对于基于服务(web服务/中间标准XML等)提供两套系统的业务功能的时候还好说,因为可以根据业务的需求来制定一个统一的中间标
准,而对于两套系统通过数据库直接连接整合的项目来说,则更为麻烦,直连库的这种在很多的情况下都会以双方的数据库结构说明书为准,这个时候在做整合时会
出现一个很容易忽略的地方,就是两套系统的设计人员对于业务理解不一致的情况,特别是两套功能基本一致的系统时,这个问题会非常的突出,很明显的一个例子
就是在系统A中某个字段是必填项,而在另外一套系统中这个字段则是非必填项,有些可以通过数据库约束来避免这种错误的产生,而有些则不行,例如在系统A中
可能认为当字段B不为空时,字段C也不能为空,而在系统B中可能就不是这样的了,这种现象呢,通常都只有在进入测试阶段时才能发现这样的错误,因为在数据
库结构说明书中通常很少会有写的这么详细的,尤其是这种涉及业务规则的地方,更复杂的就是带业务规则的字段,那就会更麻烦。
这样的现象就会导致整合项目的周期不断的变长,而且错误直到测试阶段才暴露出来,再加上可能错误会不断的一个接一个的逐渐的才能暴露出来,有可能会导致对于用户的信心以及项目成员的信心造成不小的打击。
这种情况通常在建设综合平台、废除原系统的时候容易出现,因为原系统的这种数据库的业务规则可能是很难了解到的,只能随着项目的不断进行才能逐步的暴露出来。
系统设计的不一致
这
种现象对于整合项目而言是非常大的难点,这样的难点通常都出现在通过数据库直连实现整合的项目中,出现这种现象的时候首先是需要尽量协调其中的一家公司看
看能否根据另外一家公司的设计来生成符合设计的数据,如果双方都协调不了的话,整合厂商就只能自己来做了,这个时候就非常的复杂了,需要了解两方的设计,
然后在数据进行交换的时候来根据一方的数据来生成符合另外一方设计的数据。
这种情况对于整合厂商而言,是非常复杂的,完全不夸张的说几乎是超出了做两套业务系统的难度。
协调
厂
商间的协调是整合项目中最难的地方,在整合项目中客户是非常重要的角色,客户能否照顾好各家厂商的利益协调好各家厂商进行配合,很大程度上决定了整合项目
能否成功,如果厂商不配合的话整合项目要成功的可能性非常低,一旦协调不好很有可能会导致整合厂商成为客户、其他系统开发商之间最难受的一方,也会直接导
致整合项目的成功性下降,整合厂商在进行整合项目之前应该首先调查好系统需要涉及的开发商是否能提供配合,如有不怎么配合的开发商的话需要慎重的考虑该接
口的处理。
相关文章推荐
- 开发一个业务逻辑复杂的系统,应该怎么样设计才能使项目的扩展性更好
- 高并发 强实时 强一致数据库业务系统设计的一个思路
- UML项目应用理解--快速了解整个系统架构和详细设计文档
- 整合公司业务系统,处理微服务事务不一致的问题
- .Net 应用业务系统架构设计-项目结构图
- 使用 UML 进行业务建模:理解业务用例与系统用例的相似和不同之处
- 设计实现业务系统中的用户权限管理
- 用三层架构与设计模式思想部署企业级数据库业务系统开发
- 通过系统设计来理解Paxos算法
- JavaWeb项目开发案例精粹-第4章博客网站系统-001设计
- 基于UML的科技查新综合业务管理系统的设计与实现
- 电子银行业务分析系统—项目总结7. 项目技术经验
- iOS App 项目:会员卡管理系统设计方案
- Struts2项目整合之人员管理系统(四)
- 基于WPF系统框架设计(5)-Ribbon整合Avalondock 2.0实现多文档界面设计(二)
- 项目发布系统设计原理
- 软件项目-1.6_XXX控股集团业务系统(交易与支付)SDE制度(完整版)
- 架构设计:系统存储(13)——MySQL横向拆分与业务透明化(1)
- pms项目系统安全性设计
- 业务系统设计之二:系统主控设计(上)