Roadmap Studio¶
每一个企业架构职能都会被自己的 CIO 问到同样的两个问题：三年后我们的架构版图会是什么样子， 以及如果我们做出不同的选择会怎样？ 幻灯片对第一个问题回答得很糟，对第二个问题则根本无法回答 ——它们在指导委员会开完会的第二周就过时了，而且两份幻灯片之间无法比较。
Roadmap Studio 用你已经在维护的清单来回答这两个问题。一个方案就是叠加在你活的架构版图之上的 一份计划——淘汰这个、在这个日期替换那个、增加三样尚不存在的东西——它保存为一组变更，而不是你那张图的 副本。在方案获得批准并应用之前，你所探索的一切都不会触碰你的清单；而由于计划始终是对照清单今天的内容 来读取的，它绝不会悄无声息地偏离现实。
概览¶
| 许可 | 商业版 —— 需要签名授权 |
| 最低 Turbo EA 版本 | 2.119.0 |
| 权限 | ext.roadmap-studio.view、.manage、.apply、.admin |
| 数据访问授权 | 卡片（读 + 写）、卡片事件、待办（读 + 写）、用户目录、决策记录 |
| 是否需要重启后端 | 是 —— 该扩展包含后端代码 |
| 出现位置 | 主导航中的 Roadmap · 卡片详情页上的一个标记 · 决策页上的一个面板与导出章节 |
变革项目与方案¶
一个变革项目是一组相互竞争的计划所属的项目，例如「ERP 现代化」，它指明该项目所要回应的 目标。其下是方案：对同一个问题的不同答案。其中之一可以标为 推荐方案，让会议室里的人在读数字之前就知道架构师的主张。
不属于任何变革项目的方案完全有效，只是它没有需要与之权衡的备选方案而已。
规划清单与路线图¶
路线图把计划画成泳道中带日期的条形，下方的成本条逐年显示运行成本——包括并行运行期间的 成本隆起，而这恰恰是迁移商业论证往往会隐去的那个数字。
规划清单是同一份计划的表格形式：你的现有卡片加上计划中的卡片，以及针对它们的每一项变更。 计划中的卡片只存在于方案内部，绝不会进入你的主清单。
如果某项变更的目标卡片此后被归档、移动，或在别处改了日期，该变更会被标记为过时并注明原因—— 这样一份三个月前写下的计划就能告诉你，它脚下有什么已经变了。
里程平台与架构切片¶
由于每项变更都带有日期，任意时刻的架构不过是该方案在那个日期上的求值结果。把重要的时刻命名为 里程平台——「T1 · 核心整合，2027 年第三季度」——然后逐个走过去：路线图、依赖视图和数字会一同变化。
比较方案¶
比较把每个方案与「什么都不做」的基线并排放在一起：目标年份的运行成本、转型支出、卡片数量和 生命周期终止风险敞口，每份计划的利与弊就写在它的数字旁边。还可以设置可选的折现率作用于未来年份。
计划与卡片的交汇处¶
打开清单中的任意一张卡片，一个标记会告诉你哪些计划提到了它、以及是如何提到的——作为将被淘汰的对象、 作为替换中的后继者，或作为某个计划要挂到新父节点下的卡片。
评审、决策与应用¶
这是治理路径，它把三件真正不同的事分开：建议、决策和写入。
1 · 请求评审¶
请求评审指名你想听取意见的人，并为每个人建立一条真实的待办，使其出现在他们的待办页面和 通知铃中。选择器覆盖整个用户目录——评审者就是能在这份计划上帮上忙的人：这一份找安全架构师， 那一份找财务伙伴。
每位评审者在应用中以认可、要求修改或评论作答，并附上说明。他们的回答是建议， 不决定任何事情——这正是它们不再使用「批准」和「否决」这两个词的原因。
2 · 展开讨论¶
任何能读到计划的人都可以在它的讨论中发言。这条讨论线按事情发生的顺序承载完整经过：评论、 每一次评审回复（不只是最后一次），以及之后的提交与投票。委员会读到的是评审者当时的同一场对话， 而不是一个没有论据支撑的结论。
3 · 提交给评审委员会¶
评审委员会是一组具名成员，挂在某个变革项目下（见下文）。当一份计划有委员会时， 提交决策会把它送过去：
- 状态变为等待决策，计划内容被锁定，让所有人对同一份文档投票；
- 每位成员都会收到一条对……作出决策的待办，并附带常规的指派通知；
- 你在这里选择批准后是否要归档决策记录并创建举措——在提交时就决定，好让投票的人 看清自己的赞成票会创建什么。
批准闸门（管理 → 设置，见下文）可以在评审者答复之前，把计划挡在委员会之外。
4 · 委员会投票¶
每位成员投赞成、反对或弃权，可附说明，并且只要本轮仍开放就可以改票。对话框会显示 计票结果、还差几票赞成，以及每位成员说了什么。
一旦委员会的决策规则已成定局，本轮即告结束：
| 规则 | 何时通过 | 何时否决 |
|---|---|---|
| 多数（默认） | 超过半数赞成 | 反对的人数已多到不可能形成多数 |
| 全体一致 | 全体成员赞成 | 有成员反对或弃权 |
| 任一成员 | 有一名成员赞成 | 全体已投票且无人赞成 |
只要通过在算术上已不可能，否决就立即成立，而不必等所有人对一个已成定局的问题投完票。
有投票权的依据是委员会成员身份，并不需要 ext.roadmap-studio.apply。计划的作者可以就
自己的计划投票；对话框会明确说明这一点，记录也会写明谁投了票。
撤回可在委员会作出决定之前把计划收回。作者、提交者以及任何成员都可以这样做—— 一个希望计划被返工的委员会，不该为了提出这个要求而不得不否决它。成员的待办会被删除， 而不是标记为已完成，计划回到评审状态。
5 · 批准会做什么¶
那张决定性的一票会一次完成所有事：同一变革项目中相互竞争的方案被否决，计划被锁定， 未结的请求被了结，举措被创建（变革项目对应一个项目集，每个里程平台对应一个项目）， 并在EA 交付 → 决策中归档一份决策记录草稿，写明委员会、其规则、 计票结果、每一票及其说明、目标、里程平台、相对「什么都不做」的各项数字，以及每一个被否决的备选方案。 随后系统会向投了赞成票的成员请求签署。
已批准的计划为只读，直到持有 ext.roadmap-studio.apply 的人重新打开它——这会清除该批准。
6 · 应用¶
应用会把计划写入你活的清单，需要 ext.roadmap-studio.apply。这是一个独立的动作，往往在
决策数月之后才发生。每一次写入都经过带审计的批处理机制，因此会出现在管理 → 审计日志中并可回滚。
持有 .manage 的用户可以只读方式打开同一份计划，检查它是否能顺利落地。
没有评审委员会的方案¶
不属于任何变革项目的方案，或其变革项目没有委员会的方案，保留更简单的路径：由持有
ext.roadmap-studio.apply 的人直接批准。没有治理机构可召集的小团队，不必凭空造一个出来。
评审委员会¶
委员会在一处集中管理：Roadmap 页面内的设置 → 治理 → 管理评审委员会（需要
ext.roadmap-studio.admin）。一个委员会有名称、描述、最多 25 名成员和一条决策规则。
可以从任意一侧把它关联到一个或多个变革项目。
删除委员会只会解除它所评审的变革项目的关联，绝不会删除这些项目，也绝不会触碰它过去所作决定的记录。
设置与历史¶
Roadmap 页面的设置标签页（需要 ext.roadmap-studio.admin）包含：
| 设置 | 作用 |
|---|---|
| 成本模型 | 哪个属性保存卡片的年度运行成本、指标统计哪些卡片类型、生命周期终止风险敞口向前看多久，以及可选的折现率 |
| 批准闸门 | 评审者的回答是否把计划挡在委员会之前：从不、在有人要求修改时、或直到所有评审者都已答复 |
| 评审委员会 | 打开委员会对话框 |
历史卡片是一份完整的活动台账——每一份计划、卡片、变更、里程平台、评审请求、回复、提交、 投票、评论和决策，都记录了是谁做的以及改了什么。
演示模式与幻灯片¶
演示模式带着会议室逐个里程平台走完计划，导出的 PowerPoint 也完全遵循你刚才走过的顺序。
演示数据¶
在设置中点击一次，即可载入一套完整的示例架构版图和两个相互竞争的方案，让你在录入自己的数据之前 先试用全部功能。再点一次即可清除全部痕迹。
权限¶
| 权限 | 授予 |
|---|---|
ext.roadmap-studio.view |
查看方案、比较、里程平台、讨论与决策 |
ext.roadmap-studio.manage |
创建和编辑计划、请求评审、提交决策、撤回 |
ext.roadmap-studio.apply |
把已批准的计划应用到活的清单、重新打开它，以及批准没有评审委员会的计划 |
ext.roadmap-studio.admin |
设置、评审委员会与演示数据 |
投票不是一项权限：它来自对该计划作出决策的委员会成员身份，外加打开计划所需的
ext.roadmap-studio.view。任何拥有 .view 的人都可以在讨论中发言。
如果许可到期或扩展被停用¶
Roadmap 页面及其 API 会消失，但不会删除任何内容——方案、计划、投票和讨论都保留在扩展自己的 数据表中。扩展在你清单中创建的卡片是普通卡片，不受影响。应用续期后的许可即可恢复全部内容。
说明与限制¶
- 在同一个变革项目内，一次只有一份计划会送交委员会。
- 没有主席，也没有加权投票。 每一票只计一次，也不存在决定性的一票。
- 没有催办提醒。 一轮投票会一直开放，直到规则将其决定，或有人撤回。
- 计划作者可以就自己的计划投票。 这是有意为之：如果一个小型委员会的架构师不能投票， 它将无法作出任何决定，而且每一票都会在记录中具名。
- 该扩展包含后端代码，因此安装或更新时需要一次性重启后端。届时 Turbo EA 会显示提示横幅。