如何做架构设计和评审

0、概要

架构设计是从业务需求到系统实现的一个转换，是对需求进一步深入分析的过程，用于确定系统中实体与实体的关系，以及实体的形式与功能。

架构设计可根据从业务需求到系统实现的不同需要分为：业务架构、应用架构、数据架构、技术架构。

• 业务架构：战略，价值链，端到端，业务流程，业务组件，自上而下分解
• 应用架构：系统建设，系统集成，中台，自下而上抽象
• 技术架构：技术选型，框架，PaaS平台，云原生，DevOps，微服务，容器化，部署架构
• 数据架构：数据标准，数据采集加工，数据入湖，数据治理，数据共享服务，数据安全，数据质量，数据架构

架构之间的关系如图：

 

 一、业务架构

目的：

根据企业战略，以价值链梳理分析业务开展流程，识别上下游依赖关系，从业务和产品的视角，描述整个平台或者产品的实现

设计步骤：

1.识别战略，走访业务部门，问卷调查

2.外部因素，根据宏观背景（风口），行业空间（天花板），竞争情况（赛道），上下游产业链做规划

3.内部因素，根据商业模式，技术壁垒和资源投入进行规划

1.1 如何绘制

一理场景画流程，二列页面和模块，三把功能来聚类，四五纵横法上阵

A）根据用户操作流程，罗列功能模块

B）形成功能矩阵

C）横向分层，纵向分层

另一种业务架构画法参考：

 

 二、应用架构

目的：

支持业务和数据处理需要哪些应用系统，完成从业务到IT的转换

设计步骤：

1. 根据业务架构图，做业务到IT的转换，识别应用程序和组件 （上接业务）

2. 优化应用程序和组件，该拆分就拆分，该聚合就聚合 （核心设计）

3. 设计应用与业务功能，流程，数据的关系（核心设计）

4. 设计应用集成，交互，开发 （下接开发）

2.1 如何绘制

 三、技术架构

目的：

支持应用系统所需的技术架构，技术组件，技术选型

设计步骤：

1. 根据应用架构，进行技术支撑分析，识别技术支撑的必要条件

2. 技术选型，包括开发架构，技术产品，开发技术栈，开发平台，运行平台

3. 技术影响分析，成本，难易度，规划，治理

3.1 如何绘制

 四、数据架构

目的：

描述企业数据来源，数据资产管理，数据治理，数据共享开放

设计步骤：

1. 上接业务，分析数据需求，识别数据类型，采集数据

2. 数据模型设计，概念模型（识别业务域），逻辑模型（实体关系ER），物理模型（表字段）

3. 数据治理，数据安全合规，数据质量管理

4. 数据共享开放，支撑业务决策，业务创新

4.1 如何绘制

五、架构优化总结

优化的常见手段或模式

• 静态化：动态数据和静态数据分离。

• 异步化：使用异步化减少主流程中的非关键业务逻辑。

• 并行化：使用多线程并发处理，缩短响应时间。

• 内存优化：减少对象大小，减少对象创造，数据模型优化

• 去重复运算：业务逻辑优化，或者使用缓存

• 减少数据库操作：数据冗余，数据缓存等

• 缩短数据库事务：短事务，异步化，最终一致性等方式可以考虑

• 精简代码逻辑：去除冗余代码，诸如过度设计检查等代码。

• 精简日志操作：日志大小要关注，注意IO上的瓶颈；日志太多，说明生成的string也会多，也增加了gc负担

六、架构评审

架构设计完成需要被评审，那么架构评审从哪些方面入手呢？

1）紧扣业务

虽然是做技术规划，但如果脱离了业务支撑，是引起不了老板兴趣的

2）从实际问题出发

老板只会为解决实际问题的技术规划买单。规划的开头最好能从实际问题出发，比较容易引起老板的注意

3）重点在落地

只有能落地的技术才有说服力，老板不会被天花乱坠的技术词汇给迷惑的，他只会关注最后能落地是哪几项，应该重点谈落地的目标和计划

4）突出关键点和关键路径

其中一个哥们说了很多，非常丰富，但关键点不突出，结果在老板看来就是个零。在表述规划的整个过程中，一定要紧扣关键旋律，让老板用最短的时间理解你的意图

5）少、准、狠

有的哥们搞得规划面面俱到，结果搞得老板不相信，他想要的东西不是大而全的，而是在一个阶段里能一刀见血的，因此搞规划切勿四面开花，把最关键的、老板最关心的抠出来，并确保把它搞定。

6）目标要量化

老板很关心目标，这个胜于具体的行动计划，他需要用这个来最后check你的结果，因此不量化的目标是通不过的

7）和相关的人要事先沟通清楚

技术规划少不了合作方的支持，在汇报之前一定要知会到相关方，最好能达成一致，因为老板一定会在汇报过程中质疑你是否做过沟通，有好几个哥们因为这个做得不到位，导致老板觉得这个规划是纸上谈兵，不靠谱。

8）具有足够的开放性

如果这个规划只需要你自己或小范围几个人就能搞定，老板会觉得没价值，他希望看到是能involve更多的人，最好还是跨团队的人，只有具有影响力的事情才有规划的必要

9）数据最具说服力

做汇报前，最好能把相关的数据拿到手，并且一定要精确，含糊的说辞最容易遭到PK

以上几点都是在听评审的过程中最受质疑的几点，这对自己以后做技术规划具有参考意义。