业务架构

一、前言

什么是业务架构？

业务架构是企业治理结构、商业能力与价值流的正式蓝图。

业务架构明确定义企业的治理结构、业务能力、业务流程、业务数据。其中，业务能力定义企业做什么，业务流程定义企业怎么做。

业务架构就是对企业的业务流程，进行根本性的再思考和在思考的彻底性再设计，从而获得成本、质量、速度等方面业绩的巨大的改善或提高。

综合看，业务架构包含：

战略

企业业务流程(价值链)

当前能力，未来能力；商业能力，IT能力；

其实业务架构不是技术人员在做的，因为和技术其实没有多少关系，所以要是有人问：你们公司的业务架构是什么样的，你可以直接回怼有没有搞清楚什么是业务架构，因为就不应该问技术人员这个，我们不是高层，也不是决策层，不清楚很正常。说完什么是业务架构，现在说说业务架构图怎么画，很多程序员画架构图头疼，不知道画什么、怎么画！

分享、评审、述职、答辩，只要你在程序员这个行业，就几乎离不开要画图。

一提到画图很多人就想站会起来喊，”内卷“、”内卷啦“、”PPT工程师“，但程序代码本身就是一种数学逻辑的具体实现，如果没有一些图表配合文字的阐述，讲真很难让所有人都能在共同的共识下进行交流。

这不像是文科，”八表流云澄夜色，九霄华月动春城“ 上来就能联想到它是在描述啥。但是偏理科代码逻辑或架构设计，只能把抽象的内容用图表的形式展现出来，让大家在同一的共识下共同协同工作。

而我们画的架构图、流程图、结构图、功能图、逻辑图等，都需要好看、好懂、好用、好搞，因为：

好看是为了提升沟通效率，

好懂是为了提升交流共识，

好用是为了提升交付质量，

好搞是为了提升实施速度。

这就像君子在追求漂亮姑娘一样，好看就想主动撩一下、有品行和共同的三观很快让你开口说我懂你、接下来就是交付质量和实施速度了，那也是水到渠成的事。

好，别激动，接下来我们就开始专心研究研究架构图，都有哪些，该怎么画，有什么手法。

二、架构图有哪几种？

仅说技术架构图的话，通常我们☞指的是选型各项技术组件来支撑整个服务建设的系统架构。但用于不同人群范围和不同场景下会有其他分类，如图 26-1 架构图分类

业务架构：需求初期业务的结果和过程描述一般比较模糊，可能来自于某个老板、运营或用户的反馈。客户说海尔洗衣机洗土豆会堵，海尔立马设计专门的土豆洗衣机 业务方向往往是定方向和结果的叫战略，主要包括业务规划、业务模块和流程以及问题域的列表等。

产品架构：业务提需求，产品定方案，相对于业务的粗放流程，产品架构会更加细腻以及考虑各个模块的分层和边界。

应用架构：服务复用、跨组协同，简单、灵活、整合是应用架构必须考虑的点，就像你要上线一个聊天功能，那么聊天内容的输入法、文字识别、舆情监控以及视频服务、支付服务等，它们都是在应用架构分层下沉淀到平台的产物，在供各个方使用。

数据架构：数据的获取、数据的存放和数据的使用是数据架构要解决的三个问题，数据库存放、大数据汇总、数据分析等。

技术架构：是离程序员最近的架构设计，它不仅是系统搭建的架构图设计，还包括了结构、功能、流程、逻辑等内容。它的具体描述就是整个系统如何落地的具体实现方案。

三、Zachman框架是什么？

Zachman框架，由约翰 扎科曼（John Zachman ）在1987年创立的全球第一个企业架构理论，其论文《信息系统架构框架》至今仍被业界认为是企业架构设计方面最权威的理论。

Zachman框架（Zachman framework）是一种逻辑结构，它可以对企业信息按照不同分类和不同角度进行表示。

Zachman框架，从横向六个角度看待企业，这个六个观点可以分为；什么内容、如何工作、什么地点、谁负责、为什么这么做（称为W5H）。

框架的列由一组工件组成，分为规划者、拥有者、设计者（架构师）、建造者、分包者、产品，或者有时表示为视点：范围上下文，业务概念，系统逻辑，技术，物理，组件组装和操作类。整体如图 26-2 TOGAF Zachman框架

表格横向六项 代表了用于描述信息系统的某一个方面，对于任何一个事物只要在这几个基本方面对其进行清洗的解释就足够可以描述清楚。

数据（What，即什么内容）：什么是业务数据，信息或对象？

功能（How，即如何工作）：业务如何运作，即什么是业务流程？

网络（Where，即何处）：企业运营、部署在哪里？

人（Who，即何人负责）：什么人？什么是业务部门及其等级制度？

时间（When，即什么时间）：业务计划和工作流程是什么？什么时候执行？

原因（Why，即为什么做）：为什么选择的解决方案？这是怎么产生的？

表格纵向六项 代表了在信息系统构造过程中所涉及到的人在描述信息系统时所采用的视角，包括：

范围/规划者（Planner）：此视图描述了业务目的和策略，充当其他视图将被派生和管理的上下文。

业务模型/拥有者（Owner）：这是对信息系统必须在其中运作的组织的描述。

系统模型/设计师（Designer）：该视图概述了系统如何满足组织的信息需求。

技术模型/建造者（Builder）：这是系统如何实施的表示，它使特定的解决方案和技术显而易见。

详细表述/分包者（Sub-Contractor）：这些表示说明了某些系统元素的特定于实现的细节：在生产开始之前需要进一步说明的部分。

功能系统/产品（Functioning Enterprise）：在1987年的论文（《A framework for information systems architecture》）中并没有这一行的内容，实际上此行的内容也并不在架构描述的范畴的之内，不过为了使得架构Zachman框架对于架构的表述更加完备，这一行最终还是被加了进去。

根据 TOGAF 的定义，企业是具有一系列共同目标组织的集合，而架构则是为了有效地实现这一系列目标。

在实现的过程中 定义了企业的结构和运作模式的概念蓝图（SearchCIO），以及构成企业的所有关键元素和其关系的综合描述（Zachman）。通过创建、沟通和优化用以描述企业未来状态和发展的关键原则和模型以将业务愿景和战略转化成有效的企业变更的过程（Gartner）。

可以这一部分内容会比较绕，但可以作为架构设计的知识扩展进行学习理解以及运用。

四、陪你画个架构图

简单来说，架构图就是为了达成交流共识的实现方案演示，并不一定非得拘泥于某种形式，只要你能画的清楚，讲的明白就最合适不过了。

1. 架构选型图

难度：⭐⭐⭐

作用：通常在新项目开发初期，都要做一些技术选型工作。在负载、网关、架构、治理、框架、服务、数据以及环境和支撑服务上，要选择适合当前开发的技术。

2. 微服务架构

难度：⭐⭐⭐⭐

作用：技术选型完毕后，接下来就是对于这些技术的运用。这个过程有点像搭积木一样，把每一个区域用适合此位置的积木填充进去。如果是团队初建或者是技术升级，那么这个过程还是比较复杂的，需要大量的验证。不过其实互联网的技术分层和使用已经相对稳定，搭建一个这样的微服务并不会耗费太长的时间。

3. 技术架构图

难度：⭐⭐⭐⭐

作用：技术架构图主要是对于研发层面做技术实现指导的，它可以把系统分层和实现结构划分清楚。另外一般也会把案例工程的结构拿出来一起讲解，这样可以让团队伙伴快速的进入开发。

五、总结

本章节向大家讲解了什么是架构图，架构图的分类和怎么画架构图，通过这样的内容可以让大家对架构图有一个全貌的认知。在以后自己画架构图了也可以非常明确的知道面对的什么用户群体，要画的内容是什么。

TOGAF有一套非常完善的企业架构理论，它描述了一种开发和管理企业体系结构生命周期的方法，并构成了TOGAF的核心。所涉及到的知识非常丰富，值得认真看一下。

好看，能把一件事做的好看非常重要，好看能让人提起兴趣、好看可以使沟通成本降低。也鼓励大家尽可能把经过自己手里的东西，做的好看一些。