Jason Bloomberg最近在部落格中問道：“為什麼沒有人做企業架構（Enterprise Architecture）呢？”他說：
解決方案架構師應該在實施解決方案之前完成解決方案的架構設計。Java架構師和.NET架構師做得事情應該先於程式設計人員。你不能先實施架構再設計架構，只能先設計再實施……可是，企業架構（Enterprise Architecture）卻往往從現有企業開始……當今企業架構師的角色主要面對當前企業，修補其中的問題。好吧，也許不全是這樣，但卻要做某種程度的改進。將企業架構從當前的“糟糕的”狀態扭轉到“完美的”狀態，在這一狀態下事情會變得更好。
Bloomberg認為，雖然解決現有企業的問題既重要又高尚，但是這並非企業架構的工作：
架構不是解決問題，而是為設計活動建立一套最佳實踐。
所以，在他看來，沒有人在真正地做企業做架構。企業在不斷成長，
每個企業家都知道這個基本道理。當企業首次坐下來，為新的商業投資制定方案時，如果組織(organization)大到可堪稱企業（enterprise），他們也許永遠也不敢對它做全面的架構設計，因為這裡面有太多未知的東西。相反，他們卻喜歡建立一個不斷成長的框架。播散種子，為之澆灌、除草及施肥。如果運氣好的話，沿著這條路走下去，也許能收穫一個不錯的、健康的、不斷髮展的企業架構。但是最終的架構看上去可能與最初設想的樣子相去甚遠。
Bloomberg繼續說到，這與企業架構（Enterprise Architecture）的概念有很大差異，企業架構要定義並建立一組最佳實踐，通過它們去實現企業預期的最終目標。問題是：
發展企業……意味著它會像任何生物體的生長一樣，沒有確定的最終狀態。一粒橡果最終將會長成橡樹是確定的，但是這棵橡樹到底長成什麼樣子，確實無法計劃的。相反，橡果的DNA決定了會長出橡樹這一基本屬性，但是其他的東西就取決於後天的變化了。這類變化確定了複雜系統的特徵：系統具有各種變化的屬性，但這些屬性綜合起來卻不同於任何部分的屬性。就像生物界的機體依賴於變化一樣，企業的發展同樣依賴它。
Bloomberg認為，改變企業架構的目標是沒有意義的，相反應該引入一些新原則：
也許，應該為架構的變化確定最佳實踐了。畢竟，如果我們可以對傳統系統做架構，為何不能對複雜系統做呢？……我們到底能否找到實際做企業架構的方法？畢竟，企業架構需要的是複雜的、系統的方法。最後，還得看“能不能那樣做企業架構（Enterprise Architecture）”。
JP Morgenthal在這篇帖子的評論中說道，問題不在於企業架構的原則，而在於企業架構（Enterprise Architecture）這個詞本身：
……企業架構這個詞如果換成多維度架構（multi-dimension architecture）可能更好。後者更好地抓住了該活動的本質，而且沒有將它限定在某個特定的範圍內——範圍視任務的大小而定。我一貫認為業務與多維度架構保持著緊密聯絡。人們設計的解決方案包括業務流程、工作流、應用、使用者體驗、網路連通、災備/恢復等；但是，思考系統的任何一個部分可能對其他部分造成的影響時，還有哪些東西呢？對我而言，這才是最初創造企業架構（Enterprise Architecture）這個差勁詞彙的本意所在。
我們是可以評論企業架構這個詞是好或是壞，但是，而現在當人們已經接受了這個叫法的時候去改它，顯然不是一個好建議。其結果只能是帶來更多的迷惑和論戰。根據IEEE標準1471-2000對於軟體密集型的系統架構的描述，IEEE建議：
架構是對系統、系統的內部元件、元件之間的關係、與外部環境間的關係、指導其設計和發展的原則等方面的基本組織。
此定義絲毫沒有談到最終狀態——它所關心的是人們改進和發展系統時所遵循的原則，這與Bloomberg和Morgenthal所提出的定義非常相近。不過，根據該定義，為了使企業符合合適的架構原則，而對他盡心修補和改進即是架構。
Via：Infoq