大多數技術架構確實非常復雜。想弄清楚如何對其簡化和改進嗎?我們需要多次重復使用“非常”一詞：這是真的，非常非常復雜。
當然，當一件事情如此復雜或令人費解時，在制定改進計劃之前，將事情進行分解，這是很有幫助的。在此，我們就是這樣做的，以幫助你破解一些“非常復雜”的事情，這樣你可以制定一個切實可行的策略，以確保你公司的技術架構能最好地為業務提供服務。
拆解技術架構
本系列的前一期給出了一個描述技術架構的框架，并將技術架構分解為三個資產組合及其子組合：
• 應用程序：記錄系統、接口和集成以及附屬應用程序
• 數據：結構化和非結構化
• 技術：設備、基礎設施和平臺
后一期補充了一個觀點，即技術架構需要有兩個互補的視角：資產組合的視角和整體設計的視角。該部分內容還為評估構成該技術架構的組件的運行狀況提供了指導。
該部分內容講述了如何將技術和業務架構進行連接，特別是通過“業務功能模型”(BCM)——技術架構中的每個應用程序都可以映射到業務功能分類中。
所有這些要素讓你可以識別、分類和評價自己所擁有的東西。
但從這里開始到制定出一個改進技術架構的可行計劃，你還需要決定如何處置每個資產組合和子組合中的每個組件——每個組件需要如何調整——以及處置每個組件的優先級。
具體情況取決于你要處理哪些資產組合和子組合。在此，我們將從下往上進行分解講述。
設備和基礎設施
在改進技術架構的過程中，確定優先級始終是你的首要任務。使用流程、框架和標準對每個組件的運行狀況進行評分。根據依賴該組件的應用程序的數量對其重要性進行評分。將運行狀況與重要性評分相乘，計算出每個組件的優先級指數。將結果生成一個可視化的熱圖，其中較紅的組件，其優先級就更高。
接下來是處置工作。對于設備和基礎設施而言，你有以下處置方式：
• 停用：盡管不太可能發生，但你可能會發現一些并未在使用的設備或基礎設施。將其關閉，停止使用，并取消其相關租約或產品支持合同。
• 升級：你可能會發現在設備或基礎設施中的一些組件已過時、無法獲得產品支持或需要更新到該產品的最新版本。請對其進行更新升級。
• 替換：你可能會發現某個組件已經過時、無法獲得產品支持，而且如果有一個更新的可用版本，但你認為它不可行。那么，就將其扔掉，然后用一個功能相當但更穩健的產品來替換。
• 整合：對于一個技術架構而言，擁有冗余的設備或基礎設施組件并不罕見。尤其是在企業合并或收購之后，多個數據中心或網絡通常會為我們提供一些整合的機會。
對于設備和基礎設施，你現在知道最迫切需要關注的是什么，以及該如何應對這種情況。
平臺
確定平臺的優先級和處置方式不同于為設備和基礎設施選擇平臺，因為平臺之間具有更多的相互依賴性。處理這種復雜情況的一個好方法是明確各個堆棧。一個堆棧是至少由一個應用程序所使用的多個平臺的組合，其包括服務器操作系統、開發環境(包括庫)、DBMS、CMS(內容管理系統)、Web 服務器和所支持的瀏覽器(假設應用程序的 UI 是通過瀏覽器打開)，以及運行各種平臺的操作系統。
值得注意的是，堆棧是遞歸的：各平臺可以依賴于其他平臺。同樣值得注意的是，某些應用程序也可以是平臺。例如，SharePoint 是一個應用程序，也可以用作構建自定義應用程序的開發環境。
優先級：堆棧的運行狀況是其組件運行狀況的平均值，可使用流程、框架和取樣標準進行評分。
其優先級處于什么位置?對此沒有一個絕對可靠的“最佳做法”。克服該復雜情況的一種方法是找出運行狀況不好的平臺，是否在對其進行補救之后，可以最大程度地改善大多數堆棧。為了說明這一點，假設在你的技術架構中選定了 60 個堆棧。還假設你在使用中且運行狀況最差的平臺是 Windows Server 2003 — 假設其運行狀況評分為 -1.5。
在這個假設示例中，假設將其評分提高到 +2，這會使 14 個堆棧的評分從 -1 升至 0，而使另外 6 個堆棧的評分從 0 升至 +1。這就是說，通過解決 Windows 2003 Server 的問題，可以改進 22 個堆棧。Windows 2003 Server 的優先級指數是 60 個堆棧中的 20 個得到改進，即是 0.33。
對每個平臺組件重復這一操作，你就擁有了一種對平臺優先級進行排序的實用方法。
數據
理論上，數據存儲庫應被視為改進技術架構的獨立目標。在實踐中，這些存儲庫是作為應用程序處置工作的一部分，而不是作為單獨的一項評估工作和計劃。
除非，它是某一企業的數據倉庫和其他分析庫。這些庫應作為單獨的數據層組件進行處理。但由于這些庫由企業的分析業務部門來管理，因此它們是別人的問題。你可以放心地將這些庫排除在評估過程之外。
除非一個或多個平臺層的處置工作會影響某個分析庫。
這是技術架構變得政治化的一種情況。
應用程序
現在事情變得很有趣。
你可以對應用程序的運行狀況進行評分，就如同你對技術架構較低層中的組件的運行狀況進行評分一樣：只需將評估標準分數進行平均，即可獲得應用程序的總體分數。
優先事項：即使是一家中型企業，其資產組合中擁有數百或數千個應用程序的情況也并不少見，因此，每次為一個應用程序確定優先級，這是不切實際的。為應用程序確定優先級也不是一個好主意。你最好將優先級視為業務功能的一個屬性以及你使用業務功能模型所記錄的應用程序映射的一個屬性。
在大多數技術架構中，每個業務功能都由一個或兩個核心應用程序所支持，并且通常是來自 ERP 套件或其他各種套件的模塊。
核心應用程序周圍環繞著一些附屬應用程序，這些應用程序可提供核心應用程序所欠缺的功能。附屬應用程序和核心應用程序可彼此共享和同步數據。
此外，許多業務功能會使用一些實用工具——獨立的應用程序，不需要與支持該業務功能的其他應用程序進行集成。
要確定優先級，首先要計算某一業務功能應用程序的運行狀況指數，將其作為支持該應用程序的加權平均運行狀況，并為核心應用程序分配一個加權因子為 10，然后根據每個附屬應用程序的大小和使用范圍，為其分配加權因子為3 到 7，最后，為實用程序分配加權因子為 1。
你應該已經記錄了業務功能的運行狀況——這是業務架構團隊作為業務功能模型的部分內容提供給你的。
你的首要任務是處理那個擁有最差業務功能運行狀況和應用程序運行狀況的業務功能。
處置工作：與處理技術架構的較低層相比，技術架構師在處理應用程序時擁有更多的可選方案。具體來說，對于每個應用程序而言，你可以：
• 保留：繼續使用該應用程序，隨著業務需求的變化，對其進行維護和優化。
• 替換：拋棄該應用程序，用一個功能相當且總體上更穩健的產品來替代。
• 重新配置平臺：將該應用程序“提升并轉移”到一個成本較低，而其他方面都相當的平臺上。
• 代碼重構：重新編寫該應用程序以符合你的技術架構工程標準。
• 調整：如果某一平臺要進行調整，則一些應用程序也需要隨之進行調整。
• 整合：如果一個應用程序是冗余的——即，一個功能相同且更好的應用程序正在企業的其他部門使用——那么就要轉向使用該應用程序，尤其是如果該應用程序被認為是公司未來的標準。
• 停用：停止使用該應用程序，并取消其許可證。如果情況需要的話，請先對應用程序的數據進行存檔。
那么云端呢?在你已完成所確定的應用程序處置工作之前，云端對于此項分析工作既不相關也不重要。
當完成這項工作后，如果你的技術策略包括云遷移，則云端可能是你對某一應用程序進行替換、代碼重構或重新配置平臺的正確選擇。
從優先事項和處置工作，再到制定計劃
許多技術架構師專注于瀑布方法，在規劃技術架構改進工作時，以甘特圖風格的處置時間表方式，將工作路線圖視為最重要的東西。
但是路線圖是瀑布式思維的遺留產物。在最優先的處置計劃順利進行之前，超出最優先的平臺或業務功能來規劃技術架構的調整工作，這幾乎沒有意義。正如我們在敏捷應用程序開發工作中所學到的那樣，一個過早制定的計劃會在開始實施之前就早已過時了。
通過靈活處理待辦工作的方式來管理技術架構規劃，其遠優于傳統的路線圖。
這種方法有兩種版本——平臺驅動的架構和業務功能驅動的架構。首先，平臺堆棧取代了待辦工作中的靈活“場景”。第二個是圍繞業務功能來構建待辦工作的場景。
平臺驅動的架構調整：使用這種方法，無論是基于上述的優先級方式，還是基于一些更適合自己企業的替代方案，通常都會選擇一個平臺組件。無論哪種方式，規劃人員都會去尋找平臺級的漣漪效應(其他受影響的堆棧)和應用層的漣漪效應(能利用受影響堆棧的一些應用程序)。
在實施最高優先級平臺的處置工作過程中，技術架構師將在剩余的待辦工作事項中審查當前平臺場景的優先級，如果合適的話，對其進行修改以適應不斷變化的情況，然后開始為下一個最高優先級場景制定計劃。
業務功能驅動的架構調整：借助業務功能驅動的架構調整工作，盡管相關性并不能證明因果關系，但業務和應用程序運行狀況評分都很低的功能是尋找造成業務流程瓶頸的應用程序缺陷的一個合理位置。
從技術架構的角度來看，業務功能驅動的調整工作從處置具有最高優先級業務功能的核心應用程序開始，然后從此處向外延伸去處置附屬應用程序。
同時，公司的業務架構師們將合作設計和實施通過應用程序調整來實現的流程改進。
與平臺驅動的調整一樣，在處置具有最高優先級業務功能的應用程序過程中，技術架構師將進行審查，在適當的情況下，會調整待辦工作事項的優先級，而且會開始規劃下一個最高優先事項的場景。
結論
技術架構很復雜。技術架構必須如此，因為如果你曾嘗試記錄業務中所發生的所有事情，以便于業務工作能夠進行設計、構建、銷售、配送和支持其產品和服務，那么你就會知道業務工作很復雜。
順便說一下，這就是你的業務功能模型所做的事情。前三個業務功能模型層能列出數百個業務流程和實踐，這并不少見。同樣，映射到業務功能模型(你的應用程序清單)的應用程序數量達到一千或更多，這也并不少見。
記錄你的所有資產和規劃改進工作的過程，既耗時又費錢。
但這沒關系，因為如果不記錄你的所有資產和規劃必要的改進工作，最終會耗費更多的時間和成本。
當你面臨選擇是現在去做，還是以后再做時，你應該清楚的一件事是，以后再做將會更糟糕。
版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號