本书讨论的是：在一家软件开发组织内，如何建立一套有效的软件架构实践。软件架构师，以及他们所归属的一个或多个架构团队，在某种意义上“拥有”这一实践——即他们定义、演进并维护架构。这些架构师也“拥有”团队运作所依赖的流程：如何跟踪工作、如何起草与评审变更提案、如何做决策、以及如何开展沟通。团队可能有意识、成体系地做这些事，也可能临时即兴地去做；无论哪种方式，都会形成一套成文或事实上的（de facto）流程，以此支撑架构的运作。
这些团队的规模、运作方式与正式化程度在不同组织间差异很大。四个人在车库里做下一个伟大产品，同样需要软件架构，但不需要另起一个“架构团队”、设专门角色或制定复杂的决策流程。他们完全可以把全公司（这四个人）都当成“架构团队”。（他们同时也可能是产品、工程、测试、运维与销售团队。）决策与沟通的方式，可能就是摘下耳机，和其他人简短同步一下。
在更大的组织里，数百乃至上千人可能在做同一个产品；跨相关产品组合的更大型工作，甚至可能涉及上万人。要实现规模化，组织首先会进行专业化分工，把人拆成聚焦特定学科的小团队；接着用组织结构、流程与工具把这些小团队重新编织起来，以提供必要的协同。对大型工程而言，支撑这一切所需的组织“内功”本身既是挑战，也是竞争优势。
在讲过“架构实践应如何运作”之后，本章转向“作为一门独立学科，它在更大组织中应如何编制”。正如不存在唯一最佳的组织结构，架构团队也没有唯一正确的模式。但有一组共通的关注点，每个组织都应加以考虑。
Specialization（专业化）
先从一个问题切入：架构是否应当成为组织内的专业化角色？ 我坚信，架构能力是打造优秀软件的必要前提；而在“如何命名、认可并融入这项能力”上，组织有一条连续谱可以选择。
在谱的一端，“软件架构师”是一个独立角色，担任者被期望在该领域专精：他们凭架构专业能力被聘用、被期望持续深化精进，并在合理范围内不被要求承担其他职责。
在另一端，组织认为所有软件工程岗位都需要多元技能组合。在这种组织里，软件架构不是一种专职，而是人人应具并会用的众多技能之一；同样地，人们也可能被期望掌握移动开发、云计算、数据库等领域的能力与知识。
两种做法各有利弊。通才模式的问题在于：在每一项具体工作里，个体很难与那些该领域的专才同台竞技——这正是专才存在的意义：为更深的理解与应用创造空间。
借用软件之外的例子：还记得前文提到的四人创业吗？谁来记账？难道四位写代码的人都要顺带管账？不是不可能，但也并不现实。即便在软件上他们是通才，软件本身就是专门领域；他们大概率会选择雇个会计，而不是自己硬上。
在软件领域内，专门化方向更是多如牛毛：移动、Web、服务、数据库、搜索、安全、机器学习……架构只是名单上的又一项。最终，每个团队都应就这些方向逐一考虑：需要专才吗？ 是否值得投入，取决于团队规模、产品领域及其他因素。
综合来看，是否需要专业化，主要受两点驱动：
其一，规模。 项目与组织越大，围绕特定职能进行组织的价值越高。到了某个拐点，单就架构工作量本身，架构就已经是一份全职工作。到那一步，若实施得当，采用专才模式会比继续分散责任更有效。
其二，产品起点。 并非所有产品在设计上都需要开疆拓土。若你是在一套成熟架构上做又一轮迭代、采用经验证的技术，即便项目很大，也可能并不需要太多架构性工作，因此也未必需要架构专才。例如对一款已有游戏做新变体：玩法微调与内容更新就能带来新意；做大量新架构只会让项目更贵。
相反，有些产品天生需要新的架构思考。比如智能手机刚出现时，没人真正知道最佳的移动应用架构为何。桌面应用的架构不合适，因为它们对应用生命周期的假设在移动场景下不成立；而早期功能机应用的架构也不合适，因为它们迎合了许多已不再存在的限制（如交互模型）。
因此，所需专业化程度取决于项目与环境。不需要大量架构工作的项目，没必要专设架构团队；但若因技术/平台变迁而开辟新领域，往往需要显著的架构投入，此时设立架构专职有助成功。
Structure（组织形态）
假设一家研发组织设立了架构专职。这可能是因为团队很大、分工细；也可能是因为系统在架构上挑战很大，需要引入对口专才。不管动因如何，问题来了：架构团队如何编制，放在组织的什么位置？
这同样是一条连续谱。一端是集中式架构团队，与其他职能相对分离；另一端是完全虚拟的架构团队——每位架构师都隶属（通常是跨职能）业务团队。你们应依据多种因素在其间找到最适点。
一个关键因素是组织规模。在小组织里，虚拟团队往往更顺畅，尤其是因为这类组织对专业化的需求较低。集中式团队会强化“只做架构”的倾向；若你希望架构师处理混合职责，就把他们嵌入承担这些职责的团队。组织结构应强化责任分配，而非与之背道而驰。
集中式团队也会带来自身的管理开销：需要管理者，而这位管理者（即便也是架构师）一旦团队成形，必然要分出时间处理非架构性的管理。在小组织里，完全可以把这部分收回到各小型跨职能团队的负责人，免去新增岗位；在大组织里，集中化反而能减轻其他管理者的负担。
把架构师分散嵌入组织的潜在副作用是：他们之间的沟通与自组织更难。与架构相关的跨团队工作容易被视作次于本团队目标。当然，对小团队或架构挑战不大的产品，这可能不是问题。
若架构师之间的横向沟通不足成了问题，可以叠加结构来平衡：最简单的方式是让架构师同时隶属一个“虚拟架构团队” 。即便是虚拟团队，也仍需一定程度的流程、沟通、例会、规划等；没有一点结构，很难产出。
若使用虚拟模式却迟迟运行不畅，可考虑转向更集中的模式。很多组织采取混合模式（hybrid） ：既保留一个集中架构团队，又在多学科团队中设置架构角色。其一大优势在于：集中团队中可以容纳那些跨域且重要、但个体架构师很难挤出时间去解决的议题。
混合模式的另一优势是：它能提高架构在组织内的“声音” 。当架构师嵌入多学科团队时，他们的声音往往要通过各自团队的链路层层传递，从而被稀释。这不是谁有意压低，而是这种组织风格的必然后果。
而有了集中式架构团队，其团队负责人可以在管理层讨论中代表架构发声，使架构的声音更清晰、更加一致。比如，架构负责人可能指出：若干工程团队在各自为政地解决类似的设计问题，并建议改为一致的架构路径。
更重要的是，架构负责人还要负责把组织层面的决策传达并解释给架构师们。这样，即便有一个独立的集中团队，也能反过来抑制“各自为政”的架构思维：首席架构要对齐组织目标与架构活动。
在这条连续谱的另一端，是完全集中化的架构团队。其最大优势也许在于：更容易规模化架构职能、配置行政与项目管理支持。像任何团队一样，这类支持有助工作按轨道推进，甚至加速。集中、合并的团队也更容易协调一致发声，对采用新/演进中架构的项目尤为宝贵。
图 9.1 展示了在产品研发组织内编制架构职能的三种方式。图中的 PO、E、A 分别表示 产品负责人（Product Owner） 、工程师（Engineer）与架构师（Architect） 。不同组织的头衔与人数会有所不同。
小结：
- 集中式模型：所有架构师向同一位领导汇报，再由其向组织领导汇报。架构团队内部联系更强，但与工程与其他职能的链接更松。
- 虚拟式模型：架构师不直接向架构负责人汇报（如果有此角色），而是向组织内其他领导汇报；架构负责人（若存在）与他们是虚线关系。
- 混合式模型：两者结合；部分架构师直线汇报给架构负责人，另一些留在工程团队中。
由于各组织结构千差万别，图 9.1 中其他团队仅作示意；成员被标注为产品负责人、工程师与架构师，但实际结构可能不同，并非规定动作。应当结合自身语境理解图示，而非生搬硬套。
无论选哪种模式，与工程等团队保持对齐与沟通都是成功的关键。集中模式下，架构师之间的沟通相对容易（同队伍内交流天然频繁）；此时领导层更需额外用心搭建架构—工程—其他职能之间的沟通通道。
混合模式下，还要防止把集中团队的架构师与嵌入工程团队的架构师割裂开来。可通过保持集中团队规模适中，并让部分产品线架构师参与集中团队的会议与沟通来缓解。换言之，尤其在混合模式下，集中架构团队的边界应是“可渗透的” 。
Substructure（子结构）
有些系统大到无论架构团队如何编制，单一团队都难以胜任。一个架构团队若超过十来人，往往就难以管理。一旦超过团队容量的上限，考虑把职责下放给聚焦特定领域的子团队。
子团队的划分应与系统的分解方式对齐。例如，一个子团队可以负责某个子系统、服务或应用的架构。正如第 5 章所述，组织结构最好与系统结构相匹配。
当子团队的职责边界清晰时，也更容易判断哪些变更归谁管。若某项变更只影响其职责范围内的组件与关系，那就由该子团队负责。
但若变更影响到更多组件或关系，就应上升到主架构团队来处理——避免由两个子团队直接对接推进这样的变更。因为这种“一对一”方式会让两个子团队倾向于做窄范围改动、力求不波及系统其他部分。我们当然不希望变更影响过广，但也要识别那些具有系统性意义的改动并作出相应处理——而这，正是主架构团队的职责所在。
Leadership（领导力）
团队结构的设计必须同时考虑现有的领导者与希望拥有的领导者。如果没有能胜任带队的人，建立集中式架构团队难有成效；反过来，若有一位强有力的架构领导者，却缺乏与之匹配的组织结构，他/她很可能有志难伸、徒增挫败。
前文提到，有些项目并不需要强势的架构领导——通常是因为它们在软件架构上并未开辟新天地。对这类团队而言，既不需要强势的架构领导者，也不需要集中式的架构团队。这样的情形确实存在，但不是本书关注的重点。
虚拟式架构团队需要一位能跨团队协作的领导者。许多资深架构师由于已形成自己对“如何开展架构工作”的观点，是这个角色的良好人选。由于他们没有直接下属，不必承担直接的人员管理职责——这在招募时反而是优势。当然，他们仍需与各所属团队中架构师的直线经理进行协调。
若要转向混合或集中模式，你需要一位能承担直接管理职责的架构领导者。具备此能力的领导者可能会觉得工作更简化：他们无需再与另一位可能设定不同目标、给出不同反馈的经理层层对齐。
在更大的组织中，某种层级不可避免。尽管理论上可以为架构团队另起体系，但为了解决规模问题，建议采用混合模式：让集中架构团队规模小到一位经理即可管理，同时让更多架构师嵌入工程团队。另起一套层级往往会削弱与工程的伙伴关系，而混合模式能强化这种伙伴关系。伙伴关系对于把设计落地实施与稳定运行至关重要。
在混合模式下，考虑淡化组织边界，把所有架构师都称为一个共同的“委员会（council） ”等。因为从组织角度看，部分架构师在集中团队内，部分不在；这可能让未在集中团队的架构师产生被排除感，并削弱两边合作的动力。采用如“委员会”这样的标签，既能对冲这些倾向，也能强调所有架构师团结协作的必要性。
同时要警惕：委员会不应沦为“审查官” 。一个只评审他人架构工作的集中委员会，并没有在“做架构”。并非否认评审有其作用——更好的评审实践前文已述——但把评审集中化容易制造瓶颈与争执，其收益往往小于其代价。
无论是集中式还是混合式，要在这一规模上领导架构，都需要架构能力、管理能力与领导力。此类角色通常称为首席架构师（Chief Architect） 、架构负责人（Head of Architecture）等。担任者应被视为产品领导团队的一员，与工程、产品等对应角色共同代表架构诉求。
本章余下内容将讨论构建并维持高效能架构团队的具体关注点与实践。如果你已聘请首席架构师，这些事项都在其职责范围内；若这些事项在你的组织中尚未有人负责，或许是该设立/招聘这一角色的时候了。
Responsibility（责任）
无论把架构师放在何处，专业化都伴随风险：若专家脱离实际约束，可能会提出不切实际的方案。比如你雇了一位数据库专家，他/她想从零设计一套新数据库——若你的产品本身就是数据库，这没问题；否则这很可能是个不明智的选择。
更隐蔽的风险是：架构师产出了看似合理的工作，却不对其实现负责。常见表现是：架构师完成某项变更的详细设计后就撒手不管，没有继续与工程、运维团队配合，护送该变更落地。
无论表现为何，“象牙塔式架构师”的标签不无道理：脱离产品开发现实的架构实践毫无价值。那些从未落地或在开发中被迫丢弃的设计，白白消耗了组织资源。
要对冲这种风险，必须要求架构师对其工作的实现与运营承担责任。交付详细设计并不是该变更工作的终点，而是起点的终点。直到上线一段时间后，并且可证实满足最初的目标与需求，变更才算真正完成/成功。
强调责任的好办法，是把这些阶段纳入变更流程的状态机。回想第 7 章的待办清单，可以新增“实施”“运营”等状态，并在这两阶段持续跟踪。不要在“开发完成/上线”时就关闭条目，而应等到有一定运营记录后再关。在此之前，责任架构师不得视该变更为已完成。
在存量项目上推行此法，相关架构师可能会觉得突如其来——这正说明他们把“责任的终点”放在了详细设计完成。通过调整预期、要求他们全流程持续参与，结果会更好。但别忘了：这需要他们投入此前未预留的时间与精力；你可能需要相应减少他们新架构工作的负载。
在这两个新增状态期间，架构师应持续与工程/运维对口人对齐。也许一切顺利，但更可能会学到新情况：实现是否困难/昂贵？是否需要调整或为下个变更沉淀经验？上线表现是否符合性能、规模、成本的运营预期？是否需要进一步调优？
一旦出现问题，处置必须有纪律，而非临时起意。让架构师全程参与不是为了跳过既有流程。若变更效果不佳，不要随手修；而应起草新的变更提案，按流程评审、排期并推进。它们可以是小改动，也可能紧急，因此优先级可相应提升，但仍须遵循流程，以避免决策失当、反复回滚与混乱。
你的设计流程也应考虑到这一点。第 7 章（速度）提到过：某项目的数据表明典型详细设计需要 4–6 周。但如果每个变更都要 4–6 周，我们就不可能在保持流程纪律的同时按时出货。当实施阶段出现问题时，必须能更快处理——在那个项目中，同一流程处理小改动时最快可当天周转，且不走捷径。
最后，考虑把实现与运营阶段的经验教训记录下来。并非每个变更都值得这样做，但对重大变更尤为有价值。前文已述：写下来能让其触达更广泛的受众。
归根结底，应对专业化风险的最佳方式不是回避专业化，而是强调：架构实践（如同产品开发的一切）是为产品交付服务的，而不是相反。若有人把产品当作其“架构思辨的游乐场”，那他/她就误解了角色。
Talent（人才）
无论你的架构团队大小、混合还是虚拟，其成功取决于成员的才能与技能。因此，识别与培养架构人才是关键任务。这应写入集中架构团队负责人的岗位职责。（在混合模式下，该负责人应对全组织的架构人才负责，而不仅是集中团队的成员。）若架构师嵌入小团队，这项职责可由更资深的架构师或组织领导层成员承担。
不论你的架构实践如何组织，明确承认这项实践及其运作方式，都有助于在组织内建立相应的职业发展路径。个人可以据此识别“架构”为兴趣方向并主动追求；或把它作为与想要晋升却不知路径的同事交流的起点。
理想情况下，“架构职业通道”应是众多选项之一——这正是专业化的意义：择其所长。倾向于图形、数据库或其他方向的人，也应看到这些是同样可行的道路。重点不在于各专长完全对等，而在于个人的才能与兴趣能与组织需求对齐。相反的糟糕结果是：有人选择架构专精，只是因为它看起来是最佳/唯一的晋升通道。
你的公司大概有人力资源团队；寻找与其合作的方式。许多 HR 团队会运营识别与培养人才的项目。架构师与架构通道理应与管理者通道等一并纳入讨论。
导师制（mentoring）也能帮助识别与培养人才，且常对导师与学员双方都有益。导师计划可以非正式，当然也可以正式化。无论形式如何，都应明确：架构师需要拿出一定比例的时间做指导/辅导，同时人人都能从做学员中受益。
架构师还应倡导并示范持续学习。我们工作中很多“真正会的东西”，不是在学校学到，而是靠多年实战经验积累而来。一些资深实践者把知识写成书分享出来。不读书就不去吸收这些简单、低成本的知识增益，是巨大的机会浪费。
当然，天赋固然重要，但若想真正成功——无论是软件架构还是其他任何领域——还必须配合勤奋努力。在识别与培养人才时，寻找那些渴望学习的人：既向导师学，也向书本与其他资源学，而不仅仅依赖个人经历。
Diversity（多样性）
一支强大的团队——无论是否架构团队——都应具备观点与经验的多样性。第 4 章中我们讨论过：在确定方向前，先为每个潜在变更提出**多种方案（变更提案）**的价值。这只是多样性带来更好结果的一个例子，绝非唯一。
与自然界不同，组织中的多样性并不会自然而然地出现。相反，人类的偏见容易造成同质化。在招聘架构师时，我们很自然会偏向那些“看起来像架构师”的候选人；若由架构师主导招聘，这种倾向可能进一步演化为偏爱与自己相像的人。
可惜，仅靠改进招聘流程并不能彻底解决问题。事实上，对某些岗位来说，连招到多元化候选人都很难——当对方根本不投递，你就无从录用。
因此，打造多元的软件架构职能需要长期主义。在招聘、面试与录用时考虑多样性；在识别与培养人才（见上一节）时考虑多样性；并通过营造友好、可进入的环境，鼓励具备相关技能与兴趣的人走进这个领域。
无论你当前团队的构成如何，都要记住：包容是让多样性繁荣的土壤。若一个多元团队的成员不敢/不愿发声（包括质疑现状），多样性的价值也难以体现。第 7 章中的许多实践之所以那样设计，正是为了提供多种参与方式，以此提升包容性。
Culture（文化）
当组织内的架构师开始连接起来（无论是虚拟、混合还是集中模式），他们会逐步形成团队文化并采纳一些规范。其中有些是小事——比如：邮件里用 emoji 可以吗？
更多规范会围绕更重要的话题形成。架构领导者既有责任也有机会将这些行为引导到最有利于产品开发组织的方向上。最好能在消极行为扎根前采取行动。
团队文化话题很广，本书前面已触及若干要点。例如，第 4 章的“开放式工作”某种意义上就是一种文化规范；第 7 章列出的实践也是如此：团队是严肃对待，还是觉得不方便就可以忽略？上一节所述的营造包容环境也同样是团队文化的重要方面。
除书中这些例子外，我还总结了五个最值得积极培育的团队文化要素：
- Teamwork（团队协作） ：我们一直在说“团队”，但“团队协作”仍需要强调。一个“团队”——尤其在虚拟或混合形态下——很容易只是共同工作的群体。关键在于运作方式：是各自为战，还是彼此支持与鼓励？当你建立起强协作文化，没人会孤军奋战：遇到难题，有人会搭把手；你需要离开一小时/一天/一周，有人会顶上；刚写完文档需要评审，队友会抽时间帮你看。在“群体”里，每个人只对自己的份额负责；在团队里，大家对共同目标负责，一起达成或失手。
- Humility（谦逊） ：没人全知全能、永不犯错。有人质疑你的观点或指出你的错误，并非在挑刺，而是在帮助你更好。团队亦然：团队也会犯错，必须有承认—纠正—前进的谦逊。前提是承认：我们永远可以学到更多、做得更好。
- Partnership（伙伴关系） ：如多次强调，软件架构为打造优秀产品服务，而非自我目的。成功需要与所有参与产品交付的人建立强伙伴关系——这通常是一大群人。第 10 章会展开讨论。
- Customer focus（客户导向） ：做出好产品的团队不会忘记：如果产品不能真正解决客户问题，就谈不上成功。客户需要的未必总是最炫/最新的设计，也未必是最便宜/最容易的方案。客户导向还能保持紧迫感：客户在意的不仅是是否解决，也在意何时解决。
- Rigor（严谨） ：架构工作包含许多环节：记录现状、提出变更、做决策、沟通协作……事务繁多而时间有限，走捷径很诱人，久而久之就会导致文档不全/不准 → 决策失误 → 失误与失败。最佳对策是在每个环节都要求严谨。起初会觉得慢，因为每步都更细致；但久而久之会更快：信息更准，决策更好，回滚更少，产品也会更好。
这些以及其他文化要素应相互强化。文化积极的团队产出最好、可预期性强，也更让人乐于加入与留在其中。
Gathering（相聚）
以我的经验，让一群人变成一支团队，共同相处的时间至关重要——若能同桌吃饭更是加倍有效。原因或许在于人类的本能社交，不必深究：有效即可。
附带好处是：在较为轻松的场合里共处一段时间，能加速许多架构团队的工作（第 8 章已论述对话之于沟通的重要性）。组队需要时间，共进餐需要时间，对话也需要时间。
把这些加总起来，你就有了充分的理由：把团队聚到一起。在组建新团队时这尤为有价值；即便对老团队，我也建议把它作为固定做法。即便一年只见一两次，也会有帮助；每次至少几天，甚至一周为宜。
这些聚会的话题会随时间演化：最初一两次可能聚焦构建共享概念与术语；随后，这部分会告一段落。但概念很少一成不变：产品在成长演进，就会带来新变化。任何规模可观的项目，在这些定期论坛里总会有新议题可谈。
若团队是分布式的，参会需要差旅——这反而是好事：请求大家抽身日常、专注会议上的交流，本就是我们的诉求；我们邀请大家不仅身体到场，也要精神在场。
若团队同城/同楼，也可通过更换场地来强调这种物理隔离感与专注：换个近处地点、或办公室里不常用的会议室，最好在不同楼层/楼栋。
Seminars and Summits（研讨与峰会）
上一节讨论的是单个架构团队规模的相聚，这或许已足够。但对拥有多个架构团队的大型组织，建议再加一些形式。
系列研讨（seminar series）是一种轻量但有效的跨团队沟通与协作机制。频率可从每周一次到每月一次不等，一小时通常足够。主讲人以团队内部为主，不时邀请外部嘉宾亦可。
研讨应当互动，因为对话空间才是促进跨团队连接的关键。因此，讲者不应准备塞满全程的材料。若能录制，这些视频也能成为系统文档的有益补充。
就像定期把单个团队聚到线下是有效的，对多个团队的更大型会议也同样奏效。多团队峰会需要更多时间、精力，甚至较大的预算；一年一两次通常是合适的节奏。
一场高质量峰会的议程以2–3 天为宜，聚焦广泛适用的话题——不是深入狭窄议题的时机（那可以另开会）。同时要安排用餐交流、长休息、日终社交等环节，促进人际连接。
Summary（小结）
在产品研发组织中，组织架构实践的方式多种多样。最合适的方案取决于团队规模、项目性质等因素——团队可以是虚拟式、混合式或集中式，组织应选择最贴合需求的模式。
无论结构如何选择，都要努力把架构师真正编织成团队。当他们成为团队而非松散群体时，会相互支持、发挥最佳水平。强健的架构团队会对实现与运营全过程负责；如此，即便是虚拟团队，也能成为工程等职能的强力伙伴。
培育架构团队，管理者并不陌生：识别并培养人才；以多样性提升团队与变更实践的质量；打造强调团队协作、谦逊、伙伴关系、客户导向与严谨的团队文化，让每个人都朝着正确方向发力。
还要为持续对话留出空间：线下相聚、专题讨论、定期碰头，用来承载那些重要但不紧急的话题。在大型组织中，跨产品的研讨与峰会有助于形成架构共同体。
首席架构师（Chief Architect）这一角色囊括了运行成功架构团队所需的架构、管理与领导能力。项目越大，这一角色对建立高效架构实践就越关键。
