「技術架構」EA874:技術組件和技術領域

技術架構(architecture)視點或企業技術架構(ETA)定義了技術和產品使用的可重用標準和指南,並描述了它們如何互操作以及如何支持其他視點(業務和信息)。

企業技術體系結構不僅應定義部件級建議,還應定義這些技術組件的哪些組合或配置應在單獨的實現(技術模式)中重複,以及哪些組合應作為共享基礎結構(技術服務)實際重用。

任何一個EA觀點都應該從定義未來狀態開始——在這裏,需求被識別,EA原則被建立,未來狀態模型被創建。然後定義當前狀態體系結構,執行差距分析並創建遷移路線圖。

在開始任何建模工作之前,請認識到所有模型都是從企業架構(EA)流程生成的。EA實踐者和相關角色必須通過遵循流程來生成模型。

技術領域:傳統的技術架構方法將組件組織到基於技術或組織相似性的技術領域中。幾個相關的組件可以這樣分組;公共域包括網絡和數據庫。

圖1

儘管技術領域模型是必要和有用的,但它們本身並不足夠。技術規劃需要一個整體的、端到端的視圖。特別是,設計人員(架構師或工程師)必須清楚地表達模型,這些模型能夠更有效地表達應用程序和共享服務交付的目標。這種類型的技術領域方法的一個典型結果是,對單個技術組件集進行了優化,但沒有對這些組件的集體優化直接映射到應用程序需求。需要來自每個域的組件來定義完整的端到端應用程序

技術模式:模式有助於從業務需求到技術(基礎設施)設計的映射。設計或藍圖代表了一些需要重複的東西——技術模式具體地包含了整個類或一組應用程序成功所需的所有組件。

技術服務:服務是作為單個單元(包括流程和人員)實現和重用的組件,但不必對任何一個應用程序都是必需的。它們通常由來自多個域的組件組成,但並不總是如此。通用技術服務包括廣域網、大型機、分析集成(數據倉庫)和事務集成(EAI、IEI)。技術服務也可以直接支持應用服務。其他合理的組件集合模型也存在,包括框架,比如Java EE;如果有用的話,將它們考慮進來。

下面是一個3/N層的事務模式-

版權聲明:本文源自 網絡, 於,由 楠木軒 整理發佈,共 816 字。

轉載請註明: 「技術架構」EA874:技術組件和技術領域 - 楠木軒