起点学院课程

业务中台建设系列(一):用户中台V1

10 评论 7325 浏览 77 收藏 20 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

本系列拙作是个人在公司业务中台建设中的思考,共分为3篇(按中台划分),本篇为第一篇。由于中台尚处于建设中,最终走向还待实践。公司的产品有2B和2C方向,因此在设计时需要同时考虑这两方面。

ps:我所声称的用户中台,可以认为是一个基于微服务的类SAAS的综合身份管理中心,主要给公司平台内的业务系统使用。

问题域

用户中台需要面对哪些问题呢?

把时间线往前拨一下,先看看企业在信息化方面的遇到的问题,然后再看看用户遇到的问题。

企业遇到的问题:

在多年以前,企业的业务系统是由各个部门负责建设,比如大家熟知的OA系统、财务系统、CRM和ERP等系统,这些系统是由某个部门提出然后并负责推向公司使用。

当业务系统慢慢变多的时候就会发现,虽然企业拥有了这么多系统,但是这些系统的数据是不通用的。每个系统都需要把员工和组织录入一遍。

一旦员工变动(变更组织或者辞职、新员工入职),那么所有业务系统都需要全部更新一遍,这无疑增加员工的工作。而且,由于这些系统互不相同,导致职员在上班时需要逐个登录到相关系统,浪费不少时间。

更致命的是,有的员工离职之后,某些系统的操作人员没能及时注销员工账号导致公司数据泄露;某些员工在离职前拷贝公司客户数据导致客户被挖墙脚,这些事情也屡见不鲜。

那么企业遇到的主要问题有(4A):

  • 统一管理员工账号,为新员工创建账号,为离职员工注销账号;
  • 统一管理员工权限,避免员工越权接触数据或越权操作等;
  • 统一认证,所有系统只需要登录一次;
  • 统一审计,记录所有员工的 操作日志。

除了这些企业内部遇到的问题外,还有一些是对外暴露的一些问题:用户在A产品上的账号不能在B 产品上登录,尽管A产品和B产品都属于同一个公司。

那么回到一个用户中台(类似SAAS),不仅要面对上述问题,还需要处理以下问题——组织如何注册。

  • 组织如何实名
  • 组织如何登录(组织管理员如何登录)
  • 员工怎么登录,手机密码、手机短信验证码、第三方登录(微信、QQ、微博等)、账号名称/ID
  • 怎么创建、删除、禁用员工账号
  • 管理员怎么邀请员工加入到这个虚拟“组织”
  • 组织如何分配员工权限(控制访问)

用户遇到的问题:

用户面对的问题与企业是有一些类似,明明用的都是某一个公司的产品,结果却需要用户再次注册;更有甚者web端和移动端不统一,导致用户在web端下的单但是在手机上却看不着。

如果没有统一的用户管理,付出的代价也是非常昂贵的,用户流失是一方面,用户打通的成本是另一方面。比如最近2年阿里推出的88vip,其中一个目的就是为了打通阿里系相关产品的用户体系。

对于用户,重点是以下问题:

  • 需要登录么
  • 怎么登录,手机密码、手机短信验证码、第三方登录(微信、QQ、微博等)
  • 怎么注册,手机号注册、邮箱注册
  • 怎么能够注销账号
  • 是否需要实名,如何实名

解决方法域

对于问题域中提及的问题,业内其实有很成熟的解决方案,比如4A管理和IAM。

4A管理:集中账号管理(Account)、集中认证管理(Authentication)、集中授权管理(Authorization)和集中审计管理(Audit)

IAM:Identity and Access Management,即身份识别与访问管理

当然类似的公开产品有(非公开的更多):

  • 东软 SaCa IAM
  • 国民认证的统一身份认证平台(UAP)
  • 其它的就不列举了

无论哪种解决方案,重点要解决的问题是:

  • 统一管理账号,创建账号、注销账号、修改密码、找回密码、修改信息等等
  • 统一管理权限
  • 统一登录
  • 统一注册
  • 统一认证鉴权

设计思路

在分享设计思路之前先定义一些概念

概念

下面是一些概念(来源于关于SaaS平台中应对多租户模式的设计—权限设计):

(1)资源

被安全理的对象(Resources页面、菜单、按钮、订单等)。

(2)权限

访问和操作资源的许可(Permit删除、编辑、审批等)。

(3)角色

用户通过业务需求确定一个角色(Role),并按照实际的业务场景,赋予角色对应的权限的过程,角色也可以理解是权限的集合,是众多权限颗粒组成。

(4)用户

系统实际的操作员(User)

(5)操作权限

  • 页面权限:即用户登录系统可以看到的页面,由菜单来控制,菜单包括一级菜单或多级菜单。当系统赋予用户对应菜单的权限,那么用户就可以访问对应的菜单页面。
  • 操作权限:即页面的功能按钮,包括:查看、新增、修改、删除、审核等。当用户点击按钮时,系统将会校验用户的是否包含次操作权限,如果有,就可以进行下一步操作。
  • 数据权限 :数据权限就是用户在同一页面看到的数据是不同的。比如项目管理员,就能看到当前团队正在进行中的项目,以及项目的进度情况。而团队成员,就只能看到本人具体参与的项目以及项目信息。相对于复杂一项的权限也可以基于组织结构来拓展。

注意:在用户中台中,资源归属于各业务系统,但权限(权限控制)却是属于用户中台!

关于统一管理的说明:

这里面的统一管理是从开发角度或者系统治理角度出发,并非是从使用角度出发。

以权限管理为例,之前每个业务系统需要搭建自己的权限管理,10个系统就需要开发10次 。如果将这些分散在各系统中的权限管理合并到某个系统中,那么只需要开发一次即可。

而这个独立的权限管理系统就可以称之为统一权限管理系统。这个统一的管理系统可以由专人/部门维护,也可以由各个系统来维护。

从使用角度上来看,统一权限就是有专门的人负责给平台所有用户分配权限,比如新来一个研发小张,公司信息部给他创建账号并给他分配各系统的权限。这个信息部就承担了统一管理的角色。

以“用户”为中心

用户中台是以“用户”为中心的,那么可以基于用户的活动来绘制一张“用户地图”,如下图所示。

个人思考:业务中台建设系列(一)-用户中台

从图中可以看到,用户属于用户中台,但是他在物业系统中的角色是管理员,在智慧园区系统中的角色是普通员工。这表明着用户在不同的业务系统中承担着不同的角色,换句话说,角色是与系统关联,系统限定了用户的角色。

上图有一个明显的问题,这个用户没有属于任何组织或者只属于一个组织(平台方)。如果仅是一个自用的平台、小团队等等,没有显式的组织是有可能的。但是,有人的地方就会有团队,有团队的地方就会有组织(有人的地方就有江湖)。

而软件系统是人类真实社会的一个写照一个映射,组织自然就应该加上。用户可以属于1个组织也可以属于多个组织,这些组织之间可以是相关联(比如集团公司和子公司),也可以不关联(比如特朗普不仅是总统,还是商人)。用户与组织的关联关系后面再详细介绍。

个人思考:业务中台建设系列(一)-用户中台

由于我们的部分业务是对外提供服务(SAAS),用户中台还要考虑多租户需求。各租户的权限控制可能不一样,组织架构也可能不一样,因此需要进一步调整以应对这两种挑战。

这会遇到一个问题,若租户使用多个系统,那么是每个系统都创建组织还是所有系统都使用一个组织?

个人比较大倾向于各个系统使用独立的组织(指组织机构),这样会更灵活一些(有的业务系统不需要组织架构,而有的业务系统需要组织架构来划分各种权限尤其是数据类权限)

个人思考:业务中台建设系列(一)-用户中台

此处是分割线……

如果不存在多租户概念,那就没有租户这一层。这种更接近于自用的内部平台,此时用户应当与组织关联(下图未画用户与组织的关联)

个人思考:业务中台建设系列(一)-用户中台

如果没有组织(组织架构)这一层,那么还可以简化为:

个人思考:业务中台建设系列(一)-用户中台

账号体系

从平台角度上来看,平台的账号分为两类,一类是个人账号,一类是组织账号(组织有政府机构、企业、社会团体等)。个人账号非常常见,全部的C端应用和部分B端应用都是基于个人账号体系的。

关于组织账号其实在一些平台中也是非常常见的,银行有公司账号和个人账号,支付宝和微信也有类似的账户;苹果的开发者账户有个人、企业之分。

在组织账号的实现上其实有两种方式:

  • 一种是为组织创建独立的账号(曾经在政府OA系统中设计过);
  • 一种是将个人账号绑定到组织进而通过个人账号来登录。后者在平台中非常常见,比如各类SAAS平台

ps:在授权方面,个人账号和组织账号并无区别。

权限管理

用户中台的权限体系是基于RBAC概念,这个RBAC是基于资源的RBAC而非基于角色的RBAC。

各业务系统的权限是相互独立的,没有依赖关系

业务系统的权限遵从于基于资源的RBAC

数据权限受限于数据规则

权限并集:与 RBAC2 的静态职责分离-角色互斥原则相反,平台采用多角色权限取并集的设计。即在某个业务系统中,用户可以拥有多个角色。此时用户在该业务系统的权限等于各角色权限的并集

为满足以上几点,权限体系中必须有系统标识;数据资源权限中不仅有组织标识,还必须要有部门标识和创建者标识,部门标识和创建者主要是便于区分消费者和生产者。

ps:目前暂未设计用户组和角色组概念

账号体系和权限管理小结

账户体系和权限管理遵循以下原则:

个人账户统一原则:个人账户一次注册,全平台通用,类似于全网通行证和 SSO。

业务权限独立原则:每个子系统的权限体系是独立的,但是由用户中台统一管理维护。『个人账户统一原则』明确了账户体系是统一的,但是对于每个子系统而言,每个账户所能使用的功能和服务,所能查看的数据权限是独立维护的。

组织实体隔离原则:不同的组织实体之间,是相互隔离,独立管理的。每个组织实体可以自行组织自己的组织体系、账户体系和权限体系。不同的组织实体资源权限也是隔离的。

从属关系隔离原则:个体账户与组织实体的从属关系是基于单独的业务系统存在的,『个人账户统一原则』明确的仅是个人账户的全网统一,但组织实体、从属关系并没有统一,并且是隔离的。

比如在 CRM 系统中,张三(用户)从属于 XXXX 公司(组织),但在 OA 系统中,张三(用户)默认是不从属于任何组织的,从属关系受到具体业务系统的影响。

事实上,这个原则是非强制的,具体取决于各自的业务逻辑和业务场景。

如果要简化从属关系的管理,那么可以不遵循此原则,即个体账户与组织实体的从属关系是全平台统一的,与业务系统无关,但这会为降低平台的灵活性和扩展性。灵活性和复杂度之间通常要做一个取舍。

扩展:

在序言中提及到的《平台级SAAS架构的基础-统一身份管理系统》文章中,作者用的是OS-RBAC权限体系,其中O是Orgnization组织,S是Systerm系统。笔者解释这个体系说明权限受组织和系统双重约束。

这一点我是赞同的,权限是依赖于系统,数据依赖于组织。这个在多租户体系中尤为明显,A公司的管理员不能看到B公司的数据,因为A和B是两个不同的组织;同样,A公司的组织架构、权限体系可以和B公司的完全不一样。

考虑公司平台的业务主要集中在自用和第三方开发者接入使用,短期内(半年到一年内)有租户入驻的概率较低。为了降低复杂度,我降低了组织对权限的影响(设计和开发实现上兼顾)。

即在某个业务系统中,所有管理员的功能权限是一样的(数据权限除外,因其受到组织影响)。

用户类型

下图来源于《平台级SAAS架构的基础-统一身份管理系统》,这个里面概况的用户类型非常详细。我将组织用户和行业用户都放在了组织用户概念中,与前文的组织账户对应。

个人思考:业务中台建设系列(一)-用户中台

组织类型

《GBT20091-2006组织机构类型》中定义了以下组织类型:

  • 国家机关
  • 企业
  • 事业单位
  • 社会团体(含行业协会)
  • 其它类型

我们平台对应的2B业务有智慧社区、智慧园区、智慧办公、智慧校园等,2C业务有智能家居、电商等。综合这些业务场景,平台首要考虑:

  • 国家机关,园区、社区类需要考虑,尤其是引入政府资金时,可能需要将数据提供给街道办、公安或政法委(综治办2018年被撤销,相关事宜转交到政法委)
  • 电商平台,主要考虑到企业类型

服务分解

微服务架构下的服务分解有两种方式:一种是基于业务能力的分解方式,一种是基于DDD领域驱动子域分解。由于我还在学习DDD领域驱动,故先基于业务能力来分解服务。

业务能力

用户中台需要满足下列需求:

从功能角度来看,可以分为以下模块,详见脑图:

  • 账户
  • 认证
  • 组织管理
  • 权限管理
  • 授权管理
  • 鉴权中心
  • 系统管理

个人思考:业务中台建设系列(一)-用户中台

服务分解

以下是具体的服务

(1)账号类服务

  • 账号管理服务
  • 注册服务
  • 注销服务

(2)权限类服务

  • 角色服务
  • 权限服务

(3)组织类服务

  • 组织管理服务
  • 组织机构管理服务

(4)授权类服务

授权服务:绑定/解绑角色权限,绑定/解绑用户角色,绑定/解绑用户和系统,绑定用户和组织机构。

(5)鉴权类服务

  • 登录鉴权服务:登录方式配置、登录风控和登录鉴权3个业务能力
  • 其它访问鉴权:负责外部应用访问内部服务的鉴权

(6)认证类服务

认证服务:包含个人实名认证、组织实名认证和人证资质审核3个业务能力。

(7)系统类服务

系统管理服务:负责系统的增删改查

个人思考:业务中台建设系列(一)-用户中台

参考链接

平台级SAAS架构的基础:统一身份管理系统

关于SaaS平台中应对多租户模式的设计—权限设计

 

本文@ wweiru 原创发布于人人都是产品经理,未经许可,不得转载。

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 写的挺好的。希望继续出其他中台相关文章

    回复
  2. 统一解释一下“用户中台(类似saas)“这句话。我在做这个用户中台设计时,参考的saas的多租户用户权限体系,并不是说用户中台就是saas。

    回复
  3. 这篇文章质量不高,乱堆名词,问题不说问题,写个“问题域”;还有什么“用户中台”是什么鬼?

    回复
    1. 问题域:你设计的产品,系统需要处理解决的业务范畴,简单说就是哪些做哪些不做。比如一个自营电商平台需要处理的问题域包含商品如何展示,买家如何购买等,不需要做的就是第三方商家如何入驻平台。
      至于问题域中的问题,想必你看到了我是按企业和个人顺序展开。
      用户中台:中台这个概念没有定论,请自行搜索。我对用户中台的定义是平台中负责用户权限统一管理的系统或模块,用于支撑平台上各业务系统的运行,避免各业务系统中重复设计用户权限模块。通俗来讲,你可以理解为这个是用户中心或者身份管理

      回复
  4. 中台不是saas,saas是以提供标准化功能为目标,开箱即用的产品形态。中台是以实现企业快速且低成本创新为目标的一种架构,在这种架构中可能有若干产品组合。

    回复
    1. 中台不是saas,但它可以快速支撑企业拓展发展业务,saas只是其中一类

      回复
    2. 感觉作者名词混乱,是不是把自己也写晕了。中台不是paas?saas是什么的缩写?

      回复
  5. 而且你在后面提到了租户,那一个用户,无论都是个人还是企业,都是一个租户,在这个租户里面,有自己的组织,比如部门

    回复
  6. 1、个人觉得不应该以用户为中心,应该以组织为中心。对于个人用户,也可以给他对应一个组织。也就是说,所有的用户都会隶属于一个组织,显示世界里面,也会有这样的情况。
    2、如果一个企业在系统注册,那他肯定只有一套组织和权限,无论它使用多少套应用。权限和角色只分配一次。即分配的权限是该组织可以分配的权限。

    回复
    1. 1、我考虑的是个人用户可以从属于多个组织,也可以不属于任何组织。
      2、企业入驻部分,确实如您所说

      回复