上个模块学完架构师生存法则之后，本节课来学习组织架构活动。
面临的挑战：敏捷为主，可能 会短期的技术债。构成了主要技术挑战。我们需要帮助团队抵抗反射式的研发行为、独立决策的研发模式、分散的研发团队、普遍存在的沟通障碍和认知差异，以及高风险、高工作强度和高复杂度的场景，最终保障架构活动以高确定性完成目标。
架构师起得作用：
大部分时间用来写代码、项目管理、培训 交流。这些可以有专业人员替代，不能替代的 有：建设共识，控制风险，保障交付，沉淀知识。
建设共识：
不是简单的投票。关键是寻找参与方的认知的差异点，想办法消除。
利益差异最难解决，要有全局视角跟局部视角，理解参与者的核心利益诉求，在一个 相对公平可以长期维持的机制下做利益的划分。有差异情况达成共识也要解决对方的疑惑。建设共识是个体力活，功夫再平时，而不是架构活动开始的时候。
控制风险：
发现、评估风险，制定预案，及时汇报 。因为竞争的存在，通常不会有足够的时间去量化风险跟你设计预案。考虑好风险的判断与价值回报，风险判断是一项非常有价值的个人能力。
保障交付：
降低不确定性：目标的不确定性，资源的不确定性、商业与技术的不确定性。
郭老师举了很多对应措施：分期交付，分阶段、垂直拆分、问题从宏观的领域模型到库表、粒度越来越细。最小化架构方案，最小化对上层模块的冲击。
沉淀知识：
这是 主动思考的过程，通过关键流程、公式、决策逻辑等梳理清晰，反复验证。逻辑推演的成本远低于实际全面铺开发现成本低的多。这是一个主动的、通过文档驱动的思想实验。
架构活动关键节点
下面是架构师视角下的架构活动生命周期：
搭建架构环境、目标确认、可行性探索、架构 规划、项目启动、阶段交付、全面上线、复盘。
这是郭老师认为的 一套通用模版，先固化，再内化，最后才是优化。
业务背景：偏互联网的电商
1 搭建环境
郭老师反复强调了行王道的办法，而不是霸道的。搭建安全高效的决策环境，而不是靠非常规的激励环境 、资源环境 。
使命、愿景、价值观都是相关的基础条件。
决策依赖机制，不是靠单人的判断，机制有问题，可以去迭代，保障决策环境安全。背后的 理念：尊重规则而不是 权威。
公司环境资源是有限的，激励、资源、人员、工作空间 。如何获取稀缺 的资源：获取架构活动的最小必须资源，描述架构活动产生的价值，分析投入产出。
2 目标确认
这是架构师能做的最大贡献的环节，通常架构师没有定义目标的权力，但是有权力对目标进行验证。保障目标的正确性、合理性、可达性。通常目标开始是模糊的，变成 具体的可量化的需要一个过程，需要尊重数据 、尊重事实、尊重原则，这是多个职能之间反复讨论和推演得到的，是一个发现的过程，不是拍脑袋的过程。
这里也有3个角色，赞助者、执行者 、决策者。
这个节点的重要价值在于帮助企业选择去做正确的事情，同时也帮助企业放弃不正确的事情。其中行王道的做法就是站在决策者的角色上思考问题，为公司做正确的决策（符合决策者的战略期望），让执行者做有挑战和有成就感的项目（大坑填平了，风险 可控），也让赞助者的投资最终变成有价值的回报。
3 可行性探索
架构师需要在最短时间内发现最重大的风险，并对风险发生时的响应预案做出判断。
风险相关概念：
1.风险有多大？2.回报是什么？3.公司对风险承受度有多大？4.其他的选项的风险和回报是什么？
调研准备工作：
包括调查企业对风险的态度，赞助者对风险的承受度，锁定可以提供决策帮助的领域专家。
之前两个 环节，一个是搭建架构环境，目标是建设一个安全的决策环境。另一个是目标确认，目标是帮助你锁定架构活动的目标是否正确、合理和可达。这是非常轻量的节点，除了你之外，公司还没有投入任何研发资源，消耗代价相对较小。
风险发掘的视角：项目交付 （在时间和人力的限制条件下，看看执行过程中是否存在重大风险。）商业价值、人性、资源。
那么如何在最短时间内发现最大的风险呢？一方面要靠自己的判断，另一方面则要靠自己的关系网络领域 专家。去访谈，把项目背景和情况描述出来，然后认真听取他的意见反馈。整理好之后，再带着这些答案，与风险决策建议者一起碰撞。
方案选择也要估算预案实施的成本：
1.总时间成本。2.总人力成本。3.总资金成本。4.效果折损（商业价值），5 用户体验。
风险沟通
不仅本身要持续关注，还要确保想管你执行者也在持续关注。
完成可行性探索：决策
收集到的重大风险、相应预案、参与者风险的承受度以及你所作出的建议，完整地表达出来。 你需要给出一个可行或者不可行的总建议。
拿到了上面的输入，比如最终对架构活动是否可行的判断，对风险承受度的矫正，对预案的改进建议，以及对架构目标和交付时间的调整。整理出架构文档，分享给团队成员，有助于提升整个架构 活动的成功概率。
