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

架构规划的重要性

如果没有进行合理的架构规划，将会引发一系列的问题。为了避免这些问题的发生，企业需要进行业务架构、应用架构、技术架构和数据架构的全面规划和设计，以构建一个清晰、可持续发展的企业架构。

业务架构：需求初期业务的结果和过程描述一般比较模糊，可能来自于某个老板、运营或用户的反馈。业务架构一般承载着公司的核心业务方向和战略，主要包括业务规划、业务模块、业务流程、干系人及问题域等。该阶段的设计也称为战略设计，这个阶段的设计成败也大大决定着产品的成败，通常在此阶段需要有业务专家、产品研发团队共同参与设计。
应用架构：应用架构介于业务架构和技术架构之间，是对整个系统实现的总体架构，需要指出系统的层次、依赖关系、开发原则以及各个层次的应用服务等信息。
数据架构：数据资产目录、数据标准、数据模型、数据分布可以称为数据架构体系的"四个基本内容"，具体而言应该包括：梳理企业的数据资产、制定数据标准并持续维护、建立数据模型，包括概念模型、逻辑模型和物理模型、管控数据分布，包括数据源头和流向。
技术架构：技术架构是离程序员最近的架构设计，它不仅是系统搭建的架构设计，还包括技术选项、组件设计、通信设计、存储设计、实现逻辑等内容，主要用来描述整个系统是如何落地和实现的方案。

想要顺利的完成一个复杂系统的开发上线，这几类架构是必不可缺的。它们都是用于指导和表达各个阶段的核心内容，比如通过对业务架构的深刻学习和拆解，产品同学可更合理的规划出应用架构，但是如果没有业务架构的支撑单靠一句话需求是很难理解一个业务线的工作流程和问题。

往往系统是非常复杂的，无法一下子全部表达清楚，架构要涵盖的内容和决策太多了，超过了人脑"一蹴而就"的能力范围，因此采用"分而治之"的办法从不同视角分别设计。

所以，也需要从不同的维度来描述这个系统。

也就是说架构图是对系统从某种维度视角的表达，每一种架构图，都是一种视角。

在工作中，对上汇报中，经常需要的是如下几种架构图

业务架构，是IT架构的基础。

简单来说，是从业务、产品视角，描述整个平台、或某个产品的实现。

站在整个平台视角，描述整个平台架构。

一套对存储数据的架构逻辑，它会根据各个系统应用场景、不同时间段的应用场景，对数据进行诸如数据异构、读写分离、缓存使用、分布式数据策略等划分。

数据架构主要解决三个问题：第一，系统需要什么样的数据；第二，如何存储这些数据；第三，如何进行数据架构设计。

一般要求从技术层面描述系统。
一般分为单个系统和分布式系统

技术架构就是对在业务架构中提出的功能（或服务）进行技术方案的实现，包括软件系统实现、操作系统选择和运行时设计。

技术架构的边界比较模糊，对于不同的受众，内容的详细程度也不同，技术栈自上而下比较关注技术架构，但是各层关注的点不同。

技术决策层可能关心的是系统或系统群的技术选型，对整体的把握要保证不因为选型引起其他风险，例如，如果在高性能存储方面选择 Redis，就要尽量保证网络的封闭性，避免公网访问；再如，在选择以COBOL语言实现的各类产品时，要考虑市场上开发人员数量少，需要承担更高的迭代成本等。