产品开发模式的变革

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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