产品开发模式的变革

对于做运营支撑系统软件的公司,都会有几条产品线,既有基于BSS域、OSS域、数据域等的不同特性来建立不同的团队,开发相应的产品。有的公司在业务规模起来后,即便是同一个域,针对不同的运营商,会开辟多条产品线做同一业务领域不同产品的开发。

由于不同产品线由不同的团队组成,各自对技术有不同的理解,如果没有统一总控,不同的产品线会选用不同的技术架构,各自开发不同的组件。重复造轮子的事情经常发生。

因为是重复造轮子,新产品推向市场的时间周期相应被拉长,投入的成本随之增大。

产品研发出来后,同一个产品会开辟出越来越多的市场,拥有诸多落地的客户。因为每个落地的客户存在自己个性化的需求,为满足这些需求,同一产品会延伸出各个不同分支的版本。系统存续时间越长,各地版本的差异性越大,维护的难度也随之上升。

对于产品的大版本升级,又是一件伤筋动骨的大事。在产品大版本升级的时间窗口内,产品线不是在做交付实施,就是在去交付实施的路上。

运营商支撑系统的演进,一直是走在致力于解决孤岛、干掉烟囱系统的路上。

早期谈的是通过EAI/ESB,或者数据集成等方式,打通各孤立系统,构成一张有机连接的支撑网。

后续谈的是平台+应用的架构,让搞业务的专注业务,搞技术的专注技术,逐渐收拢企业范围内的技术架构。

随着业务复杂度的增加,新业务不断涌现、逐渐开辟更多的渠道、业务管理领域的更精细化,为了更好地避免重复开发,实现服务资产积累沉淀,以及快速支持新的业务,无论是电信搞BSS3.0还是移动搞第三代,都在推动将通用的服务能力抽取出来,形成一个个的业务能力中心,然后在这些业务能力中心之上,通过服务编排,形成前端面向不同客户群、不同渠道、不同领域的各类应用。

随着运营商支撑系统架构的演进,软件公司的研发体系和流程需要相应的变革,以推动公司级的架构统一、跨产品线的组件共享,业务服务组件统一管理和维护,在维系核心服务层的稳定和统一演进的基础上,适应不同省份的需求,以及快速推出新产品。

整体的技术架构择优选型,公司级实现统一。新产品一律构架在统一的技术架构,老产品逐步实现迁移;

各技术组件,包括流程引擎、GIS平台、日志管理、运维模块、界面组件等形成公共库,跨产品线共享,且强制使用;

在业务领域,梳理出粒度合适的服务能力中心,不同产品涉及相同的能力中心,不重复开发;

在能力中心的基础上,结合业务需求,通过服务编排等方式,构建前端应用,形成完整的产品;

产品形成后,在各省实施交付。技术架构、共享组件、业务能力中心在后端统一管理,迭代演进;

现场配备业务架构师,对业务需求进行分析和分解,通过服务编排加上私有化的开发,满足各省不同的需求。

运营商的支撑体系架构变革已经在路上,对于运营支撑软件公司而言,不仅仅是涉及到研发流程、研发管理体系的变革,还关乎到更大范围的产品落地后的维护模式的变化。

挑战很大,但若变革成功,价值亦很大。

  • 发表于:
  • 原文链接:http://kuaibao.qq.com/s/20180125G0ZGMW00?refer=cp_1026

相关快讯

扫码关注云+社区