在 RUP 之上擴展企業架構

 當運用 IBM Rational 統一過程®（RUP®）的項目團隊擁有了問題陳述，或者確定了具體的用戶需求時，團隊會創建業務案例、愿景描述（Vision statement），以及其他工件中的軟件需求規格（Software Requirements Specification）來生成解決方案。技術和業務團體對這些工作產品以及生成它們的活動有很好的了解。然而，我們概念化、劃分優先級，并且選擇哪些業務問題和用戶需求需要在軟件中實現所采取的方法在我們的行業中仍舊是非常有價值的過程。

    本文探究對于當今軟件開發組織來說成熟且日益重要的角色，企業架構（enterprise architecture，EA）框架。開始，我們將企業架構規程與解決方案架構和業務架構規程進行對比，在這期間將它們與 RUP 進行聯系。然后，我們將解釋 Open Group Architecture Framework (TOGAF) 如何利用 RUP 有利地擴展企業架構集的邊界，從而包含企業業務和 IT 計劃、實現治理，以及其他活動。最后，我們將提出把 TOGAF 與一些其他 EA 框架結合的方法。

    對比不同的架構框架

    就企業、解決方案和業務架構框架的范圍而言，就像大家普遍了解的那樣，在它們之間有很多重疊。那么，它們是如何相關聯的呢？

    解決方案架構

    解決方案架構框架有各種各樣的形式。IT 專家們已經習慣于在信息系統開發和維護項目中處理應用、數據、技術和其他解決方案架構形式（這些常稱為領域）。新的（以及全部更加專門的）解決方案架構形式，例如安全及測試，也快速地成為主流。圖 1 中展示了最為廣泛公認的解決方案架構領域、其主要主題和它們之間的依賴性。

 
    圖 1：解決方案架構規程的領域及主題

    圖 1 中展示的所有解決方案架構領域被看作是“技術性的”，因為它們的范圍內包括各種技術元素，例如，軟件、數據和 IT 基礎架構。這些領域都是由技術人員來處理 —— 也就是那些具有系統工程、軟件工程或 IT 管理背景的人。

    業務架構

    業務架構在 90 年代作為單獨的領域出現了，當時許多組織接受了業務架構師角色，因為它們試圖優化它們的業務過程。

    業務架構規程是關于業務的“工作范圍”，并且描述它是如何運作的。雖然不是每個人都贊成在業務架構框架中應該包含的組件的內容，但是一般的共識是，過程及信息、組織和性能方面是相關聯的。實質上，每個組件都相當重要，并且結合了多個主題領域，如圖 2 所示。

原文轉自：http://www.kjueaiud.com