説説信息技術工程化問題_風聞

       自2014年國家取消運轉10年的信息化建設監理制度以後，面向過程的瀑布模型開發方法正式落幕，取而代之的是面向對象的所謂敏捷模型開始野蠻生長。

       瀑布模型包含“需求分析（含調研）、概要設計、詳細設計、編碼實現、模塊測試、集成測試、試運行、交付驗收、運行維護”幾個階段，是一次性過程，項目實施管理過程中發現，當實施範圍、開發規模大到一定程度後，這種模型就顯得過於理想化，被人類天生的認知規律所侷限，時常發生到項目後期試運行或運維階段才發現之前提出的需求不是內在真實需求，而此時項目已經成型。基於人類認知是螺旋上升的這一客觀規律，人們將瀑布模型的各階段提煉，然後進行全階段迭代，即重複迭代執行“分析、設計、編碼、測試、小版本發佈、反饋”全過程，逐步形成符合真實需求的信息系統。在方法提煉時，人們將以流程為核心驅動的功能化設計變更為以對象（功能與數據封裝）為基本單位粒度、以接口松耦合方式對系統進行組織，方法上稱為“面向對象的敏捷開發方法”。只是此時的定義顯得一廂情願了，因為更基本的對象、對象特性、粒度標準都沒有形成共識，實踐活動中產生了無數技術分支，大量的新開發語言、新編譯環境等新技術誕生，而所謂敏捷管理模式也淪為一種不再包含內容性內涵的行為過程抽象，至此信息技術實施路線全面分化。

       信息技術實施的天破了，自然就談不上什麼有效的管理，只能讓子彈飛啊飛。在這個源頭紊亂、技術路線繁雜的領域那些強行要求規範管理的、並且與建築管理領域進行比對和復刻的都挺蠢，願望挺好，也只能是為增進規範可能性提供素材，至於那些實施相對比較成功的項目，是被流彈打中了，多數則成為了光榮的時代背景。但仔細梳理現實中的技術要素，則會發現幾條大的脈絡逐漸成熟起來。

       首先是基礎服務器和網絡領域基於並行訪問和硬件資源利用效率的問題驅動，沿着“集羣、虛擬化、雲計算”軌跡發展。原本這是很樸素的一個問題驅動軌跡：因服務器有併發訪問請求問題，於是處理上考慮將請求分發到不同的服務器上，由多台服務來響應這些請求，這多台服務器就構成了集羣（自然也有了針對集羣的反向代理和負載均衡技術，衍生技術先不表）；又因為併發訪問請求有時間段，集羣在訪問波峯波谷利用效率就成為問題，解決方案就是虛擬機技術，將一台實體服務器虛擬成10台虛擬服務器，在需要的時候通過調度程序快速熱部署虛擬服務器，這自然會提高物理機器利用效率；這項技術展現出了潛在市場價值，於是軌跡變了，利益開始驅動，一時間幾乎所有的IDC服務商、大公司和風險資本都被吸引，使虛擬機技術得以深化，宣傳上則美其名為雲計算，其性質不過是計算機網絡世界的“廉租房”方案，因虛擬資源可調度、可計量，天然具備可租賃的商業模式。到此為止，雲計算技術還算正常，可接下來市場推廣就偏離正常軌道了，有意忽略了“廉租房”實際定位，通過概念混淆，把雲計算包裝成包醫百病的技術路徑，一夜間企業如果沒有云或者沒有加入雲彷彿就落後百年了，待到這些企業探頭進去才發現：CRM（客户關係管理）服務器、ERP（企業資源管理）服務器、PLM（產品生命週期管理）、MES（生產計劃執行系統）系統等企業常規應用服務器和數據要怎麼辦？關鍵問題是：這些系統併發訪問需求真有那麼大嗎？生產製造企業脱離這股風潮後，一些網絡平台則是迎來了真正的春天，平台型企業服務進入到社會公共平台領域。

       其次是軟件系統開發（尤其是事務型應用系統開發）領域面向對象的Java開發語言環境成熟，Struts2、Spring、Hibernate覆蓋MVC（業務模型、用户界面、控制）開發模式，提供全面的功能包支持，再輔以23種開發模式構型，開發工作彷彿標準得不能再標準了，工程化時機儼然成熟，只是相對於同期那些紮根雲計算，依託開源社區，圍繞hadoop（分佈式文件系統）、map-reduce（映射-規約）這一算法模型逐步生成的一個龐大生態，公共平台以行為分析為目標，催生了大數據、商業智能新業態雛形後，顯然，資本更偏向後者，於是一些全新的價值增長點、機制變革點爆發顯現，如機器學習、人工智能、深度學習、區塊鏈等。

       第三是圍繞軟件開發實施過程的管理標準框架，自60年代提出軟件工程概念到二十一世紀初，針對軟件開發實施內容的管理標準框架是TOGAF（The Open Group Architecture Framework 美國國防部的信息管理技術架構），針對軟件開發實施過程的則是大家都很熟悉的項目管理標準。TOGAF在內容上指導思想沿襲了詹姆斯馬丁的信息工程論思想，將內容架構依據所面向對象的不同，劃分為業務架構、應用架構、數據架構、技術架構四個基本框架；針對過程的信息化項目管理與其它行業項目管理標準基本一致，包含範圍管理、進度管理、成本管理、質量管理、人力資源管理、溝通管理、風險管理、配置管理、外包管理9大知識領域以及42個可裁剪過程管理模塊。在新業態顯現、開源社區作用日益加重之前無論國外國內，工作中遵循的指導都是這兩個方面的標準，大小公司、企業只在分工全面性、嚴謹性上有所差異，基本思路都是一致的。但面對開源社區的作用凸顯以及新業態業務內容、技術邊界這些源頭上的不確定性，TOGAF和PM都顯得不能適應，國際上一些標準組織和國家（包括我們的工信部）都應急跟進，大量出具一些行業指導白皮書，嘗試攀登標準高峯，尤其在工業互聯戰略核心要地，中國的AII，即工業互聯網體系架構2.0、德國的RAMI4.0（Reference Architecture Model Industrie 4.0）工業4.0參考架構模型、美國的IIRA（Industrial Internet Reference Architecture）美國工業互聯網參考架構、日本的IVRA（Industrial Value Chain Reference Architecture ）工業價值鏈參考架構。這些架構共同的地方都是以多維度多層級的視圖為內容組織依據，都是以數據架構為核心，側重則有所不同，德國日本側重價值鏈發掘與對接，美國側重視圖層級銜接標準化，我們則是以產業層、企業層、邊緣層作為頂層劃分，側重系統性交互連接。但到目前為止，我們並不清楚不同層級的核心需求究竟是什麼，我因工作關係，在電子、醫療等生產製造企業承擔過十餘年的ERP、PLM、CRM等企業常見系統的實施以及二次開發工作，在面向綜合性國企、政府數據互聯互通、智慧城市等項目裏承擔數據架構類工作近十年，所以個人認為產業層（目前多數是像電網這類垂直系統）需求重心是技術升級（高速交互與高度自動化交互），企業層需求重心是互聯互通和原有價值保護（它才是形成AII中產業層的前提），邊緣層是面向未來的泛在物聯全新構建。

       第四就是當前以數據為核心的大趨勢，它也是我近10年來數據工作領域的體會，數據除了呈現為決策支撐外，過程數據資產化已成必然。只是目前數據工作中的概念還比較混亂，不同的應用方向、技術路線把大數據、數據結構、數據架構、數據模型、數據集、決策數據、數據呈現、數據平台、數據中台、數據中心、數據倉庫、數據挖掘、機器學習、數據算法等等繞成一團亂麻，它也讓我遭遇了工作上的滑鐵盧，在獲取一個高級別的工作平台後，卻在無序變革帶來的概念及層次混亂中無法給工作內容清晰定位，也就無法為甲方做出有效貢獻，於是捲了鋪蓋。沉默了近一年，仔細梳理了華為、阿里、京東等服務商提供的體系手冊、資料以及針對甲方真實需求的回顧，將問題鎖定在信息技術工程化問題上，為了驗證思考，更深入理解重要行業的數據以及標準問題，個人也做了其它一些臨時工作性調整。

信息化項目建設時，許多管理者都習慣用建築工程項目進行比對，建築工程項目管理能夠標準化的前置條件：

l  分段、分部、分項清晰，場平、樁基、結構、水施、電施、消防、暖通、內外飾。

l  計量核量標準唯一，每一方土石、商砼，每一種材料都可以有標準計量。

l  結構技術上樁基、框架、磚石相對穩定，設計意圖、實施範圍容易明確。

信息化項目建設過程特徵則是：

l  業務特徵、業務需求與項目建設實施方案、技術緊耦合，形成交叉依賴，自然也會交叉影響。

l  計量上約定俗成的核價方式是“代碼行”計量方式，但隨着開源社區龐大的第三方庫源代碼開源，使得衡量工程造價的基礎標準不再具有可信性，成本造價與產出交付價值失衡。

l  傳統意義上的業務、價值鏈價值增長業務（如生產製造、銷售等）與輔助業務（如人力資源、後勤保障等）、信息技術性業務之間因信息數據耦合性原因無法有效分離，使得項目控制難以機制化。

l  信息安全、狀態探針的嵌入，物理硬件資源的虛擬化，虛擬技術的多樣化，軟件開發技術路徑的多樣化，應用領域的全面介入，新業態不斷衍生深入，技術生態支持化都使得信息化項目越來越遠離規範標準而走向特殊情況、特殊案例。

在考慮信息技術工程化問題時，除了上面這些內在的內容性和計量性因素外，還有外在法規制度、行業分類一些上層指導，但這些天國家發佈了“數據安全法”（6月10日），國家統計局前幾日則是發佈了數字經濟分類分級文件，將數字經濟獨立為農業、工業之後的第三種經濟，區分兩條路徑：數字產業化和產業數字化。數字產業化包括數字產品製造業、數字產品服務業、數字技術應用業、數字要素驅動業四個領域；產業數字化只有數字化效率提升業一個業態。

數據安全法明確了數據權利歸宿與數據利用保護，有了這些頂層的分級分類和法律規定，在範圍和邊界確認上就具備了法理基礎。

目前來看，國家信息數據資源、產業管理部門下一步工作應該就是集中精力解決計量核量問題了，隨着數字經濟的明確，表明技術層面的一些核心思想已經達成共識：那就是讓數據驅動佔據主導地位，問題驅動、技術驅動、流程驅動退居輔助地位。這些工作都是形成工程標準的基礎。