電信運營商BOSS建設流程分析與探討

謝曉軍，胡軍軍

（中國電信股份有限公司廣東研究院 廣州510630）

1 引言

通過收購和重組，電信行業進入了全業務競爭時代[1]，尤其是移動業務的競爭日趨白熱化，電信運營商紛紛啟動以客戶為中心的企業轉型之路，越來越重視與客戶體驗緊密關聯的BOSS（business & operation support system）建設。在總體投資減少的背景下，BOSS投資仍保持在相當的水平之上，投資占比也逐步接近發達國家電信運營商的水平。各家運營商[2～4]都逐步建成了以省分公司為主、集團公司和省分公司協同的兩級應用架構，基本滿足了客戶產品受理、服務保障、業務計費等急迫需求，實現了面向前端的客戶管理、產品管理、營銷管理、經營分析等功能以及面向后端的施工調度、資源管理、開通激活等功能，全面支撐了企業各項生產和管理流程。在部署方面完成了從本地網向省公司的集中，實現了系統的統一規劃，對于后期的系統運營和維護起到了降本增效的作用。然而，在技術架構方面還存在許多不盡如人意的地方，組件劃分、服務抽象、數據模型和基礎設施等方面存在嚴重的不統一和不一致的現象，這給運營商集約化業務支撐和運營管理帶來了極大的困難和障礙，難以滿足移動互聯網時代的行業競爭需要。舉例來講，某運營商為降低成本擬推廣采用LAMP（Linux+Apache+MySQL+PHP）平臺，但在實際推進過程中發現供應商在省分公司建設工程中的研發僅僅是在現有系統基礎上進行二次開發，受工程進度和研發成本的限制，根本無法進行LAMP平臺的大規模改造和移植。要解決這些問題，僅僅關注如何設計出更加完善的目標架構是不夠的，還需要對現有系統建設流程進行優化和調整，改變當前工程建設僅能基于供應商應用軟件進行二次開發的局面。

2 BOSS建設流程現狀

國內電信運營商BOSS建設的主要方式是軟件外包，雖然最早“97系統”時期有部分自主開發以及后來省集中過程中部分進行了COTS（commercial off-the-shelf）套件的嘗試，但都沒有成為主流。

當前以外包為主的系統建設主要包括以下幾個步驟：首先，由集團公司組織進行系統規劃和規范；然后，省分公司按照集團公司要求和本省業務需求組織工程實施；其次，供應商根據省分公司工程需求進行研發；最后，省分公司組織進行驗收上線運營工作。如圖1所示，通常可以將其歸納為4個閉環的過程。在部分系統全國集中建設的情況下，集團公司也會組織工程實施，其過程與省分公司的實施過程類似，這里不再贅述。

第1個閉環過程是由集團公司負責的規范圈。集團公司組織各省分公司和供應商共同編制規劃或規范，然后由供應商自主開發出相應的原型系統，最后由集團公司組織進行入網測試，根據測試結果將供應商納入省分公司招投標短名單，同時集團公司根據測試情況調整規劃和規范要求，以便于系統藍圖的落地和實施。這個閉環過程主要解決的是未來3～5年BOSS發展方向的問題。

第2個閉環過程是由省分公司負責的工程圈。省分公司根據集團公司規劃和規范要求，結合本省本年度業務需求編制工程需求，組織招投標并選擇合格的供應商負責工程實施、跟蹤和管理工程進度，最后安排系統割接上線，并組織進行系統測試和驗收工作。

第3個閉環過程是由供應商負責的開發圈。供應商根據省分公司提出的工程需求進行系統分析設計，然后在原有系統基礎上通過配置或者編碼實現定制化的二次開發，最后進行系統測試和交付。該閉環的周期有長有短，如果針對年度工程需求，大致需要幾個月的時間，如果針對突發性的業務需求，如節日促銷，可能只需要幾周或者幾天時間。

第4個閉環過程是由省分公司負責的運營圈。省分公司負責日常的系統運營維護，保障其可用性。隨著互聯網運營開發模式的興起，在這個閉環中也越來越注重日常維護性開發的工作投入。

以上4個閉環過程對系統技術架構能夠產生一定影響的是規范圈和開發圈。一方面，規范圈中供應商會根據規范要求進行原型開發，但由于缺乏明確的項目驅動和資金投入，原型系統質量難以保證；另一方面，開發圈的重點是進行定制性的二次開發，受工程進度和項目成本的限制，難以對技術架構進行較大的調整。這些問題導致了運營商對BOSS技術架構缺乏基本的管控能力。

3 供應商研發流程

在整個系統研發過程中，供應商根據省分公司進行定制開發只是冰山的一角，隱藏在水面下的是供應商龐大的系統研發過程體系。軟件產品線工程框架[5，6]大致可以描述供應商的這一過程，如圖2所示，框架將其分為領域工程和應用工程兩個過程，其好處包括：更低的研發成本、更高的軟件質量、更短的上市時間等。

領域工程的目的是建立可重用平臺，實現產品線的通用性和可變性，與平臺研發相關的主要過程步驟包括需求、設計、實現、測試等。其中領域需求過程主要是獲取和描述可重用平臺共同的變化和需求，領域設計過程會確定可重用平臺的參考架構，領域實現過程涉及可復用軟件組件的詳細設計和實現，領域測試負責對可復用組件的確認和驗證。在這4個步驟中，領域設計過程形成了系統的組件劃分、服務抽象和數據模型等大部分技術架構的決策，這些都會反映在可重用平臺的參考架構里。另外，領域實現過程決定了系統底層平臺的選擇，比如是否采用LAMP。

在領域工程所建立的平臺上，應用工程利用其可變性等特性，根據運營商具體需求配置和開發BOSS應用。運營商現有BOSS建設模式中的開發圈在這個框架中只是應用工程中的眾多應用開發過程之一，對于技術架構的影響力也就可想而知了。

運營商希望通過規范圈統一各省分公司技術架構，從而降低系統運營和維護成本，提升業務集約化支撐的能力。然而，運營商所面對的不同供應商卻有著不同的訴求，他們希望針對不同的運營商通過領域工程盡量采用統一的技術架構建設軟件產品線，這樣既可以降低研發難度和實施成本，也容易形成有效的技術積累和知識沉淀。通過以上分析可知，技術架構的決策起決定性作用的是領域工程，基于過往項目經驗的架構理所當然地成為軟件供應商的首選，于是造成了由不同供應商負責實施的BOSS技術架構存在較大差異。

4 BOSS建設流程優化建議

根據分析可知技術架構決策起決定性作用的是領域工程相關過程，因此要改變這種情況，關鍵是運營商需要作為重要的干系人參與到領域工程的需求、設計、實現和測試中，推動不同供應商設計出滿足運營商統一技術架構要求的可重用平臺。

通過優化和調整規范圈閉環的工作流程，運營商可以適度介入供應商的領域工程中，這樣規范圈不僅需要交付系統規范要求，更為重要的是需要交付一套滿足通用性和可變性要求的可重用平臺，也許稱之為領域圈更加合適，如圖3所示。有了運營商參與的領域工程對于供應商而言會更加貼近市場需求，能夠更加全面地考慮系統架構的影響，滿足產品線更加長遠的發展需要。其大致過程如下：集團公司組織供應商和省分公司共同制定領域需求（含統一的技術架構要求），通過招投標選擇有實力的供應商針對領域需求開發可重用平臺并提供資金支持，最后由運營商進行領域測試，確?？芍赜闷脚_滿足運營商技術架構統一的相關要求，如組件劃分、服務抽象、數據模型和基礎設施等，然后選擇試點省分公司進入工程圈閉環，進一步對可重用平臺進行修改和完善，最后定型推廣。

與原有流程最大的不同在于兩階段工程的引入，其中重點是運營商需要介入領域工程中，這與傳統的系統建設過程有所不同。在領域需求過程中，其主要目的是識別可重用平臺的通用和可變需求，它不解決單個應用的需求問題，這就需要與數量眾多的不同的利益相關者進行交流，研究不同來源的需求信息，歸納和整理出通用和可變的需求清單。在領域設計過程中，相對于傳統的應用設計會有更多關于滿足可變性要求的設計要求，參考架構必須支持大規模定制開發，需要更多地考慮可擴展性和可維護性等非功能需求。同時，運營商還需將統一技術架構所要求的組件劃分、服務抽象和數據模型等貫徹其中，確保得出滿足各方期望的平臺參考架構。在領域實現過程中，最大的區別還是在于對可變性的支持，為未來二次開發留下足夠的空間和手段，另外相對單一系統開發配置管理顯得尤為重要。即使運營商不參與領域實現的工作，但是為了降低后期運營和維護的復雜性，對于基礎設施和系統軟件（如操作系統、數據庫、中間件等）的選擇也應給出一些強制性的要求。在領域測試過程中，重點是對可變性的測試。對于運營商而言，由于可重用平臺不是一個完整的上線部署的系統，如何進行工程驗收是一個難題。一方面，可以通過實驗室測試進行驗證，檢驗可重用平臺是否滿足通用性和可變性需求是否滿足以及是否符合組件劃分、服務抽象、數據模型、基礎設施等技術架構方面的要求；另一方面，與試點工程結合也是一個有效的方法，根據試點工程的建設過程以及上線運行情況對可重用平臺進行評估，作為平臺最后的驗收依據之一，這樣也可較好地融入現有的BOSS建設流程。

從技術分層角度分析，運營商參與領域工程決策由易到難分別是硬件平臺、系統軟件、中間件和應用軟件，當然對于總體架構的控制力度也逐步提高。其中硬件平臺和系統軟件的選型決策可選擇范圍相對較小，一般無需定制或者二次開發，而且與供應商需要協調和溝通的復雜性較低，因此介入難度較低。然而仍有可能對應用架構造成較大影響，比如將小型機平臺改為x86云平臺，需要對應用進行云化改造，同時還涉及自動化部署、彈性伸縮、高可用性和應用監控等方面的基礎服務提供問題。中間件的介入則較為復雜，它的選擇不僅影響到應用運行的環境，如數據庫服務、消息服務、流程服務、會話服務、事務服務和緩存服務等，而且也影響到應用的開發、測試、發布和部署等方面的技術決策，對于運營商而言需要有相當的軟件研發技術實力，而且需要與供應商進行較為密切的協調和溝通，因此介入難度較高。最為復雜的當然是應用軟件的介入，這也是領域工程的核心。首先，可重用平臺通用和可變需求的識別和確定，其個性化程度要遠高于前三者，需求來源也更加復雜和多變；其次，平臺設計過程中涉及的大規模定制開發等方面是運營商較為陌生的，即使不參與代碼實現，也需要大批具備較高研發能力的人員參與其中；最后，為保證平臺實現和二次開發的有效銜接，運營商有必要對研發過程進行全程管控，甚至深度參與平臺測試工作。

運營商參與領域工程，尤其是涉及中間件和應用軟件層面時，需要具備一定的軟件研發過程管理能力。如果運營商進行可重用平臺的自主研發，可以參考CMMI進行軟件研發的組織和管理工作。如果仍采用軟件外包的方式進行可重用平臺的研發，可以對CMMI進行適當剪裁，把重點放在技術方案制定和跟蹤、配置管理、問題管理、接口測試等方面。由于外包的開發工作無論是在領域工程還是應用工程階段都可能涉及多個供應商的方案和進度的協調，因此技術方案制定和跟蹤顯得尤為重要，一般需要運營商和供應商共同成立專門的技術方案組來負責，除了在工程初期需要根據需求制定總體技術架構以及分工實施安排，且在工程過程中還需要根據項目組提交的各種問題和新的需求不斷調整技術方案并重新進行分工安排，藉此來保證技術架構要求的跟蹤和落實。

5 結束語

為滿足市場的快速變化和企業戰略轉型的要求，電信行業BOSS建設流程仍需不斷完善，運營商積極參與領域工程的需求、設計、實現和測試，推動不同供應商設計出滿足運營商要求的可重用平臺，對于運營商提升架構管控能力會有較大幫助。但領域工程對于電信運營商而言還比較陌生，還存在諸如質量保證、系統演進、工具保障等具體實施問題，需要筆者進一步研究和探索。

1 顧強,鄭世林.中國電信體制改革政策配套效果研究.中國工業經濟,2012(8)

2 李萌.BOSS管理系統研究與應用.北京郵電大學碩士學位論文,2012

3 侯蒙.IT支撐網建設和運維系統規劃.北京郵電大學碩士學位論文,2012

4 柳博亮.新環境下的電信運營商信息化建設方式探討.信息通信技術,2012(1)

5 Clements P,Northrop L.Software Product Lines:Practices and Patterns.New Jersey:Addison-Wesley,2001

6 Pohl K,B觟ckle G,Van Der Linden F.軟件產品線工程.張佳驥,李彥平譯.北京：國防工業出版社，2010