本文轉載自微信公眾號「計算機世界」，作者Bob Lewis。轉載本文請聯系計算機世界公眾號。

數據

理論上，數據存儲庫應被視為改進技術架構中的獨立目標。在實踐中，這些存儲庫是作為應用程序處置工作的一部分，而不是作為獨立的評估和計劃來處理的。

這些存儲庫應作為單獨的數據層組件進行處理。除非，它是某一企業的數據倉庫和其他分析存儲庫。但因為這些庫由企業的分析業務部門來管理，并不是你該處理的問題。所以你可以放心地將它們排除在評估過程之外。

除非一個或多個平臺層的配置工作會影響整個分析存儲庫。

這是技術架構政治化的情況之一。

應用

現在事情變得有趣了。

你可以對應用程序運行狀況進行評分，就像對技術結構體系中較低層中的組件的運行狀況進行評分一樣：只需平均評估標準分數，即可獲得總體應用程序分數。

優先級：即使是中型企業，其產品組合中也有數百或數千個應用程序，這種情況并不少見，因此，一次確定一個應用程序的優先級是不切實際的。為應用程序確定優先級也不是一個好主意。你最好將優先級視為業務功能和應用程序映射的屬性，你已經使用業務功能模型記錄了這些映射。

在大多數技術架構中，每個業務功能都由一個或兩個核心應用程序支持，這些應用程序通常是來自ERP軟件包或其他各種套件中的模塊。

核心應用程序被附屬應用程序所包圍，這些附屬應用程序提供了核心應用程序中欠缺的功能。附屬應用程序和核心應用程序可以相互共享和同步數據。

此外，許多業務功能都會使用實用程序，即獨立且不需要與支持相關業務功能的其他應用程序集成的應用程序。

若要確定優先級，首先計算業務功能應用程序運行狀況指數，并將其作為支持它的應用程序的加權平均運行狀況指數，再為核心應用程序分配10的加權因子，根據每個應用程序的大小和范圍為附屬應用程序分配3到7的加權因子，為實用程序分配1的加權因子。

你應該已經記錄了業務功能的運行狀況。這是被業務架構團隊當作其 BCM 的一部分提供給你的。

你的首要任務是處理業務功能運行狀況和應用程序運行狀況組合最差的那個業務功能。

• 處置：與處理技術架構的較低層相比，技術架構師在處理應用程序方面有更多的選擇。具體而言，對于每個應用程序，你可以：
• 保留：繼續使用應用程序，隨著業務需求的變化對其進行維護和優化。
• 替換：丟掉應用程序，用功能等效但整體更健康的產品代替。
• 重新配置平臺：將應用程序"提升并轉移"到成本較低但其他等效的平臺上。
• 重構：重寫應用程序以符合你的技術架構工程標準。
• 調整：如果一個平臺要進行調整(參見上文的平臺配置)，一些應用程序也將需要隨之改變。
• 整合：如果某個應用程序是冗余的(比如，企業也同時在使用功能等效但更高級的應用程序)，請遷移到更高級的應用程序上，尤其是當更高級的應用程序被視為公司的目標標準時。
• 停用：停止使用應用程序并取消其許可證。如果情況需要，請先對應用程序的數據進行存檔。

那么云端呢?在你完成分配應用程序部署之前，云對于此項分析既不相關也不重要。

一旦你完成此操作，如果你的技術策略包括云遷移，則云可能是你對某一應用程序進行替換、重構或重新構建應用程序平臺的正確選擇。

作者：Bob Lewis ，專欄作家

原文網址：

http://www.cio.com/article/3640510/the-secret-art-of-technical-architecture-improvement.html