阅读说明：
- 如果有排版格式问题，请移步www.yuque.com/mrhuang-ire… 《如何画好技术图（二）》，选择宽屏模式效果更佳。
- 本文为原创文章，转发请注明出处。如果觉得文章不错，请点赞、收藏、关注一下，您的认可是我写作的动力。
入职新公司，想要了解公司业务架构咋办？新接手一个系统，想要快速了解掌握系统以便能够在需求会议上侃侃而谈，应该如何做？当开发者从负责单项目逐步跨越到负责系统，系统的项目数量、功能、交互连接度都比单项目复杂度要上一个数量级。当从负责系统到负责一个公司的业务，那难度又上了几个等级。
作为一名技术人员，除了写代码之外，还需要跟别人沟通或者交流架构设计、业务规划等。这种场合不能直接扔代码出来，一般来说通常文档的形式来做表达。但是，文字有一个缺点，不直观。尤其对于流程类，文字描述容易云里雾里，观众获取不到重点。
对于以上两种场景，表达了图的重要性，不管是自己画图或者是读别人画的图。画图，能够帮助开发者梳理思路，更深层次理解系统，表达整体的设计思路。作为一个开发者，画图能力也是必须掌握的一项表达技能。
从业务架构到应用架构
企业架构包含了四部分，BA（Business Architecture，业务架构）、DA（Data Architecture，数据架构）、AA（Applications Architecture，应用架构）、TA（Technology Architecture，技术架构）。
公司管理层提出业务战略之后，业务架构师设计业务架构，在业务架构的基础上发展出了数据架构、应用架构、技术架构。
以买入股票为例。业务架构如下：
1）业务流程——由买入挂单、规则检查、上报给交易所等步骤组成。
2）业务数据——买入申报指令。
3）业务事件——图中“交易所回报”事件会触发券商“处理成交结果”，当收市时，“当日收市”事件也会触发相应业务处理。可见，用好业务事件，有利于把“条件触发的业务场景”表达清楚。
应用架构师根据业务架构分析应该用哪些应用来支持业务。分析流程如下：
1）业务流程一级的买入挂单、规则检查、上报给交易所、处理成交结果，需要IT应用服务支持，分别为挂单录入、规则检查、委托上报、接收回报、结果显示。
2）进一步地，这些IT应用服务要由具体的应用系统来实现，分别为券商App、券商集中交易系统。如下图所示。
画图三种方案
按照正向流程，从业务架构到应用架构，确实能够掌握系统。但是，这个过程很漫长，特别是对于新接手系统，老板的要求都是要尽快能够独立负责。本文从三个角度，协助我们快速熟悉系统。
管理视角组织架构
管理视角是从角色跟业务功能的角度开看的。业务功能要实现，终究是要落到具体的人身上，三五个人就能组成一个小团队，业务功能就是团队的工作内容，业务的交互就是各个小团队之间配合。通常来说，团队是跟着业务功能绑定的，业务功能如何拆分，组织结构就应该如何拆分，业务功能拆分需要解耦合，这样才能够保证高效。所以，我们会看到业务调整时，组织架构也会调整，合并或者被拆分，招兵买马扩大团队规模或者裁员。
对于管理者来讲，业务都有了具体的团队负责，管理者不一定要懂技术，术业有专攻，管理好这些团队就行了，有什么变动交给负责团队去做。所有团队组合在一起就是组织架构。通过组织架构，从宏观层面认识组织的结构和各个部分的工作内容以及各个部分之间如何系统工作。比如下图中的美团组织架构，按照事业群拆分，每个事业群负责一个专项业务方向。事业群内部还分为不同业务方向进一步拆分。到这里，打开你的工作通讯录，看一下你当前所在的组织架构，是不是也是这样的模式进行划分的。
能力架构
能力架构从产品视角，描述业务达到商业目标和目的时具备的核心能力。 能力架构图，包含两要素：业务能力极其业务功能。业务能力是指组织可以做什么，业务功能是指达到这些能力具体的操作。比如下图中的京东商城能力架构图，网站能力、交易能力、订单能力、履约能力。内部的小模块是其能力分解图。
价值流
价值流是指从原材料到最终产品或服务的整个过程中，一系列相互关联的活动和决策。这些活动包括生产、销售、物流、人力资源、研发等各个方面。对于互联网行业来说，价值流展示了企业创造和交付价值给其客户的链路，客户可以是终端消费者，，也可以是供应商、内部员工、合作伙伴等是。下图举了两个例子，分别是运输服务公司价值流和同城配送平台价值流。
一条业务线存在多个价值流，有面向用户的，也有面向内部工作人员的、还有面向系统的。价值流按照重要程度可以分成两部分：
- 核心链条：直接与企业向客户提供的产品和服务相关的“业务活动”，是价值增值的重要链条。比如同城配送平台价值流中，发货，运输、移交环节。
- 辅助链条：对核心链条起到支持作用的增值活动。比如配送调度，提高价值流流转效率。还有搭建运营平台，整体线上化。
业务能力/业务功能
有了价值流，下一步就针对价值流每个节点，分析出要具备哪些业务功能来支持节点。比如运输服务公司价值流中，每个节点进行了业务功能分解。
对于企业级业务来说，通常复杂得多。一方面可能存在多个价值流，另一方面价值流牵涉多个业务功能。 有必要将业务功能进一步聚合，将有关联的业务功能整合到一起，做成业务能力。
业务流程
业务流程定义规范：
- 第一部分：业务功能概述，业务功能通过主干流程和分支流程实现，要点是“1个主干 N个分支”方式的流程分解
- 第二部分：主干流程，要点是“阶段化 步骤化”，并附每步业务或数据模型规则
- 第三部分：分支流程，要点是“注明在主干流程的分叉位置”，并附每步的业务或数据模型规则
业务功能概述
主干流程
分支流程
虽然文本描述很详细，但是本人强烈建议文本+图相结合的方式，主要流程通过图的形式展示出来，要突出在不同应用之间交互以及业务走向图。
技术视角技术架构
架构师设计完业务架构，技术人员根据业务架构进行软件层面的设计。相比于功能架构，技术人员还多关注系统层面的东西。在架构层面，技术人员做的重要的第一件事，进行应用模块设计，将业务架构中的业务功能集成到对应应用中。 做的第二件事，就是对系统进行分层，层次划分带来的好处不同分层对应不同的功能，系统更加清晰并且解耦。技术视角主要分为四层：
- 渠道层：进入系统的入口，可以是一个终端，比如APP, PC, WAP, 小程序。也可以是终端中的某个模块。
- 系统功能层：第一要展示核心应用的功能分解图。应用功能分解图有两个要点，这里是系统或者应用级别的维度。第二个，功能分解图内部还可以继续分层。比如分为C端和B端。第二个，功能层展示上最好体现系统之间的依赖，或者人与系统之间的交互，架构图的清晰度和逻辑表达上上会更好。
- 基础层：对系统功能层起支撑作用的模块。在能力架构上，已经对各个业务能力进行了依赖划分，处于基础功能的能力对应的系统或者应用，放到基础层。
- 支撑层：业务层面相关工具，作用范围可在上述三层中。比如数据采集工具、监控分析、业务报表等等。
下面举几个例子来说明。
总结
本文分别从组织架构、能力视角架构、技术视角架构的角度阐述了如何快速熟悉业务。组织架构能够宏观层面了解业务，能力架构能够深入了解业务流程，技术视角架构能够帮助理解应用之间的交互和依赖。画图时要做到：理清思路和表达准确，只有自己真正懂了才能够把自己心中的图画出来。画图时要重点突出关键部分，必要时需要反复修改打磨。
参考
温昱.业务架构•应用架构•数据架构实战.电子工业出版社,2021
cloud.tencent.com/developer/a…
