1. 架构准备阶段到底在准备什么很多人第一次接触TOGAF的ADM架构开发方法时注意力几乎都会被后面的业务架构、信息系统架构、技术架构这些“硬核”阶段吸引觉得那才是真正画架构图、做技术选型的地方。而排在ADM最前面的架构准备阶段Preliminary Phase往往被当成一个“走流程”的过场——开个启动会、拉个群、写份章程然后赶紧进入下一阶段。我一开始也是这么想的。直到参与过几个中途夭折的架构项目之后才发现真正决定架构项目生死的恰恰是这个看起来最“虚”的准备阶段。它要解决的不是“架构长什么样”而是“我们凭什么做架构、谁来做、按什么规矩做、做完之后怎么落地”这四个更底层的问题。打个比方架构准备阶段就像是盖楼之前的地质勘探和施工组织设计。你可以跳过它直接开挖运气好也能盖起来但一旦遇到软土地基或者地下管线返工的成本会高到让你怀疑人生。TOGAF把这个阶段单独拎出来放在ADM循环之外用意就在这里——它不是某个架构开发周期的第一步而是所有架构开发周期共同的“地基”。这个阶段的核心产出是让一个组织具备“可持续做架构”的能力。注意“可持续”三个字。一次性的架构项目可以靠外聘专家、临时团队搞定但企业级架构是长期演进的必须把能力沉淀到组织内部。所以架构准备阶段要交付的东西包括架构组织模型、架构治理框架、架构裁剪后的ADM流程、架构工具与仓库、架构原则等。这些东西听起来抽象但每一样都直接决定了后续架构工作能不能顺利推进。适合谁来深入理解这个阶段我认为有三类人最需要一是刚接手企业架构工作的架构师你需要知道从零开始该搭什么台子二是被拉进架构项目但不太清楚自己角色的业务或技术骨干你需要明白自己在这个体系里的位置三是负责审批架构项目预算的管理者你需要判断一个架构项目是否“准备好了”。下面我会把架构准备阶段拆开揉碎从设计思路、核心细节、实操落地到常见坑完整讲一遍。内容会结合我自己的实践和一些常见做法涉及具体操作的地方会说明这是基于常见实践的合理补充你可以根据自己组织的情况调整。2. 架构准备阶段的整体设计思路拆解2.1 为什么TOGAF要把“准备”单独设为一个阶段要理解架构准备阶段的设计逻辑得先看TOGAF对架构工作的一个基本假设企业架构不是一次性项目而是持续运营的能力。这个假设决定了架构准备阶段必须解决“能力建设”问题而不是“项目启动”问题。如果只是启动一个项目你需要的是一份项目章程、一个项目经理、一份进度计划。但如果你要建立一种持续运营的能力你需要的是组织、治理、流程、工具、标准这一整套东西。这就是为什么架构准备阶段的产出物看起来都那么“重”——架构组织模型、架构治理框架、裁剪后的ADM、架构仓库、架构原则每一样都是为了让架构工作能够长期、稳定、可重复地开展。另一个设计逻辑是**“先定规矩再干活”**。ADM后面的阶段会涉及大量的决策业务流程怎么优化、信息系统怎么集成、技术标准怎么选。这些决策如果没有事先约定的治理机制就会变成谁声音大谁说了算或者每个项目各搞一套最后形成新的烟囱。架构准备阶段就是要把这些规矩提前定好让后面的决策有章可循。还有一个容易被忽略的点架构准备阶段要处理“架构工作的合法性”问题。架构团队往往没有直接的行政权力却要推动跨部门的架构决策。这种“有责无权”的处境必须通过准备阶段建立的治理框架来化解——比如把架构评审嵌入到项目立项流程中让架构合规成为项目推进的必要条件。没有这个合法性基础架构团队后面会寸步难行。2.2 架构准备阶段与ADM其他阶段的关系架构准备阶段和ADM其他阶段的关系可以用“一次准备、多次使用”来概括。ADM的A到H阶段是一个完整的架构开发循环这个循环可以针对不同的架构范围反复执行。而架构准备阶段是在第一个循环开始之前做一次之后所有循环都复用它的成果。具体来说架构准备阶段为后续阶段提供四样东西组织与角色谁负责架构决策、谁负责架构开发、谁负责架构评审这些在准备阶段就要明确。后续每个ADM阶段都会涉及不同角色的参与如果角色不清就会出现“不知道找谁确认”的尴尬。治理与流程架构变更怎么审批、架构合规怎么检查、架构例外怎么处理这些流程在准备阶段定义。后续阶段产出的架构制品都要经过这些流程才能生效。工具与仓库架构制品放在哪里、用什么工具建模、版本怎么管理这些在准备阶段确定。后续阶段的所有产出都往这个仓库里放避免散落在各人电脑里。原则与标准架构决策遵循什么原则、技术选型参考什么标准这些在准备阶段制定。后续阶段的每个决策都要和这些原则对齐保证架构的一致性。理解了这层关系你就明白为什么架构准备阶段不能草草了事。它就像操作系统的内核后面的应用都跑在它上面。内核不稳应用越多越乱。2.3 架构准备阶段的核心目标与成功标准架构准备阶段的目标可以归纳为四个“可”可治理、可执行、可复用、可度量。可治理建立了清晰的架构治理结构和决策流程架构工作有明确的负责人和审批路径。可执行定义了裁剪后的ADM流程和配套的模板、工具架构团队知道每一步该做什么、产出什么。可复用建立了架构仓库和参考模型后续架构工作可以基于已有资产开展不用每次从零开始。可度量定义了架构工作的度量指标能够评估架构工作的进展和效果。成功标准则可以从几个维度来判断架构章程是否获得正式批准、架构组织是否完成组建、治理流程是否试运行通过、架构工具是否部署到位、架构原则是否达成共识。这些标准最好在准备阶段开始时就用可验证的方式定义清楚避免结束时扯皮。我个人的经验是架构准备阶段最容易被低估的是“共识成本”。技术上的准备往往不难难的是让各个利益相关方对架构工作的范围、权限、流程达成一致。这个共识过程需要反复沟通、妥协、确认时间往往比预期长。所以在规划准备阶段时一定要给共识留足时间。3. 核心细节解析与实操要点3.1 架构组织模型谁来做架构架构组织模型要回答的核心问题是架构工作的决策权、执行权、建议权分别归谁。TOGAF没有规定具体的组织形式但常见的做法是建立三层结构架构决策层通常是一个架构委员会或架构治理委员会由各业务和技术领域的负责人组成负责审批架构原则、重大架构决策、架构例外。这个层的价值在于让架构决策有权威性避免架构团队孤军奋战。架构执行层通常是企业架构团队或架构办公室负责架构开发、架构评审、架构资产管理。这个层是架构工作的主力需要具备业务和技术双重理解能力。架构参与层包括各项目的架构师、业务分析师、技术专家等他们在具体项目中落实架构要求并反馈架构问题。在定义组织模型时有几个实操要点值得注意。第一架构委员会的成员要有决策权如果只是各领域派个代表来听会那委员会就形同虚设。第二架构执行层要有明确的负责人这个人最好能直接向高层汇报否则推动跨部门架构工作时会缺乏力度。第三架构参与层的角色要嵌入到项目流程中比如规定每个项目立项时必须指定架构负责人否则架构要求很难落地。还有一个容易被忽略的细节架构组织模型要定义清楚“架构师”的能力要求。很多组织把架构师当成高级开发人员来用结果架构工作变成了技术方案设计失去了企业级的视角。架构准备阶段应该明确架构师需要具备哪些能力——业务理解、技术广度、沟通协调、治理意识并据此来选拔和培养。3.2 架构治理框架按什么规矩做架构架构治理框架是架构准备阶段最核心的产出之一。它要定义的是架构决策怎么做、架构合规怎么查、架构例外怎么处理。架构决策流程通常包括几个环节决策发起、影响评估、决策评审、决策发布、决策执行。每个环节要明确谁负责、输入输出是什么、时限要求是多少。比如一个技术选型决策可能由项目架构师发起架构执行层做影响评估架构委员会评审通过后发布为架构标准项目按标准执行。架构合规检查是治理框架的“牙齿”。没有合规检查架构原则和标准就是纸面文章。合规检查可以嵌入到几个关键节点项目立项时检查架构影响、设计阶段检查架构对齐、上线前检查架构合规。检查方式可以是文档评审、模型审查、或者自动化规则扫描。架构例外处理是治理框架的“弹性”。实际工作中总会有项目因为特殊原因无法完全遵循架构标准这时候需要一个正式的例外申请和审批流程。例外流程要明确申请条件、审批权限、有效期、补偿措施。没有例外流程要么标准被随意突破要么项目被不合理地卡死。注意治理框架最忌讳“一刀切”。不同规模、不同风险的项目应该有不同的治理强度。一个内部小工具的开发和一个核心业务系统的改造架构评审的深度和频率应该不同。在准备阶段就要定义好分级治理的规则。3.3 裁剪后的ADM流程怎么做架构TOGAF的ADM是一个通用框架直接套用到具体组织往往水土不服。架构准备阶段的一个重要任务就是对ADM进行裁剪形成适合本组织的架构开发流程。裁剪的维度包括哪些阶段可以合并、哪些交付物可以简化、哪些角色可以兼任、哪些评审可以省略。比如一个敏捷开发为主的团队可能把ADM的A到D阶段压缩成一个迭代内的架构冲刺交付物从完整文档简化为架构决策记录。而一个强监管行业的组织可能需要增加合规评审环节交付物要求更详细。裁剪时要遵循一个原则保留ADM的核心逻辑调整执行方式。核心逻辑是“从愿景到落地、从业务到技术、从现状到目标”的递进关系这个不能丢。执行方式可以根据组织文化、项目类型、团队能力灵活调整。裁剪的结果要形成一份架构开发指南用通俗的语言说明本组织的架构工作怎么开展。这份指南要包括架构开发的阶段划分、每个阶段的输入输出、关键角色和职责、评审节点和要求、模板和工具的使用方法。指南要足够具体让一个没做过架构的人也能按图索骥。3.4 架构工具与仓库用什么做架构架构工具和仓库的选择直接影响到架构工作的效率和资产的可复用性。架构准备阶段要确定用什么工具建模、用什么仓库存储、怎么管理版本和协作。工具选择要考虑几个因素建模能力是否覆盖业务、数据、应用、技术各层是否支持TOGAF的元模型是否支持多人协作和版本管理是否容易上手成本是否可接受。常见的架构建模工具包括Archi、Sparx EA、Visual Paradigm等也有组织用通用建模工具甚至文档工具来替代。工具没有绝对的好坏关键是匹配组织的实际需求和团队的使用习惯。架构仓库是架构资产的“家”。它要能存储架构模型、架构文档、架构决策、架构标准等各类资产并支持检索、引用、版本追溯。仓库的结构要提前设计好比如按架构领域分目录、按时间版本打标签、按项目关联资产。仓库的访问权限也要定义清楚哪些人可读、哪些人可写、哪些人可审批。提示工具和仓库的选型不要追求“大而全”。我见过一些组织花大价钱买了企业级架构工具结果团队不会用、不想用最后沦为摆设。建议从轻量级工具起步等团队形成使用习惯后再升级。3.5 架构原则架构决策的“宪法”架构原则是架构准备阶段最“软”但影响最深远的产出。它是一组指导架构决策的陈述比如“数据应作为共享资产管理”“系统设计应优先考虑松耦合”“技术选型应遵循组织标准”。好的架构原则要具备几个特征有明确的理由为什么这条原则重要、有具体的含义这条原则在实际中意味着什么、有可衡量的指标怎么判断是否遵循了这条原则。比如“数据应作为共享资产管理”这条原则理由可能是避免数据重复和不一致含义可能是数据定义要统一、数据访问要通过标准接口衡量指标可能是数据重复率、接口复用率。架构原则的制定过程比原则本身更重要。原则必须经过关键利益相关方的讨论和认可否则就是架构团队的自说自话。制定原则时可以采用工作坊的形式让业务和技术代表一起讨论“我们希望架构遵循什么价值观”然后提炼成原则。这个过程本身就是建立架构共识的过程。原则的数量不宜多通常5到10条就够了。太多原则会让人记不住也容易相互冲突。原则要定期回顾和更新因为业务环境和技术环境在变化原则也要与时俱进。4. 实操过程与核心环节实现4.1 准备阶段的启动与范围界定架构准备阶段的启动通常源于几种触发因素高层决定开展企业架构工作、某个重大变革项目需要架构支撑、或者架构团队发现现有架构问题频发需要系统性解决。不管哪种触发因素启动时要做的第一件事是界定架构工作的范围。范围界定要回答几个问题架构工作覆盖哪些业务领域、哪些组织单元、哪些系统架构工作的时间跨度是多长架构工作的深度和广度如何。范围界定不是越宽越好太宽会导致资源分散、战线过长也不是越窄越好太窄会导致架构工作缺乏影响力。合理的范围应该是“有足够影响力又能在合理时间内产出价值”。范围界定后要形成一份架构工作章程内容包括架构工作的背景和目标、范围界定、组织模型、治理框架、主要交付物、时间计划、资源需求。章程要获得高层和关键利益相关方的批准这是架构工作合法性的来源。实操中章程的批准往往需要几轮沟通。我的经验是不要指望一次会议就能通过章程。提前和关键决策者一对一沟通了解他们的关注点和顾虑把他们的意见融入章程然后再上会审批。这样通过率会高很多。4.2 利益相关方识别与架构团队组建利益相关方识别是准备阶段的关键活动。架构工作的利益相关方包括高层管理者、业务部门负责人、IT部门负责人、项目经理、开发团队代表、运维团队代表、外部合作伙伴等。识别时要分析每个利益相关方的关注点、影响力、对架构工作的态度。识别方法可以采用“利益相关方地图”把利益相关方按影响力和关注度分类然后制定不同的沟通策略。高影响力高关注的要深度参与高影响力低关注的要定期汇报低影响力高关注的要保持沟通低影响力低关注的要提供信息。架构团队组建要基于组织模型来定。核心角色包括首席架构师负责架构工作整体方向和决策、领域架构师负责业务、数据、应用、技术各领域的架构、架构分析师负责架构调研、建模、分析、架构管理员负责架构仓库、工具、流程的日常管理。小规模组织可以一人多岗大规模组织可以细分角色。注意架构团队最好包含业务背景的人。纯技术背景的架构团队容易做出“技术上优雅、业务上无用”的架构。如果组织内没有合适的业务架构师可以考虑从业务部门借调或培养。4.3 治理框架的详细设计与试运行治理框架的设计要落到可操作的层面。以架构评审流程为例要定义清楚评审触发条件什么情况下需要架构评审比如新系统立项、重大技术选型、跨系统集成方案等。评审输入提交评审需要准备什么材料比如架构方案文档、影响分析、合规检查表。评审角色谁参与评审谁有决策权谁负责记录评审标准评审依据什么标准比如架构原则、技术标准、安全要求。评审输出评审结果怎么呈现通过、有条件通过、不通过分别怎么处理评审时限从提交到出结果需要多长时间设计完成后建议先试运行一段时间。选一两个项目走一遍完整流程看看哪里卡顿、哪里不合理然后调整。试运行期间要收集参与者的反馈特别是被评审方的感受——流程是不是太繁琐、标准是不是太模糊、决策是不是太慢。试运行通过后治理框架正式发布。发布时要配套培训和宣贯让所有相关人员知道流程怎么走、自己该做什么。4.4 架构工具部署与仓库初始化工具部署和仓库初始化是准备阶段比较“技术”的部分。以常见的架构建模工具为例部署步骤大致包括环境准备确定工具部署在什么环境本地、服务器、云配置必要的硬件和软件资源。工具安装与配置安装工具软件配置用户、权限、模板、元模型。仓库结构设计设计架构仓库的目录结构、命名规范、版本策略、访问权限。初始资产导入把已有的架构资产如现有系统清单、技术标准文档导入仓库作为初始内容。试点使用选一个小的架构任务用工具和仓库走一遍验证可用性。推广培训对架构团队和相关人员进行工具使用培训。仓库结构设计有个实用技巧按“架构领域时间版本”来组织。比如业务架构目录下按版本号分子目录每个版本包含该版本的模型、文档、决策记录。这样既能按领域查找又能追溯历史版本。4.5 架构原则的制定工作坊架构原则的制定我强烈建议用工作坊的形式。具体操作可以分四步第一步收集输入。提前让参与者思考“我们过去在架构决策上踩过什么坑”“我们希望未来的架构遵循什么价值观”。可以准备一些行业常见的架构原则作为参考。第二步分组讨论。把参与者分成小组每组讨论并提炼3到5条原则。讨论时要引导大家关注“为什么这条原则重要”和“这条原则在实际中意味着什么”。第三步汇总共识。各组汇报全体讨论合并相似原则解决冲突原则。这个过程可能需要投票或协商来达成共识。第四步完善表述。对每条原则明确其名称、理由、含义、衡量指标。指定负责人后续完善文档。工作坊的产出要形成正式的架构原则文档经过架构委员会批准后发布。发布后要在架构评审中实际使用让原则“活”起来。5. 常见问题与排查技巧实录5.1 架构准备阶段常见问题速查表问题现象可能原因排查思路解决建议章程迟迟批不下来高层对架构价值认识不足范围界定太宽或太窄与关键决策者沟通了解顾虑调整范围先做试点用具体案例说明架构价值缩小初始范围快速产出可见成果架构委员会开不起来成员优先级不高议题不清晰决策权限不明检查会议频率和时长提前发议题明确决策事项减少会议频率提高会议效率用邮件审批替代部分会议治理流程被绕过流程太繁琐缺乏强制力架构团队话语权不足调研项目团队对流程的反馈检查流程嵌入点简化流程把架构评审嵌入项目立项和上线流程争取高层支持工具没人用工具太复杂培训不到位没有配套模板了解用户使用障碍检查培训效果查看模板可用性选择轻量工具加强实操培训提供开箱即用的模板架构原则被忽视原则太抽象没有衡量指标评审时不检查检查原则表述是否具体检查评审标准是否包含原则重新表述原则增加可衡量指标把原则检查加入评审清单架构团队孤立无援组织模型不合理缺乏业务参与沟通不足检查组织模型是否有业务角色检查沟通机制调整组织模型增加业务架构师建立定期沟通机制5.2 独家避坑技巧技巧一准备阶段不要追求完美。我见过一些架构团队在准备阶段花了半年时间打磨治理框架和流程文档结果还没开始做架构业务部门已经失去耐心了。准备阶段的产出够用就行后续可以在实践中迭代。关键是快速建立基本框架然后通过实际架构工作来验证和完善。技巧二先找“盟友”再推流程。架构准备阶段推动治理流程时不要一上来就全面铺开。先找一两个愿意配合的项目做试点把流程跑通产出成功案例然后用案例去说服其他项目。这比发文件、开大会有效得多。技巧三架构原则要“少而精”。我见过一个组织制定了二十多条架构原则结果没人记得住评审时也不知道该对照哪条。原则控制在5到8条每条都要能一句话说清楚这样才能真正指导决策。技巧四工具选型让使用者参与。架构工具最终是给架构师和项目团队用的选型时一定要让实际使用者参与评估。让他们试用、提意见选出来的工具才有人用。闭门选型的结果往往是“领导满意、用户不用”。技巧五准备阶段的成果要“可见”。架构准备阶段的产出大多是框架、流程、原则这类“软”东西不容易被感知。建议把成果可视化比如画一张架构组织图、做一份治理流程手册、建一个架构原则看板。让利益相关方能看到准备阶段的价值后续争取资源会容易很多。5.3 从准备阶段过渡到A阶段的检查清单准备阶段做得够不够可以用以下清单自检[ ] 架构工作章程是否已获正式批准[ ] 架构组织模型是否已明确关键角色是否已到位[ ] 架构治理框架是否已发布是否经过试运行[ ] 裁剪后的ADM流程是否已文档化是否配套模板[ ] 架构工具是否已部署架构仓库是否已初始化[ ] 架构原则是否已制定并发布[ ] 利益相关方是否已识别沟通机制是否已建立[ ] 架构工作的度量指标是否已定义如果以上大部分都打勾了就可以进入ADM的A阶段——架构愿景。如果还有几项没完成评估一下是否影响A阶段开展。有些事项可以在A阶段并行推进不必等准备阶段完全结束。我个人在实际操作中的体会是架构准备阶段最难的从来不是技术问题而是人和共识的问题。工具可以买、流程可以写、原则可以编但让一群人真正认同并愿意遵循这套体系需要大量的沟通、妥协和耐心。准备阶段花在沟通上的时间往往比花在文档上的时间多得多。但正是这些沟通让后续的架构工作有了根基。最后再分享一个小技巧准备阶段结束时可以组织一次“架构启动会”把关键利益相关方请来正式宣布架构工作启动介绍组织模型、治理框架、工作计划。这个仪式感很重要它标志着架构工作从“筹备”进入“执行”也让所有人知道架构工作要动真格了。
