技術架構提供了描述、評估和規劃IT管理和企業所依賴的IT技術演變的一種方法。 構建高效IT可以采用框架來描述技術架構，并將其分解為組合和子組合，其中包括應用程序(記錄系統、集成應用程序)、數據(結構化和非結構化)、技術(設備、基礎設施和平臺)。
該框架使人們能夠識別和分類擁有的東西，但它并沒有告訴企業擁有的技術架構是否是正確的。這就是需要解決的問題。以下概述了企業將如何看待自己的技術架構，并提供了評估技術架構的關鍵標準。
技術架構的兩個視角
對于技術架構的描述分為兩個互補的視角：整體設計和組合視圖。
整體設計描述了技術架構的每個組件的作用——提供的功能以及這些組件如何組合在一起創建整體功能。
另一方面，組合視圖植根于投資理論。它將技術架構中的組件視為投資組合中的股票。就像投資者定期審查他們的投資組合以決定購買更多、持有或出售哪些股票一樣，技術架構師根據這一模型定期審查其技術投資組合每個組件的健康狀況，以確定哪些組件繼續作為標準，哪些組件應該逐步淘汰，以支持更好地提供所需功能的替代方案。
但與投資者有所不同的是，技術架構師有更多的選擇，而不僅僅是采用、持有和放棄。技術架構師將他們的選擇稱為處置。
需要記住的是，如果沒有整體設計，IT團隊將管理一堆構思拙劣的組件。如果沒有投資組合視圖，將會發現自己管理著一個精心設計的紙牌屋：雖然所有東西都放在一起，但不會想住在里面。
業務架構及其連接方式
如果不將應用程序映射到它們支持的業務功能，就不可能設計和規劃連貫的技術架構。因此，負責記錄業務架構的人員必須向IT技術架構師提供四個關鍵信息。
- 分類。在這里談論的是業務功能的分類，可以分為三個級別——能力(L1)、職責(L2)和流程(L3)。例如，人力資源(L1)包括薪酬管理(L2)，薪酬管理又包括工資單(L3)，就像財務和會計(L1)包括應收賬款(L2)，會計包括收款(L3)。如果采用流行術語描述的話，可以將這一分類稱為業務能力模型(BCM)。
- 映射。第二個關鍵信息是BCM中每個功能所依賴的應用程序的映射。業務架構師可能很想在能力級別映射這些，但如果沒有L2和L3映射，BCM的重要性將很有限。
- 評估。第三個關鍵信息是對每個BCM功能的整體有效性的評估。
- 重要性。第四個關鍵信息也是最具爭議的——每個業務功能的相對重要性。關于這一點有兩條建議：(1)將重要性定義為對競爭優勢的影響;(2)對其進行評級，而不是對其進行排名。
例如，人們不會就薪資是否比銷售更重要達成共識，但很容易達成一致，即在五分制(推薦)上，他們都應該獲得最高分(5)，如果賣不出去產品，就會失去市場份額，如果不給員工發工資，就難以更好地銷售產品。
分類法、應用程序映射、業務功能有效性、業務功能重要性這四部分是連接業務和技術架構的東西。
值得一提的是：雖然BCM通常類似于企業的組織結構圖，但組織結構圖并不是BCM。對于企業(尤其是大型企業)來說，根據功能以外的其他內容進行組織是很常見的，例如，根據地理位置、客戶類型或產品類別。這導致一些業務功能在企業的多個部分中表現出來。
評估技術架構
為了評估技術架構，架構師需要了解組件和集成的健康狀況，冗余和整合機會，以及業務功能支持的質量。以下是需要了解的有關組件運行狀況評分的信息。
技術架構中每個投資組合和子投資組合的每個組件都是關鍵的資產，將影響IT的工作能力和各個支持業務領域的工作能力。
用于評估架構組件的完整標準列表非常廣泛。使用的框架包括僅針對應用層的30個潛在評估標準。但即使是一層，30個標準也會過多。從數據收集和管理的角度來看，10個標準是切合實際的最大值。
根據投資組合和子投資組合采用以下簡化的標準集，將為評估技術架構奠定堅實的基礎：
(1)功能性：這是顯而易見的標準——組件是否完成了需要它完成的任務。
(2)靈活性：組件如何適應新的和不斷變化的情況。
(3)穩定性和性能：很明顯，應用程序、平臺或基礎設施組件在可用時經常崩潰，運行速度非常慢，這是一個需要解決的問題。
(4)內部工程：組件組裝的好壞(更容易確定組件何時在內部開發)是否符合工程標準。
(5)集成和接口：這僅適用于應用程序和數據存儲庫。它對每個應用程序和數據存儲庫如何與其他應用程序和數據存儲庫交換數據以同步重疊數據進行評分，如果特別復雜，還可以同步重疊的業務邏輯。
(6)遵守架構原則：企業需要花費時間闡明這些原則，采用的技術應該符合這些原則。
(7)安全性：雖然如今大多數網絡攻擊事件都是社交工程的結果，但這并不意味著不需要強化技術。
(8)供應商和產品可行性：組件及其供應商在其市場上是否具有臨界質量?也就是組件是否會得到支持和增強。企業能招募到優秀的人才來從事這項工作嗎?
(9)更新版本：該組件是否僅比其供應商當前發布的版本落后一個版本，或者在另一個極端情況下，提供組件的供應商不再支持該組件。
(10)低層的健康狀況：由于每層的組件依賴于下層的組件，它們繼承了那些下層組件的健康狀況或缺陷。例如，應用程序可能依賴于分層存儲在大型機托管的IMS數據庫中的數據。大多數IT組織認為IMS是一個過時的平臺，導致該應用程序的平臺層得分為負。此外，對于大多數IT商店而言，分層數據設計將會違反結構化數據設計標準(規范化)，從而根據應用程序的信息存儲庫特征降低其分數。
(11)冗余：當企業的其他地方正在使用其他功能相似且可能更好的替代方案時，該組件就是冗余的。如果是這樣，在冗余組件中應建立一個標準并獲得較高的排名;其他的應該被評價有問題，因為它們是多余的。
評分
無論企業決定采用哪種屬性來衡量架構組件的運行狀況，以下是三個提示：
- 為所有屬性建立一個共同的指標。在專家的咨詢工作中，發現+2到-2的評分(僅限整數)效果很好。這是一個五分制的指標，符合所有人的習慣。但是通過將指標集中在零點，它是一個更自然的系統，因為負數對應于負數，而正數對應于正數。
- 放棄加權。在將權重因素添加到評估標準之前，需要深思熟慮。原則上應該這樣做，因為有些屬性比其他屬性更重要。但在實踐中，人們可能會發現，例如，在三點權重范圍(高、中、低)上將屬性的重要性評分為高或中之間的影響差異，不會對結果產生足夠的影響，因此不值得費心。同樣，重要性較低的屬性可能不重要，可以完全刪除它們。
- 不要依賴電子表格。不要依賴電子表格來管理收集的有關技術架構的數據。建立一個數據庫，無論是自己構建的還是商業的架構管理系統。需要管理的大量數據涉及多對多關系是其中一個原因。例如，一些應用程序支持多個業務功能，而大多數業務功能依賴于多個應用程序。
建立在電子表格上的技術架構存儲庫很快就會變成一個難以管理的混亂局面。此外，如果在電子表格中管理技術架構數據，可能面臨更多的問題。
企業擁有所需的所有數據。需要知道每個應用程序支持哪些業務功能以及每個應用程序支持哪些硬件和軟件，并需要知道每個組件的健康狀況。并且對于每個組件，需要知道是否有其他組件可以完成相同的工作，如果有，是哪一個做得更好。
企業還要了解未來的架構在哪里保持不變，在哪里必須改變，以及進行改變的優先事項是什么。
