架構三問【1】：架構規劃 如何撐起數字化轉型

本文轉載自張靖笙講數 ，作者張靖笙

本文內容來自資深架構顧問

張靖笙老師

的分享！

張靖笙老師介紹：

粵港澳國家應用數學中心戰略拓展委員會委員

數治應用技術（佛山）研究院 院長

中國智慧製造百人會專家委員

中國通訊工業智慧製造專家委員會委員

南海區大資料產業協會專家委員會委員

中山大學計算機工學碩士研究生畢業，曾任職於國際商業機器（IBM）中國公司、馬恆達。薩蒂揚軟體技術（上海）有限公司等大型全球IT公司和中國農業銀行等本土企業，透過二十五年的企業資訊化工作經驗積累，多年從事企業數字化轉型、金融科技和數字銀行、數字政府、創客教育創新等領域戰略諮詢、應用研究、解決方案設計與培訓及相關科技服務工作，已構建出一整套可有效提高學員的創新意識、創新思維和創新能力，啟發學員運用網際網路大資料思維，頂層設計和戰略規劃的方法，得到政府界、企業界和教育界的廣泛關注。

獲2019年中國講師50強，2018年“廣東省最具影響力講師”第三名，2017年度中華講師網500強等眾多商業講師名譽。

個人陸續出版專著《大資料革命》、《智造：用大資料思維實現智慧企業》、《5G大時代》等暢銷書作品，另參與國家工信部智慧製造專家百人會《解密智慧》、國家計算機技術與軟體專業技術資格（水平）考試2005年版大綱審定和教程教材編寫工作，參與編寫《系統分析師教程》《資料庫系統工程師教程》等計算機資格考試教程教材。

▼

說到軟體工程，我想起了資訊產業界曾經一個很燃的說法——-“軟體定義世界”，這是由Gartner在2014年釋出的10大戰略技術趨勢中提出來的，其中第8個趨勢是Software Define Anything，簡寫為SDX，翻譯成中文為“軟體定義世界”。

現在，國民經濟和社會生活中各個行業幾乎都有計算機軟體的應用，比如工業、農業、銀行、航空、政府部門等。這些應用促進了經濟和社會的發展，使得人們的工作更加高效，同時提高了生活質量，在人類世界中軟體的痕跡已經無處不在，“軟體定義世界”所言不虛。

當前，十四五和2035遠景目標規劃的開局之際，我們要迎接數字時代，啟用資料要素潛能，推進網路強國建設，加快建設數字經濟、數字社會、數字政府，以數字化轉型整體驅動生產方式、生活方式和治理方式變革。雖然軟體工程不是數字化轉型的全部，但肯定仍然要擔當數字化轉型的核心工作。

在數字經濟發展與產業全面數字化轉型的過程中，軟體將要服務於充分發揮海量資料和豐富應用場景的優勢，促進數字技術與實體經濟深度融合，賦能傳統產業轉型升級，催生新產業新業態新模式，壯大經濟發展新引擎。

▊ 使用者需求驅動的傳統軟體工程

關於軟體工程，業界有多個定義，比較認可的一種定義認為：軟體工程研究和應用如何以系統性的、規範化的、可定量的過程化方法去開發和維護軟體，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。它涉及程式設計語言、資料庫、軟體開發工具、系統平臺、標準、設計模式等方面。

軟體是由計算機程式和程式設計的概念發展演化而來的，是在程式和程式設計發展到一定規模並且逐步商品化的過程中形成的。軟體工程的發展大致分為4個階段。

無軟體概念階段（1946年~1955年）

：此階段的特點是尚無軟體的概念，程式設計主要圍繞硬體進行開發，規模很小，工具簡單，無明確分工（開發者和使用者），程式設計追求節省空間和程式設計技巧，無文件資料（除程式清單外），主要用於科學計算。

義大利麵階段（1956年~1970年）

：此階段的特點是硬體環境相對穩定，出現了“軟體作坊”的開發組織形式。開始廣泛使用產品軟體（可購買），從而建立了軟體的概念。但程式設計師編碼隨意，整個軟體看起來像是一碗義大利麵一樣雜亂無章，隨著軟體系統規模的壯大，軟體產品的質量不高，生產效率低下，從而導致了“軟體危機”的產生。

軟體工程階段（1970年至今）

：由於“軟體危機”的產生，迫使人們不得不研究、改變軟體開發的技術手段和管理方法。從此軟體產生進入了軟體工程時代。

面向物件階段（1990年至今）

：這一階段提出了面向物件的概念、思想和方法。包括面向物件的分析（OOA，Object Oriented Analysis）、面向物件的設計（OOD，Object Oriented Design），以及面向物件的程式設計實現（OOP，Object Oriented Programming）等。

傳統企業資訊化一般是透過ERP、CRM、MES、PLM、OA 等業務和管理應用軟體系統的建設，構建覆蓋企業完整業務線的資訊平臺，從而基於資訊實現對企業人、財、物等方面的精細化管理。傳統企業資訊化系統的軟體研發主要側重於實現業務執行過程的規範性和合規性，這樣，軟體工程基本上是基於現有業務場景作為需求分析物件的，使用者需求驅動是傳統企業資訊化的基本假設。

國外大的軟體公司和機構一直在研究軟體開發方法這個概念性的東西，而且也提出了很多實際的開發方法，比如：生命週期法、結構化方法、面向資料結構的軟體開發方法、面向問題的分析法、原型化方法、面向物件方法等。

這些軟體工程的方法形式不同、各有千秋，可都還是以使用者需求驅動軟體開發作為軟體工程的基本假設，而使用者往往是在其當前的業務環境和工作場景中提出對軟體的各項需求，這本質上就是一種依葫蘆畫瓢的方法，以當前的業務場景為葫蘆，畫出資訊系統這個瓢，業務資訊是葫蘆裡的藥，資料是瓢裡面的水，有瓢才會有水。

雖然軟體工程在指導單個軟體專案的研發工作時是有效的，但我們必須看到過往企業資訊化中大量的軟體專案是在缺乏企業層面統一部署和統籌安排下，完全在各業務領域和部門的使用者需求驅動下“依葫蘆畫瓢”建設出來的。

這樣搞出來的軟體系統，雖然也發揮出規範業務、支援管理、提升效率的作用，但由於缺失在戰略和企業架構指引下建設的眾多軟體系統，而且在建設過程中使用者需求存在侷限性和短視性，遇到各種問題採用“頭疼醫頭、腳疼醫腳”打補丁的升級改進方式，因此給企業留下了大量互不相容、參差不齊的整合陷阱、資訊豎井和資料孤島，這些軟體系統雖然程式碼凌亂，但貌似穩定並且能勉強支撐當下的業務和管理需要，就是動不得、改不得、拆不得，往往不知道哪塊磚抽掉整個房子就都嘩啦啦地崩塌了。

這種沒有在企業架構指導下形成的企業資訊化現狀，會讓我們的企業資訊化決策者們猶豫要不要改造，而長此以往，這樣的企業資訊化建設路徑無論如何都無法從企業戰略全域性的高度推動和促進整體性轉型和高質量可持續發展。

▊ 縱向到頂、橫向到邊的規劃方法

而當我們進入數字經濟時代，這種傳統的軟體工程方法已經明顯不能滿足數字化時代企業對業務執行創新和變更的要求，新的數字化時代給軟體工程帶來了新的問題和新的要求，並且成為嚴重影響轉型的結構性矛盾。

下面來分析幾點比較普遍性的問題：

首先

，數字化轉型是從企業發展戰略出發的，推動數字化轉型的軟體工程中的技術決策和管理工作一方面要服從企業轉型發展戰略的需要，這需要企業掌舵人具備跟上時代技術發展前沿的數字化轉型認知能力；另一方面，軟體工程中一些具體的技術選型也會深刻影響到企業戰略的發展走向，這又需要企業內部IT組織的決策者們能全方面掌握企業的戰略發展方向和業務全域性，毫無疑問，這對大部分的中國企業來說是件極具挑戰的事情。

其次

，數字化轉型的軟體工程服務於轉型，本身就是以驅動生產方式、生活方式和治理方式變革為使命的。

目前，業務場景不能再作為軟體開發直接參照依據，傳統企業資訊化那種依葫蘆畫瓢的軟體工程方法遇到極大的不適應，提需求的業務使用者講不出數字化後的業務是怎麼回事，靠使用者需求驅動的軟體工程方法如何能畫出那些本質上還不存在的業務場景呢？這些業務場景又是從哪裡來的？這些只能從企業掌門人的戰略意圖中推匯出來，透過規劃和頂層設計將未來業務發展藍圖描繪出來，而傳統軟體工程雖然在需求分析環節也有對業務上下文環境的分析，但明確缺乏勾勒未來業務場景的指導思想和方法能力。

再次

，根據傳統軟體工程所定義的軟體生命週期，主體工作聚焦在軟體定義和軟體開發階段，在數字經濟時代，資料是生產力的關鍵要素，企業要更關注各種資料資源的採集、分析和應用，而這些資料資源既有企業內部現有的資訊系統，也有來自外部合作方和網際網路的外部資料來源。一方面，大量的軟體專案要在這樣多樣性的資料環境中實施並推動一些新生產方式和商業模式的形成；另一方面，軟體的運維也涉及大量的資料管理、治理、應用和運營工作，圍繞資料資源邊治理、邊開發、邊應用、邊（業務）創新、邊經營將成為軟體工程的新常態。

由此，我們可以總結出幾點總體要求：數字化轉型中的軟體工程必須從戰略發展大局的高度、企業全域性的寬度、結構性改革的深度、創新與變革全週期的長度來進行，以數字技術為抓手，以資料要素形成資料生產力為核心任務重新定位。與之比較的傳統軟體工程，只能說是覆蓋了其中很少一部分工作。

溫昱老師在其新書《業務架構 應用架構 資料架構 實戰》中指出：“多年來，全球業界已在業務架構、應用架構、資料架構、技術架構方面積累了大量經驗。近幾年，數字化轉型呼喚‘懂行人’打通四種架構，確保技術支撐業務、業務支撐戰略。”

在我看來，在“懂行人”看來，這本書將不啻於提出了一個符合數字化轉型要求的軟體工程實踐的全景圖。

當我們祭出The Open GroupArchitecture Framework （TOGAF） 這個企業架構最主流的方法論時，傳統軟體工程恐怕只能覆蓋其應用架構中很少一部分工作。

數字化轉型千頭萬緒、牽一髮而動全身，軟體工程是數字化轉型的核心工作，而如前分析，為了滿足數字化轉型對軟體研發工作的新要求，必須要從企業架構的角度統籌組織數字化轉型中各軟體工程專案全生命週期的各項任務，這樣才能縱覽全域性，明細戰略、業務到技術三層級工作內容的關係。

俗話說“一圖勝千言”，採用架構的形式，可以幫助決策者在紛繁的具體事務中快速識別出關鍵元素，並澄清要素之間的邏輯關係，從而幫助組織減少在劇烈變化的轉型過程中很容易引發的混亂和混淆，就此而言，我認為企業架構應該成為企業未來每一個軟體工程所必須依據和遵循的總體策略指引。

▊ 規、管、建、用、評五個環節

從企業架構的角度來看，我們同樣必須要重新定義軟體工程的生命週期。

如果我也算一個溫老師所言的“懂行人”，那麼我願意結合自己在諮詢工作中對企業架構方面的經驗和理解，在業界現有工作成果的基礎上，給出我的一點補充和調整。

我在TOGAF9。2框架的基礎上，把面向數字化轉型的軟體工程工作內容分到“規、管、建、用、評”五個環節。

評價環節

：評價代表了價值主張，這是一個既是開始也是結束的環節，願景最終要落實到可以實施評價的成功標準和規範要求，這樣才能完成戰略的有效閉環。

規劃環節

：戰略進（輸入）架構出，這是規劃和頂層設計的具體工作，沒有經過架構設計的戰略，誠如沒有地圖指引下帶兵出征的統帥，焉有不敗之理？

管控環節

：業主是每一個軟體工程的需求責任人，需求管理體現了業主對工程從目標到成果的管控依規，而與傳統軟體工程顯著不同的地方，體現在業主戰略發展權益的大需求，而非僅僅軟體功能和使用者介面的小需求上。

建設環節

：這可以看成是傳統軟體工程方法仍能發力的環節，只是基於企業架構的建設工作可以解決傳統企業資訊化中“一統就死、一分就亂”的結構性矛盾，在企業架構的總體統籌下，組織每個具體部門和業務應用系統形成了一個分而不裂、散而不亂的有機整體，就像一個框架結構建築中的功能房間，每個房間都可以按照自己的使用者需求裝修佈置拆解組合，但是隻要不破壞框架基礎設施，不改動負責建築整體結構受力的四梁八柱，就不會破壞整個建築的可靠性。

應用環節

：為了支援業務中對數字系統的應用，這裡包含了系統運維、資料治理與運營管理兩方面工作，分別對應支援業務連續性的IT保障、資料治理和資料資產經營工作。

為了做好數字轉型過程中眾多軟體工程中“規、管、建、用、評”五個環節的工作，我提議每一個企業都應該考慮成立一個數字化總規辦公室，從總控層面統籌安排好組織內各項相關能力和資源，在數字化轉型的每一個階段發揮好各自的作用，確保完成轉型中的各項工作任務。

接下來，我打算針對企業市場中各類企事業單位對數字化轉型的迫切規劃諮詢和實施方案需求，依託粵港澳國家應用數學中心和業界朋友資源，建構一個為業主們提供全戰略週期諮詢顧問服務，從戰略到架構，從架構到過程，從過程到資產，全面覆蓋“規、管、建、用、評”五個環節的管家式數字化轉型一籃子戰略諮詢顧問服務。

▊ 後記

我多年老友溫昱的新書《業務架構 應用架構 資料架構 實戰》最近大熱上市了，這本書去年8月份他曾經把手稿給我，並徵詢我的意見和建議，說起來慚愧，我當時手頭有些忙，對老溫給我的文稿囫圇吞棗翻了一遍，雖然又一次感嘆於老溫寫作風格的圖文優美、深入淺出，可對老溫的書稿由於沒有仔細讀也就沒有認真想，除了給了一兩份過去自己諮詢專案脫密後的交付成果供參考，也沒給出什麼太有價值的建議，有些對不起老友。

老溫是國內久負盛名的架構師，以邏輯通暢、結構清晰的風格把對任何一個企業來說都是宏圖大計的話題全景式陳述出來，這方面的匠心努力實在讓我佩服。坦白說雖然我也有多年做企業架構頂層設計（或者稱為資訊化戰略規劃）的諮詢專案經驗，我卻沒有勇氣像老溫這樣系統地寫出一本關於企業架構的書籍。

在諮詢專案的實戰中，我們往往扎進不同企業的組織環境和千奇百怪的具體問題中，這裡一方面涉及大量業主機密的細節，不敢披露；另一方面，從紛繁交織的經驗材料中萃取出普遍性規律性的知識和方法，這又是一件需要極高知識建構能力的文化大工程。

這次拿到出版後的書細細品讀，我也回顧了這麼些年相關工作經驗。這兩天還和老溫熱烈地透過電話與微信溝通了一番，我們初步達成一個共識，傳統軟體工程的理論與方法已經不能再全面支撐數字化轉型的需要了，非常有必要做一些創造性的思想工作，我想透過自己的想法先來拋個磚，希望能夠給大家帶來啟發。

▊《業務架構 應用架構 資料架構 實戰》

溫昱 著

每一頁都是實踐經驗的總結，參考性超強

每一頁都簡潔明瞭重點突出，可讀性超強

大局＋架構＋文件，三大篇，操作性超強

本書思路清晰，每一個概念、每一項方法都給出了簡要透徹的闡述。同時又結合實踐，給讀者看得見、摸得著的專案實感，幫助讀者迅速上手。本書還有一個作用，就是能提升讀者對IT及其業務的認知層次，為長遠職業發展提供助力。

如果喜歡本文

歡迎 在看丨留言丨分享至朋友圈 三連