當一個組織採用敏捷思維時，企業架構並不會消失，但企業架構師的角色會改變。企業架構師不再做出選擇，而是協助他人做出正確的選擇，然後傳播這些資訊。企業架構師仍需要形成願景，但接著需要在團隊之間建立橋樑，以建立學習社群。這將允許團隊探索新的方法並互相學習，而企業架構師則作為成長中的合作夥伴。

為了有效利用技術，我們需要將我們的技術思維與基礎商業計畫相結合。技術策略可以推動這種結合，只要它適當地整合了商業和技術。我們已經開發了一個概念框架來協助我們進行這種策略性思考，基礎是認識策略性計畫的共同面向，引導我們找出 11 個普遍的策略方向。對於每個方向，我們概述了它們提出的關鍵商業問題，以及我們需要進行的調查以探索技術影響。我們發現，這個框架不僅能帶來更有效的技術策略，還能讓技術告知商業思維，開發新的收入來源。

我們和我們的同事經常被要求為我們的客戶執行架構評估。當我們這樣做時，參與這些系統的架構師將討論這些系統的效能、它們對故障的復原力，以及它們如何設計成輕鬆支援新功能。然而，很少出現的大象是不同系統如何促成業務價值，以及此價值如何與這些其他架構屬性互動。

架構不一定是獨白；由少數集中化的人員自上而下傳達。本文描述了執行架構的另一種方式；作為一系列對話，由分散且賦能的決策制定技術驅動，並由四種學習和調整機制支援：決策記錄、諮詢論壇、團隊來源原則和技術雷達

Xapo 成立為比特幣服務供應商，並發展成線上銀行。在此轉型過程中，它需要重新評估其軟體資產並建立架構能力以引導其未來。它採用了領域驅動設計、團隊拓撲和架構建議流程的構想，以開發架構建議論壇。這導致其軟體交付團隊更為一致，並制定出連貫的技術策略。

管理階層熱愛他們的指標。他們的思考模式大概是這樣：「我們需要一個數字來衡量我們的表現。數字可以讓人專注，並幫助我們衡量成功。」雖然本意良好，但數字管理卻會直覺地導致問題行為，並最終損害更廣泛的專案和組織目標。指標本身並非壞事；只是經常被不適當地使用。本文說明了管理階層傳統使用指標所造成的許多問題，並提供了解決這些功能障礙的替代方案。

這是我在慕尼黑舉行的 OOP 2014 大會上的主題演講的第二部分，也是一個很難描述的主題演講。我通常喜歡用標題和摘要來描述演講的內容，但這次演講是一趟旅程，我不想告訴你我要去哪裡，而是想和你一起探索這片土地。我要說的是，它始於我對大多數敏捷軟體開發採用方式的最大問題，也就是使用者、分析師和程式設計師之間互動的本質。它繼續探討這些角色，提出關於程式設計師與使用者的關係、我們對他們的責任，以及最後我認為程式設計師需要面對的兩大挑戰。

任何讀過我文章的人都知道，我是演化設計的忠實支持者。儘管我對此方法充滿熱情，但沒有任何技術是完美的，我樂於報告它的問題，就像我樂於報告它的成功一樣。

想像一個徵才情境。有兩位候選人，兩位都有幾年的經驗。在藍角，我們有一位在您偏好的設計風格中擁有良好廣泛設計技能的人（就我而言，這將是 DRY、明智地使用模式、TDD、溝通程式碼等，但實際清單並不重要 - 只要是您偏好的即可）。然而，她對您正在使用的特定平台技術一無所知。在紅角，我們有一位對這些問題知之甚少（或不感興趣），但非常了解您的平台 - 語言中的邊界案例、有哪些可用函式庫、手指自然地在工具上移動。假設他們其他方面都相等（除了像這樣的思想實驗之外，這永遠不會發生），而且您的團隊沒有任何此候選人可能填補的巨大漏洞。您會比較喜歡哪一位？