對于臨時的最終用戶、經理或高級管理人員來說，企業架構師的工作是神奇的。無休止的同步、組織和穩定的瑣事都由計算機處理，這樣人類就可以做他們最擅長的事情，但所有的門戶網站、協作堆棧和存儲庫萬能工具都隱藏著保持一切順暢的無盡挑戰。盡管企業架構取得了進步，但它仍然是一個充滿任務和責任的新世界，沒有人完全弄清楚。

企業架構師仍然在學習、試驗，然后更多地了解他們應該做什么，更重要的是，他們不能做什么。在這個過程中，我們已經犯了許多錯誤，而且很可能會一次又一次地犯錯誤，因為我們正在尋找最好的方法來保持軟件堆棧的運行和整個企業中每個人的工作生活盡可能簡單。這在一定程度上是由于這項工作的高度技術性和復雜性，我們的企業架構師經常犯下以下錯誤。 

存儲的數據太多(或太少) 

軟件開發人員是成群結隊的人。如果可以，他們將緩存所有內容，記錄每個事件，并存儲企業不斷發展的狀態的備份副本。所有這些GB和PB加在一起，即使一些云供應商提供的冷存儲成本最低，但當數據量很大時，收取的費用可能會很高。 

更糟糕的是，隨著數據湖被填滿，找到合適的比特變得更加困難。就像《奪寶奇兵》結尾的那個倉庫一樣，嚴格來說，所有的信息都在那里，但你能找到嗎? 

問題是，保留太少的信息會帶來自己的失敗模式和痛點。一些公司試圖設定數據保留政策，在法規允許的情況下盡快銷毀一切。但隨后，這家企業就帶著一種健忘癥糊涂了，因為每個問題的每一個答案似乎都是，“我們沒有那個文件。”沒有人知道任何事情。 

找到合適的平衡可能是不可能的。我們所能做的就是努力找到一個好的數據存儲體系結構，將正確的信息保存在一個易于訪問的結構中，這樣就不會讓人覺得每個人都只是在黑暗中摸索，花了大部分時間尋找電燈開關。 

過于依賴一個平臺(或包含太多平臺) 

構建企業軟件的最簡單方法是利用外部人員構建的各種工具、門戶和平臺的力量。通常，90%以上的工作可以通過簽署采購訂單和編寫一點膠水代碼來完成。 

但將企業的關鍵部分委托給外部公司存在大量風險。也許一些私募股權公司收購了外部公司，解雇了所有優秀的員工，然后在知道你無法逃脫的情況下抬高了價格。突然，在一個平臺上實例化您的所有雞蛋開始嚴重失敗。沒有人記得來自單一平臺的單一界面所帶來的簡單性和一致性。 

然而，擴展和擁抱多個平臺可能同樣令人痛苦。銷售團隊可能會承諾，這些工具是為互操作和使用行業標準協議而設計的，但這只讓您實現了一半。每個數據庫都可以將數據存儲在SQL數據庫中，但有些使用MySQL，有些使用PostgreSQL，有些使用Oracle。 

沒有簡單的答案。太多的平臺造成了不兼容。太少會帶來供應商鎖定的風險，以及使用續訂合同打開電子郵件的所有痛苦。我們甚至還沒有談到把所有開發項目都放在家里的成本。 

將太多(或太少)外包給云 

云讓企業架構師的生活變得容易得多。如果有人需要一臺特定大小的機器，那么，幾分鐘內就可以買到。不需要填寫采購訂單。無需尋找機架空間。不需要做任何事情，只需要給云公司你的信用卡號碼。 

任何機器在幾分鐘甚至幾秒鐘內就可以使用的好處是顯而易見的。最大的不利因素是價格。云計算通常比內部工作的成本高得多。許多首席財務官害怕每月打開云計算賬單，因為它們往往比任何人預期的都要大。 

但自己做這項工作意味著管理員工、數據中心等。令人頭疼的問題和法規清單可能很長，而來自較小預算的喜悅可能會轉瞬即逝。 

一些企業架構師可以通過云大獲成功。如果您的需求在每周、每月或每年的一小段時間內激增，啟動處理負載所需的服務器幾分鐘或幾個小時可能比在內部執行任何操作都要便宜得多。其他所有人都在想，他們在云計算上的投資是太多還是太少。 

依賴(或忽視)框架 

由于當今企業堆棧的復雜性，一些聰明的架構師已經創建了框架來幫助組織它們。例如，開放式組體系結構格式(TOGAF)是一個戰略框架，用于構建企業所需的幾乎所有內容。它提供了許多指南和最佳實踐，包括體系結構開發方法(ADM)和體系結構遵從性框架(ACF)，以及其他縮略語。其他方法，如Zachman框架或聯邦企業體系結構框架(FEAF)，提供了它們自己版本的規則和法規來構建堆棧。 

最大的優勢可能是一致性。一旦企業中的每個人都熟悉了技術和理論，找到軟件的方法就變得更容易了。數據和代碼(通常)都是結構化的，因此一切都在可預測的位置。 

然而，有些人做得太過分了。他們固守規則，而不是僅僅采用規則。他們如此徹底地閱讀規格，以至于每一項決定都必須遵循規則。 

但是，即使每個人都相信這個框架，辦公室規劃會議上充斥著快樂的遵守規則的人，其他問題也可能悄悄出現。有時，團隊拒絕完全好的開源代碼，僅僅是因為它與他們想要的架構框架不一致。 

堅持方法論至上 

框架可以提供結構，但也可以為草率、懶惰甚至惡意的行為提供掩護。有時，團隊可能會拖延決策，因為他們正在等待某人填寫正確的TOGAF表格。支持性規則和陳腐的繁文縟節之間只有一線之隔。 

與我共事的一個人喜歡敏捷方法論，他扭曲了它，所以他的團隊一點也不敏捷。他知道所有的會議例行公事，并擅長用上周剛剛編寫的重構代碼的許多故事點來填充他的“沖刺”。他的團隊似乎從來沒有在重建他應該提供的信用卡結賬方法方面進展得很快，但如果你看看每一次沖刺獲得的敏捷點數圖，他的團隊在辦公室里的速度是最快的。 

我們需要某種方法來組織開發工作流。程序員可能會爭論幾天，爭論這件事是敏捷的，還是那件事是敏捷的。如果項目的規模超過了一個人周末的處理能力，那么，就需要有某種策略。 

當你開始更多地相信方法論而不是你的眼睛所能看到的東西時，問題就來了。當這種情況發生時，聰明的程序員可以玩弄系統并賺取大獎，即使他們的代碼沒有什么作用。 

追隨(或忽視)潮流 

開發人員喜歡抓住企業架構的最新想法和模型。有時他們很幸運，而新趨勢實際上滿足了他們的需求。他們的應用是一個很好的例子，說明了是什么驅使引領潮流的人首先提出了這個想法。 

但這往往只是部分情況。用例可能與激發這一趨勢的應用程序相似，但只是在稍微揮手之后。與此同時，開發團隊陷入了瘋狂的困境，試圖讓他們的代碼適應趨勢。有時，完全合適的大塊代碼會被丟棄，只是因為它們是為了某個以前流行的目標而編寫的。 

問題是，完全忽視趨勢也可能是致命的。當然，您的代碼使用了運行良好的數據庫、格式、編碼標準和協議，保持了一些原始的愿景，謝謝。但如果說整個世界都在追逐某種趨勢，那么所有的供應商、工具制造商和潛在的新員工也都是如此。在某種程度上，潮流和時尚可能會成為標準，有時甚至會變得更糟：合法的合規要求。 

企業架構師如果追隨潮流，他們就是狂熱的奴隸，但如果他們忽視了這些，他們可能會被甩在后面。他們所能做的就是謹慎地嘗試為企業的技術堆棧和必須管理它的IT專業人員做正確的事情。