我们到底在定制什么.docVIP

我们到底在定制什么 谈企业信息化，二次开发是避免不了的。关于二次开发的费用、进度、质量都是大家吐槽的问题。但大家或许没有总结过、当然由于定制大多为软件商黑箱所以也不好分析，所以虽吐槽但也无可奈何。 我是出身软件商，既做过研发最高领导人，每周还有个雷打不动的动作就是：过费用/计划/质量超标的项目、代码复查/BUG分析。通过这些项目分析/代码分析/BUG分析来反推是我们软件研发内部哪里出了问题：是人能力不行？架构问题？工具模板问题？上下游前后台协作问题？寻找问题根源以打七寸。 问题分析多了日子久了就发现很多问题是一而再再而三的，都有规律和分类，我们只不过是在原地绕圈而以。那我今天作为深喉就给大家揭露揭露，大家也对照对照自己之前提过的二次开发需求看看是不是我说的这么回事。 一、查询统计类 这是我们最常见的二次开发需求。这里面出的最多的问题就是口径不一致/计算公式不一致。客户提A就修改A，发现B报表也有这个信息，但B报表没提我就不修改。发现了就再提需求再改。 查询统计类还常见的问题就是用原始业务数据做综合统计报表。这不仅影响业务生产系统的性能，而且统计报表不稳定，经常受业务系统的特殊业务操作而篡改历史数据（撤销、反结、负退）等等。所以搞综合统计报表我们的正道是用商业智能的技术。但很多CIO一提商业智能就头大，而且要新购买一个系统，就想凑合。CIO凑合，定制开发人员也跟着凑合，有的综合统计报表写了500行SQL（性能又问题而且再修改还不好修改出了错误还不好调试），有的综合统计报表干脆用SQL写不出来的（程序员用代码+SQL混合搞个报表功能）。 二、性能调整类 由于产品开发时、定制开发时都有限的人力有限的时间赶着做业务功能了，这些性能啊、兼容性啊、可集成性啊、安全性啊等非功能要求都没人管了。数据量一上来/用户一多了性能就有了问题。所以哪个功能点有性能问题就优化哪块。等后来优化了A然后B就慢了，优化了B连带C就莫名其妙慢了的时候，这样修改就不行了，又得从架构整盘考虑了，这就小问题积累成大工程了，这又是一次大的定制优化项目。 有的性能调整还不是动动参数改改索引这么简单的，有时需要复杂的负载均衡、查询分离这些架构级的大方案。但你购买的那个版本的平台不支持这些特性，那就又是大定制啊。 三、移植类 1、把A客户曾经提过的需求定制过的代码，在B客户处再改一次，因为B提的需求和A提的需求差不多，但B客户并不知道之前已经开发过了。 2、把高版本产品中的某些业务功能移植到客户当前版本。 四、对外集成类 对外集成需要有这几个层面的集成：门户集成、业务逻辑算法集成、工作流引擎集成、消息引擎集成、主数据集成、数据同步分发。但经常会出现的是：平台提供的某些集成技术不支持、没有对外集成接口/没有支持多种主流集成技术。所以要集成，只能修改平台、再升级平台，升级平台还得考虑上面所有子系统的兼容性，这就工程量大了去了，想起这样搞就觉得风险极大。 为了防止风险被憋大，所以很多CIO在IT建设中期就开始选型独立的IT集成平台。但发现每个核心业务系统都有所谓的平台，但都不完善，而独立的IT集成平台和他们这些平台又不好整合，因为他们各自的业务系统和他们的平台绑的很死，所以还是N多平台共存，整体系统格局更复杂。 五、对内跨版本集成类 怎么还有个对内集成。这就说到了企业购买子系统（模块）是分年购买分年上线的，所以即使是同一个软件供应商，N个子系统也是不同的版本。要让不同版本的子系统还能连在一起流畅贯通，这就难了。因为有的新版本上确实有很好的功能特性是客户最需要的，但新版本的各个子系统也是业务模型完整体系的，要把其中一个新子系统抽出来给旧版本子系统配上，这有时连业务模型业务流程都走不通。这就如同要把杨贵妃的嘴、西施的眼非要堆在一个脸上一样。但这么离谱的事情居然我们很多CIO都在干。当然一番大修改了。 如果这个软件供应商平时就没怎么注意各个版本的业务模型向下兼容性、各个子系统的接口边界、以及接口的向下兼容性，那...，大家就知道定制开发工作量有多大了。 六、平台加固类 安全：这个东西是个一般看不见一般也不发生的事情，所以很多CIO是口头重视但在选型评分、日常运维方面都没有对安全做太多照顾。很多IT业务系统在研发时对安全架构并不看重，都奔着发布新功能去了。一旦说要加固系统安全，完，因为安全是遍布各层各个模块的，系统需要再很多层的关键口上加安全控制，所以一整安全项目也是大定制项目。 运维：很多平台光注重产品开发工具、定制开发工具的支持，对应用运维、技术运维没啥考虑。但系统上的时间长了，运维正规化就要提到日程上了。这样就需要加强平台对于应用运维技术运维的支撑，这还需要大定制，哪能那么容易给外围按个服务工具就行的。 七、功能完善类 有些子系统吧，虽然已经开发出品了许多年，但购买人