企业架构7——应用架构

在之前的文章中，我们把企业架构中的业务架构给整个的梳理了一下，我们从idea到商业模式、到价值链、到流程、到能力、到职责、到绩效。

通过这样的拆分，我们清楚了怎么样去将一个项目/企业运作起来，我们再结合之前的团队管理3-组织架构（点击可查看）这篇文章，选择适合本身业务/企业类型的架构。

另外我们通过将职责与绩效挂钩，那么我们能够梳理出考核的绩效指标，对于不同层级（战略、管理控制、执行）业务的拆解，负责相关层级的人分别考核什么指标，我们也能够有一个清晰的指标和框架。

在我们将业务梳理清楚之后，为了提高效率，让业务更好的运转，让业务能够自动化的运转。

我们将原来通过线下、手工操作的业务流程进行线上化、信息化，也就是打造适配业务的IT系统，让业务减少对人的依靠，减少人这个变动因素对事情运转的影响。

为了打造这个系统，我们需要先梳理应用架构。

应用架构一般也称产品架构，此处的产品也就是软件系统，互联网公司中的产品基本就是软件系统，但传统公司中不一样，他们本身是有实际的产品/服务等，还称呼为产品架构有时容易引起歧义。

为了便于理解，我们将名称统一为应用架构，等同于互联网公司普遍的产品架构。

IT系统包含应用、数据、技术三部分，逻辑关系如下。

应用架构的来源也是因为，因为也是为业务服务的。

接下来我们看如何从业务这个最根本的根基来搭建应用架构。

一、业务转应用架构

通过商业画布，我们能够绘制出商业模式图。

从商业模式图我们能够简单清晰的看明白这这个业务的各系统参与方，比如上图中涉及：

• 用户——发配送单
• 配送员——提供服务
• 运营方——运营整个平台

这几个是整个业务的不同参与方，他们构成了软件系统的使用方，他们会使用其中的一个端口。

比如说用户使用C端，配送员使用配送端，运营方使用运营后台。如果不是平台模式，基本就是用户及运营方，如果涉及的系统角色越多，那么使用的端口越多。

我们继续来根据核心价值链，来梳理应用架构。

A、根据实际业务逻辑，基于用户、角色、场景，梳理核心的业务流程，逐步将业务流程图简单绘制出来。

B、基于第一步梳理出来的核心业务流程，根据目标用户的使用路径进一步梳理每个核心价值节点的子流程，将功能罗列出来，

C、梳理辅助、职能流程，按照核心流程拆分方式进行

D、将功能进行分类汇总，（本质上流程节点就是功能）

E、将功能结合角色及渠道等进行布局调整。

我们从宏观上，基本能够根据以上的梳理，整理出以下颗粒度最大的应用架构。

以下以配送平台来举例，进一步梳理详细的应用架构：

以下为核心流程，为推演这个逻辑，过程不一定完全精准。

从核心流程中，我们能够看到整个应用中核心的顶级功能（很多时候也称为系统/模块）。

按照端到端的方式进行流程梳理

A、获取用户——用户账户管理

B、进行营销活动引导——营销

C、用户选择配送业务类型西单——对应商品及订单

D、购买支付——对应交易

E、系统调度——对应配送订单调度

F、配送员进行运输——配送员管理、地图

G、交付给收件人——履约

H、系统结算——财务

我们可以将部分同类功能聚合，比如用户账户管理及配送员账户管理都是账户管理，交易及资金结算都是属于财务，经过归类整理、聚合。

我们的核心功能就整理出来：账户管理、商品管理、营销管理、订单管理、调度管理、财务管理。

再加上我们的支撑辅助，包括角色权限、数据分析、我们基本能够得到如下的应用架构：

我们还可以进一步往下梳理应用架构，进一步将应用架构进行细化。比如说，我们继续梳理核心业务。

我们进一步将核心流程的下一级流程的节点进行归类整体，采取高内聚低耦合的方式，将涉及到的功能，归类到上一级之下，则能得到如下的架构图。

我们可以将本期要实现的功能与之后实现的功能使用不同的颜色进行区分，那么我们就有了三种架构图：当期实现架构图（如果已经有了我们再整理就是当期已实现机构图）；未来远期实现的架构图，规划与当下差异的部分。

我们的迭代规划就是补齐差异，针对差异部分，我们可以根据重要性及工作量等来进行多次增量的开发以达到规划的未来状态，这就是版本迭代规划的本质。

对于辅助和基础部分也依次来处理，我们就能够得到更详细的应用架构。

二、中台

中台的概念是阿里流传出来的，但是在这之前，已经有中台的实现方式，只是不叫这个名字。

本质上是有些公司不断地发展，业务线越来越多，多元化发展越来越广。如果每个公司都去自己做一套支撑系统，会导致资源的浪费，也不利于统一管理。

所有很多大公司比如大的集团公司，会对人力资源、财务、仓储、供应商进行统一的管理。这在本质上就是中台的方式。

只是在互联网时期，统一管理的业务更多，比如把订单、用户都可以进行统一管理，互相之间串通，也就是把统一管理扩大了。或者比如把数据的管理也集中统一。

因此每个公司的中台的切入点都可能不一样，实现的程度也不一样。

中台解“重复造轮子”的问题，进一步解决职能边界划分问题及“数据孤岛问题”。

但另一方面，也会造成各业务线的发展，受限于中台的功能结构，如果新业务线与传统业务线差距很多大，创新性很强，这可能导致与已有中台的功能架构差距比较大，中台反而会对新业务的发展又阻碍作用。

所以阿里最近又在拆中台，其实创建中台还是拆中台，都是围绕业务发展，IT始终是为业务发展服务的，IT是因为发展的催化剂。

如下图，当有多个业务的时候，可以把其中的支撑系统或数据等做成共用的更基础的部分，也就是中台。

作者

Markzou，8年产品经验。主要专注于本地生活、O2O、到家服务、新零售领域；曾任职于多家本地生活垂直领域头部公司，具有丰富的本地生活行业经验。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！