及时地向顾客反馈他们的请求。因此，组织必须建立起让开发人员拥有一定的自由度向顾客响应的文化。但是我们不是说所有的需求控制都应该委托给开发人员来做。规则还是必须的。
(4)客户代表质量模式
如果你需要顾客的回答，但是没有顾客可以随时回答你的问题，那么在你的组织中建立一个客户代表角色。
因为他们会熟悉大部分的客户的问题，并且善于与顾客交流，客户支持人员通常在给予顾客帮助方面要比开发人员更有效。相应地，当顾客解析他们的需求时，他们的愿望需要跟别的顾客的请求、业务需要相协调。直接的、任意地访问开发人员 – 即使非常谨慎 – 也会导致混乱。
这是为什么极端的顾客参与模式 – 保持顾客在开发现场，通常不被推荐的一个原因。另外，这通常也是不实际的。但是如果顾客不能马上回答你的问题，你怎么能保持满足顾客的需要呢?你可以让某个人站在顾客那边。客户代表能接触各种真实顾客并能平衡和过滤他们的请求。他代表了一个单一的、连贯的顾客观点，因此开发人员不会同时被拖向很多不同的方向。
客户代表质量模式包括：与顾客交互观点和澄清问题是非常重要的。然而，顾客可能不是随时都在身边。对于开发人员来说，往往存在猜测顾客需求的诱惑。开发人员往往假设用户的行为与他们的设计一致。然而，往往总是有其他的应用软件的思考方式，某些可能会与开发人员的观点不吻合。
因此，在项目组中创建一个代表顾客的角色，给予这个角色像顾客一样考虑的权利和义务。像对待真正的顾客一样对待这个客户代表。
如果组织有用户体验工程师，他们是最好的顾客代表。他们的重点是在用户交互，但是开发界面也存在很多难点。
(5)架构师控制产品模式
如果一个产品有很长的生命周期，那么赋予架构师展望未来的权利，并作为架构风格的长期保持者。
每个产品都有外部和内部质量。系统不仅仅要满足顾客的需要，还要满足系统的开发人员和维护人员目前和将来的需要。内部质量也一样主要由组织的价值和文化来决定的。例如，我们都知道项目的好的设计和文档会在崇拜进度面前牺牲。当然，我们总是对自己承诺我们后面会回来修正问题，但是往往很少这样做。
重视内部系统质量的组织有着长远的视角。他们想公司成功 – 不仅仅是当前季度的成功，而是将来很多年的成功。他们为了后面的回报重视目前的投入。这显然要通过一个卓越的架构角色来实现，因为架构设计和维护一个系统架构都需要很高的内部质量。架构角色与项目组的利益相关方有着很强的沟通并且是系统的技术架构的主要引导力量。
这是架构控制产品模式的组成部分：
虽然产品是由某些个体设计的，一个项目必须努力让产品的设计优雅并且内聚性强。有些项目可能通过集中控制的方式来达到，但是这种控制被大部分开发组认为是专制的。一个人不能做所有的事情，没有一个人可以很好地预见未来。
而且，需要某种程度的架构远见。有些领域技术是通过开发组的范围来分布的，系统的观点 – 尤其是创建普通的对话框和机构的设计原则 – 通常会从这些与个体思想或小组相关联的概念性的整体得到益处。
因此，创建一个架构师角色作为一个为项目定义架构风格原则的体现，并且定义符合这种风格的广泛的领域专门技术。架构师角色应该建议并对开发人员角色产生影响并应该与他们紧密地沟通。架构师角色是开发组成员之间的主要桥梁。
架构师同样应该与顾客紧密联系。
(6)架构和实现模式
如果架构师呆在象牙塔里面，他与现实是脱节的，然而，某些人需要把高层次的观点与实际结合