1. 架构准备阶段到底在准备什么很多人第一次接触TOGAF的ADM架构开发方法时会把注意力全部放在阶段B、C、D这些“出图”的环节上觉得只有画业务架构、信息系统架构、技术架构才是正经活。而预备阶段Preliminary Phase和阶段A架构愿景往往被一笔带过甚至有人直接跳过。我见过不止一个团队上来就扎进业务流程图和数据模型里结果做到一半发现没人说得清这次架构项目的边界在哪、谁有权力拍板、评审该找谁签字、交付物到底给谁看。最后项目延期、返工、甚至直接搁浅。架构准备阶段要解决的核心问题其实就一句话让架构工作具备启动的条件并且让它在组织里“合法”地活下去。它不产出具体的业务架构或技术架构图但它产出的是让后续所有阶段能够顺利推进的“土壤”——包括架构框架的裁剪、组织模型的建立、工具链的选型、原则的制定、以及架构治理机制的搭建。你可以把它理解成盖楼之前的地质勘探、施工许可、项目部的组建和施工规范的确定。楼还没开始盖但这些事没做后面一定出乱子。这篇文章面向的是正在或即将在企业里推动架构工作的从业者——可能是企业架构师、技术负责人、数字化转型项目的核心成员也可能是被临时拉来“搞架构”的技术骨干。我会把预备阶段和阶段A的核心动作、背后的逻辑、常见的坑以及可以直接抄作业的实操方法尽量讲透。全文基于TOGAF标准的核心思想结合我在实际项目中反复验证过的做法来展开不堆砌术语重点讲清楚“为什么这么做”和“具体怎么做”。2. 预备阶段在写第一行架构描述之前必须敲定的五件事预备阶段是ADM的“第零步”它的输出不是架构本身而是架构工作的“操作系统”。这个操作系统没装好后面每个阶段都会卡顿。我把它拆成五件必须落地的事每一件都对应着后续阶段会反复调用的基础能力。2.1 架构框架裁剪别把TOGAF全量照搬TOGAF是一个通用框架它的全量内容非常庞大。如果你试图在一个中型项目里把ADM的每一个步骤、每一个交付物都完整执行结果一定是团队被文档淹没进度严重滞后。裁剪不是偷懒而是让框架适配组织的实际能力。裁剪的核心判断维度有三个项目规模、组织成熟度、时间约束。一个几十人规模的系统重构项目和一个覆盖全集团的数字化转型规划裁剪策略完全不同。前者可能只需要保留阶段A到阶段C的核心交付物阶段D到阶段H做简化处理后者则需要完整走完ADM并且每个阶段的治理节点都要严格设置。具体操作上我通常建议团队先做一张“ADM阶段适用性矩阵”把每个阶段的核心交付物列出来然后逐项标注“必须做”“简化做”“暂不做”并写明理由。这张矩阵要拿到架构治理委员会或临时决策组上确认形成书面记录。后续如果有人质疑“为什么这个阶段没做”你就有据可依。注意裁剪决策一定要在预备阶段完成并记录不要等到项目中期再临时砍步骤。中期砍步骤往往意味着前期已经投入的工作要部分作废代价更大。2.2 架构组织模型谁来做、谁来审、谁来用架构工作最怕的一件事是做架构的人不负责落地负责落地的人不参与架构设计。预备阶段必须把架构工作的组织模型定清楚包括三个层面的角色。架构发起人Sponsor通常是企业高层或业务线的负责人他的核心职责不是审图而是在关键时刻拍板、给资源、扫清跨部门障碍。没有发起人的架构项目基本等于没有牙齿。架构核心团队包括首席架构师、各领域架构师业务架构、数据架构、应用架构、技术架构、以及架构管理员。这个团队的规模取决于项目范围但至少要有一个人对整体架构的一致性负责。架构评审与治理角色包括架构评审委员会、各领域的专家、以及合规与安全代表。他们的职责是在关键节点对架构交付物进行评审确保架构决策符合组织原则和标准。我踩过的一个坑是在某次项目中架构团队和开发团队完全分离架构师画完图就交给开发开发觉得不合理也不反馈直接按自己的理解做。结果上线后发现系统集成处处对不上。后来我们在预备阶段就明确了一个机制每个架构领域必须有一个来自开发团队的联络人参与架构评审同时把开发侧的实际约束带回架构设计。这个机制看起来简单但效果非常明显。2.3 架构工具链选型别让工具成为负担架构工具的选择在预备阶段就要定下来因为后续所有阶段的建模、存储、发布都依赖它。常见的选项包括专业架构建模工具、通用建模工具、以及轻量级的文档与图表协作平台。选型的核心考量不是功能多少而是团队的实际使用能力和协作需求。我见过一个团队花了大价钱买了专业架构工具结果只有两个人会用其他人还是用截图和文档来沟通工具反而成了信息孤岛。我的建议是如果团队规模不大、架构工作刚起步先用轻量级工具把核心架构资产管起来比如用结构化文档加标准图表模板的方式。等团队对架构工作的节奏和交付物有了稳定预期再考虑引入专业工具。工具是服务于协作的不是用来炫耀的。2.4 架构原则制定给后续决策提供“宪法”架构原则是预备阶段最有价值的产出之一但也是最容易被敷衍的。很多团队的架构原则写得像口号——“高可用、可扩展、安全”——这种原则等于没有原则因为任何架构方案都可以声称自己满足这些词。好的架构原则必须满足几个条件有明确的 rationale理由、有具体的 implications影响、有可操作的衡量方式。举个例子与其写“系统要高可用”不如写“核心业务系统年可用性不低于99.95%对应年度不可用时间不超过4.38小时为此关键组件必须支持冗余部署数据库必须支持主备切换”。这样的原则在后续阶段做技术选型和方案评审时才能真正作为判断依据。原则的数量不宜多通常5到10条足够。太多原则会让团队记不住也容易互相冲突。每一条原则都要经过架构核心团队讨论确认并在组织内公开让所有相关方知道架构决策的“底线”在哪里。2.5 架构治理机制让架构决策有章可循治理机制解决的是“架构决策怎么做、谁来做、什么时候做”的问题。预备阶段要建立的治理机制包括架构评审流程、架构例外处理流程、架构变更管理流程。评审流程要明确哪些节点必须评审、评审的输入输出是什么、评审不通过怎么办。例外处理流程要明确当项目确实无法遵守某条架构原则或标准时走什么流程申请豁免、谁有权批准。变更管理流程要明确架构基线确定后什么级别的变更需要重新评审。这些流程不需要一开始就非常复杂但必须存在并且被记录。我通常建议用一页纸的流程图加一段文字说明的方式让所有人都能快速理解。流程太复杂执行成本高反而会被绕过。3. 阶段A把架构愿景从“想法”变成“可执行的共识”阶段A是ADM正式循环的起点它的核心产出是架构愿景文档和架构工作说明书。如果说预备阶段是“搭台”阶段A就是“定调”——确定这次架构工作的目标、范围、约束和预期收益并让关键干系人达成共识。3.1 架构愿景文档到底该写什么架构愿景文档不是一份技术方案而是一份“沟通工具”。它的读者包括高层管理者、业务负责人、技术团队和外部合作伙伴。因此它的语言必须兼顾专业性和可读性核心内容包括问题陈述与业务背景当前业务面临什么挑战为什么需要架构工作来应对。这部分要用业务语言不要一上来就讲技术。架构工作的目标与范围明确这次架构工作覆盖哪些业务领域、哪些系统、哪些组织单元以及明确不覆盖什么。范围的边界比范围本身更重要因为边界不清是后续扯皮的主要根源。关键干系人及其关注点列出主要干系人并说明他们各自关心什么。比如业务负责人关心的是响应速度还是成本技术负责人关心的是可维护性还是扩展性。这些关注点会直接影响后续架构方案的取舍。约束与假设包括预算约束、时间约束、技术约束、合规约束等。假设部分要特别小心因为假设如果不成立整个架构方案可能需要推倒重来。我通常建议把假设单独列出来并标注验证方式和验证时间。预期收益与成功标准用可衡量的方式描述架构工作完成后能带来什么改变。比如“订单处理时间从平均3天缩短到4小时以内”“新业务功能上线周期从3个月缩短到3周”。没有成功标准的架构项目最后很难证明自己的价值。3.2 干系人地图找到真正能推动事情的人干系人分析是阶段A最容易被低估的工作。很多架构师把干系人列表当成一个行政任务随便填几个名字就过去了。但实际上架构工作能否落地很大程度上取决于是否找对了人、是否理解了他们的真实诉求。我通常用“权力-利益”矩阵来做干系人分析。横轴是利益相关度这个架构工作对他有多大影响纵轴是权力大小他对架构决策有多大影响力。四个象限对应不同的管理策略象限特征管理策略高权力-高利益关键决策者直接影响架构方向深度参与定期一对一沟通高权力-低利益有否决权但不太关心细节保持信息同步关键节点争取支持低权力-高利益日常使用者影响落地效果充分沟通收集反馈争取成为支持者低权力-低利益间接影响者定期通告即可不必过度投入这个矩阵要动态更新。在项目推进过程中干系人的权力和利益关系可能发生变化比如某个业务负责人突然被提升为分管领导他的权力就变了。定期回顾干系人地图是架构师保持项目掌控感的重要手段。3.3 架构工作说明书和发起人“签合同”架构工作说明书是阶段A和发起人之间的一份“合同”。它明确了架构工作的交付物、时间表、资源需求和验收标准。这份文档的意义在于当项目推进过程中出现资源不足、范围蔓延或优先级冲突时你可以拿出这份说明书说“我们当初确认的是这个范围如果要扩展需要重新评估资源和时间。”工作说明书的核心内容包括架构工作的具体交付物清单、每个交付物的完成标准和验收方式、里程碑时间表、所需资源人力、工具、预算、以及风险与应对措施。我特别想强调验收方式。很多架构项目的交付物验收标准是“完成文档编写”这等于没有标准。好的验收标准应该是“文档经过评审委员会评审通过且关键干系人书面确认无重大异议”。把验收标准定清楚后续的扯皮会少很多。3.4 从愿景到可执行阶段A的收尾动作阶段A结束时必须完成几个关键动作才能顺利进入阶段B。第一架构愿景文档和工作说明书必须经过正式评审并获得批准。这个评审不是走过场而是要让关键干系人在正式场合确认他们理解并认可架构工作的目标和范围。第二必须确认架构工作的资源和预算已经到位。如果资源没到位就进入阶段B后续会非常被动。第三必须建立阶段B的启动条件。包括确定阶段B的参与人员、确定业务架构的建模方法和工具、确定阶段B的评审节点。我见过一些团队在阶段A结束时没有做正式的评审和确认直接进入阶段B结果做到一半发现某个关键干系人根本不认可架构目标导致大量返工。阶段A的收尾动作看起来是行政工作但它是项目风险控制的关键环节。4. 预备阶段和阶段A中最容易踩的四个坑4.1 跳过预备阶段直接进阶段A这是最常见的错误。很多团队觉得预备阶段“不产出实际架构内容”所以直接跳到阶段A开始做愿景和建模。结果就是架构原则没定、治理机制没有、工具链没选、组织模型没建。到了阶段B、C需要做技术选型时发现没有原则可依需要评审时发现没有流程可走需要协作时发现工具不统一。我的建议是哪怕项目再小预备阶段的核心动作也要做只是可以简化。比如架构原则可以只定3条治理机制可以只定一个评审流程工具链可以先用现有工具。但“有”和“没有”是本质区别。4.2 架构愿景写成技术方案架构愿景的读者是业务领导和高层管理者但很多架构师习惯性地用技术语言写愿景文档满篇都是“微服务”“中台”“数据湖”这样的词。业务领导看不懂也不关心。结果就是愿景文档没人看架构工作得不到高层支持。正确的做法是用业务语言描述问题、目标和收益技术细节留到后续阶段。比如不要说“我们要建一个微服务架构”而要说“我们要让订单系统的处理能力提升3倍同时把新功能上线周期从3个月缩短到3周为此需要在系统架构上做相应调整”。4.3 干系人分析流于形式干系人分析不是列个名单就完了。我见过一个项目干系人列表上有20多个人但真正参与架构评审的只有3个其他人都不知道这个项目的存在。结果架构方案出来后某个没被通知到的部门负责人直接否决理由是“这个方案影响了我们的业务流程但我们完全不知情”。干系人分析的关键是识别出那些能说“不”的人并让他们在早期就参与进来。哪怕他们不直接贡献架构内容也要让他们知道架构工作的存在、目标和进展。知情权本身就是一种参与。4.4 治理机制定得太重和跳过治理相反另一个极端是把治理机制定得极其复杂每个交付物要经过三级评审、每个变更要走五个审批节点、每个例外要填十张表。这种治理机制在纸面上看起来很严谨但在实际执行中会被团队想方设法绕过因为成本太高。好的治理机制应该是轻量、明确、可执行的。评审节点要少而关键审批流程要短而清晰例外处理要有明确的时限和责任人。治理的目的是保障架构工作的质量和一致性不是给团队制造障碍。5. 一套可以直接复用的准备阶段工作清单基于上面的分析我整理了一份预备阶段和阶段A的工作清单。这份清单在实际项目中反复使用过可以根据项目规模做增减。5.1 预备阶段工作清单序号工作项产出物责任人完成标准1确认架构发起人发起人确认函项目负责人发起人书面确认2组建架构核心团队团队名单与职责表发起人关键角色到位3确定架构框架裁剪方案ADM适用性矩阵首席架构师治理组确认4制定架构原则架构原则文档架构核心团队评审通过并发布5选定架构工具链工具选型说明架构管理员团队培训完成6建立治理机制治理流程说明首席架构师相关方知悉7识别初始干系人干系人清单架构核心团队覆盖关键角色5.2 阶段A工作清单序号工作项产出物责任人完成标准1编写架构愿景文档愿景文档首席架构师评审通过2完成干系人地图权力-利益矩阵架构核心团队动态更新机制建立3编写架构工作说明书工作说明书首席架构师发起人批准4确认资源与预算资源确认记录项目负责人资源到位5召开阶段A评审会评审纪要架构管理员关键干系人确认6建立阶段B启动条件启动检查表首席架构师检查项全部通过这份清单的价值不在于形式而在于它把“准备阶段该做什么”从模糊的感觉变成了明确的动作。你可以根据自己项目的实际情况调整工作项和完成标准但核心逻辑不变先建能力再定方向最后才动手做架构。6. 关于准备阶段的一些个人体会做了这么多年架构工作我越来越觉得预备阶段和阶段A才是整个ADM里最考验功力的部分。后面的阶段B到H更多是技术活——建模、分析、设计、规划这些能力可以通过学习和练习获得。但预备阶段和阶段A考验的是对组织的理解、对人际关系的把握、对项目节奏的判断这些能力很难从书本上学到只能在实践中慢慢积累。我自己的一个习惯是在每个架构项目启动前先花半天时间做一次“准备度自检”。问自己几个问题发起人是否明确且支持核心团队是否到位架构原则是否清晰治理机制是否可执行干系人是否识别完整如果这些问题有任何一个答不上来我就知道准备工作还没做完不会急着进入阶段B。另一个体会是准备阶段的产出物不需要完美但必须存在且被确认。一份粗糙但经过确认的架构原则比一份精美但没人看过的原则文档有价值得多。架构工作的本质是沟通和共识文档只是沟通的载体。载体可以迭代但共识必须在早期建立。最后分享一个实用技巧在阶段A的评审会上不要只展示架构愿景文档而是让每个关键干系人用一句话说出“这个架构工作完成后对我最大的价值是什么”。如果他们说不出来说明沟通还没到位需要继续对齐。这个动作看起来简单但能非常有效地暴露共识缺口。