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所提出的定義非常相近。不過，根據該定義，為了使企業符合合適的架構原則，而對他盡心修補和改進即是架構。

　　查看英文原文：What Is Enterprise Architecture?

it知識庫：企業架構到底是什么？，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。