字数 10421，阅读大约需 53 分钟
第2-11讲：应用系统规划与TOGAF（下）——从蓝图到现实
本讲是TOGAF的闭环，是连接规划与落地的桥梁，内容极度实战，请务必跟随我的节奏，完成从“总设计师”到“总指挥”的终极转变）
一、 上节回顾与热身
同学们，我是老孙。在我们开始学习如何将宏伟的“城市蓝图”付诸实施之前，我们必须确保蓝图本身的质量是过硬的。
上节课，我们一起学习了TOGAF ADM循环中最核心的B、C、D三个阶段，我们学会了如何将虚无缥缈的“架构愿景”，一步步地落实为四份具体的、看得见摸得着的“施工蓝图”：
- • 阶段B (业务架构)： 规划“城市功能与主干道”，明确我们未来理想的业务流程是怎样的。这是所有架构的龙头。
- • 阶段C (信息系统架构)： 规划“城市生命线（数据）和建筑物（应用）”，定义需要什么数据和软件来支撑业务。这是架构的血肉之躯。
- • 阶段D (技术架构)： 规划“城市地基与建材”，选择用什么技术平台来承载应用和数据。这是架构的坚实地基。
最重要的是，我们掌握了一个贯穿始终的核心方法——差距分析 (Gap Analysis)。通过反复对比**“现状(As-Is)**”和“**目标(To-Be)”**，我们识别出了项目需要填补的所有“坑”，这些“坑”共同构成了一份详细的“项目任务总清单”。
课后作业的“深度剖析”
大家对四种架构蓝图的理解非常到位。特别是第三个问题，在技术选型时（比如数据库用免费的MySQL还是昂贵的Oracle），应该依据什么？大家的答案都精准地指向了我们在第9讲定义的**“架构原则”**，这完全正确！这说明你们已经掌握了作为架构师，进行高层次决策的精髓。
我这里再把这个决策过程，用一个极度仿真的“企业架构委员会”的辩论场景，给大家演绎一下，让你看看一个成熟的规划师，是如何利用“架构原则”这把尚方宝剑，来平息纷争、统一思想的。
- • 辩论场景： “智慧邻里”集团企业架构委员会，第3次会议
- • 议题： 核心业主数据库选型
- • 正方（IT部负责人小孙）： “我主张使用Oracle商业数据库。理由是，依据我们共同制定的‘安全第一与纵深防御原则’，业主的核心数据，特别是身份和资产信息，是我们的生命线，安全性不容有失。Oracle作为业界顶级的商业数据库，经过了全球金融、电信等核心行业几十年的严苛检验，其稳定性、安全性、以及厂商提供的7x24小时专业技术支持，是目前任何开源数据库都无法比拟的。为了追求长期的稳定和安全，我们应该投入必要的成本。”
- • 反方（财务总监陈总）： “我反对。小孙说的有道理，但大家别忘了我们定的另一条原则——‘成本效益最优原则’。一套Oracle的授权费加上后续的维保费用，三年下来至少要几百万。而我们目前的核心业务，对数据库的性能要求，并没有达到银行那种每秒几万次交易的级别。免费的、开源的MySQL，经过这么多年的发展，稳定性已经非常出色，完全能满足我们99%的需求。把几百万花在一个‘过度设计’的数据库上，我认为不符合成本效益原则。我建议用MySQL，把省下来的钱，投入到更能让业主直接感知的应用功能开发上。”
- • 你（作为总规划师，出来做总结陈词）：
“感谢两位领导的精彩发言。这正体现了我们架构工作中最常见的‘技术先进性’与‘成本可控性’的矛盾。我认为，两位领导的观点，都是基于我们共同制定的架构原则，都是正确的，只不过是站的角度不同。”
“现在，我们需要做的，不是二选一，而是寻找一个能平衡这对矛盾的、更优的解。我提一个折中方案，供委员会决策参考：”
“我同意陈总的观点，在当前阶段，我们没有必要为所有的应用，都配备Oracle这样的‘航空母舰’。但是，我也同意小孙的担忧，核心数据的安全，是我们绝不能妥协的底线。”
“因此，我建议，我们的数据架构，可以采用‘分级存储’的策略。依据‘数据同源与共享原则’，我们将数据分为不同的安全等级：” - • “一级（绝密）： 业主的核心身份信息、资产信息、支付密码等，这类数据量不大，但安全性要求极高。对于这部分数据，我们可以考虑采用金融级的、经过加密的、部署在私有云的PostgreSQL（一款性能和安全性都极强的开源数据库），并辅以最严格的访问控制策略。”
- • “二级（机密）： 报修工单、缴费记录、停车记录等业务数据，这类数据量大，读写频繁。这部分，我们可以采用部署在公有云上的、高可用的MySQL集群，既保证了性能和稳定性，又享受了云的弹性成本优势。”
- • “三级（公开）： 社区公告、活动信息等公开数据，对可靠性要求不高，可以直接使用云上的普通文件存储或NoSQL数据库。”
- • 老孙点评： 你看，一个优秀的规划师，在面对技术争论时，他不是一个“裁判”，更不是一个“辩手”。他是一个“方案整合者”。他能跳出“非黑即白”的二元对立，利用架构原则作为共同语言，寻找到一个能满足各方核心关切的、更优的、多维度的解决方案。这，就是你的价值所在。
- 1. 【是什么】 深刻理解TOGAF ADM循环的后半程——E、F、G、H四个阶段的核心任务，以及贯穿始终的“需求管理”的精髓。
- 2. 【为什么】 明白企业架构工作远不止是“画图”，一个不关心落地、不关心治理、不关心演进的架构，就是一张废纸。
- 3. 【怎么用】 学会如何将海量的“差距”整合成可实施的“项目包”，如何制定详细的“迁移计划”，如何在实施过程中扮演好“项目监理”的角色，以及如何在系统上线后，建立“架构变更管理”的长效机制。
“这个方案，既坚守了‘安全第一’的原则（对核心数据进行顶格保护），又体现了‘成本效益’的原则（在不同的场景使用最适合的技术，而不是一刀切），同时也符合我们的‘云优先’原则。我认为，这是一个更能体现我们架构智慧的、多方共赢的方案。”
好了，热身结束。我们手里的四张核心蓝图——业务、数据、应用、技术——已经画好了，既漂亮又科学，并且获得了所有关键干系人的一致认可。但是，蓝图终究是纸上的东西。如何把这座美丽的“数字化城市”真正地一砖一瓦地建起来，并且在建成后，还能有效地管理它、让它持续焕发生机？
今天，我们就来学习ADM循环的后半程，完成从“蓝图”到“现实”的这惊险而又关键的最后一公里。
二、 咱们今天聊点啥？（总）
【学习目标】
同学们，今天我们的任务，是完成TOGAF ADM这套“企业架构施工标准”的闭环学习。我们要探讨的是，当“施工图”画完之后，一个专业的“城市规划院”（架构团队）还需要做什么。
很多人有个巨大的误区，以为架构师画完那四张漂亮的蓝图，签上自己的大名，就可以“事了拂衣去，深藏功与名”了，剩下的就是项目经理和开发团队的事。
这是完全错误的！
一个只管画图、不管落地的架构师，不是一个好架构师，那叫“PPT架构师”。一个不关心“施工”过程，不关心“城市”建成后如何运营和改造的“总规划师”，最终的结局，就是他的蓝图被施工队改得面目全非，或者城市建成之日，就是沦为“鬼城”之时。
所以，今天我将带大家学习ADM循环的后半部分——阶段E、F、G、H，以及位于循环心脏位置的需求管理。我们将一起，身临其境地探讨几个极度现实的问题：