应用appstore模式建设电信企业级应用系统.pdfVIP

岛”，数据的完整性、一致性无法得到保证 用。2011年4月，广东移动21个地市分公司网络维护部 · 数据与应用深度耦合，各系统问的应用无法复制． 门使用的自建网管系统共 167个。至2012年6月，沿用系 优秀的运维经验无法实现共享 统共 131个，停用系统36个，新建系统34个 · 无法对厂商能力、系统的使用情况进行有效后评 分散建设模式的优势在于能够快速响应部门需求．但 估，不利于培养出优秀的系统开发商。 也存在着诸多弊端，介绍如下。 本文对 “烟囱式”系统的产生根源进行了分析．发现主 · 各地市分公司各自主导应用的建设．可能导致同一 要体现在如下几个方面 需求的重复开发，造成投资浪费 · 紧急任务所需：为了应对紧急的需求，往往忽略了 · 各地市业务需求相同，但业务逻辑可能存在一定的 对应用系统的规划和设计。 差异，导致同一指标的算法不相同，省公司难以依 · 业务体系和职能部门不同：很多 “烟囱式”系统虽能 据各地市的指标对全省进行综合分析。 满足地市分公司／业务部门的需要．功能和 目的也 · 各地市分公司开发的应用在技术架构上可能与省 都十分明确，但是没有考虑到所需数据的实际产生 公司的技术发展路线不一致，难以平滑演进。 过程和其他地市分公司／业务部门对数据的需求。 · 某些地市的IT规划、管控能力较弱．可能会产生新 - 同质组织架构的管理模式差异：各地市分公司的组 的 “烟囱式”系统。 织架构基本同质，但对于相同的需求，不同地市实 (2)省集中建设模式 现的流程、方法不尽相同，导致地市分公司的自建 由省公司统一收集各地市的需求。统一进行系统的建 系统难以复用，必须重新建设新的系统。据统计，中 设和项目管控。省公司和所有的地市分公司使用同一套应 国移动通信集团广东有限公司 (以下简称广东移 用系统，通过不同的权限访问相应的数据。在中国移动通 动)的21个地市分公司，曾自建了20多套信令分 信集团公司网络部的CM．OSS2．0规划指导下，广东移动 析、监测系统。 建设了22套省级综合网管系统，提供给省市公司网络维 · 应用系统难以发现：没有一种方便的渠道可以发现 护部门使用。 已经在线运行、成熟稳定的应用系统，只能通过地 省集中建设模式虽然避免了分散建设模式的弊端，但 市分公司之间交流、询问的方式进行了解，导致很 在建设时需要先收集21个地市分公司的需求再进行归纳、 多优秀的应用无法复制。 合并，需求分析周期较长，无法快速支撑应用使用部门的需 · 开发厂商利益驱动：对于应用开发厂商来说，其愿 求。2012年6月，广东移动开展地市分公司对22个省建综 意建设更多的系统来获得利润的最大化，因此会鼓 合网管系统的满意度调研，非常满意的比例仅为20％，对省 动各地市分公司重复建设系统。 建综合网管系统几乎不了解、不使用的比例高达40％。 笔者于2012年初参与了广东移动信令监测系统的架 目前风行的AppStore带来很多的启示：统一的开发 构规划设计工作。在规划过程中，为了实现信令监测系统 环境和运行环境，实现了标准化和规范化，便于统一管理； “灵活数据采集、统一数据共享、应用快速复制”的目标，避 各方 自主开发，共享给有同样需求的用户下载使用，开发 免 “烟