当一个组织采用敏捷思维模式时，企业架构并不会消失，但企业架构师的角色会发生变化。企业架构师不再做选择，而是帮助其他人做出正确的选择，然后传播这些信息。企业架构师仍然需要形成愿景，但随后需要在团队之间搭建桥梁，建立学习型社区。这将使团队能够探索新方法并相互学习，而企业架构师则是这种成长过程中的合作伙伴。

为了有效利用技术，我们需要将我们的技术思维与基础业务计划保持一致。技术战略可以推动这种一致性，前提是它能恰当地整合业务和技术。我们开发了一个概念框架来帮助我们进行这种战略思考，该框架基于对战略举措共同方面的认识，引导我们确定了 11 个普遍的战略方向。对于每个方向，我们都概述了它们提出的关键业务问题，以及我们需要进行的调查，以探索技术影响。我们发现，这个框架不仅能带来更有效的技术战略，还能让技术为业务思考提供信息，开发新的收入来源。

我们和我们的同事经常被要求为客户执行架构评估。当我们这样做时，参与这些系统的架构师会谈论这些系统的性能、它们对故障的弹性，以及它们是如何设计成易于演进以支持新功能的。然而，很少被提及的是，不同的系统如何为业务价值做出贡献，以及这种价值如何与其他架构属性相互作用。

架构不一定是自上而下的独白，从少数集中的人的思想和口中传递出来。本文描述了另一种架构方式：作为一系列对话，由分散和授权的决策技术驱动，并由四种学习和协调机制支持：决策记录、咨询论坛、团队原则和技术雷达。

Xapo 最初是一家比特币服务提供商，后来发展成为一家在线银行。在转型过程中，它需要重新评估其软件资产，并建立架构能力来指导其未来发展。它借鉴了领域驱动设计、团队拓扑和架构咨询流程的理念，开发了一个架构咨询论坛。这使得其软件交付团队更加协调一致，并制定了连贯的技术战略。

管理层喜欢他们的指标。他们的想法是这样的：“我们需要一个数字来衡量我们的工作。数字可以让人们集中精力，帮助我们衡量成功。” 尽管出发点是好的，但用数字进行管理会无意中导致问题行为，并最终损害更广泛的项目和组织目标。指标本身并不是一件坏事；只是经常被不恰当地使用。本文论述了管理层传统使用指标所造成的许多问题，并提供了一种解决这些问题的方法。

这是我在慕尼黑 OOP 2014 大会上主题演讲的第二部分，这是一个难以描述的演讲。通常我喜欢用标题和摘要来描述演讲的内容，但这次演讲是一次旅程，我不想告诉你我要去哪里，而是想和你一起探索。我要说的是，它始于我对大多数敏捷软件开发采用方式的最大问题——用户、分析师和程序员之间交互的本质。它继续探讨了这些角色，提出了关于程序员与用户的关系、我们对用户的责任，以及我认为程序员需要面对的两大挑战的问题。

任何读过我文章的人都知道，我是演进式设计的坚定拥护者。尽管我对这种方法充满热情，但没有一种技术是完美的，我很乐意报告它的问题和成功之处。

想象一下招聘场景。有两个候选人都有几年的经验。在蓝色角落，我们有一位在您喜欢的设计风格方面拥有良好广泛设计技能的人（就我而言，这将是 DRY、明智地使用模式、TDD、沟通代码等，但实际列表并不重要——只是这是您喜欢的）。然而，她对你正在使用的特定平台技术一无所知。在红色角落，我们有一个人对这些问题知之甚少（或不感兴趣），但他非常了解你的平台——语言的边缘情况、可用的库、手指在工具上自然移动。假设他们其他方面都一样（除了像这样的思想实验外，这永远不会发生），而且你的团队没有任何这个候选人可以填补的空白。你会更喜欢哪一个？