数据架构是什么？一文讲清数据架构和技术架构的区别

架构，从本质上来说，是针对一个系统所进行的结构性描述，它会告知你系统是由哪些部分组合而成的，以及这些部分之间是怎样展开协作的。仅仅是由于描述时所选取的视角各异，于是就产生了不同种类的架构类型。

在业内，业务架构、数据架构、应用架构、技术架构，这四个有着一个专有名词叫4A架构，它是企业数字化建设的核心方法论框架。

诸多企业开展数字化时老是陷入困境，要不一开始就去挑选技术、搭建系统，最终系统跟业务出现脱节状况，要不各个部门自行其是，弄不清楚四层架构相互之间的关联，致使架构越来越混乱。今日为大伙详尽讲解这四种架构，助力你梳理清楚它们核心的逻辑关系。

一、先建立一个整体认知

这四种架构并非是孤立存在的，它们相互之间存在着严格的、具有承接性质的关系，进而形成了一条完整的、具备逻辑性质的链路：

业务架构 → 数据架构 → 应用架构 → 技术架构

这张图，清晰地展示了，4A 架构，从企业级，到分段级，它的层级落地逻辑，核心之处，能看到，四层架构的，承接和延伸关系。

这四层呈现的是清晰的、具有依次推导关系的因与果的逻辑联系，并非是同时存在互不隶属的并列关系，对于企业数字化建设来讲存在一种核心的误区情况，那就是越过前面的架构部分行径直接去进行后面的技术选型行为，这样做极容易致使架构与业务出现相互脱节的状况。

二、业务架构1、业务架构核心解决的问题

企业架构的起始点是业务架构，它所要回应的关键问题是，这家企业需操作哪些事项，凭借何种能力去开展这些事项，这些事项相互之间的关联究竟是什么。

诸多企业于开展信息化建设之际，一开始便着重探讨投入使用哪些系统，购置什么样的软件这个行为，确凿是把事情本来该有的正常顺序给颠倒过来了。系统的功能是用来为业务提供服务的，可以说倘若连业务究竟是什么都未能交代清晰明白，那么系统又怎么能够构建得正确无误？

2、业务架构的三个核心要素

首先来说，价值流，它指的是企业从与客户开始接触起，一直到最终将价值交付出去的一整个完整的流程链条。举例而言，有一家制造企业，其从在市场获取客户，到签订合同，再到采购原材料，接着进行生产，然后完成交付，最后提供售后，这一整条链条便是价值流。

其次，是业务能力，要让价值流能够顺畅运转起来，企业究竟需要拥有什么样的能力呢？举例来说，像是供应链管理方面的能力，财务管理方面的能力，以及人力资源管理方面的能力。这些能力具备相对稳定的特性，不会由于某一个流程出现调整，就频繁地发生改变。对于业务能力进行梳理的时候，通常会划分到二至四级的不同层级。

其三，关于业务流程。每一项业务能力被拆开来看，其中存在着具体的操作步骤，这些操作步骤涉及业务对象，涉及业务活动，涉及业务规则，还涉及业务角色这四个要素。进一步而言，流程的梳理常常会精细到5到7级。

3、业务架构怎么做

弄清楚业务架构，首先得明确企业的战略目标，接着需识别为达成这些目标所需的业务场景，随后依据场景剖析出所需的业务能力，最后将每项能力的详细流程梳理出来。

其实呢，这就是一个先是从顶层朝着底层，继而言之从宏观转向微观的一步一步的拆解进程。当拆到足够细致的程度时，自然而然你就能够分辨清楚哪些功能是处于核心地位的，哪一些是起到辅助作用的，哪些又是能够进行复用的。

三、数据架构1、数据架构的定位

数据架构处于业务架构与 IT 架构的衔接位置，它的一端同业务架构里的业务对象相连接，另一端与后续的 IT 应用以及技术实现相连接。

听着是不是感觉挺耳熟的呀？好多企业在开展数据治理工作之际，业务部门所表述的是一套内容，而 IT 部门所讲的却是另外一套内容，两边的说法无法达成一致，追根溯源，其根本原因常常就是数据架构没有构建完善，没能将业务方面的需求成功转化为标准化的数据规范。

2、数据架构的主线逻辑

有一种清晰的主线存在于数据架构之中，它是这样的：先是数据主题域，之后会发展成概念模型，再之后会演化为逻辑模型，最后会变成物理模型。

在数据架构，从概念模型落地至物理模型，再到后续数仓构建、数据同步、数据治理的进程里，一款专业的数据集成工具，可大幅提升落地效率。其中，像FineDataLink，它集实时数据同步、ELT/ETL数据处理、数据服务以及系统管理于一体，能够完备地解决企业数据，从任意终端到任意终端的处理与传输问题。

3、数据架构的设计原则

用过来人的经验告诉你，数据架构设计有几个原则是必须坚守的：

四、应用架构1、应用架构是解决什么问题的

应用架构，是关于整个系统实现的总体规划，它会将业务架构之中的业务能力以及流程，转化成能够落地的 IT 应用系统，简单来讲，就是要明确企业需要哪些应用系统，要确定每个系统的功能都是什么，要弄清楚系统之间应该怎样进行交互。

阐述业务架构时所提及的是“供应链管理”，转而到了应用架构层面，便需要拆解为合同管理系统，以及采购管理系统，还有物流管理系统，其粒度已然变得更为细致，并且技术边界也呈现出清晰的状态了。

2、应用架构的两个层次

3、针对应用架构的核心设计原则里所提及的五，属于技术架构这一项来看，首先是技术架构将会去解决什么样的问题 ，对此进行探讨。

对系统的非功能性需求予以关注的是技术架构，此需求包含高可用、高性能、可扩展、安全性以及伸缩性。技术架构的任务在于明确究竟藉由何种技术组件去支撑这些应用系统的运行，还要确定这些组件该以怎样的方式进行部署，并且要思考如何确保系统能够稳定可靠地运行。

2、技术架构的三个视角

3、技术架构的核心设计原则

技术架构持续演进着，起初是传统的这般烟囱式建设，而后发展到如今的云原生架构以及微服务架构，其核心要点全都是为了去适配企业业务的相应发展态势，进而使得技术能够处于更优状态来支撑业务。

六、总结架构类型核心问题主要受众

业务架构

企业要做什么，靠什么能力做

业务负责人、架构师

数据架构

业务涉及哪些数据，数据怎么组织

数据架构师、数据工程师

应用架构

需要建哪些系统，系统怎么协作

应用架构师、研发负责人

技术架构

用什么技术支撑系统运行

技术架构师、基础设施团队

其实，业务架构并非孤立存在，数据架构也不是孤立的，应用架构同样不是孤立的，技术架构从来都不是孤立的，它们是相互紧密关联，构成环环相扣的一个整体。

无论是进行企业数字化方面的工作，还是开展IT架构设计的工作，都不可以仅仅只关注某一个架构，而是需要从整体上去着手，首先要将业务架构梳理得清晰明白，接着再按照顺序去落实数据、应用以及技术架构，唯有如此，所设计出来的架构才是符合企业需求、能够实现落地、可以进行演进的架构。

相关标签： # 数据架构 # 技术架构 # 业务架构 # 应用架构 # 企业数字化