企业级SaaS架构实战（2）：架构视图与视角

企业级的SaaS系统涉及的利益干系人众多，那么该如何将其做好分类，便于快速获取相应信息？本文将介绍SaaS架构视图与视角，便于你了解相关内容，更好展开工作。

把企业级SaaS系统架构描述清楚，是一项极其复杂的工作。

因为企业级SaaS系统涉及的利益干系人众多，例如：客户、产品经理、研发、销售、运营、管理层等等。由于背景不同，认知不同，每个人看待它的角度、方法都各不相同。

为了控制复杂度，我们需要设计一整套架构描述物，并且为它们做好分类和定义，让每种架构描述物都有自己的侧重，让每个利益干系人都能快速获取关注的信息。

为了达成这个目标，首先需要理解视图与视角的概念。

一、架构的视角

什么是视角？大白话就是你站在什么地方看。

我们以城市系统为例，你站在城市的某条马路上，能看到什么？能看到几座楼房，几排树木，几条大马路，熙熙攘攘的一些人。但是你站在飞机上看，能看到什么？能看到一片一片的楼盘，能看到群山，能看到江河湖海。所以，你能看到什么和你站在什么地方看有很大关系，同时也会影响你看事物的粒度。

如果把视角比作一个坐标点，那它需要一套坐标系，坐标系通常有4个维度：广度、深度、视图类型、时间。广度是指看待事物的宽度，以业务流程为例，根据出发点不同，有时需要看一个部门内的流程，有时需要看多个部门的协作流程，有时需要看端到端跨所有部门的流程。深度是指看待事物时，要到达哪个细节层次，例如看业务流程，需要看到组织级、部门级、还是某个岗位的具体操作步骤。看软件系统，需要看到系统级、模块级、还是一行行的代码。广度和深度一般是相互影响的，如果看待事物的广度越宽，那么层次就会越抽象，这和组织架构的设计也是相辅相成的，一般高层管理者看问题非常全面，但对细节不关注，一线执行人员，对问题的细节非常了解，但视角却非常窄。视图类型是为利益干系人量身打造的一组关注点的集合，下文中会详细介绍。时间维度比较好理解，就是看待事物的时间点，过去、现在、还是未来。

二、架构视图

什么是视图？大白话就是你想看到什么。

视图是为利益干系人量身打造的一组关注点的集合。

同样以城市系统为例，想要赶早高峰的上班族，他的关注点是哪条路线最快，因此他需要一副地铁公交路线图；想要租房的租客，他的关注点是公司附近有哪些小区，租金多少，因此他需要一副出租房源图；想要疏通下水道的工人，他的关注点是下水道是怎样排布的，因此他需要一副下水道的排布图。

同一个城市系统，不同角色的关注点是完全不一样的，想要获取的信息也是完全不一样，如果把所有信息杂糅在一起，不做视图隔离，导致的结果就是信息太庞杂，每个人都很难获取想要的信息。

同理，不同干系人看待软件系统的关注点也是迥然不同的，为了把不同人的关注点区分开，诞生了很多软件视图的分类方法，比较著名的有“4+1”视图，TOGAF的业务架构、应用架构、数据架构、技术架构等视图分类法。

企业级SaaS系统的视图可分为：商家业务架构，SaaS业务架构，应用架构，数据架构，技术架构。其中业务架构是灵魂，应用架构，数据架构，技术架构都是支撑业务架构而存在的，这三者也统称IT架构。

商家的业务架构s：为了实现企业的业务战略，企业将自身业务结构化表达为全面的、多维度的抽象模型，包括：业务能力、端到端的价值交付、信息和组织结构，它们之间的关系，以及它们与战略、产品、策略、项目执行、利益干系人之间的关系。

这里多了个“s”，并不是打错，代表复数的意思，由于SaaS软件需要服务数量庞大的B端客户，这些客户可能有多种业态、不同规模、不同行业，这意味着它不能只分析一家商家的业务架构，而需要分析多种业态下商家的业务架构，这也是SaaS系统设计复杂的原因之一。

SaaS的业务架构：其实SaaS企业与企业客户的业务架构定义是一样的，不同的是细节内容，例如：零售企业卖的产品主要是实物商品，而SaaS企业卖的产品是SaaS软件服务。业务模式上，两者也有非常大的区别。应用架构：基于业务架构，设计出应用系统的层次结构，包括系统、应用、模块、组件等构件的划分规范，它们的定义、边界、相互间的交互协议，以及它们和业务活动的关系。数据架构：数据架构描述了一系列的模型、策略、规则、标准，它们决定数据如何获取、如何存储、如何分布、如何集成，以及数据如何在系统和组织中使用。数据架构是企业架构中非常重要的一块架构领域，通常包括3个架构过程，概念模型设计（设计业务概念模型）、逻辑模型设计（设计模型间的逻辑关系与自身属性）、物理模型设计（设计数据的技术实现细节）。技术架构：技术架构描述了一系列的可部署的软件包、硬件能力，以及它们之间的协作关系，通过它们可以支撑起企业对业务、数据、应用服务的需求，它们包括但不限于IT基础设施、中间件、网络、通信设施、运算能力、硬件标准等。

总结

通过视图与视角，我们可以分离关注点，将复杂问题进行拆解，让每个局部的复杂度控制在一个可以接受的范围。

同时，团队有了统一的认知坐标系，进一步促成了业务标准化，以业务标准化为基础，通过分离不变点与变化点，提炼出可复用的组件，快速响应业务需求变化。

本文由 @汤师爷 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。返回搜狐，查看更多

责任编辑：