作者：戴維﹒英格（David Ing）
架構師喜歡使用隱喻（metaphor）。對那些通常比較抽象、複雜和變化移動的目標，隱喻提供了很好的具體媒介。無論是與其他隊員溝通，還是與最終用戶討論架構全局，找到有形實物作爲正要構建的東西的隱喻，都是十分誘人的。
開始這很有效，使用一種共同語言，也能讓大家都感覺到正確的方向，不斷演化前進。隨着時間推移，隱喻不斷髮展成長起來，栩栩如生。人們對隱喻感覺良好——我們正在不斷前進！
常見的情況是，對於架構來說，之前的那些隱喻現在變得很危險了，濫用架構隱喻經常會出現問題讓架構師不知所措，比如：
- 業務領域的客戶開始越來越來喜歡系統隱喻，這時系統還在構想中，在這種情況下，所有各方共享的是最樂觀的可能解讀（happiest possible interpretation），但其中並沒有包括任何必要的約束。
舉例而言：“我們正在構建一個運輸系統，就像在一系列停靠點之間移動的運輸船一樣。”
你想的是橫渡太平洋的集裝箱輪船。而我想的，其實只是在游泳中的單槳划艇。
- 開發團隊開始認爲隱喻比實際業務問題更重要。由於團隊耽溺（fondness）於隱喻，你不得不開始修正那些古怪的決策。
舉例而言：“我們說過，它就像一個文件櫃，當然要按字母順序顯示給用戶。我知道它是個6維的、沒有容量限制並且內置時鐘的文件櫃，但我們現在己經做好圖標了，因此它必須就是一個文件櫃……。”
- 所交付的系統包含了許多遺留名稱，從早己老舊過時、有待重新鑑定的隱喻，到多次重構和重複挖掘的概念。
例如：“爲什麼賬單工廠對象（Billing Factory Object）要爲划艇系統創建一個港口通道（Port channel）？當然它應該爲中心總線（Hub Bus）返回一個石榴視圖（Pomegranate view）？你說什麼，你是新來的？”
請記住，不要耽溺於系統隱喻之中，只將之用於探索性的溝通，不要反讓它拖了後腿。