隨著數(shù)字化進程的推進，幾位客戶多次與我提起如何導(dǎo)入TOGAF。TOGAF是The Open Group Architecture Framework的縮寫，由The Open Group，(一個非盈利的技術(shù)行業(yè)聯(lián)盟) 開發(fā)和更新。它支持在企業(yè)戰(zhàn)略指引下進行架構(gòu)分析，并構(gòu)建項目組合，通過項目推進企業(yè)不斷進行業(yè)務(wù)與數(shù)字化平臺演進，并形成企業(yè)的架構(gòu)資產(chǎn)。簡單來說，就是數(shù)字化無縫支持（或?qū)崿F(xiàn)）業(yè)務(wù)，最終支持企業(yè)愿景實現(xiàn)。
圖表 1內(nèi)容元模型概覽（參考：TOGAF）
盡管不少企業(yè)的流程管理和數(shù)字化轉(zhuǎn)型部門員工已經(jīng)獲得了TOGAF證書，然而當企業(yè)真正導(dǎo)入TOGAF 時，仍然對于TOGAF 怎樣結(jié)合企業(yè)的數(shù)字化轉(zhuǎn)型項目和項目產(chǎn)出的“架構(gòu)資產(chǎn)”如何管理存在疑問。
在TOGAF 一系列的方法中，內(nèi)容元模型這一部分被分為架構(gòu)原則、愿景、需求、業(yè)務(wù)架構(gòu)、信息系統(tǒng)架構(gòu)（包括數(shù)據(jù)架構(gòu)、應(yīng)用架構(gòu)）、技術(shù)架構(gòu)、架構(gòu)實現(xiàn)這幾部分。
圖表 2 4A企業(yè)架構(gòu)（調(diào)整版）
離散地看這些，再結(jié)合項目管理的內(nèi)容，可能會有些無所適從，不知道從哪里下手，下面我們嘗試用簡單的方式來闡述一下。
企業(yè)中的數(shù)字化轉(zhuǎn)型是為了支持價值實現(xiàn)。本著有的放矢、以終為始的原則，我們以業(yè)務(wù)價值為出發(fā)點，把企業(yè)的業(yè)務(wù)和與之匹配的數(shù)字化系統(tǒng)分層劃分為4A架構(gòu)，它們分別是業(yè)務(wù)架構(gòu)，數(shù)據(jù)架構(gòu)，應(yīng)用架構(gòu)和技術(shù)架構(gòu)。從業(yè)務(wù)價值實現(xiàn)角度出發(fā)，設(shè)計和制定流程，匹配相應(yīng)的角色和組織。沿著流程識別數(shù)據(jù)實體的增刪改查和IT需求。根據(jù)數(shù)據(jù)增刪改查和業(yè)務(wù)的需求，收斂成應(yīng)用架構(gòu)，再用技術(shù)基礎(chǔ)設(shè)施來支撐系統(tǒng)實現(xiàn)。這些架構(gòu)具有顆粒度相當?shù)膶蛹墝?yīng)關(guān)系，但并非嚴格對應(yīng)。
當一個企業(yè)需要通過數(shù)字化來支持規(guī)?；瘏f(xié)作的時候，往往需要考慮首先進行企業(yè)的頂層設(shè)計，統(tǒng)一規(guī)劃后，把可能會被各部門重復(fù)調(diào)用的流程集約化設(shè)計成為可復(fù)用的業(yè)務(wù)能力模塊，繼而開發(fā)相應(yīng)的數(shù)字化模塊來固化這個業(yè)務(wù)能力。當我們把這個可復(fù)用的業(yè)務(wù)能力模塊和相應(yīng)的數(shù)據(jù)、應(yīng)用合并為一個能力單元來看待的時候，這個組合就形成了一個積木塊。類似的、不同功能的積木塊，未來可以隨著企業(yè)需求適當排列組合，形成企業(yè)“即插即用”的能力。從頂層規(guī)劃到積木塊的開發(fā)，需要遵循統(tǒng)一規(guī)劃、逐步實施的過程。頂層設(shè)計的過程會被我們稱為架構(gòu)設(shè)計或業(yè)務(wù)規(guī)劃，基于規(guī)劃后對積木塊的逐一實施則要依賴單個的項目推進。
然而，企業(yè)在發(fā)展過程中，并不總是有著統(tǒng)一規(guī)劃的契機。當企業(yè)快速發(fā)展的時候，往往是厘清和搭建體系、建立相應(yīng)IT系統(tǒng)的******時機，錯過了就會對企業(yè)規(guī)?；瘡?fù)制賦能不足，提前了會導(dǎo)致體系與業(yè)務(wù)需求不符，進而帶來浪費。在實際情況中，急用先行的需求往往會多于“謀定后動”的需求，這并非總是關(guān)于管理的對錯，而是更多來源于市場窗口期、日漸增長的供應(yīng)鏈信息流和物流越加雜亂等現(xiàn)實壓力。
當企業(yè)一方面有著時間壓力，需要急用先行，一方面意識到頂層設(shè)計如打地基，一旦設(shè)計錯了，已經(jīng)蓋了的屋子要推倒，地基要挖出來重新做的時候，就要想辦法用架構(gòu)思維來平衡長期矛盾和短期矛盾。
一、 長期矛盾：
企業(yè)預(yù)見到快速發(fā)展期的到來時，應(yīng)盡早地進行業(yè)務(wù)架構(gòu)、數(shù)據(jù)架構(gòu)、應(yīng)用架構(gòu)的梳理，定義不同應(yīng)用模塊未來的部署方式或原則（如：購買軟件包，還是云服務(wù)，還是自研）。這會使得不同領(lǐng)域的數(shù)字化有條不紊，邊界和方向性更加清晰，減少不必要的數(shù)據(jù)集成或系統(tǒng)的重新開發(fā)。頂層設(shè)計的架構(gòu)顆粒度在業(yè)務(wù)架構(gòu)、數(shù)據(jù)架構(gòu)、應(yīng)用架構(gòu)層面可分別細化到業(yè)務(wù)流程（局部四級）、概念邏輯模型（概念層略下探）、應(yīng)用模塊層、技術(shù)域。
頂層設(shè)計的關(guān)鍵在于找到相應(yīng)領(lǐng)域在不同場景下的價值實現(xiàn)路徑（哪些變量可以支持目標實現(xiàn)，哪些活動可以支持變量改進），而非僅僅把業(yè)務(wù)現(xiàn)狀拿出來劃分成段。（參考之前的公眾號文章《價值驅(qū)動的流程管理》）
上圖描述了企業(yè)架構(gòu)頂層設(shè)計的一般過程。
? 首先，識別業(yè)務(wù)模式、場景； 厘清業(yè)務(wù)目標、子目標和關(guān)鍵結(jié)果領(lǐng)域；梳理業(yè)務(wù)流程，確保高階流程可覆蓋不同場景；類似流程進一步整合以減少后續(xù)維護和IT開發(fā)工作。
? 第二步，沿流程梳理IT 功能需求，和流程間流轉(zhuǎn)的信息，根據(jù)功能需求和信息增刪改查要求，梳理功能模塊。
? 第三步，收斂功能架構(gòu)、分析現(xiàn)有產(chǎn)品覆蓋情況、定義未來支撐的系統(tǒng)，梳理系統(tǒng)集成關(guān)系。
? 第四步，對比現(xiàn)狀與將來，識別“做幾個小手術(shù)”可完成改造；按照業(yè)務(wù)優(yōu)先級、模塊開發(fā)依賴關(guān)系等形成里程碑。
以上步驟完成后，基本形成頂層設(shè)計，后續(xù)可逐步推進各模塊的詳細設(shè)計和開發(fā)。
頂層設(shè)計的好處是企業(yè)的“管理資產(chǎn)”、“數(shù)據(jù)資產(chǎn)”、“應(yīng)用資產(chǎn)”會更有序、集約（重復(fù)調(diào)用的流程和功能都整合了）；管理/系統(tǒng)邊界和接口清晰、避免重復(fù)數(shù)字化投入和混亂的數(shù)據(jù)集成；數(shù)據(jù)資產(chǎn)管理較為“干凈”、可用性強；未來業(yè)務(wù)擴張時“可插拔”的彈性較好。但也存在弊端，比如：這個階段的花銷不直接體現(xiàn)為IT系統(tǒng)和業(yè)務(wù)收益，對于規(guī)模較小和資金緊張的企業(yè)可能會不合時宜。同時，我們也看到一些規(guī)模較大企業(yè)，由于未提前規(guī)劃好頂層設(shè)計，導(dǎo)致各事業(yè)部重復(fù)投資類似功能，或開發(fā)好功能后，發(fā)現(xiàn)由于數(shù)據(jù)集成關(guān)系的緣故，放在另一系統(tǒng)更為便捷。
二、 短期矛盾
盡管“良醫(yī)治未病”的故事已經(jīng)流傳了2000多年，然而有時企業(yè)的發(fā)展速度超出了我們的預(yù)期，規(guī)模擴張帶來的痛點先于整體規(guī)劃提前到來。
在此情況下，到底應(yīng)該先做頂層設(shè)計，還是要先解決痛點？此時應(yīng)以業(yè)務(wù)結(jié)果為導(dǎo)向。如果市場的機會窗口比較緊、企業(yè)的經(jīng)營差距較大或正在/即將面臨較大風(fēng)險，企業(yè)應(yīng)優(yōu)先選擇急用先行，其他問題在業(yè)務(wù)執(zhí)行過程中漸進糾偏。此時，如果在導(dǎo)入TOGAF同時剛好有在建項目，企業(yè)也無需暫停該在建項目，只需審視在建項目，使其交付包括業(yè)務(wù)架構(gòu)、數(shù)據(jù)架構(gòu)、應(yīng)用架構(gòu)即可，技術(shù)架構(gòu)不做強求，因為要結(jié)合實際項目來判斷用何種方式部署（比如：基于云平臺還是服務(wù)器部署等）。也為此，流程變革部門和數(shù)字化管理部門（有時候是一個部門）要主動關(guān)注到企業(yè)的外部環(huán)境和經(jīng)營現(xiàn)狀，并被給與一定獲知企業(yè)經(jīng)營信息的途徑和權(quán)限。
圖表 4 數(shù)字化賦能的業(yè)務(wù)轉(zhuǎn)型方法
在具體的數(shù)字化賦能的業(yè)務(wù)轉(zhuǎn)型（圖表4）中，項目被分為藍圖設(shè)計、功能設(shè)計、開發(fā)、驗證、試點/推行幾個階段。各階段均涉及幾條業(yè)務(wù)流，分別是業(yè)務(wù)流程與收益、數(shù)據(jù)、應(yīng)用、技術(shù)、架構(gòu)、項目管理、變革管理。其中，業(yè)務(wù)流程與收益責(zé)任人負責(zé)梳理流程、角色、組織、衡量指標；數(shù)據(jù)人員負責(zé)數(shù)據(jù)資產(chǎn)目錄、數(shù)據(jù)實體關(guān)系、數(shù)據(jù)標準、信息流等方案；應(yīng)用人員負責(zé)應(yīng)用架構(gòu)和集成架構(gòu)的設(shè)計，并開發(fā)應(yīng)用系統(tǒng)；技術(shù)人員負責(zé)技術(shù)能力和環(huán)境的部署搭建；架構(gòu)人員負責(zé)整體對業(yè)務(wù)、數(shù)據(jù)、應(yīng)用、技術(shù)架構(gòu)進行統(tǒng)籌同步，確保數(shù)字化平臺無縫支持或?qū)崿F(xiàn)業(yè)務(wù)；項目管理人員負責(zé)項目的準備、計劃、執(zhí)行監(jiān)控、關(guān)閉；變革管理人員負責(zé)通過溝通、宣導(dǎo)、培訓(xùn)等活動推動用戶的理念和行為轉(zhuǎn)變。
三、 資產(chǎn)沉淀與再利用
企業(yè)架構(gòu)是可以設(shè)計的，但最終是演進的。企業(yè)的數(shù)字化轉(zhuǎn)型中，為了平衡頂層設(shè)計和急用先行，有時會容許短期數(shù)字化投資的存在，系統(tǒng)會通過新陳代謝的方式逐步完善與革新。為此，企業(yè)要將由單一數(shù)字化轉(zhuǎn)型項目（或數(shù)字化賦能的業(yè)務(wù)轉(zhuǎn)型）所產(chǎn)出的交付，轉(zhuǎn)化為企業(yè)的流程資產(chǎn)或管理資產(chǎn)、數(shù)據(jù)資產(chǎn)、平臺資產(chǎn)；并在未來業(yè)務(wù)流程再次優(yōu)化、插拔的時候，基于當前資產(chǎn)給與復(fù)核或同步修正架構(gòu)資產(chǎn)（圖表5）。
圖表 5 TOGAF 在企業(yè)中的落地
單一項目承擔企業(yè)的具體數(shù)字化轉(zhuǎn)型（或數(shù)字化賦能下的業(yè)務(wù)轉(zhuǎn)型），企業(yè)的架構(gòu)部門予以復(fù)核，根據(jù)復(fù)核結(jié)果判斷是否修改單一項目中的具體方案，還是修改架構(gòu)本身。單一項目中的成果需要被不斷回收到企業(yè)的管理和數(shù)字化資產(chǎn)當中。這些自我迭代的活動需要通過項目管理（主要針對項目，關(guān)注項目目標）、項目治理（主要針對項目集，關(guān)注商業(yè)和戰(zhàn)略目標）和變革流程來實現(xiàn)。企業(yè)可依據(jù)具體業(yè)務(wù)復(fù)雜程度和人員規(guī)模，來規(guī)范“流程資產(chǎn)、管理資產(chǎn)、數(shù)據(jù)資產(chǎn)、平臺資產(chǎn)、項目治理和變革管理的權(quán)責(zé)?！?/span>
通過不斷的轉(zhuǎn)型演進（單一項目）與新能力的回收（架構(gòu)資產(chǎn)），企業(yè)可逐步形成自己的企業(yè)架構(gòu)。企業(yè)架構(gòu)的完善會幫助企業(yè)建立可裂變的組織能力，賦能企業(yè)業(yè)務(wù)、產(chǎn)品創(chuàng)新和開源節(jié)流。
