您是否参加过有人试图解释软件系统如何工作的会议？
我正在与一个刚入行的解决方案架构师进行沟通交流，他试图描述他们提出的系统。它具有大约八个不同的组件，并且它们都以多种方式彼此交互。
他们正在使用手势解释解决方案。。。。。
我理解从他们嘴里说出来的话，但把它们串在一起并没有任何意义。
在解释复杂的概念体系结构时，人们会在语言单词上迷路。我在遵循思路的同时试图建立一种心理模型，我需要一个视觉：
我需要一张图！
但不仅是任何图表。体系结构图不是“一刀切”的解决方案。
您的图表必须考虑到这一点。如果您想将想法传达给不同的人，则必须制作图表的多个版本。
今天，我们将讨论根据五个不同的受众而应制作的五种不同类型的图表。
1.流程图
您可以制作的最通用，最广泛的流程图是流程图。它是一个中高级图表，显示了工作流程的所有部分。
此图说明了业务流程中的活动部分。
这种图的读者通常是技术人员。它可用于将构想提交给架构委员会，或描述业务流程如何与开发人员一起工作。
注意事项:
体系结构流程图的主要部分是包含所有活动部分。在我们的无服务器AWS环境中，我们标记每个托管服务以及哪些服务彼此通信。
没有详细说明各部分之间如何相互作用，但是该图确实显示了连接。它显示了数据如何流经系统。
2.服务图
服务图从高层说明了连通性。它没有显示有关工作流或服务如何工作的任何详细信息，而是显示了正在发挥作用的主要部分。此图旨在显示应用程序中使用的内部服务与外部服务。
IT和网络工程师通常对这种类型的图最感兴趣。他们关心您与外部服务的任何连接。另外，他们需要知道是否需要监视任何内部连接。
我经常使用此图来描述系统如何与高管一起工作。他们想知道主要应用程序之间的连接，没有什么比服务图更好的表示这些连接了。
注意事项
在构建架构服务图时，最好列出组成您的应用程序或生态系统的所有微服务。标记哪些服务可以相互通信，并确保区分公司拥有的服务和外部服务。
对于此高级图表，不需要有关服务如何工作的详细信息。这就是使应用程序运行的所有服务。
3.角色图
重要的是要表明您的体系结构可以解决业务问题。角色图描述了特定工作流程中的时间顺序视图和参与者。这是证明您在开发解决方案时已将业务考虑在内的最佳工具
这是面向业务的个人和产品所有者是此类图表的目标读者。他们专注于角色以及它们与系统的交互方式。他们展示的图表谁做什么和何时会很好地描述你的系统的工作。
注意事项
该架构的人物图骤降到BPMN模型一点点。利用泳道显示工作流程中的不同角色。这种类型的图倾向于较低级别，因为它比其他图包含更多细节。确保标记角色，工作流程以及业务流程如何从一个步骤到达另一步骤的所有假设。
这些图还可以帮助刚接触某个领域的开发人员，并为他们将要构建的内容提供深刻的背景信息。
4.基础结构图
基础架构图是“所见即所得”模型。它代表已实施的所有内容。本质上是一个低级图，它意味着要包含服务/应用程序/生态系统中存在的所有内容。
该图的目的是显示已构建的内容以及系统当前的工作方式。考虑一下您构建的应用程序的蓝图。
基础结构图的受众各不相同。它可以用来向开发人员展示他们在特定微服务中必须使用的功能。它也可以用于向客户显示贵公司用于完成任务的所有资源。
技术人员将是您的基础结构图的主要使用者。由于要提供清单而不是传达想法或业务流程，因此该图的预期用途仅限于提供信息。适用于喜欢“坚韧不拔”的细节的人。
注意事项
在构建体系结构基础结构图时，请不要遗漏任何内容。这种图的目标是显示应用程序中的所有内容以及它们之间的连接方式。您无需过多地介绍其工作原理，而专注于将应用程序的所有部分都包含在图中。
这些图通常需要大量工作来维护，但是可以在CI管道中自动生成它们。
5.开发人员图
当您需要精细落地，开发人员图将是您的最佳选择。它包括开发人员构建解决方案所需的一切。
目的是通过查看流程图来回答可能出现的任何问题，并将其包括在设计中。这是最底层的图，目的是在您不存在的情况下传达想法。
人们应该能够阅读此图并确切地知道该怎么做。
实施解决方案的开发人员是这图的阅读者。图表中包含的详细程度对于团队之外的人员而言是不必要的。有时，对于不需要它的听众来说，过多的细节可能是一件坏事。
向开发团队之外的人员提供实施细节是过多细节的完美示例。它会引起分心，并且使您无法尝试传达其他消息。
注意事项
该架构图基本上是流程图基础上添加的细节。用您可以想到的任何特定实现细节来标记每个部分，并确保标记重要的过渡。
这种类型的图不能代替用户故事，但确实有助于增强用户故事并增进整个开发团队的理解。尽可能使用它们，因为完成实现后，将来将有一个有用的工件可供参考。
结论
有许多类型的架构图。每个人都有其独特的目的，许多人服务于不同的受众。作为解决方案架构师，您在提出想法时必须能够向合适的人提供合适类型的图表。
通常，仅使用图的一个版本是不够的。开始新设计时，我总是从流程图开始。我全神贯注，并将其推广给其他SA。在我们就解决方案达成共识后，我将采用流程图，将其转变为角色图，然后将其带给业务人员。
当我从客户业务侧获得批准时，我便可以随意制作开发人员图和服务图。将服务图提供给主管人员，以确保他们对我们正在做的事情有一个高层次的了解。开发人员图将提供给将要实施该解决方案的工程师。
解决方案构建完成后，我们可以更新基础结构图以包括新工作。
一幅图片值得一千个单词，但是当涉及到架构图时，它们可能值得一千个单词。能够使人们快速轻松地理解您的想法是成为出色的解决方案架构师的关键。
通过为不同的受众构建不同类型的图的能力，您可以为成功做好准备。