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