轉載地址:http://www.infoq.com/cn/news/2007/09/AM_and_EA
作者 Amr Elssamadisy譯者 孫向暉 發佈於 2007年9月6日 上午12時48分
社區 Architecture, Agile, SOA 主題 企業架構, 企業級敏捷
一份來自Cutter Consortium的報告向我們提出了這樣一個問題：“敏捷方法和企業架構兼容嗎？”並且也給出了這樣一個答案：“是的，但需要付出努力”。該報告的作者推薦運用特殊技巧以允許敏捷方法和企業架構互相受益。此外，他們的觀察結果、分析和建議也直接是適用於敏捷方法和“面向服務的架構SOA”之間的結合。
企業架構(EA)和敏捷方法(AM)擁有共同的目標——交付能夠跟業務需要對齊的軟件，並響應對這些業務需要無可避免的變更。然而，EA和AM在達成這個目標時卻採用了截然不同的方式。在報告中，對EA和AM定義如下：
EA處理如下的企業級問題：
通過提供一個整體的業務過程藍圖將業務策略連接到IT系統，藍圖可以映射到架構模式、核心服務和應用兼容性等方面。
通過維護一個當前的數據模式(schemas)、過程流和服務定義等內容的詳細目錄來改進貫穿於整個企業的一致性
通過減少系統間的冗餘以及標識可以統一的組件和系統來改進操作效率
確保靈活的IT能力，能夠響應技術廠商以及新的或者增強性的業務流程自動化的變化
通過維護IT 組合（portfolio）、當前和目標架構以及遷移路線圖來支持項目成本化和優先級劃分
爲正在進行中的操作和系統開發提供一個穩定的、可信賴的基礎設施平臺和公用服務
敏捷方法關注於以下觀念：
改進效率：關注於近期的問題，僅開發能夠滿足當前需要的的部分，允許以後形成設計
改進項目可見的可管理性：關注於允許任務的完成能被有效評估的短期的、迭代的開發週期
通過提供一個完整的過程，關注於廣泛的自動化測試、儘可能早並且經常解決集成問題、允許多個（缺少豐富經驗的）開發人員在共同的代碼上開展工作以及從最終用戶處得到持續反饋等方式來改進質量。
通過建立在持續重構過程上的集成來改進（內部質量的）可維護性
改進處理變更的能力：它是一個需求變更、一個澄清、一個新的需要優先處理的特性？通過綜合客戶反饋計劃迭代內容。
通過隱式知識的使用、共享的團隊空間以及關注問題的小的組成部分來改進交流效果。
我們會先從EA的視角來檢驗AM然後反過來檢驗以分析EA和AM之間的鴻溝。從EA的視角來看：
敏捷迭代提出的使用一到六個周的時間盒來構建一個可運行的部分系統的要求，很少得到採納。當在一個迭代發生時嘗試EA時，常常會割裂時間盒——在這個週期結束時並沒有得到可工作的軟件。
在一個典型的敏捷項目中，當系統的設計激增時，採用演進的設計、有機的增量的方式風險很大，可能會導致冗餘和不同應用間的不兼容性。EA組希望引領設計和推薦的公用基礎設施組件、數據庫模式定義等……
敏捷非常依賴於可執行的的工件，例如：編寫好的測試（不管是單元測試還是系統測試）。EA的工件不是可以測試的。它們限制了項目的影響範圍，因爲他們沒有反饋環——當沒有遵照設計時，不會給出警告。
敏捷提倡的客戶作爲團隊成員是不能被承認的。EA組中不會存在任何一個客戶，但是它有一個從IT到運營到開發團隊到最終用戶的間接的大型的廣泛客戶羣。
從AM的視角看，EA也不是非常有意義的：
EA關注於對齊IT系統和業務策略。一個映射了從現在到將來系統的計劃被開發出來，然後落到一個獨立的項目中。使用了AM的團隊可能會使用此類文檔中的信息，但當這些文檔到達團隊時它們已經失去了上下文環境，會變得難以理解。而且，文檔是可測試的。不能接觸現實狀況，這也是EA團隊被視作“象牙塔”架構的一個主要原因。
爲了減少冗餘並增進一致性，EA組會針對如何構建應用而產出參考架構、推薦框架、發佈指南。AM團隊將這些決定看做是單個項目的領域，不會由未在”前線“上的人來口述。
EA也關注於企業內不同應用的集成。同樣，EA組推薦使用參考架構和框架的特定方案。許多的AM團隊任務這些決定的是不成熟的甚至是毫無根據的。
最後，EA方法通過考慮了將來的設計（例如建立抽象來輕鬆應變）的方式來應對變更。AM團隊將此方式視爲是不成熟的，認爲是典型的龐大的預先設計（BDUF）。實踐AM的團隊寧願遲些使用抽象，通過重構並依賴於自動化測試來允許變更。
報告的標題確實說：“是的，但需要付出努力”，所以仍然還有希望。但需要EA組和AM項目認識到對方有價值的貢獻，並在他們的工作中做出適應性調整。EA組和AM團隊可以相互得到以下收益:
一個AM團隊應該認識到雖然參考架構和框架可能是一個項目級別的BDUF，但在企業中需要重複做，而且耗費好多。如果已經建立好了就沒有理由再發明輪子了。
EA團隊應該保證信息在正確的範圍內以正確的方式可提供。例如，創建的工件應該努力與每個項目創建的工件相關。
EA組應該考慮將客戶和他們的指南視爲是一類需求。
每個AM項目的架構應該與架構組進行聯絡
努力將AM項目範圍內的重構變成是企業級的。
應該建立可測試的EA工具
標準的基礎設施和平臺配置
數據模式
服務
參考架構
業務流程模型
EA應該確保企業級的“上下文”應該是隨時間流逝而分段的，以解決AM團隊關於BDUF的質疑。
EA應該與項目的生命週期有關。
信息流應該是雙向通道，當AM團隊在參考架構或者框架的瑕疵或者不足時，他們需要一種執行變更的方式，這個變更也應該有方式返回到EA組。例如，EA的過程應該支持企業服務的增強。
AM團隊可以儘可能去影響企業架構
企業內的測試環境應該增進一致性、重用並啓用集成。AM團隊是編寫測試的專家，他們應該進行均衡。EA工件應該儘可能變得可執行。
InfoQ同報告的兩位作者（Michael Rosen和Jim Watson）就該專題的內容以及導致他們給出的推薦方案的客戶經驗等方面進行了交談。Jim Watson描述了最場景的場景：
一個曾經使用過其中一種但因爲缺乏對另一個的使用而失敗了的項目會最大程度擁有使用兩者的經驗。例如，一個重要的文檔處理系統可以使用最好的AM實踐開發出來，但不能協調好系統的EA需要如跨越需求、接口、和操作性問題等。作爲選擇，一個採用瀑布方式的項目會準備妥當它的所有的企業架構，但是卻不能向及早的向客戶展現它的價值，或者不能夠通過有意義的迭代來解決風險問題。所以，這些paper都是來自於經驗的，例如：項目是如何因爲忽略了其他可行的規程才陷入這種境地的，有效的處理方式是什麼等。
一個意義更加深遠的案例可能是在項目啓動時均衡EA和AM。 然而，這其實非常難，很少發生，主要是因爲組織性問題，以及誰在過程的哪個部分被涉及的角度。你會看到很多的失敗，例如架構師跟客戶（更慘的是在根本沒有客戶）但沒有開發團隊參與的情況下整理需求，然後開發團隊脫離開架構師進行接管。
Jim Watson和Michael Rosen告訴我們，關於這個專題的範圍，SOA可以被看作是EA的一個實例。因此這裏所有相關的問題和解決方案適用於採用了SOA並存在AM團隊的組織(無需驚訝，這與InfoQ上的文章SOA和敏捷：是朋友？還是敵人？相吻合)
EA和AM的交互並不依賴於SOA，但值得注意的是SOA提供了相互的興趣和問題以允許進程一起使用EA和AM。例如，想在一個SOA主導的項目定義真正有用的業務級別的服務可能具有難度，一個缺乏AM開發實踐的由EA主導的SOA會產生許多的SOA shelfware，因爲它很難實現或者僅僅定義出不是真正需要的接口。
一個推薦的方案是， 對一個AM團隊而言它被當作架構的一個包含部分，作爲每個團隊的成員與EA組進行聯絡。當被要求闡明推薦Architect Reloadus 或是 Architect Oryzus（其定義見Martin Fowler的Who Needs an Architect? ）中的哪種架構類型時，Michael Rosen建議哪種也不採用。在大的組織中會擁有重要的EA組，一個典型的IT組可能擁有2000個員工，500個架構性的重大項目，在EA組中只有70個架構師。沒有足夠的架構時可供應因此Architect Oryzus很難應用。Architect Reloadus同樣不能得到應用，因爲它們沒有可實施的環境。有效的架構師的使用方式是作爲一個單獨的AM團隊的諮詢顧問，這樣，一個來自EA組的架構師就可以發揮效用而不是嵌入到團隊中。
所以，擁有EA組和AM團隊的組織不必要互相容忍，雖然他們擁有共同的目標，他們的缺省操作模式是不與其它成對的並且（成對使用通常會）產生問題。因此這些實踐等對達成企業的戰略目標和交付戰術性的軟件項目非常有用。
最後，完整的報告可以從http://www.cutter.com/events/multimedia/agilemethods.html 處下載，在頁面的底部還包括推廣報告所用的代碼。
查看英文原文：Making Agile Methods and Enterprise Architecture Play Nice
--------------------------------------------------------------------------------
譯者簡介：孫向暉，兒子小名“豆豆”，常被人稱爲“豆豆他爹”。1998年開始步入IT行業，現任浪潮軟件質保中心副主任。專注於研究和實踐MDA/UP/UML/SCM等相關技術在團隊中的大規模應用，對產品化的軟件項目管理、需求管理和配置管理略有心得。他的博客爲http://blog.csdn.net/xiaosun/。參與InfoQ中文站內容建設，請郵件至china-editorial[at]infoq.com。
加入書籤 Digg+ , Reddit+ , del.icio.us+ 標籤 業務/IT整合, 業務架構, 最佳實踐