Software Architecture Organizational Principles and Patterns
软件架构组织原则与模式的摘要和笔记
谁才是架构师？怎样做好架构？
软件架构的主要障碍往往在于组织方面而非技术。创造切实可行的软件架构需要对技术的深入把握、良好的认知能力和沟通技巧以及大量艰苦的工作。然而，软件架 构的成功并非只是技术和优秀工程师的事情，它的成功往往依赖于高级经理、主管和实施者（此处指架构的实施者，可以理解为产品开发者，即使用架构进行开发， 实现架构价值的人）所忽略的组织因素。技术上出色的架构往往由于没有全面的处理好组织因素而失败。
VRAPS (Vision, Rhythm, Anticipation, Partnering, and Simplification) Reference Model
VRAPS模型的核心包括构想、节奏、预见、协作、简化5项原则。模型的重点在实现和发展软件架构的组织方面。
构想
可以把构想理解为愿景、蓝图，架构构想指对架构价值的勾画，实际中往往表现为对架构主体功能、某方面特性的描述、期望等。
架构师：架构师的职责就是分析构想，设计实现构想。"作为一名架构师，更多的意味着如何平衡 业务、组织运作和技术，而不仅仅是技术细节"，架构师更像管理者而非实施者。架构师对外必须关注产品开发人员和最终客户的世界，同时又对内关注架构和业务 团体的领域。
构想面临的挑战：并非所有拥有架构师头衔的人都对架构有实质上的影响，可能需要在一个组织内找上一番，才能发现究竟是谁担当了“架构构想看护人”的角色， 可能是创业软件公司的CEO，或者产品/产品线经理、高级经理、一群高级开发人员等。许多因素影响架构构想的一致性（不存在冲突），其中一些因素是架构师 所能控制的，而其它许多对确保架构构想成功非常关键的因素则超出了架构师的影响能力和范围。
当架构师与构想的发起人，或者构想的多个发起人之间发生分歧时，说明构想是不稳定的。
准则1：确保构想与发起人、用户（指架构的用户，即产品开发者）和最终客户（最终产品的客户）期望实现的目标保持一致
1. 反模式 反重力装置 Antigravity Module
因各方面原因去实现那些看似很好却无法实现的功能特性。例如反重力装置，能够实现当然很好，却要打破物理定律才能实现。
2. 模式 前端符合 Front-End Alignment
处理如何正确的为架构添加新功能特性，尤其对于那些较为激进的目标。
准则2：实施人员（架构的使用者，即产品开发人员，以及产品的最终客户）信任并使用架构。
1. 反模式 潮流追随者 Trend Surfer
追随潮流会侵蚀架构的结构并搅乱构想。如果组织的所有部门（如高层经理、销售、市场、客服、设计部等等）对构想、产品发展方向没有达成基本的共识，都会支 配或影响组织的行为。市场的新技术、竞争对手的新功能、客户的新需求等都会驱使架构朝不同方向发展。
2. 模式 建设性构想 Generative Vision
如何为架构勾画建设性构想。要抵制创建一个无所不能的架构的诱惑。规划者应该把自己的构想更多的限定在功能或业务需求方面，而让架构师关心实现问题（既包 括技术实现方面，也包括业务设计方面）。架构师不能轻信高级经理在实现意见上的看法，应该更加关注高级经理想要得到什么。
准则3：架构潜在知识的传播
优秀的架构可能被很不恰当的使用而问题重重，一般的架构也可能被使用的很好。关键在于需要让架构的使用者明确架构的思想（潜在知识），引导使用者正确的按 照这种思想来使用。
1. 反模式 惟命是从 Following Orders
指团队成员只把精力专注在自己的任务和职责上，不原意作为架构思想的传播者，不考虑自己的成果他人是如何使用的。
2. 模式 轮转工作 Rotation
关键要实现螺旋式上升而非平面环的工作轮转。作用：避免地方保护主义者的离开造成的空缺以及潜在知识的丢失；改善潜在知识的传播；提升团队成员能力。负 面：新的具有挑战性的工作可能给部分人造成压力、威胁感；工作轮转的成本代价；空降兵从螺旋的中间插入，可能引起老员工的不满等等。
节奏
在速度（进度）、内容（包含的功能特性）、质量之间平衡，维持一种正常的节奏。打破这个平衡就意味着不正常，可能造成一系列交叉影响的风险变成现实。侠义 的理解可以是一系列主发布、次发布、缺陷修改等活动。
准则1：经理们定期的再评估、同步和调整架构
1. 反模式 杀手特性 Killer Feature
指管理层认为至关重要的一些功能特性。它打破正常的节奏，使各方的关注点高度集中在这上面，开发团队疲于应对，甚至可能影响架构发展方向。慌乱的应付经常 导致诸多问题的出现。杀手特性可以添加到架构中，但要做详尽的评估分析论证，不要打破既定的节奏。
2. 模式 发布委员会 Release Committee
从各团队挑选人选成立，定期的为节奏中的各个Release评估风险，制定解决方案。 避免成为争吵、发牢骚的会议。
变体：发布代表委员会。当发布委员会成员比较多，分歧又比较大时，定期的会议必将成为争吵的焦点。这时可以从发布委员会中抽取代表成立发布代表委员会，代 替发布委员会，这样某些分歧可以让代表先在内部评估，达成一致。
准则2：架构团队对架构Release的进度和内容具有高度信心
1. 反模式 短路 Shortcut
指架构团队感觉无法维持节奏时，在流程上做裁减以求弥补，容易造成将一些问题遗留到后续阶段才暴露出来，增加修正成本。
2. 模式 弃球前进 Drop Pass
抱着橄榄球会影响奔跑速度，而前方又无自己队员，此时可以将球丢给后方队友放手狂奔。有的时候为了不影响其它团队，可能确实需要放弃某些功能特性、缺陷修 补，而按照节奏进行Release。
准则3：通过节奏协调明确的活动
1. 反模式 破裂加载 Broken Loads
例如在整合前夕各个要整合的部分都存在不少问题，破裂加载是节奏已经被破坏的信号。将存在问题的各个部分整合起来，比预期的代价要大。例如Daily Build，偶尔失败可能不是一件大事，但如果反复出现就是一个必须解决的问题。
2. 模式 同步发布 Synchronize Releases
在各个协作部分之间保证、加速Release的措施。
...未完
谁才是架构师？怎样做好架构？
软件架构的主要障碍往往在于组织方面而非技术。创造切实可行的软件架构需要对技术的深入把握、良好的认知能力和沟通技巧以及大量艰苦的工作。然而，软件架 构的成功并非只是技术和优秀工程师的事情，它的成功往往依赖于高级经理、主管和实施者（此处指架构的实施者，可以理解为产品开发者，即使用架构进行开发， 实现架构价值的人）所忽略的组织因素。技术上出色的架构往往由于没有全面的处理好组织因素而失败。
VRAPS (Vision, Rhythm, Anticipation, Partnering, and Simplification) Reference Model
VRAPS模型的核心包括构想、节奏、预见、协作、简化5项原则。模型的重点在实现和发展软件架构的组织方面。
构想
可以把构想理解为愿景、蓝图，架构构想指对架构价值的勾画，实际中往往表现为对架构主体功能、某方面特性的描述、期望等。
架构师：架构师的职责就是分析构想，设计实现构想。"作为一名架构师，更多的意味着如何平衡 业务、组织运作和技术，而不仅仅是技术细节"，架构师更像管理者而非实施者。架构师对外必须关注产品开发人员和最终客户的世界，同时又对内关注架构和业务 团体的领域。
构想面临的挑战：并非所有拥有架构师头衔的人都对架构有实质上的影响，可能需要在一个组织内找上一番，才能发现究竟是谁担当了“架构构想看护人”的角色， 可能是创业软件公司的CEO，或者产品/产品线经理、高级经理、一群高级开发人员等。许多因素影响架构构想的一致性（不存在冲突），其中一些因素是架构师 所能控制的，而其它许多对确保架构构想成功非常关键的因素则超出了架构师的影响能力和范围。
当架构师与构想的发起人，或者构想的多个发起人之间发生分歧时，说明构想是不稳定的。
准则1：确保构想与发起人、用户（指架构的用户，即产品开发者）和最终客户（最终产品的客户）期望实现的目标保持一致
1. 反模式 反重力装置 Antigravity Module
因各方面原因去实现那些看似很好却无法实现的功能特性。例如反重力装置，能够实现当然很好，却要打破物理定律才能实现。
2. 模式 前端符合 Front-End Alignment
处理如何正确的为架构添加新功能特性，尤其对于那些较为激进的目标。
准则2：实施人员（架构的使用者，即产品开发人员，以及产品的最终客户）信任并使用架构。
1. 反模式 潮流追随者 Trend Surfer
追随潮流会侵蚀架构的结构并搅乱构想。如果组织的所有部门（如高层经理、销售、市场、客服、设计部等等）对构想、产品发展方向没有达成基本的共识，都会支 配或影响组织的行为。市场的新技术、竞争对手的新功能、客户的新需求等都会驱使架构朝不同方向发展。
2. 模式 建设性构想 Generative Vision
如何为架构勾画建设性构想。要抵制创建一个无所不能的架构的诱惑。规划者应该把自己的构想更多的限定在功能或业务需求方面，而让架构师关心实现问题（既包 括技术实现方面，也包括业务设计方面）。架构师不能轻信高级经理在实现意见上的看法，应该更加关注高级经理想要得到什么。
准则3：架构潜在知识的传播
优秀的架构可能被很不恰当的使用而问题重重，一般的架构也可能被使用的很好。关键在于需要让架构的使用者明确架构的思想（潜在知识），引导使用者正确的按 照这种思想来使用。
1. 反模式 惟命是从 Following Orders
指团队成员只把精力专注在自己的任务和职责上，不原意作为架构思想的传播者，不考虑自己的成果他人是如何使用的。
2. 模式 轮转工作 Rotation
关键要实现螺旋式上升而非平面环的工作轮转。作用：避免地方保护主义者的离开造成的空缺以及潜在知识的丢失；改善潜在知识的传播；提升团队成员能力。负 面：新的具有挑战性的工作可能给部分人造成压力、威胁感；工作轮转的成本代价；空降兵从螺旋的中间插入，可能引起老员工的不满等等。
节奏
在速度（进度）、内容（包含的功能特性）、质量之间平衡，维持一种正常的节奏。打破这个平衡就意味着不正常，可能造成一系列交叉影响的风险变成现实。侠义 的理解可以是一系列主发布、次发布、缺陷修改等活动。
准则1：经理们定期的再评估、同步和调整架构
1. 反模式 杀手特性 Killer Feature
指管理层认为至关重要的一些功能特性。它打破正常的节奏，使各方的关注点高度集中在这上面，开发团队疲于应对，甚至可能影响架构发展方向。慌乱的应付经常 导致诸多问题的出现。杀手特性可以添加到架构中，但要做详尽的评估分析论证，不要打破既定的节奏。
2. 模式 发布委员会 Release Committee
从各团队挑选人选成立，定期的为节奏中的各个Release评估风险，制定解决方案。 避免成为争吵、发牢骚的会议。
变体：发布代表委员会。当发布委员会成员比较多，分歧又比较大时，定期的会议必将成为争吵的焦点。这时可以从发布委员会中抽取代表成立发布代表委员会，代 替发布委员会，这样某些分歧可以让代表先在内部评估，达成一致。
准则2：架构团队对架构Release的进度和内容具有高度信心
1. 反模式 短路 Shortcut
指架构团队感觉无法维持节奏时，在流程上做裁减以求弥补，容易造成将一些问题遗留到后续阶段才暴露出来，增加修正成本。
2. 模式 弃球前进 Drop Pass
抱着橄榄球会影响奔跑速度，而前方又无自己队员，此时可以将球丢给后方队友放手狂奔。有的时候为了不影响其它团队，可能确实需要放弃某些功能特性、缺陷修 补，而按照节奏进行Release。
准则3：通过节奏协调明确的活动
1. 反模式 破裂加载 Broken Loads
例如在整合前夕各个要整合的部分都存在不少问题，破裂加载是节奏已经被破坏的信号。将存在问题的各个部分整合起来，比预期的代价要大。例如Daily Build，偶尔失败可能不是一件大事，但如果反复出现就是一个必须解决的问题。
2. 模式 同步发布 Synchronize Releases
在各个协作部分之间保证、加速Release的措施。
...未完
