起来。因此，要确保架构师参与到每天的实现过程中来。
架构是抽象的活动，但是架构需要具体的实现。如果架构与系统的具体实现方面脱节的话，架构是不容易被实现的。而这些会使架构师的所有好的工作失效。因此，架构师的观点必须与实现融合。最简单、最好的方式是让架构师写代码。不应该很多 – 毕竟，架构师有很多其它的责任 – 但是必须足以让架构师明白自己的实现环境。
架构和实现模式包括：
软件项目必须是在不牺牲实用的深度和对实用性的注意的前提下放宽领导范围。
虽然开发人员在单独的设计和实现决定方面很在行，但是一个项目需要总体的、指导性的、策略性的、技术性的指引。指引通常来自架构师。然而，很多软件架构师限于思考和对抽象概念的说明，而抽象是忽略无知的正式形式之一。
因此，除了建议、指导和与开发人员沟通外，架构师还应该参与到实现中来。
架构师应该有组织地参与到开发中来并编写代码。架构师可能与一个开发人员一起实现某个模块，通过结对编程的开发方式。
(7)代码拥有者模式
如果你需要在角色中内建对代码的责任以及领域知识，那么给大家以代码的整体质量的责任。
以所拥有的为骄傲会导致更高的质量。这在软件开发中也是成立的。在专注于质量的组织，人们对所负责的系统而自豪。实际上，大部分软件对于一个专家来说太大了，因此对代码的拥有分布于员工之间。作为代码的拥有者，你对代码非常了解，能帮助别人理解它，并最终对它的质量负责。当然，你不需要管理所有附加的代码或对代码的修改;事实上，这通常是大家不愿意的。但是你是确保这些代码不会引起重大系统问题的人。
代码责任制与其它领域的责任制是一样的。在我们搬家的时候，我的妻子紧紧地盯着搬运工打包她的精致的瓷器。为了缓解她的神经，搬运工对她承诺她的瓷器会完好无损地到达新家。为了证明他对安全打包的责任，他封好箱子后，清楚地在上面签上他的名字以保证不会损坏。就像你能想象到的，那些瓷器完好无损地到达了新家。
代码拥有模式可以解读为：
如果那是每个人的责任，那么结果是每个人都不会负责。
不是每个人在任何时候都知道所有的东西。即使是架构师也不能熟练地清楚项目的所有方方面面。
因此，系统的每一个模块都由其中一位开发人员拥有。
注意拥有意味着对质量的责任以及对这个模块的整体架构设计，从而鼓励拥有者要获得对模块的深入理解。
(8)质量：在于意识的改变
这些是我们在组织中看到的一些能产生高质量软件的模式。还有其他的模式。
也许你已经在你的组织中看到这些模式的核心价值。希望你的组织仅仅拥戴质量而不仅仅是口头上赞成。文化的元素 – 组织中的角色、沟通、仪式、传统、语言 – 会给你一些线索。
大部分组织支持改进和改变，而改进是健康组织的组成部分。但是重大的、动摇核心价值的改变通常是不成功的。大部分核心文化的改变包括艰难的价值转移。这通常需要长期的或者遇到危机导致对价值的深深反省才能成功。如果你的组织是这样的，那么要做好失败的准备。
但是不要失望。有些企业使用有组织性的模式和有组织的学习来形成文化的转变。从小的开始;不要尝试一下子改变太多东西。所有这些价值之间的影响可以是丰富的和复杂的。经过一段时间，你会学到什么是有效的什么是无效的。当面对价值和文化时，质量只是很多价值驱动因素之一。如果你改变你自己的角色、沟通或仪式，改变会在其他的价值方面得到反映。毕竟，没有什么价值是孤立的。