本文轉(zhuǎn)載自微信公眾號「計算機世界」，作者Bob Lewis。轉(zhuǎn)載本文請聯(lián)系計算機世界公眾號。

數(shù)據(jù)

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

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

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

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

應用

現(xiàn)在事情變得有趣了。

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

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

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

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

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

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

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

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

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

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

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

作者：Bob Lewis ，專欄作家

原文網(wǎng)址：

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