阿里云 GTS 交付技术部 负责了很多中大型客户的众多项目交付。我们的 SA / BA / TM 等各角色同学，在做云平台或数字化转型交付时，需要梳理客户需求、设计产出业务和技术架构、并协同生态及合作伙伴完成交付。这个过程中，不可避免地需要做许多架构图 PPT，而内容上也难免有很多的重复性、并且缺乏结构化的数据来源和数据沉淀。
面对这些痛点问题、我们探索了一种解决方案，即 不用画的标准架构图工具、支持“快速做出标准的架构图”，可点击查看 简要操作视频 图示 (访问需注册)。
每个平台工具都有自己的初心和特点，接着就 “与使用 PPT 的区别”、“数据”、“技术实现” 三个方面做一些介绍。
一、与使用 PPT 的区别
我们大多数人都是用 PPT 画技术架构图，从零开始画的操作流程一般是这样的：
- 脑中先勾勒出蓝图，有什么文案图片、展现的形式（线框堆叠式、网状式、星形等）。
- 选择合适的模板，技术图风格一般都简洁、甚至就不需要模板。
- 搜索各种知识库的数据，找专业术语、合适的图片图标。
- 开始画图，PPT 菜单里选择合适形状、拖放到画布里合适位置、设置 色彩/字体/间距/对齐 等等。
可以看到、这个过程中花费在“画/设计”上的时间是非常多的，除非确实很享受像画画这样艺术创作过程、不然这么繁琐的过程基本都会感到头大。
当然、现在也有能从“手绘草图”再经过 AI 艺术化生成网页或 PPT 的工具、但基本还是需要人工再调整，这就像是你使用一个现成的“PPT模板”做修改一样、仍然少不了“画”这个动作。
此外数据方面也极易有问题，比如术语的大小写准确性、是否是官方合规的图片图标、数据是否老旧过时，你很难确保找到的数据的准确性。
因此，我们希望通过自动布局的方式、免去了“画”这个动作；通过默认只给符合官方设计规范的 颜色/字号/字体 来确保最低的一致性效果；通过 规范标准 的数据来保证准确性，并能分析数据使用情况；通过 导出 PPT 功能、支持你使用强大的 PPT 来进一步做美化。
大家知道 PPT 在创作的 自由度 上几乎已达到了极致，但自由和规范天然有矛盾、就像技术的 应用框架 组件库 等等也都是在自由代码的基础上做一些符合最佳实践的规范化限制。因此“做规范”这个行为是普适的、这样主要问题就落在怎么取得“规范和自由”的平衡上，也许这个问题永远不能彻底解决、只需瞄准目标 持续做适度的调整取舍。
二、数据
大家常说，一切业务数据化、数据像石油一样重要，同样我们最大的出发点和目的就是为了沉淀“结构化的标准数据”。我们主动接入各种官方数据源，目前已接入阿里云云知平台上的云产品数据源，后续也会支持用户接入自己的数据源。
说数据离不开场景，具体到交付上、除了云产品的 “价格/规格/用量” 等基础数据外，还有比如 “项目工时/成本/人员能力” 等人力数据、“项目和资源计划/问题跟踪/验收报告/过程纪要”等过程数据、“PRD文档/系统设计/模板代码/脚手架/服务接口”等研发数据。
这么多数据必然需要以 office 套件(Word Excel PPT)、图(xmind viso uml)、视频 等各种各样的载体来呈现，但也正是这种分散的载体及不同的数据格式、导致了数据之间难以链接、互通和分析，更遗憾的是、确实还没有一个通用的办法能解决这个问题。
抛开通用性、考虑特定的不同数据场景，还是能有一些解决办法。比如架构设计器、支持操作链路上的类似“下钻/上卷”后，便能做到上下游数据的链接。再通过支持 “图文互转” 等方式、就能达成特定数据内容的互通。但只有 架构图设计器 肯定还不够，还需要 “标准(PRD)文档” 等更多的工具、一起覆盖到尽可能多的场景中，才可能得以全面解决问题。
就像石油应用在交通工具上、会产生巨大的价值；数据也一样、适时出现在需要的场景中才真正有用。这么看来、数据的价值很大程度取决于数据组织上，具体做法是需要持续探索突破。
三、技术实现
下图就是用我们这个工具，只用 5 分钟就做来的架构图！
这里主要想分享上图“绘图功能”技术块 why 的部分、即在技术选型上所做的调研和思考，暂不讲一个个单点的技术细节问题。快速的做架构图、主要就是免去“画”的过程，这种交互的刻意简单化后、也造成更多的可选技术方案：
1、使用开源的支持 dom 模块拖拽的组件；2、考虑直接复用 乐高(宜搭)的 页面搭建 引擎；3、使用一种基于 svg/canvas 实现的图形库。
我们知道第 1、2 种基于 dom 的方式、在细节控制上虽然能满足要求，但针对灵活的图形变换场景，代码实现上十分别扭、也难以具备扩展性。最终采用第 3 种方式、即通用的 web 画图工具做法，但也有代价、就是要反过来限制其过大的灵活性。接着调研了公司内外各种图形库，最终选择了 mxGraph 这个库。
这个选择有几点考虑，其一有名的 draw.io / online.visual-paradigm / processon 等产品的底层就是这个库、在多平台的导入导出图文件等场景互通上有优势。它的前身是 Java 版本的 jGraph，其代码整体架构、模块划分、变量命名、功能丰富度、兼容性、可扩展性等方面都做的非常不错。它就像 变形金刚或是一堆积木、能支持充分的自定义，也给出了许多玩法示例。在实际应用中、按我们的产品目标：需要把它的 “自由拖拽、自由调整尺寸、自由拷贝粘贴、灵活添加节点” 等等过于自由的功能做限制，又基于它已有的 “历史操作、导入导出” 等做了功能增强，后续还要添加 “协同编辑” 等高级功能。
基于灵活图形库的另一个原因，是以后可能需要支持灵活拖拽式“画”图的功能、比如形状随性的部署图。但画与不画都是表象、数据才是灵魂，即便支持了画、导致看起来与 draw.io 的交互区别不大，但重要的还是数据。另外自由度高了之后，也有机会覆盖更广阔的业务场景和用户人群。比如，
- 售前：解决方案/产品能力图、比价图。PD：业务多模块关系/泳道图、功能流程图/脑图、UX设计图。PM：人员图、里程碑图。
- BA：商业模式画布、事件风暴图。架构师：技术选型图、云原生架构图、uml/er图。QA：质量断点图。
从产品能力上不能贸然做决定、但技术上的前瞻性需要有，有能力为充分的灵活度提供快速支持。
目前为止、我们这个也许是基于 mxGraph.js 之上做的 “自定义” 功能最多的产品，而且后续准备剥离业务数据后、开源出去，希望会对可能用到的人有一些帮助作用。技术上还是不得不提自研问题，自底向上的技术自研固然好，即便造的是重复轮子、好处是带来了完全的控制，但现阶段最重要的投入不能是在这里。
最后
“不用画”是做架构图操作过程中能快速提效的核心、随之而来也确实需要牺牲一定的灵活度。透过表面的画布来看看本质，最终是为了解决什么问题，我们认为是规范性和结构化数据。总之，欢迎大家试用、提建议！