架构师的十八般武艺：业务架构

在架构方法论中我们介绍过，企业架构分成业务架构、信息系统架构（包括数据架构和应用架构）、技术架构。但是在日常的实践过程中，我们往往对业务架构比较忽视。或者直接退化成需求分析，或者直接退化成产品设计。但是，对于一个好的架构设计，业务架构是其中不可缺少的一环。

业务架构，包括业务目标、组织架构、业务服务、业务流程、业务规则、业务数据模型等。

业务目标

不管是业务系统还是中间件，我们的首要目标就是要为公司的业务带来促进。可以是效率、可以是洞察、可以是准确性。总是，在进行架构设计之前，我们首先需要明确业务目标，做到有的放矢。

组织架构

根据康威定律：设计系统的架构受制于产生这些设计的组织的沟通结构。如果忽视组织架构，产出的架构设计以及最终交付的软件/服务将不能很好的服务于该组织。在进行业务架构设计之前，我们首先需要对整个公司的组织架构进行比较深入的了解，同时确定架构设计相关的角色和 stakehodlers。

在最终的交付物中，use case 中的 actor 会体现一部分组织架构的内容。

业务流程

跨越组织架构，为了业务目标而产生的业务行为的串联。业务流程在不同的领域，大多都有成熟的范本。如果没有，也是业务架构重点需要关注的点，很大可能是本公司独特的流程或者竞争力之所在。比如丰田的敏捷制造流程、拼多多的售后处理流程、淘宝的稳定性保障流程等。

业务流程一般分为五级：

• L1：行业

• L2：业务域

• L3：业务

• L4：活动

• L5：任务

其中，前两级比较概念化。比如第一级是财务管理，第二级别是核算。

第三级就会比较具体，比如确认交易。

第四级：记录标准日记账分录。

第五级：通过 excel 导入日记账。

前三级基本在业内都是统一的不会有太大的差异，后两级可以根据公司的不同还有定制。

对于 SOA 的架构，一般我们将第 4 级抽象成服务。

对于微服务架构，一般我们将第 5 级抽象成微服务，同时通过开放网关暴露第级 4 级作为 Open API。

业务规则

对于不同的公司，在流程执行的过程中，对于流程的转化或者数据的处理，都有一定的业务规则。比如超过 XXX 金额需要进行第二级审批，对于重复多少次的错误需要 senior 人员的介入等。

梳理业务规则，或者定义业务规则，为的是业务系统更好的进行针对业务规则的设计。

业务服务

我们交付的产品最终呈现给用户的功能界面。use case 以及 user story。在 API first 的环境中，就是我们的产品最终输出的 API 的定义。根据角色的不同，可以是 online 的 API，也可以是后台的操作，或者是一些 offline 的数据分析功能。

Use Case

最终，上述的内容可以整合到 Use Case 中体现 actor 和业务服务。