SaaS架构

.SaaS的定义

SaaS，是Software-as-a-Service的缩写名称，意思为软件即服务，即通过网络提供软件服务。 SaaS平台供应商将应用软件统一部署在自己的服务器上，客户可以根据工作实际需求，通过互联网向厂商定购所需的应用软件服务，按定购的服务多少和时间长短向厂商支付费用，并通过互联网获得Saas平台供应商提供的服务。

.如何理解SaaS、PaaS、IaaS

用一个吃披萨的例子来类比SaaS、PaaS、IaaS。

• 首先在家自己做披萨是一件非常繁琐的事，除了要发面、和面外，还需要准备好各种配料。
• 在超市买好速食披萨，回家自己烤，可能是一个更好的选择。
• 当然，更快的方式是打电话点个披萨外卖，送到家里吃。
• 也有啥都不需要准备的方式，就是直接去西餐店去吃披萨，餐桌、饮料也是店里的。

以上四种方式就对应云服务的四种层次。

企业从0到1研发一款软件系统，需要关注9个层次。分别是应用、数据、运行库、中间件、运行系统、虚拟化技术、服务器、存储、网络。

虚拟化技术、服务器、存储、网络是软件的基础设施； 而中间的运行库、中间件、运行系统，就是利用基础设施搭建出的平台； 在平台之上就可以搭建各类应用。

不是所有企业都有独立搭建软件系统的能力，不同企业，根据财力不同，演化出不同需求：

• 大型企业为了控制成本，希望租用服务器，自己研发软件。（IaaS）
• 中型企业希望利用云平台，自己设计应用软件。（PaaS）
• 小型企业希望使用现成的软件，应用和数据都上云。（SaaS）

.架构的视角与视图

通过视图与视角，我们可以分离关注点，将复杂问题进行拆解，让每个局部的复杂度控制在一个可以接受的范围。 团队有了统一的认知坐标系，进一步促成了业务标准化，以业务标准化为基础，通过分离不变点与变化点，提炼出可复用的组件，快速响应业务需求变化。

视角（站在什么地方看）

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

把视角比作一个坐标点，那它需要一套坐标系，坐标系通常有4个维度：广度、深度、视图类型、时间。

广度是指看待事物的宽度，以业务流程为例，根据出发点不同，有时需要看一个部门内的流程，有时需要看多个部门的协作流程，有时需要看端到端跨所有部门的流程。

深度是指看待事物时，要到达哪个细节层次，例如看业务流程，需要看到组织级、部门级、还是某个岗位的具体操作步骤。看软件系统，需要看到系统级、模块级、还是一行行的代码。广度和深度一般是相互影响的，如果看待事物的广度越宽，那么层次就会越抽象，这和组织架构的设计也是相辅相成的，一般高层管理者看问题非常全面，但对细节不关注，一线执行人员，对问题的细节非常了解，但视角却非常窄。

视图类型是为利益干系人量身打造的一组关注点的集合，下文中会详细介绍。

时间维度比较好理解，就是看待事物的时间点，过去、现在、还是未来。

视图（你想看到什么）

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

企业级SaaS系统的视图可分为：商家业务架构，SaaS业务架构，应用架构，数据架构，技术架构。

其中业务架构是灵魂，应用架构，数据架构，技术架构都是支撑业务架构而存在的，这三者也统称IT架构。

业务架构

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

SaaS的业务架构：其实SaaS企业与企业客户的业务架构定义是一样的，不同的是细节内容，例如：零售企业卖的产品主要是实物商品，而SaaS企业卖的产品是SaaS软件服务。业务模式上，两者也有非常大的区别。

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

业务架构的5个核心概念:

商业模式

商业模式是帮助企业成功的“秘诀”，它通过整合企业内外部的多种要素，构建起一个全面、高效且具有独特竞争优势的运营体系。

这一体系的目的是满足市场的需求，实现各利益相关者价值最大化，并确保企业的长期盈利能力。

商业模式的核心架构由三个紧密相连的环节构成：创造价值、传递价值和获取价值。

• 创造价值：这一环节围绕客户的需求展开，提供具有吸引力的价值提案。

• 传递价值：通过优化资源配置和实施相关策略，确保价值的有效传递。

• 获取价值：通过精心设计的盈利机制，实现企业收益的持续增长。

这三个环节相互依赖，共同构成了商业模式的框架，它们协同工作，帮助企业在竞争激烈的市场中脱颖而出。

商业模式举例

因为互联网和数字化的发展，公司正在努力改变传统的商业模式，把生产、销售、交易、物流和支付等多个部分整合在一起，不受时间和空间的限制。

通过使用移动互联网、大数据、人工智能和云计算等新技术，公司正在改变消费者的购物习惯和生活方式。新零售的改变特别明显，线下实体门店向线上转型，而线上电商也在寻找扩大实体店市场机会。下面是一些典型的电商商业模式的例子：

• B2C（商家对消费者）：这是电商领域最为常见的模式，商家直接向消费者销售产品和服务。天猫、京东等平台是这一模式的典型代表。

• B2B（商家对商家）：在这一模式下，供应方和采购方通过电商平台完成交易，有效解决了供应链上游至中游的问题。1688等平台是这一模式的杰出代表。

• C2C（消费者对消费者）：在这种模式中，消费者可以直接与其他消费者交易。它强调产品的个性化和质量，提供类似于B2C的服务，但更注重服务。淘宝、微店等平台就是这种模式的例子。

• C2M（消费者对工厂）：这是一种消费者与制造商直接对接的模式，去除了中间环节，提供定制化的生产和消费，强调定制服务和增值服务。淘宝特价版、拼多多等平台采用了这一模式。

• O2O（线上到线下）：这一模式融合了线上信息获取和线下购买体验，是新零售商业模式的典型代表。许多传统企业正在积极探索O2O模式，以增强市场竞争力。

商业模式并非一成不变，它随着企业经营策略和市场环境的变化而变化。

商业模式画布

商业模式画布是一种广泛使用的规划商业模式的工具，由亚历山大·奥斯特瓦德（Alexander Osterwalder）首创。通过九宫格框架，企业能够将商业模式形象化，全面审视和分析其商业运作。

商业模式画布的核心要素：

• 价值主张：企业向客户提供哪些独特的产品、服务或价值，并解决客户的哪些问题？价值主张是企业与竞争对手区分开的关键，通过创新性、性能、定制化、质量、设计、品牌、定价、成本效益、风险降低、便捷性和可用性等元素来提供价值。

• 客户关系：企业打算与客户建立什么关系？可能的关系类型包括个性化服务、专属服务、自助服务、自动化服务、社区互动和共同创造等。

• 客户细分：企业的目标客户群体是谁？通过识别和理解客户的不同需求及特征，企业可以对客户群体进行精准细分，如大众市场、小众市场、多边市场、区隔化市场等，更好地满足特定客户群体的需求。

• 核心资源：企业为了支持商业活动，有哪些重要的资源？这些可能是实体资产、知识、员工、或者金融资产等。

• 关键活动：企业需要进行哪些主要活动，来确保产品或服务的顺利运作？这些活动可能包括产品制造、问题解决、平台构建和服务网络搭建等。

• 渠道通路：企业通过哪些途径将产品或服务传递给客户？渠道通路的构建涉及五个阶段：认知、评估、购买、交付和售后。渠道类型包括自有渠道（如实体店）、合作伙伴渠道（如分销商），同时还需考虑线上、线下和O2O等新零售渠道。

• 合作伙伴：企业需要与哪些上游或下游的企业建立深度合作关系？合作伙伴关系可能包括战略联盟、竞争合作、新业务合作以及供应商与购买方关系。合作的实质在于资源共享和互利共赢。

• 成本结构：企业在商业运作中是否充分考虑了成本因素？成本结构可以是成本驱动型或价值驱动型，需要考虑固定成本、变动成本、规模经济和范围经济等。

• 收入来源：企业的主要收入途径是什么？收入的生成方式包括产品销售、使用费、订阅费、租赁费、授权费、交易费和广告费等。

下图所示为滴滴企业的商业模式画布：

价值流

价值流的相关概念包括：价值主张、价值流、价值流阶段。

价值主张

价值主张概念在商业模式画布部分已解释过。

价值主张处于商业画布的中心位置，当企业决定是否投资某个产品或服务前，首先需明确它为哪个客户群体服务？提供什么价值？以及目标客户群体能否承受产品或服务的价格？

价值流的定义

价值流的定义：为客户创造结果的端到端活动的集合，客户可能是价值流的最终客户，也可能内部使用用户。

价值流更专注于特定的目标客户和价值主张，目标明确。同时，价值流更强调结果导向和价值增长。

通过价值流分析，我们可以很容易地看出哪些环节是增值的，哪些是不增值的。理论上，我们可以消除或减弱没有价值增长的环节，这可以避免流程过于繁重，效果不明显的情况。

价值流阶段

价值流可以进一步细分为不同的价值流阶段，其中的每个价值流阶段，都会贡献相应的价值增量，以确保客户所需整体价值的逐步实现和完整交付。价值流阶段有以下几个特征：

• 每个流程阶段都有相应的“价值”。如果某个阶段不能增加或贡献到客户需要的价值，理论上可以放弃这个阶段。

• 每个阶段都有进入条件。只有满足特定条件才能进入下一步。确认和保障这些条件，有利于阶段顺利实现目标。

• 每个价值流阶段都有完成条件。设定明确的完成条件，可以快速检查是否已完成该阶段的任务，并开始下一个阶段。

我们以一个门店自提服务为例子：

• 价值主张：让消费者体验便利的自提服务

• 价值流阶段：整个价值链由5个阶段组成，分别为商品浏览、下单支付、备货并通知、自提、售后。

业务能力

业务能力指的是企业开展其业务活动所必需的一系列核心技能和资源。这些能力是从业务的角度出发，为了达成特定的目标或结果，构建的特定技能或生产能力。

企业的业务能力与商业模式和价值流密切相关，因为它们直接影响了企业的业绩和价值创造。它们确保了企业战略的实施，并与客户旅程和市场环境保持一致。此外，业务能力也协调了业务需求和IT系统。

业务能力的范畴较为宏观，它有助于企业从多角度进行战略规划和业务发展。在TOGAF（开放组织架构框架）中，业务能力的实现涉及角色、流程、信息和工具的综合运用。

在其他企业管理理论中，业务能力同样被视为企业架构中的一个重要组成部分，它包括人员、组织机构、功能、流程、业务服务、数据信息、应用系统和基础设施等多个要素，并与企业的各种项目和解决方案紧密相关。

业务能力提供了一种独立于现有组织结构、业务流程、应用系统、产品/服务的业务视角，有助于企业从更高层次上理解和管理其业务。

在业务架构体系中，业务能力的关键在于系统化地表现企业的核心业务功能。

以电商业务为例，常见的业务能力包括店铺管理、商品管理、会员营销、订单处理、物流、支付结算、售后服务等方面的综合管理。这些管理活动汇集而成的能力，构成了企业高层业务能力，并且可以进一步细分为多个子业务能力。

例如，订单处理能力可以细分为平台订单管理、自营订单管理、第三方订单管理、订单来源追踪、订单分拆处理等子能力。

业务流程

业务流程是一系列逻辑上相关联的业务活动，它们组合起来以达成特定的业务结果。在业务架构的设计阶段，业务流程扮演着至关重要的角色，它不仅关系到企业资源的有效利用，也直接影响到企业IT架构中应用功能的设计和系统整合的具体需求。

业务流程是价值流概念的进一步展开，它将价值流中的概念细化为可操作的流程。

业务流程与业务能力的区别：

• 业务能力：关注企业核心业务的能力和结果，不涉及具体的流程分解。

• 业务流程：专注于流程本身，面向特定场景，通过活动组合解决具体问题，是企业日常运作的关键。

• 业务流程涵盖关键业务活动，如销售、市场推广、生产、采购和客户服务等，以及执行这些活动的角色和他们之间的互动。同时，业务流程还需遵循行业规范、专业标准和企业内部规章。

业务流程可以进一步细化为不同层级，包括主流程和子流程。它们是连接不同业务部门的纽带，端到端流程往往跨越多个部门或业务能力领域，实现价值的增加。

以电商系统为例，用户交易流程是一个相对标准化的流程，通常包括以下环节：

• 商品选择：用户浏览电商平台，选择想要购买的商品，并添加到购物车。

• 购物车确认：用户查看购物车中的商品，可以修改数量或删除不想购买的商品。

• 结算：用户选择“结算”选项，准备进行支付。在此步骤，用户还可以选择或添加配送地址。

• 支付：用户选择支付方式（如信用卡、支付宝、微信支付等），输入必要的支付信息进行支付。

• 订单确认：支付完成后，系统生成订单，确认购买的商品和支付详情，并通常通过邮件或短信形式发送订单确认信息给用户。

• 物流处理：订单信息传递给仓库，开始打包和发货流程。

• 发货与跟踪：商品发货后，用户可以通过订单系统跟踪物流状态。

• 确认收货：用户收到货物，并确认收货。

业务流程可以进一步细化为不同层次，提供更具体的管理和执行指南。通过分层方法，企业能够确保业务流程设计与价值流的每个环节紧密相连，从而在不同层级上实现价值的最大化。通常包括以下几个层次：

• 流程类别：大类别，如采购、销售、生产等。

• 流程组：在同一类别下的相关流程集合，如订单处理流程组可能包括订单接收、订单确认、订单履行等。

• 流程：具体的操作步骤，例如订单确认流程可能包括接收订单、审核订单、确认库存、生成配送单等步骤。

• 子流程：流程中的更详细步骤，如审核订单可能细化为验证客户资料、检查支付状态等。

• 任务：最基本的操作单元，具体到个人的具体工作，如输入客户订单数据、打印配送单等。

组织架构

组织架构是按照企业战略来设定和安排部门和岗位，形成稳定且科学的管理体系。这个体系保证企业能适应业务需求并支持企业发展。

组织架构对于业务架构至关重要。在梳理业务流程时，必须根据业务流程的运作规律和处理逻辑，在流程的各个节点上安排合适的人员，确保组织的灵活性和明确的责任分配。

同时，业务架构也需要考虑组织的业务需求和发展，对部门的岗位设置、人员配置、角色定义、权限分配、职责明确以及考核机制进行清晰的规划，保障业务流程中每个环节的顺利运作。

下图所示为一个中小连锁企业的组织架构图。

应用架构

基于业务架构，设计出应用系统的层次结构，包括系统、应用、模块、组件等构件的划分规范，它们的定义、边界、相互间的交互协议，以及它们和业务活动的关系。

数据架构

数据架构描述了一系列的模型、策略、规则、标准，它们决定数据如何获取、如何存储、如何分布、如何集成，以及数据如何在系统和组织中使用。数据架构是企业架构中非常重要的一块架构领域，通常包括3个架构过程，概念模型设计（设计业务概念模型）、逻辑模型设计（设计模型间的逻辑关系与自身属性）、物理模型设计（设计数据的技术实现细节）。

技术架构

技术架构描述了一系列的可部署的软件包、硬件能力，以及它们之间的协作关系，通过它们可以支撑起企业对业务、数据、应用服务的需求，它们包括但不限于IT基础设施、中间件、网络、通信设施、运算能力、硬件标准等。

.SaaS的分类

SaaS根据客户服务内容可分为2类，分别为业务垂直型、行业垂直型。

SaaS赛道是一个超级大赛道，足够容纳上万家服务商，不太可能有哪个服务商能满足所有场景，大部分SaaS服务商在某个垂直领域，提供差异化的产品和服务。SaaS产品大部分都是面向B端客户，少部分面向C端客户。

业务垂直型

业务垂直型SaaS指的是，针对企业的业务流程的某一阶段提供的工具。例如：法大大是针对电子签章环节提供SaaS产品，北森是针对人力资源，销售易针对客户管理。

业务垂直型SaaS通常会跨多行业，因为一个行业的市场规模非常有限。同时，由于该SaaS只涉及企业流程的部分环节，更容易实现标准化。

行业垂直型

行业垂直型级SaaS，指的是聚焦在某一行业深耕的产品，产品复杂度相对较低，也更容易构建竞争壁垒，对于重视规模化的巨头们对该赛道也不感冒。

.SaaS的特征

1.可配置、可定制

可配置、可定制是SaaS软件的一个显著特征，客户可以变更一系列的配置选项，这些配置会影响SaaS软件的功能和界面展示。同时，客户还可以做一些个性化的定制，不过这些定制点是提前定义好的。例如，客户可以在界面上加入品牌Logo，或者改变配色。但是客户一般不能随意改变界面布局，除非是深度定制服务。

2.快速交付

SaaS软件的迭代速度非常快，大部分SaaS软件都可以做到按周或按月更新，主要是因为： 软件应用是中心化部署的，更新完全是由SaaS服务商说了算，不依赖客户。

系统、配置都只有一套，开发、测试能够更快，服务商也不需要管理、维护多版本的软件。

服务商有权限访问客户数据，排查问题和回归测试都更加便捷。

服务商能够方便地采集用户行为，并及时回顾需求价值，快速改进。

这个特征非常符合敏捷开发理念，也让SaaS模式能快速响应市场需求。

3.开放集成

SaaS软件没有办法访问企业内部系统，一般而言，SaaS软件都会提供开放API，通过这些API，企业内部系统可以和SaaS软件打通。

4.多租户

SaaS软件以一套标准系统支撑大量的客户（又称租户），租户之间需要数据隔离、配置隔离，保证每个租户的安全与隐私，同时，不同租户对UI界面、业务逻辑、数据结构有个性化需求，这对软件平台的性能、稳定性、扩展性带来了巨大挑战。

.SaaS的挑战

1.数据存储在云端服务器上，数据安全是个隐患。

2.因为SaaS是多租户架构，对软件性能有非常大的挑战。同时，无法满足大客户的大规模地定制，通常只能在有限的范围内定制。

3.一些商业SaaS软件，需要与客户的数据打通，客户的数据量可能非常庞大，远程传输可能有巨大开销，如果包含敏感数据，可能有安全风险，甚至违反法律法规。

4.如果客户要放弃原有系统，切换到SaaS产品，需要迁移大量历史数据，这也是一项非常艰巨的任务。同时，客户内部也需要增加大量新软件的培训成本，承担新软件未知的、不稳定的风险。

5.如果SaaS服务商突然倒闭，客户无法访问SaaS软件，可能导致客户的业务无法开展，甚至客户的历史数据也将永久无法访问。

6.SaaS软件依赖互联网进行数据传输，速度远比企业内网要慢。

7.SaaS需要保障SLA中约定的稳定运行时长。

SLA（服务水平协议）是在供应商和客户之间签订的一份合同，用于规定和约定服务提供商对服务的各种承诺和保障，包括服务的质量、性能、可靠性等方面。

对于SaaS服务提供商而言，保障SLA中约定的稳定运行时长是非常重要的，因为用户依赖于其提供的软件服务来支持自己的业务运作。SLA中关于稳定运行时长的约定通常指的是系统的可用性，即系统能够保持正常运行的时间比例。通常情况下，SLA中对可用性的要求会给出一个百分比，如99.9%的可用性，这意味着系统每年最多只能有不到9小时的停机时间，以保证服务持续稳定地提供给用户。

保障SLA中约定的稳定运行时长对SaaS服务提供商来说至关重要，因为这直接关系到用户对服务的信任和满意度。如果服务经常出现故障或停机，不仅会影响用户的正常使用，还可能引起用户的不满和流失，影响供应商的声誉和业务。因此，SaaS服务提供商在运营过程中需要不断监控和维护系统，保障SLA中约定的稳定运行时长，确保用户能够持续享受高质量的服务。

B端SaaS产品的挑战

B端SaaS产品为企业提供协同办公的工具，帮助企业解决某类经营管理问题，核心价值在于增加收入、降本提效、管控风险。

一般会按业务垂直或行业垂直来细分:

• 业务垂直型的SaaS产品有CRM、人力资源、ERP、推广营销、财税、OA等细分市场；
• 行业垂直型的产品有零售、餐饮、旅游、教育、医疗、物流等细分市场。

B端SaaS产品有以下特点

• 客户是一个群体：B端SaaS产品为某个企业组织服务，一项业务目标通常需要由多名角色完成，例如，订单履约流程，需要消费者、运营人员、仓储人员、配送人员共同完成，产品帮助他们高效完成分工协作。

• 功能繁杂：由于B端SaaS产品涉及企业经营的方方面面，关联的用户角色多、业务流程长，反应到产品上，菜单、界面、配置项特别多，复杂度远高于C端产品。为了实现一项功能需求，往往会影响其他许多功能，需要进行全面的梳理，考虑各种极端情况，才能保证整体功能正常。

• 定制化功能：B端SaaS产品必然会有很多定制化需求，如果一味抗拒，很容易丢掉一些优质客户，但如果大包大揽地接受，系统复杂度会指数级上升，高昂的研发维护成本将很难承受，所以如何处理好定制化需求，是一项非常艰巨的任务。

• 见效慢、难量化：由于B端SaaS产品的客户是一个群体，产品上线新功能，通常是管理层先评估，能否在企业中适用，如果合适，才会组织一线人员，进行操作培训。这样一来一回，可能要2个月后才有客户正式使用新功能。其次，业务见效的影响因素非常多，很多时候并非因为产品设计问题。

这些特点都会导致SaaS产品的软件架构错综复杂，很容易严重腐化，演变成难以维护的“大泥球”，最终导致产品丧失竞争力，被市场淘汰。

下面通过一个SaaS产品的生产系统的简易模型，来描述SaaS产品的各个发展阶段的状态。

1. 生产系统刚开始的状态
2. 业务越来越复杂，架构腐化严重，生产系统的状态
3. 期望的生产系统状态

B端产品最难模块：组织管理的底层逻辑与架构设计

组织管理模块属于B端产品非常底层的架构，非常考验架构能力，几乎所有的业务场景都需要应用组织数据，背后反应的是企业决策层的经营战略和财务战略，因此需要掌握一定的企业管理知识和财务知识，如果能够掌握组织管理的概念和要点，对设计好B端产品帮助巨大。

.企业架构

企业架构既包括对企业的愿景、战略、业务、组织的分析，又包括基于业务架构进行的应用系统分析与设计，是非常全面的架构设计框架。

在软件研发过程中应用企业架构，循序渐进掌握好企业数字化转型的方法论，企业架构可能是需要重点关注的解题方法。

企业架构的历史

1996年，克林格.科恩法案颁布，美国联邦政府立法，强制要求政府机构使用企业架构理论构建自己的IT系统，最重要的机构是国防部、财政部，这一举措，直接让政府机构的数字化水平，像坐上火箭般高速发展。

同一时间，大名鼎鼎的TOGAF也逐步形成，它大量参考了政府机构的企业架构理论，沉淀出一套更加通用的企业架构方法论。

目前80%的福布斯排行榜前50名的企业，以及60％的美国500强企业，都在使用TOGAF理论改善自身的IT架构。

TOGAF（The Open Group Architecture Framework 开放式集成平台企业架构）是一种用于开发和管理企业架构的框架，它由Open Group制定，并提供了一种方法论来帮助组织设计、规划、实施和管理其企业架构。以下是TOGAF框架的主要内容：

1. 企业架构概述：包括了对企业架构的定义、目的和好处，以及TOGAF框架的概述和目标。这部分介绍了为什么企业需要架构，以及如何利用TOGAF来管理和优化企业架构。

2. 企业架构开发方法 Architecture Development Method（ADM）：ADM是TOGAF框架的核心部分，提供了一种逐步的方法来开发、实施和管理企业架构。ADM包括了以下几个主要阶段：

   • 预备阶段（Preliminary Phase）：准备和启动企业架构项目。
   • 防御阶段（Phase A）：建立企业架构的基础。
   • 业务架构阶段（Phase B）：描述和分析业务架构。
   • 数据架构阶段（Phase C）：设计和分析数据架构。
   • 应用架构阶段（Phase D）：设计和分析应用架构。
   • 技术架构阶段（Phase E）：设计和分析技术架构。
   • 机会和解决方案阶段（Phase F）：确定机会和解决方案。
   • 迁移规划阶段（Phase G）：制定迁移计划。
   • 实施和改进（Phase H）：实施企业架构并持续改进。

3. 企业架构内容框架：包括了对企业架构的各种视图和模型的详细描述，如业务架构、数据架构、应用架构、技术架构等，以及如何在这些层次上进行建模和描述。

4. 企业架构能力框架：描述了企业架构管理和能力的组成部分，如组织结构、流程、工具和技术，以帮助组织建立和管理有效的企业架构实践。

通过TOGAF框架，企业可以采用标准的方法来制定和管理企业架构，促进业务和信息技术之间的协作和整合，实现企业的战略目标和优化组织运作。

企业架构期望解决的主要痛点问题

• 信息孤岛：业务与IT技术存在信息鸿沟，各业务域间存在信息鸿沟，协作效率低下。

• 标准不一：业务概念非标准化，系统边界划分复杂混乱，技术标准不兼容。

• 灵活性差：新业务无法基于已有的解决方案和能力快速组装上线，业务无法快速迭代创新。

企业架构的价值

认知框架带来效率提升的价值

要说清楚认知框架的价值，首先要了解什么是认知负荷。认知负荷是专业的心理学理论，简单来说就是，人脑的短时记忆和处理的信息数是极其有限，一般人就2-3条信息，牛掰点的4-5条。但是，长时记忆的容量几乎是无限的，长时记忆就是我们积累的知识。知识以框架的形式存储于长时记忆中，框架就是根据信息元素的使用方式来组织信息，它提供知识组织和存储的机制，可以减少短时记忆负荷。

说人话就是，人脑的短时记忆和长时记忆，可类比为内存和硬盘，人脑的内存容量就芝麻点大，只能存储2-3条信息，但硬盘空间是无限的。为了提高人脑处理效率，就必须将信息进行抽象，原来有30条信息，抽象后就变3条了，这样就能处理过来了，而抽象的框架就是我们要说的架构。

其实整个研发周期，真正在生产（敲代码）的时间非常少，可能连20%都不到，产研团队大部分时间都花在澄清信息和认知信息上，有了认知框架，能够显著降低整个团队的认知负荷，进而极大地提升生产效率。

质量提升的价值

这个比较好理解，通过架构规划和治理活动，可以有效提升整个软件系统的质量属性。

产品层面的质量属性

• 功能性：指软件产品能够提供正确的、符合预期的结果，能够安全地保存信息和数据，用户权限与访问权限匹配等。

• 易用性：指产品对用户来说易理解、易学习、易操作。

技术层面的质量属性

• 稳定性：不容易出故障，出了故障也能快速恢复。

• 性能：软件的响应时间符合预期，在极端场景下（例如高并发、大批量数据处理等），也能维持一定的性能水平。

• 可维护性：软件容易修改，不会牵一发而动全身；容易调试和修复bug；容易落地自动化测试。

自我约束的价值

系统不做什么和能做什么同样重要，就像成功的经验需要固化下来，并规模化复制。

成熟的认知框架也需要固化下来，并约束团队，让团队在正确的路上行进，错误的路就别再尝试了。

例如，团队A做了商品管理，其他团队拿去用就行了，别再重复造轮子，最终导致一座座数据孤岛。

可能有人会说，这会约束团队创新吧？但创新和荒诞常常就一步之遥，这一步可能就是遵守最基本的约束规则。

企业架构的概念模型

目标

指的是企业的宏观业务目标或战略，一般会依赖多个业务能力来实现。

业务项目

指的是长期的、持续性的业务项目，一般需要制定明确的经营计划和财务预算。

业务能力

业务能力描述了企业目前能做什么或需要做什么。 业务能力建模的关键点在于它定义了企业做什么，而不是如何做（由业务流程描述）。业务能力独立于组织架构、业务流程、资源，准确地说，这些业务要素是支撑企业的业务能力而存在的。

以“招聘人才”为例，“招聘人才”包括人力部门（人力资源团队）、业务流程（例如吸引、筛选、面试、雇用）和IT系统（例如招聘系统、人事系统）。

准确定义的业务能力是非常稳定的，在过去的几十年中，招聘的流程、技术、模式发生了翻天覆地的变化，但“招聘人才”这项业务能力始终恒定存在，业务能力遵循高内聚、低耦合的特性，正是因为业务能力的这些特性，业务能力对构建IT架构提供了至关重要的帮助，围绕业务能力构建的IT系统会具备更加稳定的结构，并易于扩展。

组织架构

想要深入理解企业的组织架构，是非常困难的一件事。因为大部分人都没有实际经营过一家企业，更没有参与设计过企业的组织架构。但组织架构属于 B 端 SaaS 产品非常底层的架构，非常考验架构能力，几乎所有的业务场景都需要应用组织数据，背后反应的是企业决策层的经营战略和财务战略，因此需要掌握一定的企业管理知识和财务知识，如果能够掌握组织架构的概念和要点，对设计好 B 端 SaaS 产品帮助巨大。

业务流程

是指为达成特定业务目标，由不同的角色分工完成的一系列活动。活动之间不仅有严格的先后顺序限定，并且活动的内容、方式、责任等也都必须有明确的安排和界定，让不同活动在不同岗位角色之间进行流转与交接。

业务流程对于B端产品的意义不仅在于对B端客户业务的一种描述，更在于SaaS产研团队对B端业务运营的理解和剖析，这种理解是对企业资源的优化、对企业组织机构的优化以及对管理制度的一系列深入探究。只有真正理解业务流程，才能帮助B端客户达成期望的目标：降低企业运营成本，提高市场需求的响应速度，争取企业利润的最大化。

应用系统

即应用系统的架构设计，它起到统一规划、承上启下的作用，向上承接了企业战略目标和业务发展，向下规划和指导各个IT组件的定位和功能定义。通常包括系统、容器、组件、代码等元素的划分规范，以及它们的定义、边界和交互协议。

服务

应用系统间的交互协议，具备一定的服务功能，并且提供给外部使用。

IT组件

具体的IT技术组件，例如，mysql、kafka、虚拟机、es等。

提供方

提供和维护IT组件的人，一般是运维团队。

技术类别

通过抽象IT组件的共性特征，对组件进行分类的方法，用于管理IT组件。

组织管理的概念

所有管理分类法，最终都会在组织架构上体现，因为组织架构是经营理念的载体。

组织单元

所有的组织都是由组织单元构成，这里的组织单元是一个抽象的概念，可以类比为一个装东西的容器，可以往里面装个人/团体、业务流程、资源等生产要素。

组织单元上下级关系

组织单元间有上下级关系，缺省的应用场景至少有汇报和数据统计汇总。

组织树

组织单元通过上下级关系联系在一起，就形成了一颗组织树，组织树需要明确关联一种组织视图类型。

组织视图类型

把所有组织单元关联在一起，形成一颗巨大的组织树，对于中大型零售企业来说，这种做法是毫无意义的。因为中大型企业，内部分工明确，通常会划分为多个业务系统，例如采购系统、供应链系统、销售系统、仓配系统、CRM系统、HR系统、财务系统等，这些系统都会以不同的视图来使用组织数据。

因此，会引入组织视图类型的概念，以多组织视图的方式来管理和使用组织数据。这里列举一些常见的组织视图类型：

• 业务组织类型：企业按照特定的业务模式区分出的一种组织类型，例如零售企业的运营组织，他们需要制定企业和分店的业绩目标，推动业绩目标实现，并对各个分店进行管理，指导分店作业。业务组织类型可以根据管理复杂度进一步细分，例如运营组织、采购组织、物流组织等
• 行政组织类型：和上文的部门岗位分类法的管理逻辑一致。对应于企业中真实存在的组织单元，是指各个层级、各类部门、各个职位等所共同构建的一个完整团体，按照职能目标分工，每个职能岗位有明确的权责分配、工作流程，是企业内部当前真实的结构。
• 财务组织类型：财务组织单元是独立会计核算的主体，主要用于财务会计系统，每个财务组织单元都有一套完整的账套，同时能够独立出三大财务报表：资产负债表、损益表、现金流量表，一般法人主体都会对应一个财务组织。
• 责任中心类型：和上文的责权分类法的管理逻辑是一致的，责任中心是管理会计的概念。责任中心是承担一定经济责任，并享有一定权利的组织单元。责任中心可划分为成本中心、利润中心和投资中心。

组织单元的形态

是组织单元的形态说明，例如：集团、公司、分公司、事业部、部门、区域、门店、电商网店等。需要特别注意，本质上是一种组织单元的标签，对业务应用不产生影响，只是便于团队达成理解共识。

组织单元的法人属性

明确组织单元的法人属性，包含：法人企业（形态=集团、公司）、法人分支机构（形态=分公司、加盟商）、非法人机构（形态=事业部、部门、门店等）。

组织单元的责任中心模式

责任中心模式可划分为成本中心、利润中心和投资中心，用于管理会计分析使用。

组织单元的业务能力

明确组织单元的可执行的业务范围，例如：门店销售能力、加工能力、库存能力、要货能力、线上销售能力等。

组织单元的业务终端属性

如果组织单元是业务终端，一是代表该节点是组织树的叶子节点，二是代表该节点直接从事一线的业务活动。业务终端的典型形态就是门店、电商网店、配送中心。

组织单元的数据共享模式

全局共享模式、部分共享模式、完全隔离模式。

企业架构在SaaS中的应用场景

赋能企业数字化转型是SaaS产品非常重要的发展方向，而数字化转型最重要的一步，就是将企业的业务模式和商业模式从真实世界搬到数字世界，这需要对业务进行全量全要素的建模和采集。

企业架构在国外已经发展了二三十年，为什么又被重新提及。因为企业架构是一套非常优秀且在国外有大量成功案例的架构方法论，能够显著提高数字化的效率和质量。

我们以零售行业为例，列举一些数字化水平低的经营痛点。

会员数字化水平低

门店与会员互动的渠道主要是个人微信号，个微限制较多导致大量会员流失。

门店会员缺乏触达渠道，进店率低，由于疫情原因，会员招募逐年下滑。

会员被掌握在导购个人手上，随着人才流失而流失。

会员数据没有合理采集和使用，只能基于销售数据或财务数据决策，单客价值挖掘效率低下。

渠道数字化水平低

线上线下交易履约流程没有标准化，线上运营主要依赖外部人员，业务数据散落在各处。

渠道全链路数据无法收集，没有数字化手段洞察消费者需求，不同渠道的商品布局规划只能依赖经验做决策。

渠道商对数字化认知低，前端用户数据收集难，系统打通难。

烟囱式的系统架构

企业内部系统烟囱式发展，系统之间数据没有打通，数字资产无法共享，无法相互连接。形成一座座数据孤岛，完全没有发挥出数据的价值。

建设IT系统非常烧钱，企业花了大把的投入，但缺乏企业自上而下的全局设计，对业务收益甚微。

零售企业运转简易模型

零售企业内部可以抽象为3大要素：组织、流程、资源。

• 组织：为了经营好一家企业，相互联系起来的集体或团体。

• 流程：为达成某个业务目标，由不同人分工完成的一系列活动，这些活动通常有严格的先后顺序，而且活动的内容、方式、输入输出等也有明确设定。例如，门店要货流程、订单履约流程等。

• 资源：既包括有形资源，例如资金、机器设备、门店等，又包括无形资产，例如品牌资源、信息资源、技术资源等。

零售企业的外部环境也可抽象出一些核心要素：设计者、盈利目标、分钱规则、经营结果。

• 设计者：通常是企业的决策层，他们合伙创办的公司。

• 盈利目标：例如，先定个小目标，赚他一个亿。

• 分钱规则：所有零售企业的财务目标都是赚钱，赚完钱要按照事前定好的分钱规则，给组织各团队分钱，这样才能保障机器正常运转，不然机器就罢工了。

零售企业运转的过程可以抽象为，决策层给机器一个输入（盈利目标、分钱规则），过一段时间（通常是按财务核算周期划分），机器产出经营结果（各类经营数据、收入、成本、利润等财务数据）。

当然，决策层不会只给个输入就完事了，一般还会在事前、事中、事后，做一些管理动作，主要是对各个要素进行调整，例如调组织、调流程、调资源等。

其中，想重点强调的一个要素是经营结果，决策层需要通过观察经营结果，根据分钱规则给组织分钱或惩罚，但这需要数据支撑，需要知道每个团队创造的收入多少，成本多少，费用多少。

除此之外，决策层还需要做一件很重要的事情，就是复盘经营结果，做好根因分析，在下个周期开始前，将企业这台机器调整到最佳状态，提升下个周期的业绩。

这些分析工作都需要大量结构化的数据支撑，而这些结构中最重要分析维度，就是管理分类维度。

零售管理主流分类法

零售企业是一个高度复杂的业务性、社会性系统。

它包含众多的要素：组织、地理位置、资源、流程、经营理念，以及将它们有机组织在一起的机制。

一种非常重要的管理方法论是将这些要素划分为多维度的分类视图，然后对每种分类视图进行经营管理，只要每种分类都能管理好，叠加在一起大概率就能管理好企业。

通过这些分类法，零售企业可以组织好他们的决策和执行计划，同时，也可以抽象或细化出待解决的问题。

商品分类法

即商品品类管理，长期以来，百货超市的基础经营管理体系就是品类管理。品类管理就是对商品进行不同角色定位，确定不同的品类策略。

大多企业一般划分五大品类策略：目标性品类、重点品类、补充性品类、季节性品类、便利性品类等。不同的企业会有不同的品类划分及策略。

商品品类管理的核心经营理念是通过商品影响顾客，把门店的商品形象准确地传递给消费者，通过商品打动消费者，让消费者能加购或持续复购，最终提升门店业绩。

责权分类法

上文提到零售企业是一个高度复杂的业务性、社会性的系统。责任分配是经营企业的非常重要的一种机制，该机制能让零售业务灵活扩展。

从模型上看，责权分类法主张将企业划分为一个个责权明确的组织单元，他们通常具备一定范围内的责权，并且计划、执行、度量各自的业务活动。

这个概念非常重要，尤其是在产出经营报表的时候。在财务核算时，收入中心、成本中心、利润中必须关联某个组织单元，这样才能产出可衡量的经营成果。

地理分类法

一些跨地域的零售企业，会按照地理维度来划分企业的经营活动（例如，省市区县乡镇、华东华中华南大区等）。

与企业责权分类法相比，地理分类法提供了一种不同的管理视图，它能够帮助零售企业洞察经营活动背后的一些额外的因素，这些因素可能会严重影响企业的业绩结果，例如，地域差异、人文差异、地理环境差异等。

这里需要注意一点，有些企业表面上看按地理分类法划分组织，例如，华东区、华中区、华南区，但是，本质上是责权分类法，核心要看是否使用财务的衡量体系来考核这些组织单元（收入、成本、费用等指标）。

部门岗位分类法

部门岗位分类法将组织划分为一系列的部门和岗位，这种分类法是根据部门岗位的工作性质、责任轻重、难易程度和所需专业资质等进行分类，划分为若干种类和等级，对从事不同工作的人，用不同的要求和方法管理，以“因事择人”为中心的管理方法。

这里特别注意，有些企业，部门岗位分类法划分出的组织和责权分类法划分出的组织，可能看起来差不多，但底层逻辑是完全不一样的。 部门岗位分类法是面向人和事，以“因事择人”为中心的管理方法。 而责权分类法是面向组织单元（这里的组织单元并不是指具体的人和事，可以类比为一个装东西的容器，可以往里面装个人/团体、流程、资源等生产要素），以收益和成本为中心的管理方法。

从先后顺序来看，先有责权架构，再有部门岗位架构，就好比先立王，再招兵买马，立王象征责权建立，随后才牵动人和事的建立。

从粒度上看，责权架构粒度也会比部门岗位架构更粗。

连锁企业的组织结构模型

根据连锁企业发展的几个阶段，可以分为小型连锁经营组织（1-10家门店）、中型连锁企业的组织结构（10-50家门店）、大型连锁经营组织（50-150家门店）、多元化大型连锁组织（150以上家门店）。

小型连锁经营组织（1-10家门店）

小型连锁企业可以采用直线型组织，这种组织结构适用于门店数量不多、经营集中的零售商家，属于初创期的连锁企业。

由于连锁企业在初创期规模较小，管理并不复杂，总部业务老板一人负责就行，各分店经营对老板负责。

中型连锁企业的组织结构（10-50家门店）

当连锁企业规模不断扩大，商品品类不断增加，经营区域不断扩大，这时，就需要增加相应的职能部门。

大体上，中型连锁企业在组织分层上分为两层：上层是管理型组织；下层是门店。

中型连锁企业组织结构图中，部门按照职能设置，但是，门店运营部会按照区域划分分店。

如果连锁企业是复合型的，除设置直营连锁门店外，还应设置相应的特许连锁门店、自由连锁店等职能部门。

中型企业组织结构的特征：

优点：各部门职责明确，分工明确。

缺点：需要沟通协作，成本高、效率低。

大型连锁经营组织（50-150家门店）

大型连锁企业的特点是，门店数量多，地域分布广，甚至是跨国经营。一般采用多层次或事业部组织架构。

总部主要承担对企业政策、发展规划的制定、监督、执行，协调和统一各区域管理部的经营活动。

大型企业组织结构的特征：

优点：各区域在总部的指导下，负责本区域经营活动，处理门店日常的经营管理，总部不用管理终端细节。

缺点：管理层级多，各层次的沟通困难，协调问题多，决策路径长，组织无法快速适应变化。

多元化大型连锁组织（150家以上门店）

多元化企业是指企业拥有多项业务单元并独立发展。

事业部是总部为促成某专项事业的发展而设置的，它拥有一定的经营管理权，独立核算，具有法人地位。

多元化经营连锁企业的各项事业发展到一定规模时，每个事业部下面还要设置区域管理部，来管理门店的运营工作。

从管理的角度看，组织架构应该由金字塔结构尽量向扁平化结构转变，借助现代化的信息技术，缩短管理层级和决策路径，扩大管理幅度，提高管理效率。

管理层的责任就是营造一个稳定的和自适应的组织架构，需要设计好管理运作机制、组织文化、股权激励和分权等。

下面列举了永辉2010招股书、苏宁易购2013披露的组织架构。

永辉2010招股书披露的组织架构

苏宁易购2013披露的组织架构

SaaS架构实践

商品系统架构设计