《The Open Group：2020數字時代的敏捷架構白皮書（31頁）.pdf》由會員分享，可在線閱讀，更多相關《The Open Group：2020數字時代的敏捷架構白皮書（31頁）.pdf（31頁珍藏版）》請在三個皮匠報告上搜索。

1、2019 年5月白皮書數字時代的敏捷架構 The Open Group 白皮書數字時代的敏捷架構作者: Herv Barbazange, Socit Gnrale Peter Beijer, DXC Technology Jean-Marc Bunouf, Socit Gnrale Carl Kinson, DXC Technology Frdric L, DXC Technology Jean-Pierre Le, Socit Gnrale Antoine Lonjon, MEGA International Jrme Rgnier, Societe Gnrale 譯者： 鄧明審校： 彭斐特

2、別鳴謝: 感謝Xavier Cabot、 Cesames、 Daniel Krob、 Ecole Polytechnique 和Cesames 為本文作出的貢獻。 以及本文的譯者鄧明， 審校人彭斐， 他們志愿地付出自己珍貴的時間和精力， 在認真地閱讀和理解原著的基礎上， 經過反復推敲， 將本文精準地翻譯成中文的表達形式。2019 年5月版權所有 2019, The Open Group The Open Group特此授權您可以將此文檔用于任何目的， 前提是您對此文檔全文或其任何 部分的復制， 必須在復制內容上保留此文檔包含的所有版權信息及其他所有權聲明。 此文檔可能包含其他所有權聲明及版權信

3、息。 此文檔中任何內容均不可被理解為以暗示、 禁止反言或其他方式涉及到The Open Group或 任何第三方組織的任何專利或商標相關的許可或權利的授予。 除了以上明確申明， 此文檔中 任何內容均不可被理解為涉及到The Open Group所屬版權的許可或權利的授予。 請注意此文檔提及的任何產品、 流程或技術均有可能為The Open Group所保有知識產權的 主體， 不得依據此文檔而被授予許可。 此文檔是 “按現狀” 提供的， 沒有任何形式的(不論是明示還是默示的)保證， 包括對適銷性、適 用于特定用途或非侵權性的默示保證。 某些司法轄區不允許排除默示保證， 故以上排除規定 可能對您不

4、適用。 The Open Group的任何出版物均可能有不精當之處或刊誤， 故本組織可能對出版物進行定 期修訂并將更正內容發布于出版物的新版本中。 The Open Group可能在不另行通知的情況 下， 隨時對其出版物中涉及的產品或程序進行完善或修改。 如讀者就本文檔內容提出問題、 評論、 建議等反饋信息， 此類信息將被視為非保密信息。 The Open Group對上述信息不承擔任何保密義務， 并可不受任何限制地復制、 使用此類信 息或向他人披露或分發此類信息。 此外， The Open Group可自由將此類信息中包含的任何 觀點、理念、 知識技能或技術方法用于各種用途， 包括但不限于開

5、發、 制造及營銷包含此類信息的產品。 如您不是通過The Open Group獲得此文檔復本， 您所持文檔可能并非最新版本。 為您方便 起見， 請訪問 www.opengroup.org/library 或 下載最新 版本。 數字時代的敏捷架構 The Open Group 白皮書ArchiMate, DirecNet, Making Standards Work, Open O logo, Open O and Check Cer-tification logo, OpenPegasus, Platform 3.0, The Open Group, TOGAF, UNIX, UNIX-WA

6、RE, and The Open Brand X 標識為注冊商標。 Boundaryless Information FlowTM, Digital Practitioner Body of KnowledgeTM, DPBoKTM, EMMMTM, FACETM, the FACETM logo, IT4ITTM, the IT4ITTM logo, O-DEFTM, O-HER- ATM, O-PASTM, Open FAIRTM, Open Platform 3.0TM, Open Process AutomationTM, Open Subsurface Data UniverseTM

7、, Open Trusted Technolo- gy ProviderTM, SOSATM, Sensor Integration SimplifiedTM, and the SOSATM logo為The Open Group 商標。 Linux是Linus Torvalds的注冊商標。.NET、 Microsoft和Windows是Microsoft Corporation在美國或其他國家和地區的注冊商標。AirbnbTM is a trademark of Airbnb, Inc.Cassandra, Flink, and Kafka are registered trademarks

8、 and SparkTM and StormTM are trademarks of Apache Software Foundation (ASF).CORBA is a registered trademark of Object Management Group, Inc. in the United States and/or other countries. Google is a registered trademark and TensorFlowTM is a trademark of Google Inc.Java is a registered trademark of O

9、racle and/or its affiliates.LeSSTM (Large-Scale Scrum) is a trademark of The LeSS Company BV.MongoDBTM is a trademark of MongoDB, Inc.Netflix is a registered trademark of Netflix, Inc.SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.Spotify is a registered trademark of

10、Spotify AB.UberTM is a trademark of Uber Technologies, Inc.其他所有品牌、 公司及產品 名稱的使用均只是為了識別用途， 這些品牌、 公司及產品名稱可能是其各自所有人的專有財產。 The Open Group 白皮書數字時代的敏捷架構文檔編號:W186CThe Open Group于2019年5月出版 如有與本文內容相關的意見， 請郵寄至以下地址: The Open Group, ApeXPlaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom 中國上海浦東新區花木路

11、1388號商務中心三樓20室 或發送電子郵件至: ogpubsopengroup.org The Open Group 白皮書目錄66810111212131516181921222224262729305綜述簡介自治和松耦合領域驅動設計模塊化和賦能的組織自治和統一的平衡命令控制模式的缺點改變組織模式業務架構模式軟件架構模式分布式計算的新規則新數據模型基礎設施代碼敏捷架構框架 （AAF）架構的角色架構流程敏捷架構的開發方法參考文獻關于作者和譯者關于The Open Group The Open Group 白皮書這里提出的架構方法可以幫助各種規模的組織更好地實現無邊界信息流 Boundar

12、y-less Information FlowTM 的愿景， 這個愿景通過全球協作， 可以更安全， 可靠， 和及時地達成。我們觀察到當前的架構實踐和技能正在被重新審視， 因為它們通常是精益和敏捷文化的反模式。 人們常認為它們妨礙了迭代開發， 最小化可行產品 （MVPs） ， 和協作。當今的架構師需要延續多年的傳統， 但又不得不以另一種方式工作： 創建新制品， 學習新技能， 并且學會在跨職能團隊中工作。 架構需要創建對開發團隊和運維團隊有用的資產。本白皮書的目標是解決這些問題， 并嘗試描繪出數字化企業所需要的新架構框架。麥肯錫最近的一次調查1顯示， 組織級敏捷能力越來越被重視： 越來越多的大型組

13、織開始推行規?；艚?， 例如Scaled Agile Framework (SAFe)2， Large-Scale Scrum (LeSS)3， 或者Spotify Model4。IEEE Software5上發表的一篇論文聲稱， 僅通過流程改進還無法解決敏捷能力低下的 綜述由于技術架構和組織層面的準備不足， 導致很多敏捷化嘗試的結果未能盡如人意。 本白皮書提出了一個新的架構框架， 敏捷架構框架 （Agile Architecture Framework， AAF） ， 此框架可以滿足數字化企業的需求。 這套框架提供了一個以獨特方式組成的愿景： 將系統以及設計這個系統的組織， 分解成松耦合服務

14、和自治團隊的方法 與業務戰略保持統一的機制， 該機制提倡將共同認可的文化作為一種凝聚力， 使賦能的組織避免松散 能夠利用最新軟件創新技術的架構模式， 這些軟件創新包括分布式計算， 自治系統，數據流， 以及人工智能 從超大型企業近年來開啟的規?；艚葜分蝎@得的已驗證的經驗6簡介 The Open Group 白皮書“企業能否展現敏捷能力成為了首要考慮的因素” ?！懊艚輰嵺`者的努力主要聚焦在改進軟件的開發流程， 對技術的健壯性則不是那么的重視我們曾經經歷過大型機構的敏捷化改造， 在改造過程中應用了很多精益原則， 但是反響平平這是因為速度測量， 計劃撲克， 未解決的缺陷列表， 看板卡， 結對編程，

15、 或基于迭代的計劃等方法和工具， 對于根本問題的觸動相當有限。 ”來自一線的經驗也驗證了上述論點： 問題的根因不僅限于技術健壯性， 還源自于企業的組織和文化。 如下所述：我們認為， 架構 （名詞） 和架構建設 （動詞） 不能被區別對待。 換句話說， 在敏捷的語境中，技術的健壯性和流程維度是密不可分的。 企業往往會忽視敏捷在架構， 組織， 和文化方面所需的前提條件， 而直接將敏捷轉型的焦點放在了流程維度?？傊?， 我們看到： “傳統的方法傾向于減緩最初的迭代后續迭代常常會更改之前迭代中定義的架構模式。 ” “如果我們每次在這些嘗試中都不得不實現一個規劃未來一兩年或五年的笨重架構，我們將會陷入麻煩。

16、 我們做不到敏捷。 ” “我們希望能進行最簡單的最小可行實驗， 驗證一個假設， 要么增強這個實驗， 要 “理想情況下， 團隊應該有一個資深技術人員資源池， 扮演了代理架構委員會的角色， 我們不必去找那些有著唬人頭銜的坐在象牙塔上的人， 這些人可能在最近十年都沒有做過類似的東西， 因為他們習慣了高階思維。 ” “從實用層面看我覺得那些架構師就是在浪費時間。 我真的不認為他們知道他們現在在說什么。 ” “雖然架構原則是需要的， 架構師在團隊的角色定位卻不甚明了團隊架構師應該加入所有的敏捷儀式， 否則他們就有被邊緣化的危險。 ”么跟從這個實驗的走向， 圍繞和跟從這個最小實驗到任何地方。 這意味著我們

17、整個架構構都將是自然發生的， 取決于我們的走向。 ” The Open Group 白皮書本白皮書展示了一個期望解決這些問題的愿景。 這個愿景基于如下判斷：DevOps 2017現狀報告6調研了架構與持續交付和IT效能之間的關系。 這份報告度量了服務和組件之間的耦合關系， 度量方法是判斷是否：DevOps 2015報告中發現高效能團隊相對于中等或低效能團隊， 更有可能采納松耦合的架構。 在DevOps 2017報告中進一步確認了這個發現， 并驗證了兩個新的假設： 自治和松耦合 企業架構師應該將注意力 （重新） 聚焦在大型系統的模塊化上， 因為這是實現敏捷最重要的前提條件 現有的架構實踐和架構角

18、色需要順應敏捷轉型的趨勢做出調整， 要保持與架構的關聯性 需要完成架構師的知識體系， 以適應數字化企業的要求 在組織從大型項目群向自治組織轉型的過程中， 傳統的架構治理模式失去了與架構的關聯 如果團隊的自治程度不夠， 將降低持續交付效率并限制敏捷度 為避免混亂， 團隊自治一定要與某種統一機制相平衡， 但是這種統一機制不能是強管控模式的， 因為這種模式會妨礙自治 新的軟件架構模式將對企業架構的演化產生深遠的影響 數字化企業需要一套新的架構知識體系， 新的流程和治理實踐； 架構的角色需要被重新定義 應用能夠在沒有集成環境的情況下進行測試 應用及服務能夠獨立于它所依賴的其他應用及服務， 單獨部署和發

19、布 能自主決定采納哪些工具的團隊在持續交付方面有更好的表現 作為對比， 有些團隊只能使用集團指定的工具 在IT和組織表現突出的團隊里， 系統架構被設計成可以獨立測試， 部署， 和變更， 不需要依賴其他團隊額外的工作， 資源， 或審批， 并且盡量減少與前后端的通信 The Open Group 白皮書分層的思想創造了一代架構師， 他們熱衷于學習技術以提升市場價值， 但是對領域知識缺乏興趣。 Eric Evans在他的影響深遠的書10中稱， 領域是軟件復雜度的主要來源。 他開發了一個新的方法， 領域驅動設計 (DDD)， 來應對這個問題。這里的關鍵發現是， 當系統或團隊耦合太緊時， 流程就可能被卡

20、住， Forrester將之形象地稱為 “瀑-敏捷-布”（Water-Scrum-Fall7） 。 敏捷開發流程可以快， 但是部署環節會被協調、測試、 和集成工作帶慢節奏， 而這些工作在生產環境部署前是必須的。 最終結果是， 瀑-敏捷-布的研發周期并不比瀑布模式短多少， 這嚴重影響了敏捷所提倡的更快、 更頻繁的價值交付目標。MacCormak8等學術研究表明， 組織結構和這個組織的產品設計之間存在某種關系。 實驗表明， 松耦合的組織比緊耦合組織產出的模塊化設計更多。作者比較了六對類似的產品。 每對產品中都有一個由松耦合的組織開發， 另一個由緊耦合的組織開發。 由松耦合組織開發的產品明顯在模塊化

21、方面做得比緊耦合組織的產品好。 模塊化的評估標準是考察產品組件之間的耦合程度。差異程度非常大 如果以一個組件設計的改動所影響的周邊組件個數算的話， 可能差到8個。這里的關鍵發現是， 如果要架構一個松耦合的系統， 重要的是要關注其組織。 因為這兩者是一致的， 反向康威定律9指出架構的設計會影響組織的設計。兩者的關系已經建立起來了， 下面我們將探討如何分解軟件系統及開發軟件系統的組織。 傳統上， 基于技術的考慮， 架構往往采用分層式的軟件體系， 例如數據訪問， 業務邏輯， 應用邏輯， 或展現邏輯。 這樣做主要的好處在于： 標準化， 標準化可以降低技術風險和技術成本 某種程度的模塊化， 因為某一層的

22、變化不會影響下一層 The Open Group 白皮書一言以蔽之， 領域驅動設計 （DDD） 將領域分解成子領域和語境。 如果做得好， 領域架構會定義一系列松耦合的服務。 領域驅動設計關注垂直的系統分解。 圖1展示了這個轉變。系統被分解成多個服務， 每個服務封裝了一套同質的能力。 模塊化規則依然有效， 服務內部高聚合， 服務之間松耦合， 實現細節則隱藏在API后面。每個服務有自己的持久機制， 并將自己的功能特性通過良好定義的接口開放出來。 服務之間的通信通過同步或異步的方式來進行。 當采用異步通信方式時， 消息或者事件采用類似發布訂閱的機制將服務串到一起。 不允許通過共享數據庫、 共享庫等方

23、式來通信。 對工具和開發技術棧的選擇沒有限制， 這帶來兩個好處：領域驅動設計是一種目前被廣泛采用的方法， 用來將系統分解成不同的模塊。服務可以被單獨測試和部署， 并且很容易被容器化， 這進一步加快了持續交付的流程。對領域的分解需要有深厚的領域知識， 以防設計的服務開放API而容易泄露技術細節。 服務的粒度可以變。 當服務負責某個能力， 又被稱為微服務?！盀槊總€服務選擇合適的責任級別其范圍是最難的挑戰之一。 ”12“很多微服務的采納者都轉向Eric Evans的領域驅動設計方法， 這個方法有一整套優秀的流程和實踐幫助針對大型復雜系統實現有效和業務環境友好的模塊化。 ”13圖1 從分層到服務 創新

24、不會因技術標準而減慢， 因為技術標準隨著時間的推進有可能過時 團隊能自己決定使用哪些工具更好地實現持續交付1110領域驅動設計 The Open Group 白皮書綜述簡介自治和松耦合領域驅動設計模塊化和賦能的組織自治和統一的平衡命令控制模式的缺點改變組織模式業務架構模式軟件架構模式分布式計算的新規則新數據模型基礎設施代碼敏捷架構框架 （AAF）架構的角色架構流程敏捷架構的開發方法參考文獻關于作者和譯者關于The Open Group 但即使有一個優秀的方法也無法替代領域專家， 因此Martin Fowler14建議可以先建一個傳統的大一統的系統， 在對領域知識有更好的了解以后， 再通過重構將

25、其改造成微服務。一年之后， 團隊就可以把這個大一統的系統分解成微服務架構， 這些微服務之間的邊界被證“最終， 團隊將服務整合回一個大一統的系統中， 給他們更多時間來理解如何確定邊界。明更加穩定。 ”15讓我們看看企業如何改變其運營模式和組織架構以變得更敏捷， 如何與軟件系統模塊化的演進保持一致。傳統的方式要依靠項目群或項目組來領導一個變革， 項目組的成員可能來自于共享資源池。 你需要建立一個市場項目組來定義產品， 一個IT項目組來實現產品需要的應用系統，還需要一個變革管理項目組指導其在組織內的部署。 開發團隊再將軟件轉交給IT運維團隊。在新的運營模式下， 重點關注如何維持一個穩定的團隊來設計、

26、 構建、 和運行產品和服務。 整個流程將被產品負責人牢牢把控， 產品負責人通常來自于業務團隊， 他將與IT團隊緊密協作并深度參與產品的整個生命周期。所有的角色被整合進了具有自組織特性的團隊， 或者一些團隊也經歷重組。16項目經理轉型為敏捷教練， 而經理們則關注能力的構建。實踐案例下面我們以一家電商企業為例， 這家企業的業務模式是在線上提前24小時發起持續幾天的特賣活動。 每個品牌每年只發起2次通過供應的不確定性和時間限制， 其目標是為購買者制造消費的欲望和沖動。雖然服務質量不是最好的， 這個業務模式很有效， 并且引領了持續10年的高速增長。 與此同時， 互聯網巨頭們影響了客戶的預期。 例如，

27、客戶期望知道多久能收貨， 希望支付方式更靈活， 還希望能把同一天購買的幾個商品放在同一批次收貨。11模塊化和賦能的組織 The Open Group 白皮書命令控制(Command-and-Control)思想的特點是： 決策制定與執行是分離的。 這讓經理們接觸不到執行的細節。 這種思維的核心理念是基于數字的管理， 這些數字是真實世界的一個簡化和抽象的視圖。當權威自上而下流動時， 管理將面臨風險： 決策與現實是否脫鉤了。 由于這種信息的簡CEO任命了新CTO， 他被要求將技術帶入企業的核心。 這家企業曾經還是一個時尚行業的初創公司， 如今它將變成一家技術公司。 曾經的IT部門的組織架構是金字塔

28、形的， 像一家IT服務公司， 而如今它的架構將變成扁平的分布式。企業和軟件系統被分解成50多個產品并由自治團隊管理； 例如， 支付團隊和物流團隊分別負責開發和運行最好的支付和物流產品。 現有的軟件系統太過死板也太過龐大， 將采用微服務架構將它逐步重構。領導團隊希望排除一切障礙， 加快自治團隊的運作。 新組織架構的目標是運營幾十億生意的同時， 重拾初創公司的敏捷性。 一種緊迫感驅動著組織變革， 因為CEO感覺：增長的運營規模導致任何演進都變得更困難也更慢。 沒有技術的有效支撐， 任何重大進展都難以實現。這家企業如何區分混亂的情形和 “賦能的” 統一性呢？雖然團隊高度自治， 統一和協作是必須的。

29、具體來說， 企業要求： 自治和統一的平衡12 必須保證客戶的購物體驗是無障礙的， 并且能媲美互聯網巨頭所提供的用戶體驗 需要整合不同來源的數據并構建高效的預測模型當前企業的業務模式需在銷售前準備好庫存， 因此市場和銷售數據很關鍵， 可以用來預測需求并安排物流團隊運貨。命令控制模式的缺點 The Open Group 白皮書“失控的高速增長將把業務帶到絕境” ?！按_保底層的意見上層能夠聽見這是我們最終必須要克服的困難命令可以自下而上地浮現， 與之相仿， 也可以至上而下地隨著計劃一起下發。 ”17當至下而上的溝通減少到只有一句話和只用綠/黃/紅色標記報告進度時， 這也同時減少了上下級交互的次數，

30、導致 “命令” 與現實的距離更遠。命令控制思想在統一自治團隊方面不是一個有效的方法， 因為至上而下有缺陷的決定很可能與自治團隊發生沖突。 舉例來說， Spotify的開發文化抵制無效的指令： 如果它有效就保留， 不然就放棄。 在Spotify， 大家廢除了沒有意義的移交物， 無用的會議， 以及企業中荒唐的的規章制度。18相反， 敏捷組織以有意義的目標去統一工作任務上層提供了清晰的愿景， 優先事項， 以及任務。 透明度使團隊擁有所需的權限以獲取用來制定決策的信息和內容。 消息靈通的團隊被賦予權限和信任。 有特權訪問重要信息已經不再是中層管理者用來強加意愿給團隊的權力來源?；统橄?， 對真實問題和

31、機會的洞察變得模糊不清。13從命令控制模式變為敏捷模式需要企業文化的轉變。 Frdric Laloux在 重新發明組織19一書中創建了一種組織模型分類法。 作者觀察到， 大部分現代國際公司都是一種他所稱為的橙色組織類型的體現， 這種組織被等級化的組織架構所主導。 虛擬團隊， 跨職能舉措及項目， 以及專家組織能培養出有競爭力的創新響應能力。在下一個演進階段將是綠色組織， 其保留了橙色組織中精英治理的等級化組織架構， 但是將絕大部分決策權下放給一線的工作人員。 在綠色組織中，太多實施大規模敏捷的企業缺少賦能， 強大的文化， 以及共同認可的價值觀， 這些才是實施敏捷轉型的前提。 習慣于在橙色組織中工

32、作的企業架構師往往對敏捷變革準備不足。 在橙色組織中發展起來的架構治理模式在敏捷轉型中成為變革的阻礙。John Kotter曾開發過一個模型來描述傳統的等級化組織機構如何進化到下一個階段。對于絕大多數組織來說， 等級化體系是企業核心單一的運作模式。改變組織模式 The Open Group 白皮書他們以一系列共同認可的價值觀為指導， 而不是一本厚厚的規章制度” 。作為一種凝聚力， 使賦予權力的組織避免松散。 公司信任一線員工能做出正確的決策， 因為“一種強大的， 共同認可的文化但事實情況是， 這種體系無法適應現在變化常態化的商業環境。 Kotter倡導一個新的體系另一個更敏捷的， 網狀結構的體

33、系， 與等級化的體系相配合地構成他所說的 “雙運營體系” 這個體系讓公司既能充分應對急速變化的外界挑戰， 又能完成業務目標。加速20(XLR8)一文生動地描述了新網狀體系的五個核心原則， 八個驅動加速器， 以及領導者如何通過樹立正面典型來為其他人制造變革的緊迫感。 圖2比較了這兩種模式以及他們之間如何互相作用。讓我們看看這需要多大的變革。 Stanley McChrystal將軍面臨一組靈活機動的敵人。 為了應付他們， 他不得不改變機構的文化和運作模式， 這個機構一直以來習慣于命令控制的思維模式:14圖2 雙組織模式 The Open Group 白皮書圍執行， 這種敏捷的特點通常只在小規模團

34、隊中才有”之推廣到分布在三大洲的上萬人的組織。 我們變成了 “團隊的團隊” ： 重要的指令很快被大范下的天花板那些制度曾經讓我們很高效我們觀察最小作戰單元的行為方式， 并將行” ） 的原則， 自上而下地重建了我們軍隊我們拆除了障礙那些部門墻和等級制度“我們基于極端透明化信息共享 （我們稱為 “共享意識” ） 和去中心化決策權力 （ “授權執反映到軍事歷史上， McChrystal將特拉法加戰役的勝利歸因于Nelson一手打造的組織文化。 這個文化鼓勵個人舉措和批判性思維， 而不是簡單地執行命令。 這種文化的變遷意味著不應該讓領導者做出或審批所有的重要決定：如果我們同意， 在敏捷組織里命令控制模

35、式不是一個有效的統一方式， 我們還有什么替代方式呢？ 頂層的領導團隊需要為其團隊提供指導， 反饋， 和支持。 他們需要目標導向的領導方式， 這種方式需要有戰略清晰度。在一篇重要論文中21， Michael E. Porter寫到：這都始于戰略定位的定義， 其基于客戶的需求， 客戶的體驗， 和/或一些產品和服務的組合。15戰略的目標是創建一個獨特的定位， 通過一系列獨特的行為更好地滿足客戶的需求， 同時提供卓越的體驗。 這些行為執行的方式決定了成本 （運營視角） 。 客戶愿意付出的價格與成本之差就是利潤 （商業視角） 。業務及其運營模式的構建再也不能采用 “至上而下” 的瀑布方式了。精益創業22

36、一書中普及了一種漸進式的方式， 這種方式依賴于快速實驗和經證實的認知。面對客戶的自治團隊最適合設計需要市場快速驗證的最小可行產品 （MVP） 。 雖然自治團隊擁有自主權， 他們還是需要有人指導。領導團隊需要制定清晰的愿景， 這個愿景可以被轉變為分配給下級組織的使命。 被授權的敏捷團隊將實施這些使命， 如有需要可以提出質疑。 如果引導得好， 認知過程， 精益方法稱之為接球23， 提供了一個強大的統一機制。業務架構模式 The Open Group 白皮書了”更重要也更令人吃驚的是， 我們發現， 除了速度變快， 我們向下授權后決策的質量也提高大的價值， 所以我改變了流程行動太慢的風險要高于讓有能力

37、的人自行決斷的風險“等我做審批也不會等來更好的決策我慢慢了解到， 在一般情況下， 我發揮不了更“戰略的精髓在于行動與競爭對手相比， 差異化地采取行動或者采取不同的行動。 ”近期， 一份來自MIT信息系統研究中心的論文揭示了幾種統一機制的組合是如何幫助Spotify在保證團隊自治的同時避免混亂的：一種新的技術賦能的業務模式正在改變行業， 這就是平臺。 它將人， 組織， 和資源整合到交互的生態中， 這個生態對行業現狀造成顛覆性沖擊。 AirbnbTM, UberTM, Alibaba, 或Amazon Marketplace集中體現了其對行業的顛覆性影響。傳統業務模式是圍繞產品或服務構建的， 產品

38、或服務在設計出來以后被交付給客戶。 當平臺式的企業進入傳統市場時， 它們就具備了強大的競爭優勢。 為什么？ 因為傳統模式依賴低效能的守門人來控制價值流， 而平臺提倡自服務和參與者之間的直接交互。平臺可以擴張和成長得更快更高效， 因為傳統的守門人角色被市場參與者透過平臺傳遞的信號所替代， 平臺在這里起到了中介的作用。 平臺刺激了增長， 因為它們釋放了新供給并解鎖了新需求。 它們還利用大數據/快數據分析能力創建了社區反饋環。24平臺需要治理， 包括設立一系列規則以約束誰能參與到這個生態， 如何分配收益， 以及如何解決沖突。 好的治理規則以大家認為公平的方式將收益分配給提供附加值的各方。 治理尤其需

39、要注意外部效應。 例如， Airbnb受制于公共管理機構發布的新規則， 這些新規則希望限制Airbnb的外部效益以減少對公寓出租市場的負面影響。因為技術是一個關鍵的促進者， 我們將看看讓數字化業務成為可能的軟件架構模式。 我們還將簡要介紹一下Michael A. Cusumano稱為 “內部平臺”25的另一種平臺。 這種平臺讓企業可以重用或重復部署橫跨產品線的資產來獲取更好的經濟效益。 不引入層次化的等級制度， 向自治化組織指明清晰的目標和任務并使它們統一 隨著團隊數量的增加， 建立正式的分享機制來協調團隊間的行動 通過定義架構標準來輔助自治團隊， 確保各個模塊之間的兼容性16Marc And

40、reessen說過，“軟件正在吞噬這個世界” 。26 軟件架構模式 The Open Group 白皮書快速演進的軟件技術刺激了數字經濟。 在互聯網巨頭的帶領下， 一些來自舊經濟模式的企業也在嘗試將自己重塑成技術公司； 例如， 西班牙對外銀行(BBVA)認為：3. 不允許出現別的跨進程通訊方式： 沒有直接鏈接， 不能直接讀對方的數據庫， 沒有共4. 服務接口的實現方式不限。 HTTP， CORBA， Pub/Sub， 自定義協議不限。 Bezos不5. 所有的服務接口， 沒有例外， 必須被徹底設計成可外部化的。 也就是說， 這些接口可以享內存， 沒有后門等等。 唯一的通信方式就是通過網絡調用服

41、務接口。關心這些。隨時被企業之外的開發者拿來使用。 沒有例外?；ヂ摼W巨頭確實成功保持了初創企業的敏捷性， 同時保持著高速成長并在全球范圍運營。 他們特別注意松耦合和團隊自治， 他們還知道如何掌控大規模分布式計算。 讓我們看看Amazon和Google。在2002年， Amazon面臨一個很復雜的難題。 其主頁有800MB大小， 編譯一次就要花8到12個小時。 Jeff Bezos發布了一個命令， 從而深刻地改變了軟件的開發方式和企業的組織方式。 Steve Yegge在一篇文章里提到28：通過轉向模塊化和API， Amazon變得很容易將分銷和物流能力開放給第三方廠商。 平臺的自服務特性讓廠商

42、可以無障礙地接入并銷售自己的產品。 這讓Amazon在與eBay的競爭中具備了差異化優勢。2004年， 來自Google的Jeffrey Dean和Sanjay Ghemawat發表的一篇論文29中描述了MapReduce編程模式。 這個創新深深地影響了分布式計算。 MapReduce把處理過程高度抽象為函數， 很容易自動并行化處理， 并在大型商業化機器集群上運行。17“如果我們想成為領先的銀行， 我們不得不變成技術公司” 。271. “所有的團隊只能通過服務接口來開放數據或功能。2. 團隊之間必須通過這些接口來溝通。6. 任何人違反， 將被開除。7. 謝謝； 祝愉快！ ” The Open

43、Group 白皮書它讓沒有并行和分布式經驗的開發者可以很輕松地利用大型分布式系統的資源。 它還具備很強的擴展能力， 及對硬件和網絡的故障容錯。兩年后， Google的某個團隊發表了一篇論文30， 描述了一種可以管理極大量結構化數據（在上萬臺商業服務器上的PB級數據） 的分布式存儲系統。 這個系統利用不變性 （immuta-bility） 來簡化并行控制：人工智能 （AI)是發掘互聯網巨頭海量數據潛力的最佳工具。 分析算法幫助預測客戶行為和推薦商品。 深度學習讓基于計算視覺和自然語言處理的應用成為可能?；ヂ摼W巨頭遵從的模式是開發很多定制化的方案以支持其產品和服務。 他們將很多內部方案寫成白皮書，

44、 進而演化成開源項目。 大量前沿技術是免費的， 包括高級AI庫， 例如TensorFlowTM31。 有一些開源項目甚至包括了預先訓練的深度學習算法， 以簡化新AI應用的開發； 例如， OpenFace332：奔流不息的技術創新之河對企業軟件架構產生了深遠的影響。 自動化的興起最終將產生自治系統， 這已經并將繼續顛覆現有的業務和運營模式。下面我們將聚焦幾種關鍵的軟件設計模式， 它們將是架構師知識體系的一部分?！拔覀冊谧xSSTable的時候不需要對文件系統做任何同步訪問控制。因此， 對行數據的并行控制可以非常高效” ?！懊赓M和開源的基于深度神經網絡的面部識別請負責任地使用！ 我們不支持侵犯隱私和

45、安全的應用項目。 ”18 將系統分解成可分布式運行的組件， 在商業化硬件上并行運行 可根據負載水平擴展和彈性伸縮 充分利用現代多核處理器設計， 開發， 和運維分布式系統一直以來是一個高難度的嘗試。 過去， 基于交易監控和兩階段提交協議的中間件技術已經夠用了33。 如今， 它再也不能滿足數字化運營模式所需要的可擴展性和高可用性。架構師需要理解和運用新分布式計算模式下的范式：分布式計算的新規則 The Open Group 白皮書“編寫并發程序的關鍵在于控制對共享可變狀態的訪問如果一個對象的狀態是不變的， 風險和復雜度也隨之而去了。 ”3419 一致性 （Consistency， C） 高可用 （

46、High Availabilty， A） 網絡分區容錯性 （Tolerance to Network Partitions， P）將一個系統分解成分布式的組件可以擴展對外服務的性能， 利用大量處理單元來服務更多用戶。 不同地域的數據或功能副本被用來實現容錯恢復， 進一步提升高可用性的質量。因為傳統的并行編程容易出錯， 新的 “不可變” 編程模式變得越來越重要。 推導出復雜對象的情況很難。 推導出不可變對象的狀態就很容易， 因為它只有一種狀態， 并且可以被安全地共享：函數式編程 （FP） 將計算當成數學函數。 一個純函數， 當接收到相同的輸入時總是返回相同的輸出， 沒有任何副作用。 純函數完全獨

47、立于外部的狀態， 因此它對需要共享可變狀態的各種缺陷 （bugs） 完全免疫。它們這種獨立的特性使其成為跨CPU處理、 跨集群計算的優秀候選方案。 因此， 函數編程是用來構建大規模分布式系統的主流模式。 例如， 用來編寫Apache SparkTM和KafkaR的編程語言Scala， 就是函數式語言， 而像JavaScript或Java這類語言具備函數式擴展。高度分布式的計算模式在數據方面帶來了挑戰。 例如， 一些微服務并行地運行在多個節點， 每個都有自己的數據。 這讓數據的一致性成為一個挑戰。 Saga模式則可以用來解決這個問題。設計分布式系統架構需要在運維復雜度， 性能， 可用性， 和一致

48、性之間做平衡。 CAP定理指出任何需要通過網絡分享數據的系統， 最多只能擁有下列三個屬性中的兩個：Saga是一個長活事務35， 由一系列可以交錯的事務組成。 系列中的事務要么全部執行成功， 要么出現錯誤的部分由補償事務來恢復。 Saga的概念和實現都相對簡單， 卻可以潛在地極大提升性能。新數據模式 The Open Group 白皮書20 探測客戶想做什么， 并實時給其提供幫助， 以提高客戶體驗 實時監測欺詐交易， 保護資金 監測銷售網點的系統故障并在客戶離開前解決問題， 提升門店服務質量 根據客戶在門店的位置實時推送促銷信息， 提升營業額 實時分析傳感裝置的流數據以監控病人的狀態， 降低風險

49、過去， 相當一部分的持久機制采用的是關系型數據模型。 這種情況這在發生改變， 因為前無古人的的數據規模擴張迫使互聯網巨頭們發明了基于不同數據模型的新數據庫管理系統 （DBMS)， 新數據模型舉例來說有鍵值對或圖形。對于數據存儲正在從一種方式轉變為多語言的存在形式。 現在最好是根據數據的實際用途選擇不同機制。 例如， 機器學習 （ML)最好使用便于處理數據幀的機制， 數據幀是機器學習算法常用的數據結構。 JSON是一種流行的替代XML的數據結構。 像MongoDBTM這樣的數據庫管理系統利用JSON文檔存儲記錄， 為程序員帶來方便。架構師需要理解新數據技術的一個主要原因是， 這會直接影響系統能否

50、滿足非功能需求。 讓我們以Apache CassandraR為例， 其實現了一個分片算法。 數據庫模式 （schema） 中定義的分區鍵驅動了分片行為。 如果設計得不合適， 分片算法可能會將太多數據分布在同一個節點， 這將導致性能急劇下降。 這在以前不是個問題， 因為關系型數據庫 （RDBMS） 技術不依賴物理設備。 架構師如果還囿于老的RDBMS/TPC思維模式， 其設計的系統在擴展性和穩定性方面就可能存在風險。傳統的批量分析不再適合今天的商業實踐。 洞察力時間 （Time-to-insight） 太長， 通常需要花幾天時間才能在正確的位置拿到正確的數據。 批量方式通常在大數據革命后沒有任何

51、改變?？鞌祿谌〈髷祿?。 其特點是高速地持續實時處理大量數據。 實時分析利用快數據在幾秒甚至不到一秒的時間內， 做出預測或給出方案。 讓我們通過下面的例子看看快數據和實時分析的價值： The Open Group 白皮書21技術創新讓快數據和實時分析的實現變得簡單。 Apache StormTM和Spark為此鋪平了道路。 Apache FlinkR將此提升到新的高度， 實現了真正的大規模實時流處理。 新的業務和運營模式因此成為可能。 甚至業務人員也要理解這些技術來架構新的服務系統， 以便實現杰出的客戶體驗和卓越的運營。軟件在 “吞噬” 基礎設施。 基礎設施即代碼(Infrastructu

52、re as Code)借用軟件開發的實踐來實現基礎設施的自動化； 例如， GitHub管理的源代碼， 測試驅動開發 （TDD） ， 或持續部署（CD） 。不變性的優勢也能讓基礎設施受惠。 你可以利用編程概念中的不變性來創建和運維基礎設施。 也就是說， 一旦你實例化某樣東西， 你再也不會改變它， 只會用另一個實例替換它。并不是說這個系統不再變化， 只是換了一種更簡單有效的方式在規模不斷變化的情況下管理基礎設施。36云原生基礎設施 （CNI） 由一組通過軟件管理的API控制。 得益于自動化， 運行具有這種特征的基礎設施會更高效， 擴展性更強。 云原生基礎設施使自動化應用管理成為可能。一個運行在云原

53、生基礎設施上的云原生應用 （CNA） 變成了一個自治系統， 大部分情況下不用人工參與決策。 在它不知道如何自動處理時， 系統會通知人工介入。云原生應用需要一個平臺， 這個平臺能有效地監控和收集指標數據， 并且在發生故障時作出反應。 Heroku曾經發表過一個宣言， 宣言中聲明了云原生應用應該遵循的指導方針。 從那之后， 最初的12個要素也被更新了。37在傳統環境下， 服務器提供了應用所需要的所有資源， 從滿足應用依賴性到提供宿主環境。 如今， 構建制品包含了運行應用組件的所有資源。 容器技術將構建制品封裝到鏡像中以便于部署， 同時也促進了持續部署和方便了云移植。云原生帶來的更大的隔離性為自治化

54、提供了關鍵的助力， 因為這將敏捷團隊所須管理的依賴性降到最低?；A設施即代碼 The Open Group 白皮書22 敏捷架構框架云計算更多影響了應用開發的方法， 而不是運行應用的基礎設施。 傳統上應用和基礎設施之間的邊界越來越模糊?！澳銟嫿?， 你運行” 的原則促進了跨職能的DevOps團隊， 打破了傳統的IT部門墻。 這個演變對架構的角色和流程產生的重大影響， 要求其與開發流程有更好的聯動。因為本文中描述的這些趨勢具有顛覆性， 我們相信企業需要一種新的架構框架。 讓我們說說那些影響架構角色和架構流程的變化。IEEE Software上發表的一篇論文描述了在數字化時代軟件架構師角色的演變38

55、。 表1總結了這篇論文中的主要論點：表1:數字時代的架構師角色Target公司的IT副總裁說過：“企業架構歸根結底是要為我所用， 而不是跟我們對著干” 。 架構的角色1. 軟件團隊越來越樂于使用工具和實踐幫助他們避免或分解重大管理決策。 6. 新式軟件架構還將設計的關注點放在自動化部署，動態伸縮，自動故障切換，預測式監控，和很多其他高級的運行時功能。 2. 實踐證明，絕大部分成功的架構和架構決策是團隊協作的結果，而不是僅僅依靠架構師。 7. 新的架構和方法，例如云計算和DevOps，能幫助傳統公司與數字化顛覆者競爭，也讓組織架構和工作文化的轉變成為必須（反向康威定律）。 3. 大規?；ヂ摼W公司

56、的架構依賴代碼，而不是將架構決策的寫到文檔里堆積起來。 8. 架構決策不過度約束設計細節：松耦合的系統和領域驅動設計的演進順序原則。 4. 互聯網架構模糊了系統之間的邊界，將單個的軟件應用變成一系列 API經濟下互相聯系的服務生態這讓團隊很難固化設計，反而帶來了具有靈活性的超高質量架構。 9. 架構師必須將以前一些諸如嵌入式系統，分析，基礎設施設計等單獨領域的知識轉移及合并進入主流軟件開發團隊，起到橫向連接的作用。 5. 將軟件部署在互相連接的各種設備上，讓架構考慮點的范圍從以前的某個特定領域（例如網絡安全，能耗，運行時配置，自動化，等等）擴展到更大的范圍。 10. 身處劇烈變化的時代，架構師

57、需要在不同項目組間，不同領域間，和組織不同層級間起到導師和搭橋人的作用。 The Open Group 白皮書23 提供一頁紙的企業級架構圖 利用社交編碼和開發源碼庫構建開發文化 （例如GitHub） 讓開發者編寫標準， 然后要求架構師簡化流程 自動評估合規性 在混亂的邊緣進行管理 每個系統都有一個語境： 平臺或租戶 每個系統都有明確的邊界： 數據， 流程， 業務邏輯， 聚合， 用戶界面簡而言之， 架構師正在變成導師和搭橋人。 對架構師角色的要求變得更高， 因為以前限于特定領域的問題需要有人融會貫通。 一個成功的架構師是一個T型人才， 他既能把這些點連成線， 又在某些特定領域有足夠的深度，

58、以便與開發團隊對話。在最近一次采訪中， Target公司架構副總裁JoelCrabb說： 39。他說， 他曾經讓獵頭在數字化企業找可以招聘的企業架構師。 他發現NetflixR和Facebook都沒有企業架構師， 雖然Amazon雇了很多架構師幫助客戶把系統遷移到AWS。Joel Crabb說企業架構正在被去中間化。 專業或領域架構師在敏捷團隊和其他角色之間形成了一個無用層。 例如， 如果領導敏捷團隊的產品經理來自業務部門并且被授權做真正的業務決策， 業務架構師還有什么價值呢？這是否意味著企業架構已死？ Joel Crabb并不這么想。 他開發出了一種 “支持架構” 的開發文化。 想有所作為，

59、 架構團隊應該通過以下幾個方面確保開發團隊快速運用到好的想法：Joel Crabb基于其內部的可重用和標準化的軟件平臺繪制了一個企業級架構愿景。 這個架構模式將平臺和其租戶分開。 租戶通過事件驅動的異步通信模式與平臺通信。最終要求的是一致性， 除非有特殊業務需求導致有例外產生。 最終整個系統非常健壯，可以彈性伸縮， 并且從各種故障中恢復。 整個參考架構模式可以在一張紙上用一個簡單的圖表現出來。這種內部平臺也需要治理。 Target公司的架構治理原則總結如下：“大架構時代已經終結了” The Open Group 白皮書24架構流程 租戶與其他租戶和平臺之間解耦 語境決定了企業治理所需的部分一邊

60、帶領一百個小隊在往前沖， 一邊在混亂邊緣管理， 企業架構師應該避免扼殺創新，同時也要樂于接受變化。 因為開發團隊行動太快你無法跟蹤， 新的想法在幾周之內浮現又湮滅， 新技術被快速采納又拋棄， 管理團隊和企業架構師要學會放手。在Target公司,架構的目標是創建一個有利創新的環境， 在這個環境下優秀的想法能快速勝出并上線。 例如， 架構團隊幫助Target公司將報價系統的數量從七個減少到一個。 從架構團隊看來， 從七個縮減到一個是一個了不起的成就。 開發團隊也愿意這樣做， 不是因為架構團隊讓做， 而是因為他們覺得這確實是個好主意。老模式下的重大前期設計被最小可用架構 （MVA）40的概念所取代。

61、 最小可用架構定義了架構決策和基礎設施能力的最小集， 以啟動第一次 （或下一次） 敏捷迭代。有很多介紹最小可用架構的文章提到， 很多不確定因素影響了它的定義； 例如， 需求的不穩定性， 未知因素， 對風險的容忍度， 成本， 以及系統的可進化能力。最后一項可變因素指的是響應未知變化的能力。 表2中列出的設計策略能幫助架構師構建一個在未來可優雅演進的系統。表2： 可演進設計策略設計策略 描述 技術 關注點分離 將軟件系統分解成幾個不同種類的方案，這樣每一部分可以解決不同的關注點。 面向方面的編程(Aspect-oriented programming)，干凈架構（clean architectur

62、e ） 模塊化 以信息隱藏和關注點分離的原則，將一個系統分解成多個模塊 領域驅動設計，設計結構矩陣 延遲設計決策 只基于已知的要素做設計決策，而不是過度補償未知需求 基于集的并行開發 元建模 為建模語言和標記法的概念及關系建模 元對象協議 增強智能/基于知識的系統 可供算法用的，可降低修改系統成本的知識 規則引擎，機器學習，深度機器學習 The Open Group 白皮書25 開發出一個總體架構愿景來指導開發團隊 主動自發地識別出該由其做出的類型1決策每種設計策略都有優點有缺點。 例如， 采用規則引擎可以方便地演進業務規則。 另一方面， 這也可能增加了系統的耦合度， 因為規則引擎會跟所有其

63、他系統都有交互。傳統上， 架構師做的決策難度高且修改成本高。 在將可演進性明確作為架構目標后， 決策的改變就不那么困難了。 但是， 一部分決策還是很難改變。 因此， 將這些決策識別出來就很重要。Suudhan Rangarajan解釋了Netflix如何使用Amazon的決策分類法區分類型1和類型2的決策。41類型1的決策是產生重大后果的， 不可逆或者幾乎不可逆的是單向門。 類型1的決策過程必須是有條不紊的， 小心謹慎的， 穩扎穩打的， 必須要深思熟慮和經過充分協商的。 如Jeff Besos 所說：類型2的決策可以由自治敏捷團隊做出， 但是類型1的決策需要更好的治理。在Netflix有三種類

64、型1的決策： 共享庫和通信， 同步和異步， 和數據架構。 類型1決策需要視情況而定， 要考慮企業的現實情況； 例如， 其業務和技術的戰略， 或其成熟度。我們認為這種分類方法對于架構治理很重要。 企業架構師們再也不能像以前一樣等著敏捷團隊讓他們做審批， 他們必須：架構流程應該不再是瀑布/守門式的。 我們需要定義一個詳盡的的最終狀態。 這就是開發新的敏捷架構框架的動機。 我們邀請社區為這個舉措做貢獻。 我們計劃使用長故事 （Epics） 來組織開發， 如圖3所示?！敖^大部分決策不是這樣的。 它們可以更改也可逆， 它們是雙向門。 如果你做了一個次優的類型2決策， 你不必長期忍受其不良結果。 類型2的

65、決策可以也應該由高判斷力的個人或小團隊快速確定。 ” The Open Group 白皮書26敏捷架構框架的開發方法 自治，隔離，和統一 架構流程和角色 架構知識體系因為通向最終狀態的過程是漸進式的， 我們計劃開發一個敏捷架構成熟度模型， 來幫助企業成功轉型。 這個模型將明確說明從一個成熟度級別升入下一個級別所需的前提條件和成功要素。我們建議以三個主題的結構開發敏捷架構框架：表3：敏捷架構框架的開發長故事AAF.E-01 松耦合的系統和組織 . 如何構建松耦合的系統？ . 如何構建由自治團隊組成的模塊化組織？ . 如何設計能實現模塊化架構的組織？ . 如何重構高耦合及單片系統？ AAF.E-

66、02 業務架構模式 . 如何在業務和運營模式上創新？ . 哪些業務戰略概念能與企業保持一致：愿景，使命，目標. ？ . 如何將業務分解成模塊化的運作單元？ . 如何以非命令控制的方式落實戰略？ AAF.E-03 統一的組織和系統 . 如何在保持局部自治性的同時增強全局的統一性？ . 需要哪些組織模式和文化變革？ . 哪些治理模式能在保持組織和系統統一的情況下同時保持自治？ . 如何讓多個服務可以交互和組合？ AAF.E-04 軟件架構模式 . 如何構建高度分布的軟件系統，使其能夠： . 快速響應用戶請求 . 動態適應負載變化 . 保持高可用？ . 如何利用大數據和快數據架構模式？ . 人工智能

67、/機器學習對系統架構的影響有哪些？ AAF.E-05 最小可用架構 . 面對下一個敏捷迭代，需要做多少架構工作？ . 如何做出架構決策，并驗證決策？ . 最小可用架構將如何影響/沖擊敏捷團隊？ . 如何保持最小可用架構與最小可用產品一致？ AAF.E-06 可演進架構 . 什么樣的架構實踐和模式促進未來的變化？ . 如何預見變化并避免不必要的復雜度？ . 如何避免架構隨著時間逐漸退化？ AAF.E-07 成熟度模型 . 有多少成熟度級別？ . 如何定義成熟度級別？ . 如何評估企業的成熟度級別？ . 要成功升級到下一個級別，需要滿足哪些前提條件？ . 有哪些關鍵成功要素？ AAF.E-08 架

68、構師的角色和責任 . 作為突擊隊成員，架構師的角色是什么？ . 架構師需要變成一種“Uber開發工程師嗎？ . 在保護系統整體一致性方面，架構師應該承擔什么樣的角色？ AAF.E-09 敏捷架構的能力和技能 . 哪些是所有架構師都應具備的核心能力和技能？ . 需要哪些軟技能來領導和促進團隊協作？ . 要成為”T 型“全棧架構師，應該具備哪些軟件開發技能？ AAF.E-10 領域驅動設計和事件驅動架構 . 如何運用事件風暴(event storming)方法識別語境和聚合事件？ . 如何利用領域驅動設計策略模式設計繪制語境關系圖？ . 如何使應用代碼避免未來的技術欠費？ AAF.E-11 數據和

69、信息建模 . 如何演進數據和信息建模技術以迎合大數據和快數據的趨勢？ . 如何用微服務架構風格處理數據？ . 實時流分析技術對系統架構有什么影響？ AAF.E-12 復雜系統建模 . 如何引導建模并演進可適應性復雜系統？ . 如何利用設計結構矩陣（DSM）發現復雜技術系統中的層次排序和循環群？ The Open Group 白皮書27 參考文獻1 See 2 See . 3 See https:/less.works/less/framework/introduction.html. 4 Scaling Agile Spotify with Tribes, Squads, Chapters

70、 & Guilds, Henrik Kniberg, Anders Ivarsson, October 2012; refer to: https:/blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf.5 Modular Architectures Make You Agile in the Long Run, Dan Sturtevant, IEEE Software, Vol. 35, Issue 1, January/February 2018; refer to: https:/ieeexplore.ieee.org/

71、document/8239949/. 6 See 7 Analyst Watch: Water-Scrum-fall is the reality of Agile, Dave West, December 2011; refer to: https:/sd- 8 Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis, Alan MacCormack, John Rusnak,Carliss Baldwin, Harvard Bu

72、siness School Working Paper; refer to: www.hbs.edu/faculty/Publica-tion%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf. 9 See www.agilealliance.org/resources/sessions/the-reverse-conway-organizational-hacking-for-techies.10 Domain-Driven Design: Tackling Complexity in the Heart of Software,

73、 Eric Evans, Addison Wesley, August 2003.11 Source: 2017 State of DevOps Report12 Microservices in Action, Morgan Bruce, Paulo A. Pereira, Manning Publications, 2018.13 Microservice Architecture: Aligning Principles, Practices, and Culture, Irakli Nadareishvili, Ronnie Mitra, Matt McLarty, Mike Amun

74、dsen, OReillyMedia, 2016.14 See https:/ Building Microservices, Sam Newman, O Reilly Media, 201516 See http:/schd.ws/hosted_files/agilecamppacificnorth-west2017/20/AgileCamp2017%20-%20Jeff%20Nicholls.pdf.17 Team of Teams: New Rules of Engagement for a Complex World, General Stanley McChrystal, David

75、 Silverman, Tantum Collins, Chris Fussell,Portfolio Penguin, 2015.18 See https:/ Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage of Human Consciousness, Frdric Laloux, Nelson Parker, 2014.20 Accelerate: Building Strategic Agility for a Faster-Moving World, Joh

76、n P. Kotter, Harvard Business Review Press, The Open Group 白皮書2821 What is Strategy?, Michael E. Porter, Harvard Business School Press, 1996.22 The Lean Startup: How Today s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Eric Ries, Random HouseAudio, 2011.23 See

77、www.lean.org/lexicon/strategy-deployment.24 Platform Revolution: How Networked Markets Are Transforming the Economy and How to Make Them Work for You, Geoffrey G. Parker,Marshall W. Van Alstyne, Sangeet Paul Choudary, W. W. Norton & Company, 2016.25 Industry Platforms and Ecosystem Innovation, A. Ga

78、wer, M. Cusumano, Journal of Product Innovation Management, 2013.26 See See 28 See http:/homepages.dcc.ufmg.br/mtov/pmcc/modularization.pdf and https:/plus.goo- See https:/ See http:/ See www.tensorflow.org.32 See https:/cmusatyalab.github.io/openface/.33 Essential Guide to Object Monitors, Karen

79、Boucher, Fima Katz, Wiley, 1999.34 Java Concurrency in Practice, Brian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug Lea, |Addison-Wesley Professional,2006.35 SAGAS, Hector Garcaa-Molrna, Kenneth Salem, Department of Computer Science, Princeton Universi-ty, 1987.36 Immutable I

80、nfrastructure: Considerations for the Cloud and Distributed Systems, Josha Stella, O Reil-ly Media, Inc., 2016.37 Beyond the Twelve-Factor App, Kevin Hoffman, OReilly Media, Inc., 2016.38 See puter.org/csdl/mags/so/2016/06/mso2016060030.pdf.39 See For example, see Minimum Viable Architecture Good E

81、nough is Good Enough in an Enterprise, James Governor, 2017(http:/ and How to Create aMinimum Viable Architecture, Deepak Karanth, 2016 (https:/ See https:/ The Open Group 白皮書 關于作者HervBarbazange是SocitGnrale的企業架構師。 他擁有工程學學位 （巴黎中心） 和企業架構碩士學位。Peter Beijer博士是DXC架構方法的公認開創者， 多年來一直在架構行業擔任領導角色。他是The Open Gr

82、oup管理委員會的成員， 并擔任專業計劃的主席。 他獲得了經濟學博士學位。Jean-Marc Bunouf是MMA Insurance的信息系統架構師， 現在是SocitGnrale的集團架構師， 擁有計算機工程 （UTC） 學位。Carl Kinson是DXC的首席架構師， 一位技術思想領袖。 在為客戶設計， 構建和管理復雜解決方案方面擁有20多年的經驗， 專注于采用新技術和技能來發展企業和個人。FrdricL是DXC公司技術辦公室的技術戰略專家。 他領導著DXC新的敏捷架構框架的開發。 Frdric畢業于Audencia商學院， 擁有巴黎多芬大學的計算機科學研究生學位。Jean-Pierr

83、e Le Cam是SocitGnrale的集團變革管理專家， 擁有工程學學位 （Tl-comParis） ， 是ESSEC變革管理學院的變革大師。Antoine Lonjon是MEGA International的首席創新官。 Antoine為HOPEX企業架構工具集的基礎做出了貢獻， 并且還積極參與如The Open Group和Object Management Group （OMG） 標準組織。JrmeRgnier是法國社會事務和衛生部的企業架構師， 現在是SocieteGnrale的集團架構師， 擁有計算機工程學位 （ENSIIE - Mines-Telecom Institut） 。

84、鄧明先生是The Open Group認證架構師項目的大師級IT架構師， 并多年擔任IBM GBS架構師評審委員會專題組組長。 他擁有19年的IT工作經驗， 涉及金融業、 制造業、 電信業、 以及石油石化等多個行業。譯者介紹： The Open Group 白皮書彭斐 （ Fei Peng） 目前在Oracle公司擔任首席產品戰略經理， 具備十多年國際及跨區域工作經驗， 擅長產品戰略管理、 IT治理、 云計算合同管理與框架設計、 云計算及服務管理、 解決方案架構設計、 及風險管理等。 The Open Group 白皮書 關于The Open Group 領導廠商中立的開放的技術標準和認證的開發The Open Group是一個全球性聯合機 構，旨在幫助企業通過技術標準實現業務目標。 The Open Group與客戶、 供應商、 聯盟及其 他標準組織緊密合作， 致力于: 捕捉、 了解和滿足當前及未來的需求， 制定策略并分享最佳實踐 促進互操作性， 達成共識， 發展和整合規范及開源技術 提供行業一流的專業認證服務 關于The Open Group更多信息可在 www.opengroup.org 或 查閱。