TOGAF 9.2是企業架構實際上的標準，在全球有廣泛實踐。其包含的四種架構也被廣泛認同：

TOGAF最重要的事項就是落地，在整個方法論體系中，并未明確說明實踐路徑，在整個項目推進環節，需要適時調整或剪裁，確保平穩著陸，有幾項觀點為大家作參考：

觀點1：調研、診斷、優化三者的關系

從小處說，調研是為了了解現狀、明確問題、定位痛點，這需要“內部分析”。從大處說，調研還有助掌握政策趨勢、洞察行業機會、解讀標桿實踐。這需要“外部分析”和“行業分析”。

同時，無論是“問題與痛點驅動”還是“趨勢與機會驅動”，都要做好診斷與優化。診斷優化環節的價值在于把脈、在于針對性。一是輸出“具體差距”，二是給出對應藥方、對應改進策略。

頂層架構規劃時，調研必須充分，從上至下全面覆蓋。很具體的IT解決方案，調研環節小做即可。

觀點2：分析不透時，要返回頭優化分析模型

分析模型應細致、合理。例如，PEST分析的內容就不是一刀切的，可以根據需要規劃的方案的不同背景或特定場景，做相應側重或剪裁。

其次，分析不透時，要有意識地返回頭優化分析模型。例如下圖，針對現在流行的“風口識別”，進行了模型優化：

行業格局方面——產業鏈初步成型，是風口條件1。

客戶&市場方面——增量市場初步形成，是風口條件2。

競爭格局方面——壟斷格局尚未形成，是風口條件3。

觀點3：企業級頂層規劃，如何縱向到頂

企業頂層規劃的本質是“變革規劃”或“轉型規劃”，因此縱向到頂的調研與分析必是重中之重。

如下圖所示，外部分析、行業分析、內部分析、標桿與最佳實踐調研等都是制定或理解戰略不可或缺的環節。同時，頂層規劃中也有必要對運營模式、商業模式、組織機構、業務流程、業務渠道等進行診斷優化。實際實踐中，更少不了在標桿調研、診斷優化兩項工作之間反復迭代。

觀點4：具體IT方案規劃，可對方法剪裁

有方案經理問我，具體IT解決方案規劃中，“縱向到頂”的調研分析要不要做？做多少？

問題1：你作為方案負責人，有“變革拍板權”嗎？

問題2：你做好方案后的匯報對象，有“變革拍板權”嗎？

如果都沒有，就對方法剪裁，別花大力氣在外部分析和行業分析等高大上環節。

觀點5：應用架構設計，如何上接業務

實踐中，應用架構設計環節的核心產物，有4個：應用功能架構、應用系統劃分、應用集成架構、應用部署架構。其中，應用功能架構長這樣，高層文檔中屢見不鮮：

在《業務架構·應用架構·數據架構實戰（第2版）》一書中，筆者也提煉總結出了“應用功能架構模式”。如下圖所示：

TOGAF實踐要落地，“業務驅動的應用功能架構設計”是重中之重。業務驅動的邏輯是否充分、是否通達，是方案最終成敗的關鍵。

下圖簡要揭示了“上接業務”的思維要點：

觀點6：應用架構設計，如何下接研發

在下游，承接規劃方案的是項目研發。如何做到這之間的“銜接貼地”呢？重點是“不虛”。

應用架構設計環節中，“應用系統劃分”這項工作，切出來具體前端項目、后臺項目、平臺項目，就是“不虛”。相反，僅僅切出來一堆業務組件、功能模塊，去驅動研發，就又“虛”又“飄”。

請讀者看下圖，“桌面應用”項目旁邊代表75%的符號,在研發管控中有何實際價值？