关于架构师职责的最完美解答

---

前言

不想到将军的士兵不是好士兵，同样不想当架构师的程序员不是好程序员。每一个程序员都怀有一个成为架构师的梦想，对架构师满怀憧憬和敬意。但是架构师的职责是什么？

解决技术难题？进行技术选型？搭建项目架构？做方案设计，画架构图？

乍一听，确实好像确实是架构师应该要做的一些事，但是都非常片面。今天分享下人月大佬对架构师职责的总结，
也是我目前心中最完美的解答。

---

软件架构要做三个方面的工作：

一、业务架构设计

针对软件需求中的业务场景和流程，功能性需求进行功能性架构设计

其中包括了核心的功能架构设计，子系统和模块的划分，接口和集成模式的设计，数据架构和数据模型的设计等。即通过概念模型，类图或数据库设计等静态模型+用例，序列图等动态模型共同来抽象表达出完整的业务需求。

二、技术架构设计

通过软件需求中的非功能性需求，来考虑整个系统的技术架构设计

技术架构本身又包括了类似消息，缓存，安全，日志，分布式等关键技术的实现，也包括了IT基础设施和部署架构的设计，同时还包括了类似高可用，高可靠，高性能，高扩展等非功能性需求满足的架构设计。

三、开发规划设计

对于软件生命周期和软件工程域标准内容的设计

其中包括了开发框架，技术选型，软件生命周期，持续集成模式，架构标准规范，开发规范，测试规范，以及各种架构规约和约束等方面的内容设计。同时还需要基于上面内容进行相应的架构原型搭建和验证工作，确保架构设计内容能够真正落地。

要能够做好上面三方面的内容，一个真正架构师必须既懂技术又懂业务，而对于当前很多互联网应用，由于本身工作相对细分，可以看到很多架构师往往仅仅只需要专研深核心技术领域的技术和某一垂直业务场景即可。在这点上企业内部信息化架构师和互联网本身还是存在区别，即。

企业内部架构师更加强调业务+技术综合能力

架构设计的核心目的是全面的理解业务需求后给出整体的技术方案，避免后续在开发实现中遗漏。架构设计内容不仅仅是指导后续的详细设计和开发，同时更加重要的是通过组件和划分和接口的设计，让后续的开发工作真正能够并行起来，最终再进行集成，以降低软件研发的复杂度，同时又缩短软件开发周期提升效率。

能够把一个复杂的大系统真正想清楚和透彻，同时还能够把大系统拆散为松耦合的多个模块，最终又在各个模块独立并行完成开发后，能够通过预先定义的接口将这些模块又组装和集成起来，这就是一个真正架构师应该做的事情。

技术最终是解决业务问题和为业务目标服务，也正是整个原因，一个好的架构师不应该陷入到技术驱动，而是业务驱动；不是选择最新，最热的技术或框架，而是应该选择当前最合适的技术和框架。架构师应该避免过度设计和技术狂热，而是真正做好业务和技术的适配，成本和收益的分析工作。

对于架构和架构设计，本质上是解决从业务现实到技术实现之间的抽象问题。

总结

本文主要从三个方面介绍了架构师的职责，简单来说，就是深入理解业务进行业务架构设计，并根据非功能性需求设计技术架构，并制定相关的开发流程和规范，确保架构设计正确落地。
一直死磕技术，思维不能提升，始终难以打破架构师壁垒。