在开始具体讲解企业及应用的设计法之前，首先让我们先来理解下什么是应用？
相信大家在工作中经常会听到系统与应用这两个词，那么这两个词有什么区别呢？是否代表着同一个事物呢？
答案肯定是否定，这这两个词完全是不同的含义，这二者的关系可以用这张图来进行示意。
具体来说：
这里我举一个具体的例子，大家就好理解了，例如一个电商管理系统其包含了商品管理功能，订单管理功能等。这些功能被有机的整合在一起，各应用之间的数据可以跨应用流转和查询，例如订单中可以显示商品相关的数据。
理解了系统与应用这两个基础概念之后，那么所谓企业级应用就是面向整个企业内用户而提供的全局服务，这个应用属于公司信息化建设的最底层，而多个企业级应用共同组成了公司最底层的系统，在某种意义上来说可以理解为一家企业的信息化“操作系统”，其关系如下图所示。
通过这张图我们可以得到这样的两个信息化建设历程：
（1）企业信息化视角
企业级应用共同组成了企业级信息化，也就是企业最底层的信息化系统，这个最底层的信息化系统向上支撑着具体的各业务线的信息化诉求，各业务线系统均是基于企业“操作系统”孵化出的子系统。而常见的操作系统有ERP/中台等。
（2）业务线信息视角
对于各业务线来看，为了满足本业务线的业务诉求，业务线研发团队将首先选择调用企业级应用来解决具体需求，无法满足时将自主开发对应的业务应用，而当存在多个业务应用时，业务线往往会启动“重构”将多个应用聚合成为一个业务系统。图中业务线二因为只有一个业务应用，所以并未演化出业务系统。
因此到这我们就可以明白，一家企业的操作系统好与坏往往就决定了，企业的上层业务应用是否可用，好用，用现在的流行话语来说就是“企业信息化成熟度是否足够高”。
那么企业级应用的设计思路是什么呢？作为企业级应用在进行架构时，我们要将其分为两个层级进行设计，一个是基础处理能力，可以为整个企业内同一事务提供服务，另一个是为了支持公司内的核心业务而提供的支持能力。
而这两个维度从专业视角来看其实就是两层：
下面让我们来一个个看。
所谓企业级能力层，就如前面所说的就是去解决整个企业内的该领域问题，最常见的如员工信息，账号系统，权限体系等。
在我的《中台产品经理：数字化转型复杂产品架构案例实战》一书中，我对企业级能力层设计提出了4个一的设计目标：
也就是说要想建设一个成功的企业级能力必须要满足这四个设计目标。
举例来说，以企业内主体代码管理能力为例，为了能对企业的不同主体进行区分，并且用于后期进行财务口径的业务应收统计，此处对于集团下的不同业务子公司都应该有一个主体账号概念。
具体设计如下表所示：
可以看到此处本质就是要将企业内的整个账号体系进行统一，从而实现一处创建，一处维护，多处使用一份，全局唯一的设计目标。
如果对于一些做过数据治理的朋友看到这里肯定会倍感熟悉，没错这里其实也是在进行主数据管理，而主数据管理本质就是属于企业级能力层需要兼顾的范畴。
既然是企业信息化的操作系统，那除了直接提供领域级解决方案外，下一步还需要做的就是建立一个能方便业务使用的支持能力。
这里不同于企业级能力建设，而是更多思考如何做好后勤能力，如何更好的提供半成品能力，方便前线使用。
在这里具体来说需要进行两步走设计：
将企业级应用事无巨细的拆解开，将企业级应用的每一项处理能力都以API的方式提供给业务线。
从而让业务线的应用就如壳子一样，罩在企业级能力的发动机上，直接使用现成的能力。此时就要求企业级应用覆盖场景非常全面，例如某企业级应用提供如下详细API能力。
在这种模式下，各业务线的订单就可以很容易依赖该企业级应用实现，而不用再造一遍轮子。
仅仅处理前台业务的请求，这是被动的响应前台的需求，那么有没有什么办法能更好的支持前台的业务诉求，那就是提供拓展场景支持。
还是以上面的订单为例，企业级应用除了提供订单的增删改查的基础能力之外，还可以对订单的其他常见场景如订单风控，订单统计提供额外的支持，从而让前台业务线可以一站式接入订单服务。
可以看到通过如上两步我们就实现企业级应用的架构设计。
事实上，企业级应用只是企业数字化转型中的一个新的叫法，在中台战略中，企业级应用其实就是中台向外提供的能力。不管叫法如何，我们都是在去解决企业底层的操作系统问题，让企业的底层操作系统更全面，更流畅的运行，并能更好去支持上层业务应用这才是我们的终极目标。
专栏作家
三爷，微信公众号：三爷茶馆，人人都是产品经理专栏作家，2019年年度作者。《中台产品经理宝典》作者，原万达高级产品、MBA特约讲师、独立创业者，现叮咚买菜B端产品线负责人，拥有多款集团项目从零到一经验并带领实现商业化布局。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
关注微信
