随着数字化进程的推进，几位客户多次与我提起如何导入TOGAF。TOGAF是The Open Group Architecture Framework的缩写，由The Open Group，(一个非盈利的技术行业联盟) 开发和更新。它支持在企业战略指引下进行架构分析，并构建项目组合，通过项目推进企业不断进行业务与数字化平台演进，并形成企业的架构资产。简单来说，就是数字化无缝支持（或实现）业务，最终支持企业愿景实现。
图表 1内容元模型概览（参考：TOGAF）
尽管不少企业的流程管理和数字化转型部门员工已经获得了TOGAF证书，然而当企业真正导入TOGAF 时，仍然对于TOGAF 怎样结合企业的数字化转型项目和项目产出的“架构资产”如何管理存在疑问。
在TOGAF 一系列的方法中，内容元模型这一部分被分为架构原则、愿景、需求、业务架构、信息系统架构（包括数据架构、应用架构）、技术架构、架构实现这几部分。
图表 2 4A企业架构（调整版）
离散地看这些，再结合项目管理的内容，可能会有些无所适从，不知道从哪里下手，下面我们尝试用简单的方式来阐述一下。
企业中的数字化转型是为了支持价值实现。本着有的放矢、以终为始的原则，我们以业务价值为出发点，把企业的业务和与之匹配的数字化系统分层划分为4A架构，它们分别是业务架构，数据架构，应用架构和技术架构。从业务价值实现角度出发，设计和制定流程，匹配相应的角色和组织。沿着流程识别数据实体的增删改查和IT需求。根据数据增删改查和业务的需求，收敛成应用架构，再用技术基础设施来支撑系统实现。这些架构具有颗粒度相当的层级对应关系，但并非严格对应。
当一个企业需要通过数字化来支持规模化协作的时候，往往需要考虑首先进行企业的顶层设计，统一规划后，把可能会被各部门重复调用的流程集约化设计成为可复用的业务能力模块，继而开发相应的数字化模块来固化这个业务能力。当我们把这个可复用的业务能力模块和相应的数据、应用合并为一个能力单元来看待的时候，这个组合就形成了一个积木块。类似的、不同功能的积木块，未来可以随着企业需求适当排列组合，形成企业“即插即用”的能力。从顶层规划到积木块的开发，需要遵循统一规划、逐步实施的过程。顶层设计的过程会被我们称为架构设计或业务规划，基于规划后对积木块的逐一实施则要依赖单个的项目推进。
然而，企业在发展过程中，并不总是有着统一规划的契机。当企业快速发展的时候，往往是厘清和搭建体系、建立相应IT系统的******时机，错过了就会对企业规模化复制赋能不足，提前了会导致体系与业务需求不符，进而带来浪费。在实际情况中，急用先行的需求往往会多于“谋定后动”的需求，这并非总是关于管理的对错，而是更多来源于市场窗口期、日渐增长的供应链信息流和物流越加杂乱等现实压力。
当企业一方面有着时间压力，需要急用先行，一方面意识到顶层设计如打地基，一旦设计错了，已经盖了的屋子要推倒，地基要挖出来重新做的时候，就要想办法用架构思维来平衡长期矛盾和短期矛盾。
一、 长期矛盾：
企业预见到快速发展期的到来时，应尽早地进行业务架构、数据架构、应用架构的梳理，定义不同应用模块未来的部署方式或原则（如：购买软件包，还是云服务，还是自研）。这会使得不同领域的数字化有条不紊，边界和方向性更加清晰，减少不必要的数据集成或系统的重新开发。顶层设计的架构颗粒度在业务架构、数据架构、应用架构层面可分别细化到业务流程（局部四级）、概念逻辑模型（概念层略下探）、应用模块层、技术域。
顶层设计的关键在于找到相应领域在不同场景下的价值实现路径（哪些变量可以支持目标实现，哪些活动可以支持变量改进），而非仅仅把业务现状拿出来划分成段。（参考之前的公众号文章《价值驱动的流程管理》）
上图描述了企业架构顶层设计的一般过程。
• 首先，识别业务模式、场景； 厘清业务目标、子目标和关键结果领域；梳理业务流程，确保高阶流程可覆盖不同场景；类似流程进一步整合以减少后续维护和IT开发工作。
• 第二步，沿流程梳理IT 功能需求，和流程间流转的信息，根据功能需求和信息增删改查要求，梳理功能模块。
• 第三步，收敛功能架构、分析现有产品覆盖情况、定义未来支撑的系统，梳理系统集成关系。
• 第四步，对比现状与将来，识别“做几个小手术”可完成改造；按照业务优先级、模块开发依赖关系等形成里程碑。
以上步骤完成后，基本形成顶层设计，后续可逐步推进各模块的详细设计和开发。
顶层设计的好处是企业的“管理资产”、“数据资产”、“应用资产”会更有序、集约（重复调用的流程和功能都整合了）；管理/系统边界和接口清晰、避免重复数字化投入和混乱的数据集成；数据资产管理较为“干净”、可用性强；未来业务扩张时“可插拔”的弹性较好。但也存在弊端，比如：这个阶段的花销不直接体现为IT系统和业务收益，对于规模较小和资金紧张的企业可能会不合时宜。同时，我们也看到一些规模较大企业，由于未提前规划好顶层设计，导致各事业部重复投资类似功能，或开发好功能后，发现由于数据集成关系的缘故，放在另一系统更为便捷。
二、 短期矛盾
尽管“良医治未病”的故事已经流传了2000多年，然而有时企业的发展速度超出了我们的预期，规模扩张带来的痛点先于整体规划提前到来。
在此情况下，到底应该先做顶层设计，还是要先解决痛点？此时应以业务结果为导向。如果市场的机会窗口比较紧、企业的经营差距较大或正在/即将面临较大风险，企业应优先选择急用先行，其他问题在业务执行过程中渐进纠偏。此时，如果在导入TOGAF同时刚好有在建项目，企业也无需暂停该在建项目，只需审视在建项目，使其交付包括业务架构、数据架构、应用架构即可，技术架构不做强求，因为要结合实际项目来判断用何种方式部署（比如：基于云平台还是服务器部署等）。也为此，流程变革部门和数字化管理部门（有时候是一个部门）要主动关注到企业的外部环境和经营现状，并被给与一定获知企业经营信息的途径和权限。
图表 4 数字化赋能的业务转型方法
在具体的数字化赋能的业务转型（图表4）中，项目被分为蓝图设计、功能设计、开发、验证、试点/推行几个阶段。各阶段均涉及几条业务流，分别是业务流程与收益、数据、应用、技术、架构、项目管理、变革管理。其中，业务流程与收益责任人负责梳理流程、角色、组织、衡量指标；数据人员负责数据资产目录、数据实体关系、数据标准、信息流等方案；应用人员负责应用架构和集成架构的设计，并开发应用系统；技术人员负责技术能力和环境的部署搭建；架构人员负责整体对业务、数据、应用、技术架构进行统筹同步，确保数字化平台无缝支持或实现业务；项目管理人员负责项目的准备、计划、执行监控、关闭；变革管理人员负责通过沟通、宣导、培训等活动推动用户的理念和行为转变。
三、 资产沉淀与再利用
企业架构是可以设计的，但最终是演进的。企业的数字化转型中，为了平衡顶层设计和急用先行，有时会容许短期数字化投资的存在，系统会通过新陈代谢的方式逐步完善与革新。为此，企业要将由单一数字化转型项目（或数字化赋能的业务转型）所产出的交付，转化为企业的流程资产或管理资产、数据资产、平台资产；并在未来业务流程再次优化、插拔的时候，基于当前资产给与复核或同步修正架构资产（图表5）。
图表 5 TOGAF 在企业中的落地
单一项目承担企业的具体数字化转型（或数字化赋能下的业务转型），企业的架构部门予以复核，根据复核结果判断是否修改单一项目中的具体方案，还是修改架构本身。单一项目中的成果需要被不断回收到企业的管理和数字化资产当中。这些自我迭代的活动需要通过项目管理（主要针对项目，关注项目目标）、项目治理（主要针对项目集，关注商业和战略目标）和变革流程来实现。企业可依据具体业务复杂程度和人员规模，来规范“流程资产、管理资产、数据资产、平台资产、项目治理和变革管理的权责。”
通过不断的转型演进（单一项目）与新能力的回收（架构资产），企业可逐步形成自己的企业架构。企业架构的完善会帮助企业建立可裂变的组织能力，赋能企业业务、产品创新和开源节流。
