架构标准 TOGAF 实践最重要的三件事

TOGAF 高大上，但生搬硬套到企业信息部门，不妥。

TOGAF 实践最重要的三件事：落地，落地，还是落地。

TOGAF 9.2 是企业架构实际上的标准，在全球有广泛实践。其包含的四种架构也被广泛认同：

观点 1：调研、诊断、优化三者的关系

从小处说，调研是为了了解现状、明确问题、定位痛点，这需要“内部分析”。从大处说，调研还有助掌握政策趋势、洞察行业机会、解读标杆实践。这需要“外部分析”和“行业分析”。

同时，无论是“问题与痛点驱动”还是“趋势与机会驱动”，都要做好诊断与优化。诊断优化环节的价值在于把脉、在于针对性。一是输出“具体差距”，二是给出对应药方、对应改进策略。

顶层架构规划时，调研必须充分，要大做。很具体的 IT 解决方案，调研环节小做即可。

观点 2：分析不透时，要返回头优化分析模型

首先，分析模型应细致、合理。例如，PEST 分析的内容就不是一刀切的，可以根据你要规划的方案的不同背景，有不同侧重。

其次，分析不透时，要有意识地返回头优化分析模型。例如下图，针对现在流行的“风口识别”，进行了模型优化：

• 行业格局方面——产业链初步成型，是风口条件 1。

• 客户 &市场方面——增量市场初步形成，是风口条件 2。

• 竞争格局方面——垄断格局尚未形成，是风口条件 3。

观点 3：企业级顶层规划，如何纵向到顶

笔者认为，企业顶层规划的本质是“变革规划”或“转型规划”，因此纵向到顶的调研与分析必是重中之重。

如下图所示，外部分析、行业分析、内部分析、标杆与最佳实践调研等都是制定或理解战略不可或缺的环节。同时，顶层规划中也有必要对运营模式、商业模式、组织机构、业务流程、业务渠道等进行诊断优化。实际实践中，更少不了在标杆调研、诊断优化两项工作之间反复迭代。

观点 4：具体 IT 方案规划，可对方法剪裁

有方案经理问我，具体 IT 解决方案规划中，“纵向到顶”的调研分析要不要做？做多少？

问题 1：你作为方案负责人，有“变革拍板权”吗？

问题 2：你做好方案后的汇报对象，有“变革拍板权”吗？

如果都没有，就对方法剪裁，别花大力气在外部分析和行业分析等高大上环节。

观点 5：应用架构设计，如何上接业务

实践中，应用架构设计环节的核心产物，有 4 个：应用功能架构、应用系统划分、应用集成架构、应用部署架构。其中，应用功能架构长这样，高层文档中屡见不鲜：

在《业务架构·应用架构·数据架构实战（第 2 版）》一书中，笔者也提炼总结出了“应用功能架构模式”。如下图所示：

TOGAF 实践要落地，“业务驱动的应用功能架构设计”是重中之重。业务驱动的逻辑是否充分、是否通达，是方案最终成败的关键。

下图简要揭示了“上接业务”的思维要点：

观点 6：应用架构设计，如何下接研发

在下游，承接规划方案的是项目研发。如何做到这之间的“衔接贴地”呢？重点是“不虚”。

应用架构设计环节中，“应用系统划分”这项工作，切出来具体前端项目、后台项目、平台项目，就是“不虚”。相反，仅仅切出来一堆业务组件、功能模块，去驱动研发，就又“虚”又“飘”。

请读者看下图，“桌面应用”项目旁边代表 75%的符号,在研发管控中有何实际价值？可留言。

书已出版