大家好，我非常荣幸能够站在The Open Group 的舞台上与大家分享。回溯过去，从2015年与The Open Group结缘，至今已将近十年。今天，我将以一个新的角色，与大家深入探讨架构与模型的结合，以及如何通过它们助力企业架构的落地。

 

当提及“架构”与“模型”时，许多人可能会觉得这是一个复杂且抽象的话题。但实际上，我们所追求的是通过有序的简化，将复杂的问题分解并描述清晰。我分享的内容是如何通过模型的手段解决设计和治理的问题，推动复杂业务从架构到流程，再到IT的有序落地建设，实现持续的贯通与优化。

 

在此，我想强调两个方面。模型可以赋能真正的架构设计和分析，使我们的架构设计工作变得更为简洁高效；在持续的架构治理的过程中，我们应该充分利用模型，确保资产的有效管理和持续更新。

 

许多人认为架构很抽象，这是因为它确实与我们日常接触的实体对象相距甚远。真正的架构，其实就是决定最终实现方案背后的逻辑层设计。这也是为什么大家觉得架构如此抽象的原因。结合对TOGAF®标准的理解，以及在近十年的架构实践中的一些心得，把架构做实需要关注三个方面的能力：

 

• 架构设计：架构设计过程可以简单理解为将复杂的对象通过科学的分层体系，推进从抽象到具象一层一层地设计出各个要素，形成对整体更可靠的追溯、管理、维护能力。

   

• 内容呈现：设计出来的这些要素，我们需要更好地呈现给不同的利益相关方，包括技术团队、管理者和用户，使其形成一个共识、共用的内容框架。

   

• 持续管理：我们过去依赖PPT和Word来呈现一次性的架构内容，但现在，我们希望能够通过建模标准，将架构内容更加精准化、持续化，使其成为可以持续治理、持续分析的活的要素。

 

可以看到，在上述三个方面，模型提供了灵活、精准、有效的描述和管理方式。

 

为了更直观地展示，我为大家准备了一个实际的例子：假设你作为架构师，进入一个企业。领导给你一个任务——优化数据流，进而优化业务流程。面对一堆业务表单和复杂的业务流程，你如何开始呢？你可能会与业务人员沟通，了解表单的用途和形式，然后得到一系列的业务流程。这种时候，架构的知识就显得尤为重要。按照数据架构逻辑，你需要深入了解表单背后的逻辑数据元素，分析这些数据元素在流程中的使用情况。这样，你就可以从数据流贯通和数据权责的角度更好地理解业务流程的合理性，找出优化的空间。上述例子转换到模型表达，在EMAGE建模平台上，主要就是四个要素之间的关系：流程、业务对象、逻辑数据元素和逻辑数据对象。你可以把掌握的信息按照模型元素罗列出来，并建立关系，进一步将你的想法作为规则，放到每个连线上进行评估，由计算机自动评判要素的规则符合性，从而评估业务的运行质量和数据的质量，进而实现业务的自动优化。

 

总之，无论是架构还是模型，其背后的目的都是为了更好地理解、优化和管理业务。

 

尽管架构本身很抽象，但通过模型，它可以变得更加具象化。可能有人会问，为什么我们要用规范的模型来约束自己，而不是直接使用PPT或VISO这样的工具呢？答案很简单：当我们采用统一规范的方式去描述时，可以带来整个团队对逻辑的一致性认知。这样，大家可以共同进行分析和优化，形成一个真正的团队合作基础。

 

这也是为什么我们的团队被命名为“数孪模型科技”。在我们的理解中，模型不仅是企业所有实体资产和虚拟资产的载体，而且也是我们重构整个体系的路径和方法。通过模型，我们可以将复杂的物理世界进行分层、简化和抽象描述，形成一个有序的数字镜像。基于这个数字镜像，我们可以进行多视角分析，进行各种规划、讨论和优化，从而实现对物理世界的改造。

 

这也正是我们在数字化转型工作中所追求的目标。在实际的治理工作中，模型可以应用在哪里呢？我们可以从企业的架构资产的产生和使用的场景来看。

 

在组织内，一方面有做规划和顶层设计的人员，他们负责将业务架构与战略对齐，找到合适的应用架构模式，规范化数据架构，并进行相应的流程和技术建设。另一方面，还有一些同事正在进行数字化建设工作，包括数字化环境的建设、流程制度的建设等。

 

在这个过程中，我们需要确保架构落实到治理活动中，将从规划到落地的工作内容贯通起来。从战略、业务、应用、技术、物理到数据，我们都需要实现模型化的表达。而这正是我们今天所要探讨的主题。这实际上是一个巨大的挑战，因为我们需要既要考虑已有的碎片化资产，又要从顶层推进设计。

 

最后，我还想通过几个实际的例子，与大家分享关于架构模型化在数字化转型中的重要性。

 

例子1：基于模型的架构资产治理

模型的目的是使原来抽象的架构概念具体化，让业务人员和IT人员都能看得懂。我们不仅要显性化战略架构、业务架构、流程、数据、软件和应用，还要将它们关联起来。按照TOGAF的方法，我们首先要明确企业的范围，然后确定业务与其他业务之间的联系，进而定义业务需求，最后传递给IT，过程中建立需求的条目化管理方式，确定是一个IT需求最终是由软件还是硬件来实现。

 

例子2：IT项目的治理

这里，我们面临的主要问题是保证对客户需求理解的正确性，以及提出的解决方案的先进性、适用性，结合业务架构、应用架构、数据架构、技术架构等分层设计理念的展开，我们建议将需求分为四类：原始需求、结构化的业务需求、结构化的IT需求和项目需求。在实际的项目实践中，我们发现往往不是一个项目就能满足当前的业务需求，而是需要将业务需求不断分解到边界清晰的多个IT需求中，由多个原有系统的改造和新系统的建设实现，建立需求牵引的项目群或多项目的组合管理。

 

例子3：数字化转型时代的组织治理

在数字化转型时代，当我们谈论IT治理和数字化体系的治理时，我们实际上是在谈论组织治理。因为没有业务架构，就做不好IT架构。同样，如果IT不能与业务体系联动，那么业务治理也会失效。在这里，我们需要关注IT的四大价值流：规划、项目建设、服务交付和运维。同时，我们至少要在三个场景上做到位：围绕组织的业务战略进行IT战略规划、实现需求和项目的内容方案管控、以及进行资产关系的监测。

 

简言之，在数字化转型的过程中，模型化的架构是非常关键的。它不仅可以帮助我们更好地理解和管理企业的资产，还可以为我们提供一个清晰、有序的数字地图，帮助我们更好地进行分析、规划和优化。希望大家能够从中受益。谢谢大家！

 

欲获取该篇完整笔记（PDF版本）

可发送“程燕笔记”至公众号免费领取

 

 

欲获取20+篇大咖演讲笔记合集

可扫码添加小助手

「提交预约登记」