架构师如何分类？-从ISO国标到技术实现的架构师分类

导读：

“ 以前大家对架构师有个朴素的理解：搭建技术框架、解决疑难技术问题、优化系统提供高并发高可用场景支撑。

但随着spring体系的不断成熟，以前需要架构师搭建的框架大部分由spring体系提供了成熟的一套架构标准，普通技术选型也趋向统一；在新技术领域如云、大数据、区块链等涌现出一批架构师；随着数字化转型的浪潮，企业也缴纳了足够的“智商税”，不再相信咨询公司的“忽悠”，而更加重视企业EA架构师。

这时候我们如何对架构师进行分类，就成了一个公说公有理婆说婆有理的、各自领域自说自话的混乱局面。

为正本溯源，我在写此文章过程中翻阅了ISO国际标准、Togaf标准，以微软架构师分类标准为基础，聊一聊架构师的分类及未来的演进，不足之处敬请各位同仁指正。

本文共分为四个章节：

第一章节讲ISO标准、第二章节讲Togaf理解、第三章节讲微软架构师分类、第四章节讲演进。想一步到位的朋友请直接跳到第三、四章节。

”

目录

01 ISO/IEC/IEEE42010.架构标准 

02 Togaf对企业架构的解释 

03 “微软”架构师分类 

04 综合理解 

---

 

01

—

 

 

ISO/IEC/IEEE42010.架构标准 

 

 

本文对软件体系架构的描述方法的研究基于ISO/IEC/IEEE42010. ISO/IEC/IEEE 42010 于2011 年批准使用并发布，该标准是继 2006 年 ISO 快速采用 IEEE 标准后，ISO 和 IEEE 联合制定的修订 IEEE Std 1471:2000 的产物。

 

其中，“系统（System）”指其结构受到关注的实体，在软件开发过程中，可以认为是“软件密集型系统”：任何软件对其设计、构造、部署和演变有重要影响的系统，包括单个应用程序、传统意义上的系统、子系统、系统的系统、产品线、产品系列、整个企业和其他利益的集合。

 

“利益相关者（Stakeholder）”是指在系统中拥有利益的各方。利益相关者的利益表现为“系统关注点”（System Concern）。利益相关者赋予系统各种目的（Purpose），目的是系统关注点的一种。

 

“环境（Environment）”决定了系统在其整个生命周期中受到的全部影响，包括与环境的相互作用。一个系统处在一个环境中，一个环境可以包含多个系统。

 

“架构（Architecture）”构成了系统与其环境相关的基本内容，可能涉及到如下几点：系统的构成要素或元素；系统要素如何安排或相互关联；系统的组织或设计原则；系统在其生命周期中的演变原则。

 

“架构描述（Architecture Description）”用于表达有关系统架构的内容。下面对架构描述的方法进行详尽的阐述与分析。

 

架构描述是系统和软件体系架构的工作成果。下图是在应用此国际标准编制架构描述时，用于描述一个“利益系统（System of Interest，或简称系统）”的一个架构的概念模型。

 

架构视图由一个或多个“架构模型（Architecture Model）”组成。架构模型使用规定好的建模规范，这些规范由管理该模型的模型种类指定。在一个架构描述中，一个架构模型可以是一个或以上架构视图的一部分。

每个架构模型应包括：

（1）组织和（或）项目指定的版本标识。

（2）所管理模型的种类标识。

（3）架构描述应记录其架构模型和架构视图中任何已知的不一致之处。

 

架构描述应包括对其架构模型和架构视图的一致性分析。

 

 

一个系统的利益相关者对系统和与其有关的问题进行关注。

一个关注点可能由一个或多个利益相关者持有。

在整个生命周期中，对系统的需求和要求以及实施和运行的考虑等都可能成为关注点。

关注点可以通过多种形式表现出来，例如与一个或多个利益相关者的需求、目标、期望、责任、要求、设计约束、假设、依赖性、质量属性、架构决策、风险或其他与系统有关的问题有关。

 

架构描述应确定系统利益相关者，这些利益相关者的关切被认为对相关系统的架构至关重要。架构描述中应考虑并在适用时确定以下利益相关者：

 

系统的用户；

系统的操作者；

系统的获取者；

系统的所有者；

系统的供应商；

系统的开发者；

系统的建设者；

系统的维护者。

 

 

 

体系结构说明应确定被认为对有关系统的体系结构至关重要的关注点。架构描述中应考虑并在适用的情况下确定以下关注点：

    （1）系统的目的。

    （2）体系结构对实现系统目的的适用性。

    （3）构建和部署系统的可行性。

    （4）系统在整个生命周期内对利益相关者的潜在风险和影响。

    （5）系统的可维护性和可演变性。

 

 

通读下来发现，此国际标准定义的架构标准属于企业EA架构，对架构师的理解也是企业EA架构师。感兴趣的朋友可以通读中文翻译版，下载地址：关注EA之家公众号并回复：ISO

 

 

02

—

 

 

Togaf对企业架构的解释 

 

 

Togaf对“企业架构”的理解：

在“企业架构”上下文中，“企业”这一术语不仅可用来表示整个企业（包含所有信息和技术服务、流程和基础设施），而且可以表示企业内的一个特定领域。在这两个情形中，架构可以跨越多个系统和企业内的多个职能群组。“企业”术语本身的演化性经常导致困惑。当今的扩展企业常常包含伙伴、供应商和客户。如果目标是集成扩展型的企业，那么企业就该包含伙伴、供应商和客户，以及内部的业务单位。业务运营模型的概念对决定组织内企业架构的范围和本质十分有用。大型公司和政府部门可以由多个企业组成，并且可以开发及维护一些独立的企业架构来应对每一个企业的运营。但是，这些企业的信息系统经常存在许多共同之处，因此，使用一个共同的架构框架通常会有大的潜在收获。例如，一个共同的框架能提供架构储藏库作为开发基础，提供可重用模型、设计以及基线数据。

 

 

 

企业架构可以分为两大部分：业务架构和IT架构，大部分企业架构方法都是从IT架构发展而来的。

（1）业务架构：是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布、业务流程设计等内容。

（2）IT架构：指导IT投资和设计决策的IT框架，是建立企业信息系统的综合蓝图，包括数据架构、应用架构和技术架构三部分。

 

在业务战略方面，可使用Togaf及其架构开发方法论来定义企业愿景/使命，目标/目的/驱动力，组织架构，职能及角色。

在IT战略方面，Togaf及ADM详细描述了如何定义业务架构，数据架构，应用架构，和技术架构，是IT战略规划的最佳实践指引。

 

企业架构是承接企业业务战略与IT战略之间的桥梁与标准接口，是企业信息化规划的核心。

 

显然Togaf定义的架构师与国标ISO/IEC/IEEE42010定义的架构师同样是企业EA架构师。

 

 

 

 

03

—

 

 

“微软”架构师分类 

 

 

网传“微软”架构师分类，原因是我一直没有找到微软的官方定义出处，我感觉此定义可能“国产化”居多一些，但划分的仍然合理，不妨碍我们讨论架构师分类问题。

 

“微软”架构师分类参考：

 

• 企业架构师EA(Enterprise Architect)

• 基础结构架构师IA(Infrastructure Architect)

• 特定技术架构TSA(Technology-Specific Architect)

• 解决方案架构师SA (Solution Architect)。

 

Togaf架构及ISO/IEC/IEEE 42010国际标准中描述的架构师即是企业EA架构师。负责将企业战略分解成业务、数据、应用、技术、安全5大架构体系，指明企业信息化方向。

IA的工作就是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件，这些都是一个技术型公司传承下来的最宝贵的财富之一，也是对架构师的最传统理解。

TSA特定技术架构师，他们主要从事类似安全架构、存储架构、或新技术等专项技术的架构工作。

SA的工作则专于解决方案的规划和设计，一般用于售前架构人员与客户沟通。

 

 

 

软件架构师：TSA+IA，是程序员最容易突破，也是对架构师最朴素的理解。

系统架构师：SA+TSA，更着力于综合运用已有的产品和技术，来实现客户期望的需求。

软件架构师主要工作：

（1）确认需求

（2）系统分解

（3）技术选型

比如：数据库ORM框架采用Hibernate还是Mybatis？需要不需要采用MVC或者Spring等轻量级的框架？前端采用Vue还是其他方式？类似的工作，都需要在这个阶段提出，并进行评估。

架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。

（4）制定技术规格说明

　　架构师与开发者沟通的最重要的形式是技术规格说明书，它可以是UML视图、Word文档，Visio文件等各种表现形式。通过架构师提供的技术规格说明书，保证开发者可以从不同角度去观察、理解各自承担的子系统或者模块。

 

 

 

 

04

—

 

 

综合理解 

 

 

Togaf定义的架构师及国标ISO/IEC/IEEE42010定义的架构师与“微软”架构师分类结合起来看：

 

SA：最关注战略及业务满足度。【售前架构】

EA：战略与技术之间的桥梁，负责架构规划与治理，含业务、数据、应用、技术四大基础架构，确保规划架构与落地实施的一致性。【企业架构】

IA：负责技术框架搭建、技术选型等。【技术架构】

TSA：专业领域架构师，如安全等。随着新技术的发展，出现如大数据架构师、区块链架构师等。【技术架构】

 

 

随着spring体系的不断成熟，以前需要架构师搭建的框架大部分由spring体系提供了成熟的一套架构标准，普通技术选型也趋向统一。

在新技术领域如云、大数据、区块链等涌现出一批架构师。

随着数字化转型的浪潮，企业也缴纳了足够的“智商税”，不再相信咨询公司的“忽悠”，而更加重视企业EA架构师。

 

对企业应用软件来讲

IA架构师正在与ISA架构师融合，技术框架有且只有稳定的一套，技术组件有但可供选择的也就如此，尤其是在上云之后，如阿里云提供了一整套微服务上云治理体系、技术组件体系、数据中台体系，甚至devops的能力都已经囊括。

SA架构师与EA架构师融合，以我在企业应用的直接感受是：企业的“智商税”已经交够了，不在相信传统咨询公司或“皮包公司”的“忽悠”，PPT画的再好落地不成功，用户体验总是差的，企业开始重视真正落地的规划，“表里如一”的信息化系统。另外数字化转型的大趋势已经来临，同样会倒逼企业做好信息化规划。

 

 

企业架构治理委员会是确保规划与落地的中间桥梁，其作用简单归纳了四点：

作用一：确保架构合规性。【面向利益相关者-如甲方客户】

确保甲方认可架构规划，达成对未来目标的一致性。

作用二：确保架构与实际落地的一致性。【架构规范实际开发】

作用三：在实践过程中依据原则及策略更新架构体系。【实际开发反哺架构】

实际开发过程中反映出架构不合理的地方，需要不断治理架构体系，并与利益相关者达成一致。

作用四：提供架构变更决策支撑。

 

备注：有小部分架构师定义内容来源互联网，未能原作者了，特此说明。