日常架构规划中所面临的问题
在企业架构规划工作的过程中，会沉淀大量架构资产（比如流程、能力、数据、系统等）。在架构资产的数量比较少时，我们还可以通过Numbers、Excel、Word、PPT等非结构化方式对架构资产做盘点和记录。可是一旦架构资产增加到一定数量后（比如几百个流程，几千个数据，几百个系统），再希望去高效使用这些架构资产时，这些工具就会显得捉襟见肘。这也是我们团队在日常工作中面临的一个大的问题，总结起来主要包括以下两方面挑战。
挑战一：对架构资产的实时联动读取变得很困难。
架构资产是一个逐步沉淀和滋养的过程，对架构资产的维护一直处在动态的迭代之中，而迭代的前提是能看到之前的信息。比如我们在架构沉淀过程中获得了新的业务能力，在录入这个能力时，我们希望确认它是否已经存在，如果已经存在和其他架构资产的关联关系，通过对比关联关系验证该业务能力是否是当前场景所需要的。
挑战二：从现有架构资产中提炼产出物视图和洞见很困难。
在架构工作的最后阶段，我们需要融合所有架构资产形成架构产出物，这些产出物多是对多种架构资产做关联分析后的结果（比如系统集成关系、系统能力流程关系等）。通过传统的方式去完成这项工作会很煎熬，不仅要同时读取大量的文件，而且需要将这些数据手动关联起来。同时当发现现有架构资产中的错误时，还要将其联动更新修正过来（联动更新文档确实不是一个很惬意的工作）。我们希望通过架构资产间天然的关联关系能够自动生成架构产出物视图，且对架构资产的调整和变更会自然地在架构产出物中得到体现。
是时候做出一些改变了
我们逐步认识到，架构规划工作本身的“数字化”诉求变得很高，不是简单地将架构资产记录下来，而是要支持丰富的实时分析和交互。
其实前文提到的流程、数据、能力、系统都是属于企业架构元模型概念的一部分，简单来讲企业架构元模型记录了企业架构中的各种架构元素及其之间的关联关系。Thoughworks有一套自己的企业架构工作方法——MEAF 及其元模型，我们要做的就是将 MEAF 的元模型数字化，以便进行架构资产的查询和联动分析，我们在工作中沉淀了一个架构管理工具——MOSS 来完成这项工作。
通过MOSS，我们可以做到架构资产的实时录入、确认、查询。同时基于MEAF元模型建立的底层架构资产之间的关联关系，可以辅助我们做架构资产关联分析、架构资产变更拟真（某个资产的调整对其他所产生资产的影响）、架构分析视图的定制、架构产出物自动生成等。通过MOSS，大幅提升了我们的工作效率，简单来讲，过去在架构产出阶段需要几天时间的工作量，现在都可以实时生成。
图是怎么帮助到我们的？
前面讲了很多我们遇到的问题以及工具，那么和图是什么关系呢？MOSS是如何做到架构资产间的关联关系的实时分析呢？
首先我们看下MOSS是怎么存取数据的。我们先简单介绍下两种常见的数据库类型。
关系型数据库是一种强事务型的、结构化数据存储的数据库，适合有固定模式和复杂查询的场景，比如电子商务、金融服务场景。
NoSQL数据库是一种分布式架构的、基于CAP理论一致性、非结构化/半结构化的数据存储，适合于需要灵活性和扩展性的场景，比如社交网络、实时日志存储等。
企业架构资产数据类型比较丰富，包含了结构化数据（如企业架构元模型对数据有强一致性需求）和非结构化数据（如尚未提炼到元模型中的暂存和备注信息等）。实际上MOSS也是综合利用了以上两种类型的数据库做架构资产的存取。但MOSS不仅仅要存取架构资产，还要对架构资产进行演进、分析、评估、优化、追踪等，这依然可以使用关系型数据库的复杂查询来处理。可当这类查询变得比较多的时候，我们开始思考有没有更直观、灵活、高效的形式可以辅助我们完成这些工作，图数据库就是这样一种形式，很适合做数据的灵活建模和复杂关系分析。
图数据库是一种基于图论的数据结构，它由节点和边组成，节点表示实体，边表示实体之间的关系。图数据库可以用于表示复杂的关系网络，如社交网络、知识图谱等。与传统的关系型数据库相比，图数据库更适合处理复杂的关系查询和图分析任务。上文提到了企业架构的元模型，即描述企业架构的基本元素和它们之间关系的抽象模型，而图数据库天然适合处理这样的关联关系 。
图1 极简化的企业架构元模型概念图
如上图所示为企业架构元模型极简示意图（此处暂时不做概念展开，主要为说明如何用图的方式表示元模型），流程片段会产生或使用多个业务对象，一个业务能力可以通过多个流程片段化，通过系统组件可以实现业务能力的数字化。
图2 以图的形式表示企业架构元模型元素及其关系
上图是将一部分企业架构元模型映射为图的存储结构后的形式。带颜色的圆代表节点，带箭头的边代表节点之间的关联关系。图数据库提供了一种所见即所得的方式，帮助我们记录架构资产及其之间的关联关系，节点和关系的结构更贴近现实世界的复杂关系，而Cypher等图查询语言则提供了更直观、更高效地表示和查询这些关系的方式，而在SQL中可能需要编写更复杂的连接（JOIN）查询来表达类似的关系，尤其是在处理多对多关系或者深度关联的情况下。
我们可以用一个计算系统组件集成关系的例子，来说明使用图数据库做盘点和分析的优势。在上面的模型中，如果系统A关联产生（支撑的业务能力的流程片段产生）的业务对象被系统B关联使用，则认为系统A支撑了系统B，这会帮助我们通过业务对象建立系统间的集成关系。在图中，可以通过如下Cypher语句查询：
*MATCH (a:*系统组件 *{name: "aSys"})-[*2]-()-[:产生]->()<-[:使用]-()-[2]-(b:系统组件)
RETURN b
简单解释一下上面的语句：名字为aSys的系统组件通过2个关联最终产生了业务对象，被另外一个系统B通过2个关联最终使用了，返回所有B的集合。而同样的功能，通过传统的Sql语句，需要多个连接和子查询结合才可以查出来。
许多在企业架构工作中遇到的问题和效率提升的点，本质上可以通过架构工序的优化、架构资产的盘点和分析得到解决，图可以辅助我们更直观、更简单和高效地对架构资产进行盘点和分析，从而大幅度减少手动工作量和编写大量复杂逻辑代码的成本。我们在MOSS工具中也集成了图的功能。接下来再通过两个场景来说明图在企业架构规划工作中的应用。
场景一：业务访谈面临的挑战
在企业架构规划项目的开始阶段，我们需要通过客户访谈对业务现状做盘点和分析，访谈的主要工作通常由BA（业务架构师）来完成，并最终帮助客户梳理核心业务流程、分析痛点举措、整理业务架构全景等。在这个过程中负责应用架构、数据架构和技术架构的相关角色通常也会参与，以便及时消化和理解业务，为后续架构设计工作做准备。
图3 通过业务流程访谈梳理的流程信息
对于企业级架构规划，访谈对象往往会涉及企业的多个相关部门的干系人，面对这种高强度访谈，团队往往面临着维持访谈流畅性、捕捉细节信息以及信息准确性之间的权衡和挑战。在梳理流程过程中，业务架构师需要记录流程的阶段、关键活动、活动所关联的业务对象、活动的任务等信息，这些信息的完整性和准确性将影响后续架构规划工作。流程活动的断点（有缺失的关键活动）、业务对象的不准确（缺失或者名字不统一）等都会影响到后续对业务能力的提取和应用架构的设计。当架构人员发现这些问题时，一般是架构团队内部沟通达成共识（但信息可能已经失真了），或者再去跟客户干系人确认（周期会变长）。
有没有什么方法能够帮助我们提前发现访谈流程中的不准确的信息呢？如果我们能将流程中活动信息、活动的业务对象信息（包括输入和输出业务对象）及关联关系等信息以图结构的形式及时导入到图数据库中，就可以更直观地看到流程活动及业务对象的关联关系，这可以帮助我们及时发现访谈流程中是否存在断点，是不是丢失了一些关键流程和数据信息。
图4 通过图的形式分析访谈流程
比如通过图，我们可以更直观地发现活动之间的依赖关系，是否存在循环依赖的活动，是否存在孤立的活动。这不一定是完全准确或者严谨的，不过对 于架构师来说这是一种潜在的味道，并可以通过及时和客户确认来消除这种味道。
图所提供的这种直观展示方式，不仅可以提高架构师的工作效率，还可以提升最终产出的质量。此外，图数据库的检索语法使我们能够快速验证企业架构工作中遇到的问题和潜在的效率提升点。
场景二：如何灵活动态展示系统对流程的支撑
图5 流程支撑、系统集成关系图
在完成了系统规划后，我们需要展示和验证系统对业务流程的支撑。如上图所示，针对某个端到端流程，需要拉取出其关键流程节点的系统触点（该节点被哪个系统支撑）、核心的业务对象，以及系统间的数据集成关系等，将流程、系统和数据串接起来。当所有的业务流程都需要以这种形式和系统一起展示的时候，巨大的工作量导致架构师很难以手工的方式去完成这项工作（而且准确性也无法保证），那么如何灵活地支撑这种需求呢？
参考图2模型中描述的系统组件、业务能力、流程片段、业务对象之间的关系，我们可以以流程为主线，通过图查询语句快速查找出流程所关联的系统触点，并计算出系统间的集成关系。相比于额外开发定制的代码或脚本，通过图的方式可以更直观、更快和灵活地提取出我们所需的数据。
写在最后
前面介绍了我们日常架构规划工作中面临的问题和诉求，包括对架构资产的实时高效读取和联动分析的需求，以及从现有架构资产中提炼产出物视图的需求等。我们使用图的方式对架构资产做导入和分析，并在几个典型工作场景中做了尝试，图可以帮助我们更直观和高效地从大量的架构资产中快速提取所需的信息。
在持续探索企业架构工作方法的同时，团队也在持续探索如何通过数字化手段提升日常企业架构工作的效率，我们还将这些经验和最佳实践整合到了我们的架构治理工具MOSS中。未来MOSS不是仅仅是一个架构资产管理平台，它会更像是一个智能的EA，辅助架构师的日常工作和规划落地，辅助决策者看到企业并决策。