1.4 沉吟至今

通過尋根溯源我們可以發現，即便是從TOGAF算起，業務架構這個詞也有20多年的歷史了，但是在開發人員中，業務架構顯然沒有需求分析的概念明確，業務架構師也遠不如產品經理常見。筆者曾就職的單位曾經實施了一個長達數年的、以企業級業務架構驅動的轉型項目，但是很多企業并沒有這樣的經歷，因此，每當與技術人員討論至此，他們就會覺得業務架構有點兒虛，細究可能有如下幾點原因。

1．用得少

原有的單體式或豎井式開發依然是企業更常采用的項目構建方法，而這種開發基本上沒有橫向視角，所以無需強調業務架構，通常的產品分析或者需求分析即足以滿足其開發需要。

2．難設計

業務架構，特別是大型企業這種錯綜復雜的業務架構，說起來容易做起來難。業務架構對戰略的分解、業務架構自身的整合與標準化，到IT設計的過渡都存在不少陷阱，業務越復雜寬泛就越難駕馭。因此，即便是嘗試過業務架構設計的企業，也有不少是將業務架構設計保持在高階狀態，讓做過的人自己都覺得有點兒沒底氣。

3．易偏離

施工期間由于客觀因素可能會導致實施對業務架構的偏離，這種偏離如果沒有得到及時糾正或架構調整，那么累積久了就會造成業務架構的失真。

4．難維護

少數度過了業務架構落地困難期的企業，也會由于感受到維護架構的難度而心生放棄，從而降低了對業務架構的評價。