传统企业数字化架构设计

一、总览

传统企业数字化架构设计可分为2层,4种架构,分别是业务架构,数据架构,应用架构,技术架构。业务架构是上层,他驱动应用、数据、技术架构,反过来,应用、数据、技术架构是下层,他支撑业务架构的实现。除此之外,我们还应该在业务架构之上,再设立战略层,战略层主要由公司高管设计。

  1. 业务架构
    业务架构需要知道为什么要做,做什么,怎么做,谁来做四件事。
  • 为什么做是一切的缘起,需要理解公司战略目标
  • 做什么,即公司想实现或能提供的业务服务
  • 怎么做是基于做什么的基础上,细化提供业务服务所需要的业务流程
  • 谁来做,指的是业务服务的执行方。
  1. 应用架构
    应用架构需要解决应用有哪些,以及对应的功能点。
  2. 数据架构
    数据架构需要解决数据的类型、来源,后续还需要针对不同的场景和功能,设计确定数据模型,存储方式,数据处理加工方式。
  3. 技术架构
    技术架构需要解决技术需求、选型、发展路径等的问题。诸如,技术栈,技术平台,技术框架,中间件,部署方式等等。

从阶段上看,一般架构设计到实施,可以分为启动阶段,架构设计阶段,研发实施阶段,上线运维阶段。每个阶段要解决的问题重点各不相同。

  • 启动阶段,需要做好战略调研,确定方向。为下一阶段做好准备。
  • 架构设计阶段,首先根据公司业务模式,商业模式,规划业务架构,分析需求,详细设计功能,流程,数据等。第二步,根据业务架构,设计规划应用,数据,技术架构,还应当评估风险,做可行性分析等。
  • 研发实施阶段,根据总体需求规模,研发实施阶段时间长度可能是1年,也可能是5年,所以该阶段需详细拆解任务项,制定时间表。很重要的是,如果涉及公司组织架构调整,商业合作伙伴变更等,也需要制定相对应时间表。另外,很多公司做数字化转型前,经常会存在历史系统,这些系统可能是之前采购的SaaS系统,或是外包研发的系统等,需要对遗留系统进行改造,或是迁移等动作,也均需考虑在内。
  • 上线运维阶段,该阶段未必是研发实施后,可能会和研发实施有交叉,研发实施部分功能,上线运维,再研发实施,而后再上线运维。这阶段在维护的基础上,需要收集遗漏或者缺失的功能,以便在后续的优化完善。

可以看出,数字化转型的架构设计,不仅仅是IT部门,或是CTO,CIO的事,而是需要公司达成一致,至少是需要公司高层达成一致。前期的战略设定,后续的人员招聘,组织架构调整,上线培训使用等,都需要各个部门紧密配合。

二、 业务架构设计

业务架构必须基于企业的战略来做,脱离了企业战略,业务架构就无法真正意义上实现其价值,也就成了无源之水,无本之木。基于战略,我们可以知道为什么要做,而后,业务架构还需要解决做什么,怎么做,谁来做的问题。做什么指的是所提供的业务功能,怎么做是业务流程,谁来做是组织架构,此外我们还可以引入商业模式。另外,业务架构的设计,往往牵扯到公司多个部门甚至事业部,而大多数企业在做数字化转型前,或多或少都会有已有系统,无论是采购亦或者外包开发,所以业务架构设计往往是跨部门,跨系统的,这也要求我们在做业务架构设计时需要将这些因素考虑在内。

2.1 企业战略

企业战略往往由公司董事或高层制定,而我们所需要做的,就是对标企业战略目标,理解公司战略驱动因素。我们可以通过与高层进行访谈,了解战略的由来,逻辑。可以通过收集内外部信息,包括政策,友商策略等,再结合案例与最佳实践,最终达到理解战略意图。
理解战略意图后,我们需要分解战略大目标,而后就每个目标进一步分解为达成目标所需要的策略动作,策略动作可以从之前提到的做什么,怎么做,谁来做,商业模式几方面考虑,最后总结即可得到业务架构图。
以数字化转型这个战略目标为例,一般而言,传统企业做数字化转型的三个目标是降本,增效,增收。达成降本目标所设定的服务是,提供某个智能化平台,通过AI算法,达到减少积压库存的目标。达成增效目标是建立采购平台,大客户可通过平台自行下单采购,提高下单效率。达成增收目标所设定的是建立客服主动回访机制,通过主动回访,提高客户复购率。最后,我们需要提取各项因素,分析细化,总结为业务功能,流程,组织架构。

2.2 业务功能

分析业务功能,可以从价值链开始,逐步拆解到功能域,二级功能域等。是一个从大到小逐步细化的过程。我们需要分析拆解公司内所能提供的对内和对外的服务项。
以医药制造企业为例,价值链最顶级是人力行政,研发,采购,生产,物流,销售,售后等。而后需要对每项进行再一次拆解,诸如销售可拆解为大客户渠道,药店渠道,电商渠道等,作为二级功能域。

2.3 业务流程

业务流程也可逐层拆解,诸如线上购买商品,“搜索->进入商品详情页->下单支付”,这是一级主干流程,主干流程内的各个节点可以继续拆解,诸如搜索可能会有筛选项,详情页需要选择型号、规格、尺码,下单支付则可能会出现不同的支付渠道。再往下还需要设定规则,诸如某些场景不允许使用信号卡,或是不允许使用货到付款等。

2.4 组织架构

组织结构需要考虑是否改动或者新增新的组织体系,诸如原有物流部新增电商物流岗位,新增电商客服部等。
其次,组织架构不仅是公司内的调整,可能还会涉外部合作伙伴的变更,合作渠道的变更,都需要考虑在内。诸如新增电商渠道,需要考虑与之相关的渠道链路,考虑组织架构的调整。

  • 最上层是个人客户,企业客户。
  • 第二层是售卖渠道,有第三方电商平台,自有官网商城等。
  • 第三层有客服,物流,售后,运营,品牌,品项等。
  • 第四层有财务,人力,行政等基础支持性部门。

2.5 案例

本节以在官方商城购买商品作为虚拟案例。我们从业务功能,业务流程,分支流程进行说明,这几部分是自上而下,逐步拆解的过程。

  1. 业务功能
    也即在官方商城购买商品这个服务场景。
  2. 业务流程
    主干流程:客户进入商城某个商品详情页,在登录后进行购买并支付。
    分支流程:
  • 查找商品流程
  • 选择具体SKU流程
  • 登录流程
  • 选择收货地址流程
  • 支付流程
    详细阐述对每个分支流程再次细化,直至全覆盖每个流程的每个分支以及其处理规则。
  1. 组织架构
    如涉及组织架构变更,还需明确所产生的调整策略,涵盖时间,范围,方式等。

三、应用架构设计

应用架构包含一系列应用以及之间交互方式,应用架构关注的应用的功能以及之间的交互方式,而不是具体到每个应用内部的实现技术。

3.1 设计步骤

  1. 梳理应用架构前,需梳理好业务架构,也即整理好业务功能,细化流程,明确流程内处理规则。比如登录场景,需考虑登录成功与失败的场景,并考虑忘记密码的场景。
  2. 识别每个流程,每个分支,处理规则背后的需求点。比如忘记密码,则会产生重置密码的流程,进而会有发送重置密码链接到注册邮箱的需求。
  3. 对需求点进行分类,将其归类到各个系统功能,注意这里开始出现偏技术向的内容,诸如,支付管理,用户管理等,此外类似日志管理这类后台功能也是系统的一部分。如果出现各部门业务功能似乎就可以直接划分成系统,这时候可以考虑是否有更优方式组织系统划分方式,优化使用感受。
  4. 按照终端->系统以及内部功能->底层后台服务的层次排列,形成功能架构图。注意不应出现过于技术向的构件,诸如不应出现MySQL,ELK这类词汇,而是面向功能进行分层排列。对于过大的构件,也应拆解成小构件,这其实是构件细粒度的问题。
  5. 根据之前的需求分类,定义各系统各功能点开发顺序,定义迭代内容。注意,现实情况一般是并非所有功能和需求都是新增的,也可能是对原有系统的重构,完善优化,重写等,也可能是原有系统就已满足的。
  6. 定义接口,如果可能的话,可细化输出时序图,数据库表结构等。

四、 数据架构设计

数据架构描述的是企业的主要数据类型和来源,物理和逻辑数据资产,数据管理。

4.1 设计内容

数据架构设计的内容可以归纳为以下5个方面:

  • 数据架构类型及其来源,诸如订单库,商品库,操作日志等
  • 数据模型,诸如订单模型,BI星型模型等
  • 数据存储,诸如,关系型数据库,图数据库
  • 数据流,诸如数据治理过程等
  • 数据管理,诸如安全规范等。

从落地角度来看,数据架构设计可分为三大块

  1. 现有或未来需要的数据,这既是需求,也是现状
    a. 针对不同的部门,不同的业务,分析已有的数据,并通过调研分析未来所需要的数据。
    b. 设计跨部门的数据结构,总结主数据结构
    c. 分析非结构或半结构化的数据的应用场景
  2. 设计物理和逻辑数据资产,数据生命周期,数据流
    a. 设计逻辑数据资产模型,可使用ER图表示
    b. 设计物理数据资产结构,可能是OLAP,JSON,XML等
    c. 数据生命周期设计,诸如分库分表场景,热数据定时迁移到历史表中。
    d. 数据流设计。第一应关注用户本身是如何使用数据的,数据应该是从哪个系统往哪个系统流转,直到最后被使用。第二明确数据处理过程,可设计ETL过程,用来将原始数据处理成可展示的目标数据。
  3. 设计数据管理规范
    数据管理规范包含三点,一是数据标准,二是数据质量,三是数据安全

4.2 设计步骤

  1. 分析现状,识别未来需求
    注意分析和识别需是横跨不同的部门,不同的业务。关注可提取作为主数据的数据类型和来源。
    在识别数据类型时,可借鉴UC矩阵的方式,仔细梳理每个业务产生和消费的数据。
  2. 数据建模
    数据建模必须建立在业务的基础上,具体来说,可将业务进行分层,而后进行分析。
  • 通过业务域发现数据域
  • 通过业务流程,发现数据实体,属性,关系
  • 通过功能和处理规则,逐步细化数据实体,属性,关系
    数据建模是数据架构设计的核心,是最重要的一步。
  1. 定义数据生命周期
    由于数据量大等原因,可能对系统产生性能产生影响,有时候需要制定数据生命周期,定期清理或迁移数据。也有可能是某些场景,诸如电商抢购,用户下单后30分钟未付款应关闭订单等等。
  2. 规划数据存储与分布
    这步决定了数据应该如何存储以及分布,举个例子,数据是结构化还是非结构化的,就要考虑数据存储在某种关系型数据库上,或是非结构化的数据库上。
  3. 设计数据流
    针对BI报表甚至是AI的需求,我们往往会需要做数据治理,处理原始数据,最终可能是落地到数仓,或是报表,仪表盘等。
  4. 制定数据管理规范
    这点主要是根据企业或实际业务要求,定义数据标准,质量,安全。

五、 技术架构设计

5.1 设计内容

技术架构设计是很多技术人最擅长接触最多的部分,大概涉及以下几方面

  • 技术需求,主要分析业务架构,应用架构,数据架构,所设定的需求作为起点
  • 技术选型,针对平台,组件,框架等进行选型
  • 物理选型,考虑是否使用公有云,或者私有化部署
  • 选型管理,针对所需要的技术进行指标评估,制定选型标准

5.2 设计步骤

  1. 分析技术需求,主要包含识别需求所需要的技术以及部署位置。
    技术架构设计的第一步,是分析技术需求,技术需求必须以业务架构,应用架构,数据架构为源。如,是否有高并发和弹性伸缩的需求?甲方或公司是否对数据存储安全有要求?现有团队技术栈情况等。

  2. 技术选型,盘点现有系统使用的技术,并与需求进行对比,明确差异和差距,最后选择合适的技术
    可以结合横向和纵向进行分析,举个例子,数据库选型,横向可以分析 SQLServer、MySQL、TiDB之间的差异。纵向可以分析各数据库的功能,质量,现状,社区,文档,法律风险,未来发展趋势等。

  3. 影响分析,对比技术架构目标和现状,明确成本,规模,学习曲线等影响。

你可能感兴趣的:(大数据,运维,数据库)